Draft: draft-ietf-rtcweb-jsep

Commentary: Update of ekr 's PR . Details : Initial offers / answers have no candidates   property Add text regarding a = end - of - candidates Clarify dummy / null address / port stuff 
 lgtm 
 can you review this before Friday ? 
 I 'll try and carefully read this tomorrow morning but I 'm running out of time for today . It looked good on my quick skim of it but I want to read it carefully but do n't expect to have issues with it . 
 On this morning 's Editor 's Call we discussed the topic of what trickle indicators should appear in the SDP . The trickle draft prescribes two indicators : a = ice - options : trickle a = end - of - candidates However , as agreed at the interim , JSEP agents always do trickle and just expose a canTrickle property . Accordingly , the conclusion was to interpret a = ice - options : trickle as " I can do trickle " ( this is consistent with half - trickle ) and thus  agents always send it , even if canTrickle = false . So , we should insert a = end - of - candidates when gathering is done to mean " I am done trickling " . This means that JSEP agents will generate a = ice - options : trickle in response even to offers which do not contain it . However , offerers should already ignore that . As before , it 's up to the app to wait for all the candidates before sending the offer if  = false 
 Agreed 
 Sounds good ! 
 Fixed by
Paragraph (version B):
No SDP has been received from the other side, so it is not known
if it can handle trickle.  This is the initial value before
setRemoteDescription() is called.
Paragraph (version B):
SDP has been received from the other side indicating that it can
support trickle.
Paragraph (version B):
SDP has been received from the other side indicating that it
cannot support trickle.
Paragraph (version B):
As described in sec.ice-candidate-trickling, JSEP implementations
always provide candidates to the application individually, consistent
with what is needed for Trickle ICE.  However, applications can use
the canTrickle property to determine whether they can actually do
Trickle ICE, i.e. safely send an initial offer or answer followed
later by candidates as they are gathered.  As "true" is the only
value that definitively indicates remote Trickle ICE support, an
application which compares canTrickle against "true" will by default
attempt Half Trickle on initial offers and Full Trickle on subsequent
interactions with a Trickle ICE-compatible agent.
Paragraph (version A):
The port value is set to the port of the default ICE candidate for
this m= section; if this m= section is not being bundled into
another m= section, the port value MUST be unique.  If no
candidates have yet been gathered, and a 'null' port value is
being used, as indicated in I-D.ietf-mmusic-trickle-ice,
Section 5.1., this port MUST still be unique.
Paragraph (version B):
The port value is set to the port of the default ICE candidate for
this m= section, but given that no candidates have yet been
gathered, the "dummy" port value of 9 (Discard) MUST be used, as
indicated in I-D.ietf-mmusic-trickle-ice, Section 5.1.
Paragraph (version A):
If the BUNDLE policy for this PeerConnection is set to "max-
bundle", and this is not the first m= section, or the BUNDLE
policy is set to "default", and this is not the first m= section
for this media type, an "a=bundle-only" line.
Paragraph (version A):
Lastly, if a data channel has been created, a m= section MUST be
generated for data.  The <media> field MUST be set to "application"
and the <proto> field MUST be set to "DTLS/SCTP", as specified in I-
D.ietf-mmusic-sctp-sdp, Section 3; the "fmt" value MUST be set to the
SCTP port number, as specified in Section 4.1.
Paragraph (version B):
If the BUNDLE policy for this PeerConnection is set to "max-
bundle", and this is not the first m= section, or the BUNDLE
policy is set to "balanced", and this is not the first m= section
for this media type, an "a=bundle-only" line.
Paragraph (version B):
Within each m= section, for each candidate that has been gathered
during the most recent gathering phase (see sec.ice-gather-
overview), an "a=candidate" line MUST be added, as specified in
RFC5245, Section 4.3., paragraph 3.  If candidate gathering for
the section has completed, an "a=end-of-candidates" attribute MUST
be added, as described in I-D.ietf-mmusic-trickle-ice,
Section 9.3.
Paragraph (version B):
The port value would normally be set to the port of the default
ICE candidate for this m= section, but given that no candidates
have yet been gathered, the "dummy" port value of 9 (Discard) MUST
be used, as indicated in I-D.ietf-mmusic-trickle-ice, Section 5.1.
Paragraph (version B):
Because use of DTLS is mandatory, the <proto> field MUST be set to
"UDP/TLS/RTP/SAVPF".
Paragraph (version A):
If a data channel m= section has been offered, a m= section MUST also
be generated for data.  The <media> field MUST be set to
"application" and the <proto> field MUST be set to "DTLS/SCTP", as
specified in I-D.ietf-mmusic-sctp-sdp, Section 3; the "fmt" value
MUST be set to the SCTP port number, as specified in Section 4.1.