4.1.9.  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>  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>  To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8.  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>  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>  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.  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.  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>  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>  Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and

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

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.  <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  <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.  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  <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"  <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  <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.  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  <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


m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials.  Each "a=setup" line MUST use an "active" or "passive" role value consistent with the existing DTLS association, if the association is being continued by the offerer. limits specified in RFC5245, Section 15.4. tls-id value, which MUST be set according to I-D.ietf-mmusic- <del> dtls-sdp, Section 5.  If this is a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values.  If this is an answer, the tls-id value, if present, MUST be the same as in the offer. </del>  DTLS setup value, which MUST be set according to the rules specified in RFC5763, Section 5 and MUST be consistent with the new ICE credentials, an error MUST be generated.  If an ICE restart is performed without a change in tls-id or fingerprint, then the same DTLS connection is continued over the new ICE <del> channel. </del>  If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any

In section 5.10, the text that says to tear down the old TLS connections seems like it needs a tweek. For the case of a PR_ANS, I would expect it to not get torn down until the resources are freed when the ANS happens.
See: URL
We had a call to discuss and I think reached resolution on the SDP issue. I will prepare a PR and send to the list for approval. Separately we need to close on tls-id size, but that need not hold JSEP if we are willing to have the examples use the longer size (which we all agree is permitted)
Update: we had a call to discuss this and I think have resolution on the SDP semantics. I will prepare a PR for that and send to lists. Separately, we have to discuss the S
JSEP says: values. If this is an answer, the tls-id value, if present, MUST be the same as in the offer. But tls-ids are independently generated on each side.
Examples/example generator will also need to get tweaked

m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <ins> Each "a=tls-id" line MUST stay the same unless the offerer's "a=tls-id" line changed, in which case a new "a=tls-id" value MUST be created, as described in I-D.ietf-mmusic-dtls-sdp, Section 5.2. </ins> Each "a=setup" line MUST use an "active" or "passive" role value consistent with the existing DTLS association, if the association is being continued by the offerer. limits specified in RFC5245, Section 15.4. tls-id value, which MUST be set according to I-D.ietf-mmusic-  <ins> dtls-sdp, Section 5.  If this is a re-offer or a response to a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values. </ins> DTLS setup value, which MUST be set according to the rules specified in RFC5763, Section 5 and MUST be consistent with the new ICE credentials, an error MUST be generated.  If an ICE restart is performed without a change in tls-id or fingerprint, then the same DTLS connection is continued over the new ICE  <ins> channel.  Note that although JSEP requires that answerers change the tls-id value if and only if the offerer does, non-JSEP answerers are permitted to change the tls-id as long as the offer contained an ICE restart.  Thus, JSEP implementations which process DTLS data prior to receiving an answer MUST be prepared to receive either a ClientHello or data from the previous DTLS connection. </ins> If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any


resolution when needed, or may be locked to a specific output resolution. <del> For each encoding being produced by the RtpSender, the following rules are applied to determine what should be transmitted: First, the most suitable "a=imageattr recv" attribute is selected. This is performed by taking the attribute with the highest "q=" value from the set of attributes that reference the media format that has been selected for the specified encoding.  If multiple attributes have the same "q=" value, the one that appears first in the m= section is used.  Note that while JSEP endpoints will include at most one "a=imageattr recv" attribute per media format, JSEP endpoints may receive session descriptions from non-JSEP endpoints with m= sections that contain multiple such attributes. If there is an applicable "a=imageattr recv" attribute for the encoding, the limits from the attribute are then compared to the encoder resolution.  Only the specific limits mentioned below are </del>  considered; any other values, such as picture aspect ratio, MUST be ignored.  When considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the If the attribute includes a "sar=" (sample aspect ratio) value set to something other than "1.0", indicating the receiver wants to <del> receive non-square pixels, this cannot be satisfied and the sender MUST NOT transmit the encoding. </del>  If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its picture aspect ratio of the encoding.  For example, if the encoder resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If <del> downscaling cannot be applied, the encoding MUST NOT be transmitted, and an error SHOULD be raised to the application. </del>  If the encoder resolution is less than the minimum size permitted <del> by the attribute, the encoding MUST NOT be transmitted, and an error SHOULD be raised to the application; the encoder MUST NOT apply upscaling.  JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. </del>  3.7.

Still LGTM
NAME we have consensus on this from the editor team, but please comment here if you see anything else and I'll take a look.
Thanks, I think it looks good in general. Regarding the "par" question NAME raised the current text promotes some picture over correct picture aspect ratio. Having a bullet that one selects one that has PAR that the sending side supports to send can result in more optimal choice but also may result in a slight increase in blocked video where a stretched video may be shown instead.

resolution when needed, or may be locked to a specific output resolution.  <ins> For each encoding being produced by the RtpSender, the set of "a=imageattr recv" attributes in the corresponding m= section of the remote description is processed to determine what should be transmitted.  Only attributes that reference the media format selected for the encoding are considered; each such attribute is evaluated individually, starting with the attribute with the highest "q=" value.  If multiple attributes have the same "q=" value, they are evaluated in the order they appear in their containing m= section.  Note that while JSEP endpoints will include at most one "a=imageattr recv" attribute per media format, JSEP endpoints may receive session descriptions from non-JSEP endpoints with m= sections that contain multiple such attributes. For each "a=imageattr recv" attribute, the following rules are applied.  If this processing is successful, the encoding is transmitted accordingly, and no further attributes are considered for that encoding.  Otherwise, the next attribute is evaluated, in the aforementioned order.  If none of the supplied attributes can be processed successfully, the encoding MUST NOT be transmitted, and an error SHOULD be raised to the application. The limits from the attribute are compared to the encoder resolution.  Only the specific limits mentioned below are </ins> considered; any other values, such as picture aspect ratio, MUST be ignored.  When considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the If the attribute includes a "sar=" (sample aspect ratio) value set to something other than "1.0", indicating the receiver wants to  <ins> receive non-square pixels, this cannot be satisfied and the attribute MUST NOT be used. </ins> If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its picture aspect ratio of the encoding.  For example, if the encoder resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If  <ins> downscaling cannot be applied, the attribute MUST NOT be used. </ins> If the encoder resolution is less than the minimum size permitted  <ins> by the attribute, the attribute MUST NOT be used; the encoder MUST NOT apply upscaling.  JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. If the encoder resolution is within the maximum and minimum sizes, no action is needed. </ins> 3.7.


The next step is to generate m= sections, as specified in RFC4566, Section 5.14.  An m= section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped <del> RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection. </del>  For each m= section generated for an RtpTransceiver, establish a mapping between the transceiver and the index of the generated m=

NAME as Justin points out, 3264 explicitly authorizes this.
i'm a bit late but... without this, the following sequence of events is always going to happen: createOffer setLocalDescription onicecandidate(null) / icegatheringstatechange(complete) Executing this snippet in Chrome never shows a candidate. Is that the intended behaviour? Also the ice gathering state stays "new"? My confusion about this is probably related to ;-)
I guess if we need to allow empty SPDs (no m-sections) then ICE related events should fire right away as they know that nothing is going to happen any way.
NAME I don't see why any events need to fire, since ICE gathering never starts in the first place and there are no in that case.
I failed to find any text in webrtc-pc or JSEP which indicates that the createOffer() call should fail if no RtpTransceiver or data channel has been added to a PeerConnection. Webrtc-pc contains the following: But section does not seem to contain any wording indicating to treat the absence of any RtpTransceiver and DataChannel as such an failure. I think such a scenario should be treated as a failure, as I fail to see any value in generating an empty offer.
Good observation. Personally, I'm inclined to allow this, unless it's forbidden by 3264 - we would just generate the session-level values with no m= sections.
3264 indicates that this is OK: The offer will contain zero or more media streams (each media stream is described by an "m=" line and its associated attributes). Zero media streams implies that the offerer wishes to communicate, but that the streams for the session will be added at a later time through a modified offer. I think we should explicitly mention that this is allowed, but otherwise take no action.

