Change:
Update of ekr's PR . Details: Initial offers/answers have no candidates Add canTrickle property Add text regarding a=end-of-candidates Clarify dummy/null address/port stuff
lgtm
NAME 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 don'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 JSEP 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 canTrickle=false
Agreed
Sounds good!
Fixed by

Discussion:
4.1.9. <ins> [[TODO: Revise if the W3C API uses different stuff here.]] The canTrickle property indicates whether the remote side supports receiving trickled candidates.  There are three potential values: 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. SDP has been received from the other side indicating that it can support trickle. SDP has been received from the other side indicating that it cannot support trickle. 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. 4.1.10. </ins> The setConfiguration method allows the global configuration of the PeerConnection, which was initially set by constructor parameters, to be changed during the session.  The effects of this method call

may result in a change to media state if it results in connectivity being established. <del> 4.1.10. </del> <ins> 4.1.11. </ins> The addIceCandidate method provides a remote candidate to the ICE Agent, which, if parsed successfully, will be added to the remote

followed: The port value is set to the port of the default ICE candidate for <del> 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. </del> <ins> 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. </ins> To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8. <ins> The m= line MUST be followed immediately by a "c=" line, as specified in RFC4566, Section 5.7.  Again, as no candidates have yet been gathered, the "c=" line must contain the "dummy" value "IN IP6 ::", as defined in I-D.ietf-mmusic-trickle-ice, Section 5.1. </ins> Each m= section MUST include the following attribute lines: An "a=mid" line, as specified in RFC5888, Section 4.  When

An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4. <del> For each candidate that has been gathered during the most recent gathering phase, an "a=candidate" line, as specified in RFC5245, Section 4.3., paragraph 3. For the current default candidate, a "c=" line, as specified in RFC5245, Section 4.3., paragraph 6.  If no candidates have been gathered yet, the default candidate should be set to the 'null' value defined in I-D.ietf-mmusic-trickle-ice, Section 5.1. </del> An "a=fingerprint" line, as specified in RFC4572, Section 5; the algorithm used for the fingerprint MUST match that used in the certificate signature.

If the BUNDLE policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the BUNDLE <del> policy is set to "default", and this is not the first m= section </del> <ins> policy is set to "balanced", and this is not the first m= section </ins> for this media type, an "a=bundle-only" line. Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" <del> 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. </del> <ins> and the <proto> field MUST be set to "DTLS/SCTP" [TODO: fix this in profile PR], 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.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </ins> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and

The "s=" and "t=" lines MUST stay the same. <ins> Each "m=" and c=" line MUST be filled in with the port and address of the default candidate for the m= section, as described in RFC5245, Section 4.3.  If no candidates have yet been gathered, the dummy values MUST be used, as described above.  [TODO: update profile UDP/TCP per default candidate] </ins> Each "a=mid" line MUST stay the same. Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless

STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified. <ins> 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. </ins> For MediaStreamTracks that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same.

further processing for this m= section can be skipped. Provided that is not the case, each m= section in the answer should <del> then be generated as specified in RFC3264, Section 6.1.  Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/ SAVPF".  If the offer supports BUNDLE, all m= sections to be BUNDLEd must use the same ICE credentials and candidates; all m= sections not being BUNDLEd must use unique ICE credentials and candidates.  Each m= section MUST include the following: </del> <ins> then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed: 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. Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF". The m= line MUST be followed immediately by a "c=" line, as specified in RFC4566, Section 5.7.  Again, as no candidates have yet been gathered, the "c=" line must contain the "dummy" value "IN IP6 ::", as defined in I-D.ietf-mmusic-trickle-ice, Section 5.1. If the offer supports BUNDLE, all m= sections to be BUNDLEd must use the same ICE credentials and candidates; all m= sections not being BUNDLEd must use unique ICE credentials and candidates.  Each m= section MUST include the following: </ins> If present in the offer, an "a=mid" line, as specified in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the

options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4. <del> For each candidate that has been gathered during the most recent gathering phase, an "a=candidate" line, as specified in RFC5245, Section 4.3., paragraph 3. For the current default candidate, a "c=" line, as specified in RFC5245, Section 4.3., paragraph 6.  If no candidates have been gathered yet, the default candidate should be set to the 'null' value defined in I-D.ietf-mmusic-trickle-ice, Section 5.1. </del> An "a=fingerprint" line, as specified in RFC4572, Section 5; the algorithm used for the fingerprint MUST match that used in the certificate signature.

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 <del> "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. </del> <ins> "application" and the <proto> field MUST be set to "DTLS/SCTP" [TODO: fix this when fixing profiles], 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.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </ins> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and