The next step is to generate m= sections, as specified in RFC4566, Section 5.14.  An m= section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped  <ins> RtpTransceivers; this is done in the order the RtpTransceivers were added to the PeerConnection.  If there are no such RtpTransceivers, no m= sections are generated; more can be added later, as discussed in RFC3264, Section 5. </ins> For each m= section generated for an RtpTransceiver, establish a mapping between the transceiver and the index of the generated m=


If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its resolution, the encoder SHOULD apply downscaling in order to <del> satisfy the limits, although the downscaling MUST NOT change the picture aspect ratio of the encoding.  For example, if the encoder resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If downscaling cannot be applied, the attribute MUST NOT be used. </del>  If the encoder resolution is less than the minimum size permitted by the attribute, the attribute MUST NOT be used; the encoder MUST

LGTM.
In spite of what was said at the W3C WebRTC WG virtual meeting yesterday I think the aspect ratio preservation can be an issue also in context of . Just to take as example that the video resolution of the track is 595 by 753 (e.g. capturing a part of the screen) and has limited what can be transmitted to 480 by 640. Scaling according to JSEP section 3.6 (if I read right) gives a transmission resolution of 480 by 607.4621.. but since we can't transmit fractional pixels we would transmit 480 by 607 and have a slight aspect ratio mismatch. The spec should clarify what to do in situations like this.
OK, perhaps then we change this text: the encoder SHOULD apply downscaling in order to satisfy the limits, although the downscaling MUST NOT change the picture aspect ratio of the encoding. to allow for rounding.
Makes sense to me.
LGTM

If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its resolution, the encoder SHOULD apply downscaling in order to  <ins> satisfy the limits.  Downscaling MUST NOT change the picture aspect ratio of the encoding, ignoring any trivial differences due to rounding.  For example, if the encoder resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If downscaling cannot be applied, the attribute MUST NOT be used. </ins> If the encoder resolution is less than the minimum size permitted by the attribute, the attribute MUST NOT be used; the encoder MUST


5.2.3.1. If the "OfferToReceiveAudio" option is specified, with an integer <del> value of N, the offer MUST include N non-rejected m= sections with media type "audio", even if fewer than N audio MediaStreamTracks have been added to the PeerConnection.  This allows the offerer to receive audio, including multiple independent streams, even when not sending it; accordingly, the directional attribute on the audio m= sections without associated MediaStreamTracks MUST be set to recvonly.  If this option is specified in the case where at least N audio MediaStreamTracks have already been added to the PeerConnection, or N non-rejected m= sections with media type "audio" would otherwise be generated, it has no effect.  For backwards compatibility with pre- standard versions of this specification, a value of "true" is interpreted as equivalent to N=1. </del>  5.2.3.2. If the "OfferToReceiveVideo" option is specified, with an integer <del> value of N, the offer MUST include N non-rejected m= sections with media type "video", even if fewer than N video MediaStreamTracks have been added to the PeerConnection.  This allows the offerer to receive video, including multiple independent streams, even when not sending it; accordingly, the directional attribute on the video m= sections without associated MediaStreamTracks MUST be set to recvonly.  If this option is specified in the case where at least N video MediaStreamTracks have already been added to the PeerConnection, or N non-rejected m= sections with media type "video" would otherwise be generated, it has no effect.  For backwards compatibility with pre- standard versions of this specification, a value of "true" is interpreted as equivalent to N=1. </del>  5.2.3.3.  If the "VoiceActivityDetection" option is specified, with a value of "true", the offer MUST indicate support for silence suppression in the audio it receives by including comfort noise ("CN") codecs for receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. <del> 5.2.3.4. If the "IceRestart" option is specified, with a value of "true", the offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in RFC5245, Section 9.1.1.1.  If this option is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd are already generated).  Similarly, if the ICE configuration has changed, this option has no effect, since new ufrag and pwd attributes will be generated automatically.  This option is primarily useful for reestablishing connectivity in cases where failures are detected by the application. </del> 5.3. When createAnswer is called, a new SDP description must be created 5.3.3.  5.4. 5.5.

ORTA/ORTV can now be set to a number smaller than the number of MSTs, leading to a=sendonly settings. Also allowed VAD to work in CreateAnswer. ()
LGTM
NAME do you have any remaining concerns?
lgtm
LGTM
Per e-mail, I feel like the text around how to not change extant m= sections is confusing. Ignoring recycling, if we have N mediastreams of which O are old and are sendrecv and someone asks for offerToReceive=M, then we end up with: if O >= M: O sendrecv m= lines N - O sendonly m= lines if O < M: M sendrecv m= lines N - M sendonly m= lines I am fine with that, but I feel like the text may not make it entirely clear.

5.2.3.1. If the "OfferToReceiveAudio" option is specified, with an integer  <ins> value of N, and M audio MediaStreamTracks have been added to the PeerConnection, the offer MUST include N non-rejected m= sections with media type "audio", even if N is greater than M.  This allows the offerer to receive audio, including multiple independent streams, even when not sending it; accordingly, the directional attribute on the N-M audio m= sections without associated MediaStreamTracks MUST be set to recvonly. If N is set to a value less than M, the offer MUST mark the m= sections associated with the M-N most recently added (since the last setLocalDescription) MediaStreamTracks as sendonly.  This allows the offerer to indicate that it does not want to receive audio on some or all of its newly created streams.  For m= sections that have previously been negotiated, this setting has no effect.  [TODO: refer to RTCRtpSender in the future] For backwards compatibility with pre-standard versions of this specification, a value of "true" is interpreted as equivalent to N=1, and "false" as N=0. </ins> 5.2.3.2. If the "OfferToReceiveVideo" option is specified, with an integer  <ins> value of N, and M video MediaStreamTracks have been added to the PeerConnection, the offer MUST include N non-rejected m= sections with media type "video", even if N is greater than M.  This allows the offerer to receive video, including multiple independent streams, even when not sending it; accordingly, the directional attribute on the N-M video m= sections without associated MediaStreamTracks MUST be set to recvonly. If N is set to a value less than M, the offer MUST mark the m= sections associated with the M-N most recently added (since the last setLocalDescription) MediaStreamTracks as sendonly.  This allows the offerer to indicate that it does not want to receive video on some or all of its newly created streams.  For m= sections that have previously been negotiated, this setting has no effect.  [TODO: refer to RTCRtpSender in the future] For backwards compatibility with pre-standard versions of this specification, a value of "true" is interpreted as equivalent to N=1, and "false" as N=0. </ins> 5.2.3.3. <ins> If the "IceRestart" option is specified, with a value of "true", the offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in RFC5245, Section 9.1.1.1.  If this option is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd are already generated).  Similarly, if the ICE configuration has changed, this option has no effect, since new ufrag and pwd attributes will be generated automatically.  This option is primarily useful for reestablishing connectivity in cases where failures are detected by the application. 5.2.3.4. </ins> If the "VoiceActivityDetection" option is specified, with a value of "true", the offer MUST indicate support for silence suppression in the audio it receives by including comfort noise ("CN") codecs for receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm.  5.3. When createAnswer is called, a new SDP description must be created 5.3.3. <ins> The createOffer method takes as a parameter an RTCAnswerOptions object.  Special processing is performed when generating a SDP description if the following constraints are present. 5.3.3.1. Handling of the "VoiceActivityDetection" option in answers is the same as is indicated for offers in sec.voiceactivitydetection1. </ins> 5.4. 5.5.


security considerations for this document. While formally the JSEP interface is an API, it is better to think of <del> it is an Internet protocol, with the application JavaScript being </del>  untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious

I'm sure the RFC editor would have caught this nit: While formally the JSEP interface is an API, it is better to think of it is an Internet protocol s/is an Internet/as an Internet/

security considerations for this document. While formally the JSEP interface is an API, it is better to think of  <ins> it as an Internet protocol, with the application JavaScript being </ins> untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious


section for this media type or in the same bundle group as the first m= section for this media type.  Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed:

If an answerer rejects the "offerer tagged" m= section (the one listed first in "a=group:BUNDLE"), the BUNDLE spec requires rejecting all m= sections in the BUNDLE group. This means that stopping one transceiver between setting an offer and creating an answer may potentially cause multiple m= sections to be rejected. See: URL

section for this media type or in the same bundle group as the first m= section for this media type. <ins> This m= section is in a bundle group, and the group's offerer tagged m= section is being rejected due to one of the above reasons.  This requires all m= sections in the bundle group to be rejected, as specified in I-D.ietf-mmusic-sdp-bundle-negotiation, Section 7.3.3. </ins> Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed:


For each MediaStream that was associated with the transceiver when it was created via addTrack or addTransceiver, an "a=msid" <del> line, as specified in I-D.ietf-mmusic-msid, Section 2.  If a MediaStreamTrack is attached to the transceiver's RtpSender, the "a=msid" lines MUST use that track's ID.  If no MediaStreamTrack is attached, a valid ID MUST be generated, in the same way that the implementation generates IDs for local tracks. If no MediaStream is associated with the transceiver, a single "a=msid" line with the special value "-" in place of the MediaStream ID, as specified in I-D.ietf-mmusic-msid, Section 3.  The track ID MUST be selected as described above. </del>  If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more For each MediaStream that was associated with the transceiver when it was created via addTrack or addTransceiver, an "a=msid" <del> line, as specified in I-D.ietf-mmusic-msid, Section 2.  If a MediaStreamTrack is attached to the transceiver's RtpSender, the "a=msid" lines MUST use that track's ID.  If no MediaStreamTrack is attached, a valid ID MUST be generated, in the same way that the implementation generates IDs for local tracks. If no MediaStream is associated with the transceiver, a single "a=msid" line with the special value "-" in place of the MediaStream ID, as specified in I-D.ietf-mmusic-msid, Section 3.  The track ID MUST be selected as described above. </del>  Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or this information is superfluous when using ICE. If present, "a=msid" attributes MUST be parsed as specified in I- <del> D.ietf-mmusic-msid, Section 3.2, and their values stored. </del>  Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.

And also URL Since introducing transceivers, replaceTrack, early media, etc., the definition of a MediaStreamTrack has changed and track ID signaling has become somewhat pointless. In many cases, "URL" on one side will not match "URL" on the other side; endpoints must use MIDs or m= section indices or some other means to identify which track is which. Thus this PR just removes track ID signaling altogether and the lingering problems it causes.
Now that we only use the stream ID, "a=msid:{streamId}", I just want to verify that I understand this correctly: If I do addTrack(track) without any streams, "a=msid" is completely omitted. If I do addTrack(track, stream1, stream2, ...) with multiple streams, I get one "a=msid" line per stream. Is this correct?
Or is "a=msid" mandatory in which case I would have to do "a=msid:-" in the case of no stream?
FWIW, I missed this discussion, and do not agree with the change. It is a significant, breaking protocol change introduced very late in the process, and has not (AFAIK) been discussed on the mailing list. So by IETF consensus rules, there's no basis for ruling that the change has consensus in the WG.
Before this change, "a=msid" was broken e.g. URL and URL The track ID is only surfaced to JavaScript if the answerer does not have any transceivers to match with the offer. Relying on "mid" or MediaStream IDs are clearly the better alternative, because they have a reliable behavior that works not just in edge-cases and are not misleading in all other cases. An argument can be made for keeping track IDs, but I suspect the argument would be for backwards compatibility reasons or for people who want to parse SDP to figure out ID information (information which, by the way, would have been easier to carry through streams). In either case, JSEP and MSID specs . As I recall from testing, while Chrome surfaces track IDs in some edge-cases, Firefox does not. If we can survive the switch to Unified Plan without track ID related breakages, as Firefox did, then I see little reason to try to save the sinking ship that is "a=msid". This is a remnant of the track/stream way of thinking. To be discuss at TPAC. There is a slide for the issues referenced.
a=msid is still relied on to create streams with synchronized tracks -- LS groups haven't made it to any implementation afaik.
AFAIK tracks synchronization in receiver is based in RTCP CNAME rather than msid. msid is just an artifact to tell the app whether different tracks should be grouped within the same MediaStream, but that's just a hint and a unfortunate remnant of the "stream based API" that shouldn't be part of WebRTC itself.
Anyone who is sad to not be able to rely on URL could though, because of "a=msid", do this :)
NAME a=msid is not mandatory, and can be omitted if there are no streams.
discoveries when updating -msid to allow for this: omitting a=msid will lead to a default stream (legacy behavior) the way to signal that a track is no longer present is by omitting msid after it has been present so the only way to signal "one track no stream" is to send a=msid:- -msid used to allow for sending one track into multiple recipient streams.With a=msid:- it can no longer do so. PR is up. URL

For each MediaStream that was associated with the transceiver when it was created via addTrack or addTransceiver, an "a=msid"  <ins> line, as specified in I-D.ietf-mmusic-msid, Section 2, but omitting the "appdata" field. </ins> If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more For each MediaStream that was associated with the transceiver when it was created via addTrack or addTransceiver, an "a=msid"  <ins> line, as specified in I-D.ietf-mmusic-msid, Section 2, but omitting the "appdata" field. </ins> Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or this information is superfluous when using ICE. If present, "a=msid" attributes MUST be parsed as specified in I-  <ins> D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring any "appdata" field. </ins> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.


The second SDP line MUST be an "o=" line, as specified in RFC4566, Section 5.2.  The value of the <username> field SHOULD be "-". The sess-id MUST be representable by a 64-bit signed integer, and <del> the initial value MUST be less than (2**62)-1, as required by RFC3264.  It is RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the two highest bits being set to zero and the remaining 62 bits being cryptographically random. The value of the <nettype> <addrtype> <unicast-address> tuple SHOULD be set to a non-meaningful address, such as IN IP4 0.0.0.0, to prevent leaking the local address in this field.  As mentioned in RFC4566, the entire o= line needs to be unique, but selecting a random number for <sess-id> is sufficient to accomplish this. </del>  The third SDP line MUST be a "s=" line, as specified in RFC4566, Section 5.3; to match the "o=" line, a single dash SHOULD be used

Also add ip-handling reference
ping NAME NAME
NAME NAME PTAL - Barring any objections this one ought to get merged.
Also think this is uncontroversial, planning to land this next week if there are no objections.
JSEP -24 currently says: The sess-id MUST be representable by a 64-bit signed integer, and the initial value MUST be less than (262)-1, as required by [RFC3264]. It is RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the two highest bits being set to zero and the remaining 62 bits being cryptographically random. There are two problems here: RFC 3264 actually doesn't place that restriction on the sess-id, that's the restriction on the version field.Deployed code (libwebrtc) generates sess-ids that are larger than 2^62-1 Quote from RFC 3264: The offer (and answer) MUST be a valid SDP message, as defined by RFC 2327 [1], with one exception. RFC 2327 mandates that either an e or a p line is present in the SDP message. This specification relaxes that constraint; an SDP formulated for an offer/answer application MAY omit both the e and p lines. The numeric value of the session id and version in the o line MUST be representable with a 64 bit signed integer. The initial value of the version MUST be less than (262)-1, to avoid rollovers. Although the SDP specification allows for multiple session descriptions to be concatenated together into a large SDP message, an SDP message used in the offer/answer model MUST contain exactly one session description. So what's easiest to change, deployed code or JSEP?
Firefox also creates session IDs > 2^62. The restriction in JSEP looks to me like someone accidentally put the requirements from 3264 version field onto the session ID. I think this should be fixed in JSEP.
Would changing to 2^63 (and removing the citation for 3264) be sufficient? cc NAME
I think so yes. Firefox already does generate 2^63 session IDs.
I think saying 2^63 is probably wrong. Lets say that we changed it to 2^63 an something randomly choose a number very close to 2^63 then when that number got incremented a few times, it could be larger than 2^63. And do the ABNF silliness we don't have a way to represent this. We could do something like 2^63 - 1,000,000 or something if people had some sort of real concern about this extra bit.
We are talking about the session ID, which is not suppose to be incremented if I'm not mistaken. So the roll over concerns should only apply to the version.
NAME is correct. I need coffee.
PTAL at
Looks like NAME was faster then me in creating a PR. Thank you.
yeah, next time I will read the etherpad notes first :)
LGTMLGTM

The second SDP line MUST be an "o=" line, as specified in RFC4566, Section 5.2.  The value of the <username> field SHOULD be "-". The sess-id MUST be representable by a 64-bit signed integer, and  <ins> the value MUST be less than (2**63)-1.  It is RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the highest bit set to zero and the remaining 63 bits being cryptographically random.  The value of the <nettype> <addrtype> <unicast-address> tuple SHOULD be set to a non-meaningful address, such as IN IP4 0.0.0.0, to prevent leaking a local IP address in this field; this problem is discussed in I-D.ietf-rtcweb-ip- handling.  As mentioned in RFC4566, the entire o= line needs to be unique, but selecting a random number for <sess-id> is sufficient to accomplish this. </ins> The third SDP line MUST be a "s=" line, as specified in RFC4566, Section 5.3; to match the "o=" line, a single dash SHOULD be used


The application will BUNDLE all of its media streams, including data channels, on a single transport.  All streams other than the first will be marked as bundle-only.  This policy aims to minimize <del> The application will offer BUNDLE, but mark none of its streams as bundle-only.  This policy will allow all streams to be received by non-BUNDLE-aware endpoints, but require separate candidates to be gathered for each media stream. </del>  As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST

LGTM
lgtm
If you know the remote side is going to use BUNDLE and RTCP mux, it's desirable to only gather a single set of ports, since the RTCP ports won't be used. Since max-bundle is already trying to minimize port gathering, it should probably assume rtcp mux. If there is a need to keep max-bundle as is, we could also add a fourth policy, e.g. force-bundle, that differs from max-bundle in that it forces use of RTCP mux.
I think we need another one, since currently max-bundle is minimally compatible with old endpoints and if you force rtcp-mux, then you will have ann interop problem. That's what I have on my slides now. Feel free to comment.
I can go with whatever the WG decides.
WG decision is to add an additional policy. Name will be force-bundle unless someone comes up with a better one.

<ins> The application will offer BUNDLE, but mark none of its streams as bundle-only.  This policy will allow all streams to be received by non-BUNDLE-aware endpoints, but require separate candidates to be gathered for each media stream. </ins> The application will BUNDLE all of its media streams, including data channels, on a single transport.  All streams other than the first will be marked as bundle-only.  This policy aims to minimize  <ins> Similar to max-bundle, but RTCP candidates are not gathered.  This policy reduces the candidates that must be gathered to the absolute minimum, but will not be compatible with legacy endpoints that do not support RTCP mux. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST


generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its <del> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/TLS/RTP/SAVPF". </del>  In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer:

says: The string is not registered in . Presumably, this text should say .
Opened PR .
Fixed in

generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its  <ins> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". </ins> In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer:


5.1.2. For media m= sections, JSEP implementations MUST support the <del> "UDP/TLS/RTP/SAVPF" profile specified in RFC5764, and MUST indicate this profile for each media m= line they produce in an offer.  For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this profile for each data m= line they produce in an offer.  Although these profiles are formally associated with UDP, ICE can select either UDP RFC8445 or TCP RFC6544 transport depending on network conditions, even when advertising a UDP profile. </del>  Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its <del> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/TLS/RTP/SAVPF". </del>  In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer: The second SDP line MUST be an "o=" line, as specified in RFC4566, Section 5.2.  The value of the <username> field SHOULD be "-". The sess-id MUST be representable by a 64-bit signed integer, and <del> the initial value MUST be less than (2**62)-1, as required by RFC3264.  It is RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the two highest bits being set to zero and the remaining 62 bits being cryptographically random. The value of the <nettype> <addrtype> <unicast-address> tuple SHOULD be set to a non-meaningful address, such as IN IP4 0.0.0.0, to prevent leaking the local address in this field.  As mentioned in RFC4566, the entire o= line needs to be unique, but selecting a random number for <sess-id> is sufficient to accomplish this. </del>  The third SDP line MUST be a "s=" line, as specified in RFC4566, Section 5.3; to match the "o=" line, a single dash SHOULD be used line(s) MUST be generated according to the same rules as for an initial offer. <del> Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as described in I-D.ietf-mmusic-ice-sip-sdp, Section 3.2.1.2.  If ICE checking has already completed for one or more candidate pairs and a candidate pair is in active use, then that pair MUST be used, even if ICE has not yet completed.  Note that this differs from the guidance in I-D.ietf-mmusic-ice-sip-sdp, Section 3.3.4, which only refers to offers created when ICE has completed.  In each case, if no RTP candidates have yet been gathered, dummy values MUST be used, as described above. </del>  Each "a=mid" line MUST stay the same. 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 I- <del> D.ietf-mmusic-ice-sip-sdp, Section 3.2.1.2.  Note, however, that the m= line protocol need not match the default candidate, because this protocol value must instead match what was supplied in the offer, as described above. </del>  Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials If present, "a=msid" attributes MUST be parsed as specified in I- D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring <del> any "appdata" field. </del>  Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.

The main difference between this patch and is that this one says TCP should be set as the protocol any time the selected pair is TCP, whereas only sets TCP when there are only TCP candidates (a condition that currently cannot happen, IIRC).
cc NAME
NAME What happens in the following situation? Browser client is placed behind the firewall which only allows TCP connections No TURN servers are configured Client establishes connection to a server which supports ICE TCP ICE nomination completes Client browser app calls createOffer with no options (ICE restart option is not present) In this case ICE nomination is complete and the TCP candidate is nominated. No other candidates should be present in the offer.
I believe the other candidates can still be present in the updated offer, as noted in the JSEP examples section.
NAME What example specifically are you talking about? Also, please take a look at RFC 5245 section 9.1.2.2 (URL): The agent MUST include candidate attributes for candidates matching the default destination for each component of the media stream, and MUST NOT include any other candidates. And in mmusic-ice-sip-sdp Section 3.4.1.2.2 (URL): In addition, the offerer only includes SDP candidates representing the local candidates of the nominated candidate pair. The offerer MUST NOT include any other SDP candidate attributes in the subsequent offer. Does JSEP overwrites this somewhere?
example: URL JSEP seems to say that a=candidate lines MUST always be added: If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see Section 3.5.1), an "a=candidate" line MUST be added, as defined in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1. If candidate gathering for the section has completed, an "a=end-of- candidates" attribute MUST be added, as described in [I-D.ietf-ice-trickle], Section 9.3. If the m= section is bundled into another m= section, both "a=candidate" and "a=end-of- candidates" MUST be omitted.
I guess it was not immediately obvious to me if this section referrers to offers sent while ICE nomination process or when it is completed. RFC5245 and ice-sip-sdp both make a distinction between the two. The ICE nomination status in the example is also not clear. In any case, if overwriting a MUST from a referenced RFC was intentional, it should be explicit. I think I am not the only person who is confused by this right now. Also, what is the reason to keep old candidates once ICE nomination is completed? When does the browser release the unused candidates?
It wasn't intentional; it sort of assumed that renomination could occur at any time (which was my view on ICE at the time this was written), which meant you would want the additional candidates
Since this was not intentional, non-obvious, and somewhat contradicts RFC5245/RFC8445/ice-sip-sdp specifications, what do you want to do here? One way to solve this is to make this compliant with RFC8445/ice-sip-sdp, and to specify that once ICE nomination completes, only nominated candidates are kept and implementation can release other candidates. Subsequent offer after the end of ICE nomination includes only nominated candidates. If TCP candidate is a default in this case, proto should be TCP based. Another way to deal with this is to specify how JSEP nomination process is different from normal ICE. For instance ICE nomination from the browser is never considered complete, so that candidates are never released and all candidates are always included in the offer. In this case, m= and c= line can be assigned to one of the UDP candidates even if TCP candidate is the default. This way proto is always UDP based and browser based client will never generate TCP based proto. Current specification is kind of between these two points which makes it ambiguous.
My guess is that the consensus view for JSEP would be that it match 8445, and not include extra candidates. Chrome supports renomination, and would include the extra candidates accordingly, but that's not something that JSEP needs to adhere to (especially because there is no active standards-track renomination spec).
Just for my own interest, does Chrome send keep-alives and consensus checks for all candidates that it includes in subsequent offers? If not, how does Chrome check that a pair still works if it wants to renominate?
Updated this PR to incorporate the feedback regarding what candidate should be put into the m=/c= during ICE negotiation (now JSEP says to simply follow sip-sdp).

5.1.2. For media m= sections, JSEP implementations MUST support the  <ins> "UDP/TLS/RTP/SAVPF" profile specified in RFC5764 as well as the "TCP/DTLS/RTP/SAVPF" profile specified in RFC7850, and MUST indicate one of these profiles for each media m= line they produce in an offer.  For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile as well as the "TCP/DTLS/SCTP" profile, and MUST indicate one of these profiles for each data m= line they produce in an offer.  The exact profile to use is determined by the protocol associated with the current default or selected ICE candidate, as described in I-D.ietf-mmusic-ice-sip-sdp, Section 3.2.1.2. </ins> Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its  <ins> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". </ins> In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer: The second SDP line MUST be an "o=" line, as specified in RFC4566, Section 5.2.  The value of the <username> field SHOULD be "-". The sess-id MUST be representable by a 64-bit signed integer, and  <ins> the value MUST be less than (2**63)-1.  It is RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the highest bit set to zero and the remaining 63 bits being cryptographically random.  The value of the <nettype> <addrtype> <unicast-address> tuple SHOULD be set to a non-meaningful address, such as IN IP4 0.0.0.0, to prevent leaking a local IP address in this field; this problem is discussed in I-D.ietf-rtcweb-ip- handling.  As mentioned in RFC4566, the entire o= line needs to be unique, but selecting a random number for <sess-id> is sufficient to accomplish this. </ins> The third SDP line MUST be a "s=" line, as specified in RFC4566, Section 5.3; to match the "o=" line, a single dash SHOULD be used line(s) MUST be generated according to the same rules as for an initial offer.  <ins> Each "m=" and c=" line MUST be filled in with the port, relevant RTP profile, and address of the default candidate for the m= section, as described in I-D.ietf-mmusic-ice-sip-sdp, Section 3.2.1.2, and clarified in sec.profile-names.  If no RTP candidates have yet been gathered, dummy values MUST still be used, as described above. </ins> Each "a=mid" line MUST stay the same. 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 I-  <ins> D.ietf-mmusic-ice-sip-sdp, Section 3.2.1.2.  Note that in certain cases, the m= line protocol may not match that of the default candidate, because the m= line protocol value MUST match what was supplied in the offer, as described above. </ins> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials If present, "a=msid" attributes MUST be parsed as specified in I- D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring  <ins> any "appdata" field.  If no "a=msid" attributes are present, a random msid-id value is generated for a "default" MediaStream for the session, if not already present, and this value is stored. </ins> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.


An "a=sendrecv" line, as specified in RFC3264, Section 5.1. For each supported codec, "a=rtpmap" and "a=fmtp" lines, as <del> specified in RFC4566, Section 6.  For audio, the codecs specified in I-D.ietf-rtcweb-audio, Section 3, MUST be be supported. </del>  If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and <del> RFC3264, Section 6.1.  For audio, the codecs specified in I- D.ietf-rtcweb-audio, Section 3, MUST be supported.  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </del>  If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the

lgtm with justin's comments.
Ping on this
overall this LG for consistency with the surrounding text, I would change the usage of "[XXXX] (see Section 3)" to "[XXXX], Section 3"

An "a=sendrecv" line, as specified in RFC3264, Section 5.1. For each supported codec, "a=rtpmap" and "a=fmtp" lines, as  <ins> specified in RFC4566, Section 6.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5). </ins> If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and  <ins> RFC3264, Section 6.1.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5).  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </ins> If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the


the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; some parameters are declarative, and the remote side MUST either accept them or reject <del> them altogether.  An example of such a parameter is the DTLS fingerprints RFC8122, which are calculated based on the local certificate(s) offered and are not subject to negotiation. </del>  In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an

clarified TLS fingerprints, removed comments, issue 7
7) [rfced] Section 3.2: We do not see any mention of DTLS in RFC 8122; we only see "TLS." Will this citation be clear to readers? Original: An example of such a parameter is the DTLS fingerprints [RFC8122], which are calculated based on the local certificate(s) offered, and are not subject to negotiation. Possibly: An example of such a parameter is the TLS fingerprints [RFC8122] as used in the context of DTLS [RFC6347]; these fingerprints are calculated based on the local certificate(s) offered and are not subject to negotiation.
Comment is correct, suggestion seems reasonable.
NAME please close this issue once you consider it resolved.

the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; some parameters are declarative, and the remote side MUST either accept them or reject  <ins> them altogether.  An example of such a parameter is the TLS fingerprints RFC8122 as used in the context of DTLS RFC6347; these fingerprints are calculated based on the local certificate(s) offered and are not subject to negotiation. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an


setup. When setLocalDescription is eventually called and the JSEP <del> implementation goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.  If there are candidates in the pool, they SHOULD be handed to the </del>  application immediately via the ICE candidate event.  If the pool becomes depleted, either because a larger-than-expected number of ICE components are used or because the pool has not had enough time to

use 'prepares to gather' instead of 'goes to gather', removed comments, issue 9
9) [rfced] We suggest clarifying "goes to gather" - perhaps "gathers", "starts to gather", "prepares to gather", etc. "goes to gather" may be confusing for some readers. Original: When setLocalDescription is eventually called, and the JSEP implementation goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.
'prepares to gather' seems like the right choice.
NAME please close this issue once you consider it resolved.

setup. When setLocalDescription is eventually called and the JSEP  <ins> implementation prepares to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool. If there are candidates in the pool, they SHOULD be handed to the </ins> application immediately via the ICE candidate event.  If the pool becomes depleted, either because a larger-than-expected number of ICE components are used or because the pool has not had enough time to


actually accepts the call, the application can plug in the real MediaStreamTrack and create a new "sendrecv" offer to update the previous offer/answer pair and start bidirectional media flow.  While <del> this could also be done with a "sendonly" pranswer, followed by a </del>  "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.

used suggestion 2, deleted comments, issue 12
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right

actually accepts the call, the application can plug in the real MediaStreamTrack and create a new "sendrecv" offer to update the previous offer/answer pair and start bidirectional media flow.  While  <ins> this could also be done with a "sendonly" pranswer followed by a </ins> "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.


RFC4566 is the base SDP specification and MUST be implemented. <del> RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF RTP profile. </del>  RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE remote, MUST indicate support for the following specifications.  If any of these are absent, this omission MUST be treated as an error. <del> Either the UDP/TLS/RTP/SAVP or the UDP/TLS/RTP/SAVPF RTP profile, as specified in RFC5764, MUST be used. </del> ICE, as specified in RFC5245, MUST be used.  Note that the remote endpoint may use a Lite implementation; implementations MUST properly handle remote endpoints which do ICE-Lite. DTLS-SRTP, as specified in RFC5763, MUST be used.  5.2. When createOffer is called, a new SDP description must be created indicated in I-D.ietf-mmusic-trickle-ice, Section 5.1. To properly indicate use of DTLS, the <proto> field MUST be set to <del> "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8. </del>  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 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" [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 </del>  Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] 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. <del> Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF". </del>  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 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" [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] </del>  Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and

I just rewrote this.
Overall this LG - if you can resolve these nits tonight, great - otherwise let's land it and clean it up later
I don't think I can get to these tonight, but I may be able to get to them tomorrow AM before Cullen does.
lgtm

RFC4566 is the base SDP specification and MUST be implemented.  <ins> RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF RFC5764 and TCP/TLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- registration RTP profiles. </ins> RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE remote, MUST indicate support for the following specifications.  If any of these are absent, this omission MUST be treated as an error.  ICE, as specified in RFC5245, MUST be used.  Note that the remote endpoint may use a Lite implementation; implementations MUST properly handle remote endpoints which do ICE-Lite. DTLS-SRTP, as specified in RFC5763, MUST be used. <ins> 5.1.3. For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ RTP/SAVPF" and "TCP/TLS/RTP/SAVPF" profiles and MUST indicate one of these two profiles for each media m= line they produce in an offer. For data m= sections, JSEP endpoints must support both the "UDP/TLS/ SCTP" and "TCP/TLS/SCTP" profiles and MUST indicate one of these two profiles for each data m= line they produce in an offer.  Because ICE can select either TCP or UDP transport depending on network conditions, both advertisements are consistent with ICE eventually selecting either either UDP or TCP. Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its willingness to support "(UDP,TCP)/TLS/RTP/SAVPF".  In order to simplify compatibility with such endpoints, JSEP endpoints MUST follow the following rules when processing the media m= sections in an offer: The profile in any "m=" line in any answer MUST exactly match the profile provided in the offer. Any profile matching the following patterns MUST be accepted: "RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no effect; support for DTLS-SRTP is determined by the presence of the "a=fingerprint" attribute.  Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. The use of AVPF or AVP simply controls the timing rules used for RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute is present, assume AVPF timing, i.e. a default value of "trr- int=0".  Otherwise, assume that AVPF is being used in an AVP compatible mode and use AVP timing, i.e., "trr-int=4". For data m= sections, JSEP endpoints MUST support receiving the "UDP/ TLS/SCTP", "TCP/TLS/SCTP", or "DTLS/SCTP" (for backwards compatibility) profiles. Note that re-offers by JSEP endpoints MUST use the correct profile strings even if the initial offer/answer exchange used an (incorrect) older profile string. </ins> 5.2. When createOffer is called, a new SDP description must be created indicated in I-D.ietf-mmusic-trickle-ice, Section 5.1. To properly indicate use of DTLS, the <proto> field MUST be set to  <ins> "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the default candidate uses UDP transport, or "TCP/TLS/RTP/SAVPF", as specified inI-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport. </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 Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application"  <ins> and the <proto> field MUST be set to "UDP/TLS/SCTP" if the default candidate uses UDP transport, or "TCP/TLS/SCTP" if the default candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt" value MUST be set to the SCTP port number, as specified in </ins> Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] 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> The <proto> field MUST be set to exactly match the <proto> field for the corresponding m= line in the offer. </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 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  <ins> "application" and the <proto> field MUST be set to exactly match the field in the offer; 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


This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE <del> is used in full trickle mode with a policy of max-bundle-and-rtcpmux </del>  and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's browser initiating the session to Bob's The SDP for |answer-B1| looks like: <del> The SDP for |offer-B2| looks like: </del>  <del> The SDP for |answer-B2| looks like: </del>  8.

NAME NAME PTAL
This LGTM. Have you run it through a parser? If not, I'm going to give that a shot.
Addressed all comments, save the parser. PTAL.
LGTM. Fluffy?
LGTM - I did not really have time to review it but again, looks close enough I'd like to see it merged into the draft and that will make it easier to fix any nits.

This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE  <ins> is used in full trickle mode with a policy of max-bundle-and-rtcp-mux </ins> and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's browser initiating the session to Bob's The SDP for |answer-B1| looks like:  <ins> The SDP for |candidate-B4| looks like: </ins>  <ins> The SDP for |candidate-B5| looks like: The SDP for |candidate-B6| looks like: The SDP for |offer-B2| looks like: (note the increment of the version number in the o= line, and the c= and a=rtcp lines, which indicate the local candidate that was selected) The SDP for |answer-B2| looks like: (note the use of setup:passive to maintain the existing DTLS roles, and the use of a=recvonly to indicate that the video streams are one-way) </ins> 8.


said library would implement a given signaling protocol along with its state machine and serialization code, presenting a higher-level call-oriented interface to the application developer.  For example, <del> libraries exist to adapt the JSEP API into an API suitable for a SIP interface or an Extensible Messaging and Presence Protocol (XMPP) interface RFC6120.  Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. </del>  1.2. descriptions, instead offering APIs that would control each component directly.  This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer <del> would not be beneficial; it would result in an API where even a </del>  simple example would require a significant amount of code to <del> orchestrate all the needed interactions, as well as creating a large API surface that needed to be agreed upon and documented.  In </del>  addition, these API points could be called in any order, resulting in a more complex set of interactions with the media subsystem than the JSEP approach, which specifies how session descriptions are to be

Updated a few sentences in Section 1 regarding XMPP and SIP libraries and the API surface. Removed comments. issue 5 and issue 6.
6) [rfced] Section 1.2: We had trouble parsing this sentence. If the suggested text is not correct, please clarify "as well as creating ..." Original (the previous sentence is included for context): A second approach that was considered but not chosen was to decouple the management of the media control objects from session descriptions, instead offering APIs that would control each component directly. This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer would not be beneficial; it would result in an API where even a simple example would require a significant amount of code to orchestrate all the needed interactions, as well as creating a large API surface that needed to be agreed upon and documented. Suggested: This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer would not be beneficial; it would (1) result in an API where even a simple example would require a significant amount of code to orchestrate all the needed interactions and (2) create a large API surface that needed to be agreed upon and documented.
This mostly LGTM, but the final sentence reads a bit oddly now - perhaps

said library would implement a given signaling protocol along with its state machine and serialization code, presenting a higher-level call-oriented interface to the application developer.  For example,  <ins> libraries exist to provide implementations of the SIP RFC3261 and Extensible Messaging and Presence Protocol (XMPP) RFC6120 signaling protocols atop the JSEP API.  Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. </ins> 1.2. descriptions, instead offering APIs that would control each component directly.  This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer  <ins> would not be beneficial; it would (1) result in an API where even a </ins> simple example would require a significant amount of code to  <ins> orchestrate all the needed interactions and (2) create a large API surface that would need to be agreed upon and documented.  In </ins> addition, these API points could be called in any order, resulting in a more complex set of interactions with the media subsystem than the JSEP approach, which specifies how session descriptions are to be


begin gathering candidates for each transport, using ones from the candidate pool if available. <del> If setRemoteDescription was previously called with an offer, and </del>  setLocalDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. </del>  4.1.10. This API changes the local media state; among other things, it sets up local resources for sending and encoding media. <del> If setLocalDescription was previously called with an offer, and </del>  setRemoteDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. </del>  4.1.11.

clarified that there are four conditions, removed comment. issue 14
14) [rfced] Sections 4.1.9 and 4.1.10: We had trouble following the purpose of all of the "and"s in these sentences. Are four conditions set in these sentences, or fewer? Original: If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. ... If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. Possibly: If (1) setRemoteDescription was previously called with an offer, (2) setLocalDescription is called with an answer (provisional or final), (3) the media directions are compatible, and (4) media is available to send, media transmission can start. ... If (1) setLocalDescription was previously called with an offer, (2) setRemoteDescription is called with an answer (provisional or final), (3) the media directions are compatible, and (4) media is available to send, media transmission can start.
need to keep 'this will result in the starting of media transmission'
There are 4 conditions that have to be satisfied, as noted.

begin gathering candidates for each transport, using ones from the candidate pool if available.  <ins> If (1) setRemoteDescription was previously called with an offer, (2) </ins> setLocalDescription is called with an answer (provisional or final),  <ins> (3) the media directions are compatible, and (4) media is available to send, this will result in the starting of media transmission. </ins> 4.1.10. This API changes the local media state; among other things, it sets up local resources for sending and encoding media.  <ins> If (1) setLocalDescription was previously called with an offer, (2) </ins> setRemoteDescription is called with an answer (provisional or final),  <ins> (3) the media directions are compatible, and (4) media is available to send, this will result in the starting of media transmission. </ins> 4.1.11.


Lastly, if a data channel has been created, an "m=" section MUST be generated for data.  The <media> field MUST be set to "application", and the <proto> field MUST be set to "UDP/DTLS/SCTP" RFC8841.  The <del> "fmt" value MUST be set to "webrtc-datachannel" as specified in </del>  RFC8841. Within the data "m=" section, an "a=mid" line MUST be generated and

This PR covers the following: updated xrefs ok, removed comment ( issue 41) fixed xref and formatting of fmt, removed comment. issue 32 current text ok, removed comment. issue 22 It does not cover , issue 37, despite the branch name, because that issue was actually closed with PR
41) [rfced] Section 5.3.2: We found this RFC Editor Note on : OLD: NEW: Please note that the "OLD" text does not match what we found in the provided draft (i.e., "[RFC5245], Section 4.3., paragraph 3" versus "[I-D.ietf-mmusic-ice-sip-sdp], Section 4.1"): Please review, and let us know if further changes are needed. (As noted previously, "[RFC8839]" and "[RFC8840]" are the RFC numbers assigned for [I-D.ietf-mmusic-ice-sip-sdp] and [I-D.ietf-mmusic-trickle-ice-sip], respectively.) Currently:
Proposed text LGTM
I incorrectly mentioned this issue number when I created my branch and PR. This issue is technically still open (the comments that need to be deleted are still there), and instead these edits fixed (note the similarities in the titles of the issues...). Sorry about that.
32) [rfced] Section 5.2.1: We could not find any mention of "webrtc-datachannel" in Section 4.1 of RFC 8841 [I-D.ietf-mmusic-sctp-sdp]. Please confirm that this citation is correct and will be clear to readers. Original: The "fmt" value MUST be set to "webrtc- datachannel" as specified in [I-D.ietf-mmusic-sctp-sdp], Section 4.1.
It's never really spelled out well in that document; Section 4.5 is the only direct mention, but it's as an example, which is suboptimal. NAME any thoughts on this?
Section 15.3 of draft-ietf-mmusic-sctp-sdp registers the "webrtc-datachannel" value with IANA. But, as you point out, there are no real procedures defined. draft-ietf-mmusic-data-channel-sdpneg also only uses the value in examples.
NAME thoughts?
draft-ietf-mmusic-data-channel-sdpneg seems to assume that draft-ietf-mmusic-sctp-sdp defines the usage of "webrtc-datachannel". But, draft-ietf-mmusic-sctp-sdp cannot have a generic procedure for that, since the spec could be used for other things too. I guess the solution would be to add a normative statement somewhere, saying that the m- line fmt value muts be "webrtc-datachannel" for data channels. The question is whether such statement should be in draft-ietf-mmusic-sctp-sdp or draft-ietf-mmusic-data-channel-sdpneg.
I think NAME is correct; and, given that it's draft-ietf-mmusic-sctp-sdp that registers the value with IANA, I think that's the document that should say as much (e.g., "The token 'webrtc-datachannel' indicates the protocol defined in [I-D.ietf-rtcweb-data-protocol]", either in section 4.4.2 or section 15.3) Christer -- can you work with NAME and the RFC Editor to make sure this change makes it into draft-ietf-mmusic-sctp-sdp?
I assume you meant "makes it into draft-ietf-mmusic-sctp-sdp"?
Ah, right. Copied the wrong document name. Thanks -- it should go into draft-ietf-mmusic-sctp-sdp.
I have sent an e-mail where I suggest the following new text to Section 4.4.2.: "When the SCTP association is used to realize a WebRTC data channel [I-D.ietf-rtcweb-data-protocol], the parameter value is 'webrtc-datachannel'." Feel free to indicate your support, so people don't think this is just Christer wanting past deadline additions :)
Thanks NAME for doing this, will chime in on the list.
Looks like this one is now straightforward. I believe the new section to reference is 4.4.2, but please double-check.
I've double-checked the xref and RFC 8841 (was draft-ietf-mmusic-sctp-sdp), Section 4.4.2 is correct. The formatting of "fmt" is , so the updated sentence is:
22) [rfced] Section 5.2.1: We found this RFC Editor Note on : OLD: NEW: Please note that the "OLD" text does not match what we found in the provided draft: We updated as follows. Is the "and [RFC8445], Section 10" still applicable? Currently:
I think we want An "a=ice-options" line with the "trickle" and "ice2" options MUST be added, as specified in [I-D.ietf-ice-trickle], Section 3 and [RFC8445], Section 10.
NAME please close this issue once you consider it resolved.
Upon further reflection, while I think the current draft text (the 3rd block of text above) is correct, based on the note the proposed text (4th block) may be preferred. NAME as he wrote the note and can help disambiguate.
Well, it's definitely not RFC 8440 section 3, as that says nothing about SDP syntax or the trickle attribute. I think this is correct: >An "a=ice-options" line with the "trickle" and "ice2" options MUST be added, as specified in [RFC8840], Section 4.1.1 and [RFC8445], Section 10. (Which is the final block above.) I have to concede that I've lost context for why the RFC Editor note was necessary in the first place, but it's probably better to be more precise in any case.
NAME we're deciding between mmusic-trickle-sip-sdp, Section 4.1.1, which says: and ice-trickle, Section 3, which says:
Ah, sorry -- I missed that we were talking about two different documents. Given that the reference to trickle-ice-sip-sdp is both more indirect and unnecessarily involves a document about an only marginally related technology, I think the ice-trickle section 3 reference is cleaner. My vague recollection now is that ice-trickle used to rely on trickle-ice-sip-sdp for this behavior, and we reversed that dependency later in the cycle by moving the normative definition into ice-trickle.
I looked into this a bit more closely as part of some related JSEP issues and am now leaning toward keeping the trickle-sip-sdp reference; JSEP already leans on this document for the definition of a=candidate, a=ice-ufrag, a=ice=pwd, etc, and as a similar signaling protocol topic I think a=ice-options should be handled the same way.
For the avoidance of doubt, I am suggesting use of the final block above:
I don't feel strongly about it either way. I think the intention is clear, and implemetors will get it right regardless of which of the two citations you choose.

Lastly, if a data channel has been created, an "m=" section MUST be generated for data.  The <media> field MUST be set to "application", and the <proto> field MUST be set to "UDP/DTLS/SCTP" RFC8841.  The  <ins> <fmt> value MUST be set to "webrtc-datachannel" as specified in </ins> RFC8841. Within the data "m=" section, an "a=mid" line MUST be generated and


For each offered "m=" section, if any of the following conditions are true, the corresponding "m=" section in the answer MUST be marked as <del> rejected by setting the port in the "m=" line to zero, as indicated </del>  in RFC3264, and further processing for this "m=" section can be skipped: the specific order and with the specific syntax defined in RFC4566. The "m=" line itself MUST be parsed as described in RFC4566, and the <del> media, port, proto, and fmt values stored. </del>  Following the "m=" line, specific processing MUST be applied for the following non-attribute lines: Specific processing MUST also be applied for the following attribute lines: <del> If the "m=" proto value indicates use of RTP, as described in </del>  sec.profile-names above, the following attribute lines MUST be processed: <del> Otherwise, if the "m=" proto value indicates use of SCTP, the </del>  following attribute lines MUST be processed: Other attributes that are not relevant to JSEP may also be present,

The following changes have been made: changed to "set to zero" from "set to 0", removed comment. formatted media-field subfields consistently, removed comment.

fmt value / "fmt" value Justin: Would we also do media, port, and proto? This one needs more discusison.
RFC 4566 (SDP) was inconsistent in the formatting of fmt (, "fmt"), proto ("proto", ), and port (port, ). For the most part, media was just formatted media. RFC 8866 (SDP), which obsoletes RFC 4566, consistently formats these "m=" line subfields as , , , and . This document uses the following formats: fmt (3 instances) vs (2 instances) proto (7 instances) vs (5 instances) port (31) vs (0 instances) -- most are not referring specifically to the subfield, though I suggest using angle brackets (but not formatting -- I was just working around GitHub's markdown with that) for these terms when discussing "m=" line subfields.
SGTM, let's align with 8866 usage when an instance of these words refers specifically to a m= line subfield.
set to zero / set to 0 >(May we use the latter, because of '"dummy" port value of 9' in Sections 5.2.1 and 5.3.1?) Justin: What's the IETF style guide say on this sort of thing? 'zero' looks more natural to me, and matches RFC 3264's usage of 'zero'.
From our style guide: "In general text, we follow the CMOS guidance that numbers under 10 are written out and those above are represented using digits. However, if a value is followed by a unit of measure (e.g., 8 bytes, 3 octets), it should be in digit form regardless of value." There is one instance of "set to 0" in this document vs four instances of "set to zero". I can change that one instance to match the other four.
LGTM

For each offered "m=" section, if any of the following conditions are true, the corresponding "m=" section in the answer MUST be marked as  <ins> rejected by setting the <port> in the "m=" line to zero, as indicated </ins> in RFC3264, and further processing for this "m=" section can be skipped: the specific order and with the specific syntax defined in RFC4566. The "m=" line itself MUST be parsed as described in RFC4566, and the  <ins> <media>, <port>, <proto>, and <fmt> values stored. </ins> Following the "m=" line, specific processing MUST be applied for the following non-attribute lines: Specific processing MUST also be applied for the following attribute lines:  <ins> If the "m=" <proto> value indicates use of RTP, as described in </ins> sec.profile-names above, the following attribute lines MUST be processed:  <ins> Otherwise, if the "m=" <proto> value indicates use of SCTP, the </ins> following attribute lines MUST be processed: Other attributes that are not relevant to JSEP may also be present,


4.1.9. <del> The canTrickleIce property indicates whether the remote side supports receiving trickled candidates.  There are three potential values: </del>  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 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 <del> the canTrickleIce property to determine whether their peer can actually do Trickle ICE, i.e., whether it is safe to 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 canTrickleIce against "true" will by default attempt Half Trickle on initial offers and Full Trickle on subsequent interactions with a Trickle ICE- compatible agent. </del>  4.1.10.

It has a new name.
Overall this LG, although having thought about it a bit more, .canTrickleIce seems like a not-fully-formed clause. .canTrickleIceCandidates seems like it might match better to addIceCandidate().
LGTM. NAME NAME LMK if you have any issues with this
The diff is incomprehensible due to the all the gratuitous whitespace changes. I'll make a diff I can review at some point and see if I can figure it out.
LGTM
I will manually merge this.

4.1.9.  <ins> The canTrickleIceCandidates property indicates whether the remote side supports receiving trickled candidates.  There are three potential values: </ins> 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 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  <ins> the canTrickleIceCandidates property to determine whether their peer can actually do Trickle ICE, i.e., whether it is safe to 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 canTrickleIceCandidates against "true" will by default attempt Half Trickle on initial offers and Full Trickle on subsequent interactions with a Trickle ICE-compatible agent. </ins> 4.1.10.