For any specified "CT" bandwidth value, set this as the limit for the maximum total bitrate for all m= sections, as specified in <del> Section 5.8 of RFC4566.  The implementation can decide how to allocate the available bandwidth between m= sections to simultaneously meet any limits on individual m= sections, as well as this overall session limit. </del>  For any specified "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.

Originally raised by Magnus: o For any specified "CT" bandwidth value, set this as the limit for the maximum total bitrate for all m= sections, as specified in Section 5.8 of [RFC4566]. The implementation can decide how to allocate the available bandwidth between m= sections to simultaneously meet any limits on individual m= sections, as well as this overall session limit. I think this text can be improved to make it clearer that CT doesn't imply a fixed over time divide of the bandwidth between RTP streams. As long as individual media sources streams stay within other requirements such as b=AS/TIAS they can be changed dynamically.
Makes sense.

For any specified "CT" bandwidth value, set this as the limit for the maximum total bitrate for all m= sections, as specified in  <ins> Section 5.8 of RFC4566.  Within this overall limit, the implementation can dynamically decide how to best allocate the available bandwidth between m= sections, respecting any specific limits that have been specified for individual m= sections. </ins> For any specified "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.


RFC4588 MUST be implemented to signal RTX payload type associations. <del> RFC3556 with bandwidth modifiers MAY be supported for specifying RTCP bandwidth as a fraction of the media bandwidth, RTCP fraction allocated to the senders and setting maximum media bit-rate boundaries. </del>  As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines.

I agree that this text is correct. I have no strong opinion on whether we should make the change...
Proposed text:
This seems satisfactory to me. You have my preemptive LGTM

RFC4588 MUST be implemented to signal RTX payload type associations.  <ins> RFC3556 MUST be supported for control of RTCP bandwidth limits. </ins> As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines.


The next step is to generate m= sections, as specified in RFC4566 Section 5.14.  An m= section is generated for each RtpTransceiver <del> that has been added to the PeerConnection.  This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTransceivers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . </del>  Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique

Originally raised by Magnus: This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTransceivers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . I am bit surprised to see "recycled" on a list of things that may occur in generating an initial offer? Can that really occur?
check this - prob editorial

The next step is to generate m= sections, as specified in RFC4566 Section 5.14.  An m= section is generated for each RtpTransceiver  <ins> that has been added to the PeerConnection, excluding any stopped RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection. </ins> Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique


section for all Source RTP Streams using the specified media formats.  Specifically, begin or continue sending the requested feedback types and reacting to received feedback, as specified <del> in RFC4585, Section 4.2.  When sending RTCP feedback, use the SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC; if no outgoing Source RTP Stream exists, choose a random one. </del>  If the directional attribute is of type "recvonly" or "inactive", stop transmitting all RTP media, but continue

Originally raised by Magnus: When sending RTCP feedback, use the SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC; if no outgoing Source RTP Stream exists, choose a random one. This is okay, but could be slightly more open in regards to sending feedback packets efficiently. Section 5.4.1 in URL is providing more detailed rules for things to consider.
Magnus, what do you think is needed here. Informative ref ?
A reference would be good. I would consider cutting away the explicit recommendation here and only say that "When sending RTCP feedback, follow the rules and recommendations in Section 5.4.1 of [draft-ietf-avtcore-rtp-multi-stream] to select which SSRC to use."

section for all Source RTP Streams using the specified media formats.  Specifically, begin or continue sending the requested feedback types and reacting to received feedback, as specified  <ins> in RFC4585, Section 4.2.  When sending RTCP feedback, follow the rules and recommendations from I-D.ietf-avtcore-rtp-multi- stream, Section 5.4.1 to select which SSRC to use. </ins> If the directional attribute is of type "recvonly" or "inactive", stop transmitting all RTP media, but continue


4.2.2. <del> The stopped method returns "true" if the transceiver has been </del>  stopped, either by a call to stopTransceiver or by applying an answer <del> that rejects the associated m= section, and "false" otherwise. </del>  A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP.  It cannot be restarted.

stopped The stopped method returns "true" if the transceiver has been stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated m= section, and "false" otherwise. [BA] This should be rewritten as follows:
Agree, there is precedent for this regarding the canTrickleIceCandidates property in URL We should make these consistent (note use of 'property' vs 'attribute')

4.2.2.  <ins> The stopped property indicates whether the transceiver has been </ins> stopped, either by a call to stopTransceiver or by applying an answer  <ins> that rejects the associated m= section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </ins> A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP.  It cannot be restarted.


possible forms of initial candidates - host, server reflexive, and relay.  However, in certain cases, applications may want to have more specific control over the gathering process, due to privacy or <del> related concerns.  For example, one may want to suppress the use of host candidates, to avoid exposing information about the local network, or go as far as only using relay candidates, to leak as little location information as possible (note that these choices come with corresponding operational costs).  To accomplish this, the browser MUST allow the application to restrict which ICE candidates are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I- D.ietf-rtcweb-ip-handling. </del>  There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime

It’s an API requirement, so the MUST doesn’t belong here. Also remove discussion of application filtering of local addresses, which is no longer believed to be useful.
Originally raised by Christer Section 3.5.3 contains requirements regarding what a browser MUST do - e.g., allowing the application to select what types of ICE candidates are used. 1) I am not sure why such requirements are listed here. But, in any case, is there a mechanism for applications for selecting candidate types etc? If so, what mechanism?
This is ICE policy. Editorial
Suggested revision: to

possible forms of initial candidates - host, server reflexive, and relay.  However, in certain cases, applications may want to have more specific control over the gathering process, due to privacy or  <ins> related concerns.  For example, one may want to only use relay candidates, to leak as little location information as possible (keeping in mind that this choice comes with corresponding operational costs).  To accomplish this, JSEP allows the application to restrict which ICE candidates are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I-D.ietf-rtcweb-ip-handling. </ins> There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime


3.3. <del> In the WebRTC specification, session descriptions are formatted as SDP messages.  While this format is not optimal for manipulation from Javascript, it is widely accepted, and frequently updated with new features.  Any alternate encoding of session descriptions would have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity.  As a result, JSEP currently uses SDP as the internal representation for its session descriptions. </del>  However, to simplify Javascript processing, and provide for future flexibility, the SDP syntax is encapsulated within a

Also, remove awkward reference to WebRTC spec
Originally raised by Christer Section 3.3 says: "In the WebRTC specification, session descriptions are formatted as SDP messages." 1) To me it is unclear what an ³SDP message² is, so I suggest we say ³SDP syntax², as we also do later in the section.
FWIW, RFC 4566 itself uses the term 'SDP message' in Section 7. However, we could say 'descriptions use SDP syntax' instead.

3.3.  <ins> JSEP's session descriptions use SDP syntax for their internal representation.  While this format is not optimal for manipulation from Javascript, it is widely accepted, and frequently updated with new features; any alternate encoding of session descriptions would have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity. </ins> However, to simplify Javascript processing, and provide for future flexibility, the SDP syntax is encapsulated within a


although there may be more RtpTransceivers than m= sections when RtpTransceivers are created but not yet associated with a m= section, or if RtpTransceivers have been stopped and disassociated from m= <del> sections.  An RtpTransceiver is never associated with more than one m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver. </del>  RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds desc).  This means that some RtpTransceivers that were previously associated will no longer be associated with any m= section; in such cases, the value of the RtpTransceiver's mid property MUST be set to <del> null.  RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed.  However, a RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </del>  A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection.  Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Bundle-only m= sections MUST NOT contain any The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section: <del> An "a=mid" line, as specified in RFC5888, Section 4.  All mid </del>  values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-mmusic-sdp- <del> bundle-negotiation, Section 14. </del>  A direction attribute which is the same as that of the associated transceiver. If the media section proto value indicates use of RTP: If there is no RtpTransceiver associated with this m= section <del> (which should only happen when applying an offer), find one and </del>  associate it with this m= section according to the following steps: <del> Find the RtpTransceiver that corresponds to the m= section with the same MID in the created offer. </del>  <del> Set the value of the RtpTransceiver's mid property to the </del>  MID of the m= section. If RTCP mux is indicated, prepare to demux RTP and RTCP from If the m= section is being recycled (see sec.subsequent- offers), dissociate the currently associated RtpTransceiver by <del> setting its mid attribute to null. </del>  If the m= section is not associated with any RtpTransceiver (possibly because it was dissociated in the previous step), Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid <del> property to the MID of the m= section.  If the m= section does not include a MID (i.e., the remote side does not support the MID extension), generate a value for the RtpTransceiver's mid property, following the guidance for "a=mid" mentioned in sec.initial-offers. </del>  For each specified media format that is also supported by the local implementation, establish a mapping between the specified

Also describing explicitly what it means for an RtpTransceiver to be "associated" with an m= section. Namely, that it has a mid attribute that matches the MID of that m= section. Addresses issue .
There probably are better ways of wording this, I'm open to suggestions.
Ekr pointed out that this doesn't handle situations where "a=mid" is not used. So I added text describing a transceiver->m= section index mapping.
I think I've addressed all of ekr and juberti's comments; ready for another review.
LGTM

although there may be more RtpTransceivers than m= sections when RtpTransceivers are created but not yet associated with a m= section, or if RtpTransceivers have been stopped and disassociated from m=  <ins> sections.  An RtpTransceiver is said to be associated with an m= section if its mid property is non-null; otherwise it is said to be disassociated.  The associated m= section is determined using a mapping between transceivers and m= section indices, formed when creating an offer or applying a remote offer.  An RtpTransceiver is never associated with more than one m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver. </ins> RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds desc).  This means that some RtpTransceivers that were previously associated will no longer be associated with any m= section; in such cases, the value of the RtpTransceiver's mid property MUST be set to  <ins> null, and the mapping between the transceiver and its m= section index MUST be discarded.  RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed.  However, a RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </ins> A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection. <ins> For each m= section generated for an RtpTransceiver, establish a mapping between the transceiver and the index of the generated m= section. </ins> Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Bundle-only m= sections MUST NOT contain any The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section:  <ins> An "a=mid" line, as specified in RFC5888, Section 4.  All MID </ins> values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-mmusic-sdp-  <ins> bundle-negotiation, Section 14.  Note that this does not set the RtpTransceiver mid property, as that only occurs when the description is applied.  The generated MID value can be considered a "proposed" MID at this point. </ins> A direction attribute which is the same as that of the associated transceiver. If the media section proto value indicates use of RTP: If there is no RtpTransceiver associated with this m= section  <ins> (which will only happen when applying an offer), find one and </ins> associate it with this m= section according to the following steps:  <ins> Find the RtpTransceiver that corresponds to this m= section, using the mapping between transceivers and m= section indices established when creating the offer. </ins>  <ins> Set the value of this RtpTransceiver's mid property to the </ins> MID of the m= section. If RTCP mux is indicated, prepare to demux RTP and RTCP from If the m= section is being recycled (see sec.subsequent- offers), dissociate the currently associated RtpTransceiver by  <ins> setting its mid property to null, and discard the mapping between the transceiver and its m= section index. </ins> If the m= section is not associated with any RtpTransceiver (possibly because it was dissociated in the previous step), Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid  <ins> property to the MID of the m= section, and establish a mapping between the transceiver and the index of the m= section.  If the m= section does not include a MID (i.e., the remote endpoint does not support the MID extension), generate a value for the RtpTransceiver mid property, following the guidance for "a=mid" mentioned in sec.initial- offers. </ins> For each specified media format that is also supported by the local implementation, establish a mapping between the specified


As a result of sharing the media streams, the application will end up with N parallel PeerConnection sessions, each with a local and remote description and their own local and remote addresses.  The media flow <del> from these sessions can be managed by specifying SDP direction attributes in the descriptions, or the application can choose to play </del>  out the media from all sessions mixed together.  Of course, if the application wants to only keep a single session, it can simply terminate the sessions that it no longer needs.

LGTM
Section 3.8.2 - "the media flow from these sessions can be managed by specifying SDP direction attributes in the descriptions". This seems out of place. Surely flipping URL is a much simpler way of managing them if the problem is what to play to the user? Suggestion: Remove text.

As a result of sharing the media streams, the application will end up with N parallel PeerConnection sessions, each with a local and remote description and their own local and remote addresses.  The media flow  <ins> from these sessions can be managed using setDirection (see sec.transceiver-set-direction), or the application can choose to play </ins> out the media from all sessions mixed together.  Of course, if the application wants to only keep a single session, it can simply terminate the sessions that it no longer needs.


5.8. The following steps are performed at the media engine level to apply <del> a local description. </del>  First, the parsed parameters are checked to ensure that they have not been altered after their generation in createOffer/createAnswer, as 5.9.  If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. <del> The following steps are performed at the media engine level to apply a remote description. </del> The following steps MUST be performed for attributes at the session level; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned.

Plan is to write the text in the apply local/remote sections to indicate that upon an error, the session state should be restored to the pre-call state.

5.8. The following steps are performed at the media engine level to apply  <ins> a local description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. </ins> First, the parsed parameters are checked to ensure that they have not been altered after their generation in createOffer/createAnswer, as 5.9. <ins> The following steps are performed to apply a remote description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. </ins> If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false.  The following steps MUST be performed for attributes at the session level; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned.


specific "a=imageattr" attributes MUST be inserted for each payload type. <del> As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to at most 360p.  In this case, the implementation would generate this </del>  attribute: <del> a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] </del>  This declaration indicates that the receiver is capable of decoding <del> any image resolution from 16x16 up to 640x360 pixels. </del>  3.6.2.

This is from the Windows HW offload framework, and spells things out more specifically in the surrounding text.

specific "a=imageattr" attributes MUST be inserted for each payload type.  <ins> As an example, consider a system with a multiformat video decoder, which is capable of decoding any resolution from 48x48 to 720p, and where the application has constrained the received track to at most 360p.  In this case, the implementation would generate this </ins> attribute:  <ins> a=imageattr:* recv [x=[48:640],y=[48:360],q=1.0] </ins> This declaration indicates that the receiver is capable of decoding  <ins> any image resolution from 48x48 up to 640x360 pixels. </ins> 3.6.2.


A rollback discards any proposed changes to the session, returning the state machine to the stable state, and setting the pending local <del> and/or remote description back to null.  Any resources or candidates </del>  that were allocated by the abandoned local description are discarded; any media that is received will be processed according to the previous local and remote descriptions.  Rollback can only be used to associated will no longer be associated with any m= section; in such cases, the value of the RtpTransceiver's mid property MUST be set to null.  RtpTransceivers that were created by applying a remote offer <del> that was subsequently rolled back MUST be removed.  However, a RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </del>  A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or

Is there any other action to be taken for the issues mentioned in ?
NAME I concluded no.
Grouping these as one bug. Section 4.1.7.1 - the term "inactive" final answer is introduced without a defintion. Need to either define "inactive" or use another term. Section 4.1.7.2 Rollback - "and possibly the answerer as well" is wishy-washy. Suggest "and the answerer if it has done set-remote-description". Section 4.1.7.2 This is the first mention of "pending local / remote description". Suggest link to definition. Section 4.1.7.2 "RTPTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed". The term "removed" is undefined. Deleted, discarded, destroyed or detached from the PeerConnection? Suggestion: "stopped and removed from the PeerConnection". (if the JS app still has a reference to them, it may still inspect the object).
LG % nit

A rollback discards any proposed changes to the session, returning the state machine to the stable state, and setting the pending local  <ins> and/or remote description (see sec.pendinglocaldescription and sec.pendingremotedescription) to null.  Any resources or candidates </ins> that were allocated by the abandoned local description are discarded; any media that is received will be processed according to the previous local and remote descriptions.  Rollback can only be used to associated will no longer be associated with any m= section; in such cases, the value of the RtpTransceiver's mid property MUST be set to null.  RtpTransceivers that were created by applying a remote offer  <ins> that was subsequently rolled back MUST be stopped and removed from the PeerConnection.  However, a RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method. This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </ins> A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or


JSEP gathers ICE candidates as needed by the application.  Collection of ICE candidates is referred to as a gathering phase, and this is <del> triggered either by the addition of a new or recycled m= line to the local session description, or new ICE credentials in the description, indicating an ICE restart.  Use of new ICE credentials can be triggered explicitly by the application, or implicitly by the browser in response to changes in the ICE configuration. </del>  When the ICE configuration changes in a way that requires a new gathering phase, a 'needs-ice-restart' bit is set.  When this bit is process is complete. Note that gathering phases only gather the candidates needed by <del> new/recycled/restarting m= lines; other m= lines continue to use their existing candidates.  Also, when bundling is active, candidates are only gathered (and exchanged) for the m= lines referenced in BUNDLE-tags, as described in I-D.ietf-mmusic-sdp-bundle-negotiation. </del>  3.5.2. "candidate-attribute" field defined for ICE.  For example: The IceCandidate object also contains fields to indicate which m= <del> line it should be associated with.  The m= line can be identified in one of two ways; either by a m= line index, or a MID.  The m= line index is a zero-based index, with index N referring to the N+1th m= line in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= line.  JSEP implementations creating an ICE Candidate object MUST populate both of these fields, using the MID of the associated RtpTransceiver object (which may be locally generated by the answerer when interacting with a non-JSEP remote endpoint that does not support the MID attribute, as discussed in sec.applying-a-remote-desc below).  Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= line index, if not (the non-JSEP remote endpoint case). </del>  3.5.3. and/or pending remote description according to the rules defined for Trickle ICE.  The pair of MID and ufrag is used to determine the m= section and ICE candidate generation to which the candidate belongs. <del> If the MID is not present, the m= line index is used to look up the locally generated MID (see sec.applying-a-remote-desc), which is used in place of a supplied MID.  If these values or the candidate string are invalid, an error is generated. </del>  The purpose of the ufrag is to resolve ambiguities when trickle ICE is in progress during an ICE restart.  If the ufrag is absent, the object.  The set of parameters for RTCAnswerOptions is different than those supported in RTCOfferOptions; the IceRestart option is unnecessary, as ICE credentials will automatically be changed for all <del> m= lines where the offerer chose to perform ICE restart. </del>  The following options are supported in RTCAnswerOptions.

S 5.2.1 says: Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. This seems like it would be better as a should
Discussed in DC: Some concerns that things that appear at the session level have, in the past, missed by bad implementations.
Dc - decdie to change to SHOULD NOT and for things that are big, like idientiy, will put MUST

JSEP gathers ICE candidates as needed by the application.  Collection of ICE candidates is referred to as a gathering phase, and this is  <ins> triggered either by the addition of a new or recycled m= section to the local session description, or new ICE credentials in the description, indicating an ICE restart.  Use of new ICE credentials can be triggered explicitly by the application, or implicitly by the browser in response to changes in the ICE configuration. </ins> When the ICE configuration changes in a way that requires a new gathering phase, a 'needs-ice-restart' bit is set.  When this bit is process is complete. Note that gathering phases only gather the candidates needed by  <ins> new/recycled/restarting m= sections; other m= sections continue to use their existing candidates.  Also, when bundling is active, candidates are only gathered (and exchanged) for the m= sections referenced in BUNDLE-tags, as described in I-D.ietf-mmusic-sdp- bundle-negotiation. </ins> 3.5.2. "candidate-attribute" field defined for ICE.  For example: The IceCandidate object also contains fields to indicate which m=  <ins> section it should be associated with.  The m= section can be identified in one of two ways; either by a m= section index, or a MID.  The m= section index is a zero-based index, with index N referring to the N+1th m= section in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= section.  JSEP implementations creating an ICE Candidate object MUST populate both of these fields, using the MID of the associated RtpTransceiver object (which may be locally generated by the answerer when interacting with a non-JSEP remote endpoint that does not support the MID attribute, as discussed in sec.applying-a- remote-desc below).  Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= section index, if not (the non-JSEP remote endpoint case). </ins> 3.5.3. and/or pending remote description according to the rules defined for Trickle ICE.  The pair of MID and ufrag is used to determine the m= section and ICE candidate generation to which the candidate belongs.  <ins> If the MID is not present, the m= section index is used to look up the locally generated MID (see sec.applying-a-remote-desc), which is used in place of a supplied MID.  If these values or the candidate string are invalid, an error is generated. </ins> The purpose of the ufrag is to resolve ambiguities when trickle ICE is in progress during an ICE restart.  If the ufrag is absent, the object.  The set of parameters for RTCAnswerOptions is different than those supported in RTCOfferOptions; the IceRestart option is unnecessary, as ICE credentials will automatically be changed for all  <ins> m= sections where the offerer chose to perform ICE restart. </ins> The following options are supported in RTCAnswerOptions.


3.5.2.1. <del> As with session descriptions, the syntax of the IceCandidate object provides some abstraction, but can be easily converted to and from the SDP candidate lines. The candidate lines are the only SDP information that is contained within IceCandidate, as they represent the only information needed that is not present in the initial offer (i.e., for trickle candidates).  This information is carried with the same syntax as the "candidate-attribute" field defined for ICE.  For example: </del>  The IceCandidate object also contains fields to indicate which m= <del> section it should be associated with.  The m= section can be identified in one of two ways; either by a m= section index, or a MID.  The m= section index is a zero-based index, with index N referring to the N+1th m= section in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= section.  JSEP implementations creating an ICE Candidate object MUST populate both of these fields, using the MID of the associated RtpTransceiver object (which may be locally generated by the answerer when interacting with a non-JSEP remote endpoint that does not support the MID attribute, as discussed in sec.applying-a- remote-desc below).  Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= section index, if not (the non-JSEP remote endpoint case). </del>  3.5.3.

Updated to address Eric's comment
I note the following new text: "The IceCandidate object contains a field to indicate which ICE ufrag it is associated with, as defined in , Section 15.4. This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts." Exactly what value does this field contain? How does one use it to determine to which session description the IceCandidate belongs?

3.5.2.1.  <ins> In JSEP, ICE candidates are abstracted by an IceCandidate object, and as with session descriptions, SDP syntax is used for the internal representation. The candidate details are specified in an IceCandidate field, using the same SDP syntax as the "candidate-attribute" field defined in RFC5245, Section 15.1.  For example: The IceCandidate object contains a field to indicate which ICE ufrag it is associated with, as defined in RFC5245, Section 15.4.  This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts.  If this field is absent in a received IceCandidate (perhaps when communicating with a non-JSEP endpoint), the most recently received session description is assumed. </ins> The IceCandidate object also contains fields to indicate which m=  <ins> section it is associated with, which can be identified in one of two ways, either by a m= section index, or a MID.  The m= section index is a zero-based index, with index N referring to the N+1th m= section in the session description referenced by this IceCandidate.  The MID is a "media stream identification" value, as defined in RFC5888, Section 4, which provides a more robust way to identify the m= section in the session description, using the MID of the associated RtpTransceiver object (which may have been locally generated by the answerer when interacting with a non-JSEP endpoint that does not support the MID attribute, as discussed in sec.applying-a-remote-desc below).  If the MID field is present in a received IceCandidate, it MUST be used for identification; otherwise, the m= section index is used instead. When creating an IceCandidate object, JSEP implementations MUST populate all of these fields. </ins> 3.5.3.


setLocalDescription will succeed when it attempts to acquire those resources. <del> Calling this method may do things such as generate new ICE </del>  credentials, but does not result in candidate gathering, or cause <del> media to start or stop flowing. </del>  4.1.7. usable by setLocalDescription; like createOffer, the returned description should reflect the current state of the system. <del> Calling this method may do things such as generate new ICE credentials, but does not trigger candidate gathering or change media state. </del>  4.1.8.

NAME has given his thumbs up as well.
Originally raised by Christer Section 3.2 says: "To support this, the JSEP media layer can provide an offer via the createOffer() method whenever the Javascript application needs one for the signaling. The answerer can send back zero or more provisional answers, and finally end the offer-answer exchange by sending a final answer. The state machine for this is as follows:" 1) I would like to explicitly note that the generated offer is not applied (and any previously applied offer is not removed) until setLocalDescription() is called.
OK. In this case, we should note this for the provisional answers as well.
I thought about this for a while and came to the conclusion that this is the wrong place for such text; spelling everything out makes the overall message less clear. If we need to be super-prescriptive about the fact that the offer does not take effect until after setLD is called, we should state this in the createOffer/Answer sections (4.1.5/4.1.6), not here. NAME PTAL.
Will update document according to my last comment.
See PR
PR looks ok.

setLocalDescription will succeed when it attempts to acquire those resources.  <ins> Calling this method may do things such as generating new ICE </ins> credentials, but does not result in candidate gathering, or cause  <ins> media to start or stop flowing.  Specifically, the offer is not applied, and does not become the pending local description, until setLocalDescription is called. </ins> 4.1.7. usable by setLocalDescription; like createOffer, the returned description should reflect the current state of the system.  <ins> Calling this method may do things such as generating new ICE credentials, but does not trigger candidate gathering or cause a media state change.  Specifically, the answer is not applied, and does not become the pending local description, until setLocalDescription is called. </ins> 4.1.8.


Video size negotiation is the process through which a receiver can use the "a=imageattr" SDP attribute RFC6236 to indicate what video frame sizes it is capable of receiving.  A receiver may have hard <del> limits on what its video decoder can process, or it may wish to constrain what it receives due to application preferences, e.g. a specific size for the window in which the video will be displayed. </del>  Note that certain codecs support transmission of samples with aspect ratios other than 1.0 (i.e., non-square pixels).  JSEP 3.6.1. <del> In order to determine the limits on what video resolution a receiver wants to receive, it will intersect its decoder hard limits with any mandatory constraints that have been applied to the associated MediaStreamTrack.  If the decoder limits are unknown, e.g. when using a software decoder, the mandatory constraints are used directly.  For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing createAnswer call. Any constraints set after setLocalDescription is used to set the answer will result in a new offer-answer exchange.  For the offerer, because it does not know about any remote MediaStreamTracks until it receives the answer, the offer can only reflect decoder hard limits. If the offerer wishes to set mandatory constraints on video resolution, it must do so after receiving the answer, and the result will be a new offer-answer to communicate them. If there are no known decoder limits or mandatory constraints, the "a=imageattr" attribute SHOULD be omitted. </del>  Otherwise, an "a=imageattr" attribute is created with "recv" <del> direction, and the resulting resolution space formed by intersecting the decoder limits and constraints is used to specify its minimum and </del>  maximum x= and y= values.  If the intersection is the null set, i.e., <del> there are no resolutions that are permitted by both the decoder and the mandatory constraints, this MUST be represented by x=0 and y=0 values. </del>  The rules here express a single set of preferences, and therefore, the "a=imageattr" q= value is not important.  It SHOULD be set to The "a=imageattr" field is payload type specific.  When all video codecs supported have the same capabilities, use of a single attribute, with the wildcard payload type (*), is RECOMMENDED. <del> However, when the supported video codecs have differing capabilities, </del>  specific "a=imageattr" attributes MUST be inserted for each payload type. As an example, consider a system with a multiformat video decoder, <del> which is capable of decoding any resolution from 48x48 to 720p, and where the application has constrained the received track to at most 360p.  In this case, the implementation would generate this attribute: </del>  <del> a=imageattr:* recv [x=[48:640],y=[48:360],q=1.0] </del>  This declaration indicates that the receiver is capable of decoding <del> any image resolution from 48x48 up to 640x360 pixels. </del>  3.6.2.

The second paragraph of section 3.6.1 seems odd when talking about creating answers, and downright incorrect when talking about offers. Minimally, it needs text to explain why x=0/y=0 would ever make more sense than using "a=sendonly/recvonly/inactive."
There was a clear rationale for why we did this, as I remember having this exact conversation before, but I need to go dig it up.
NAME -- >There was a clear rationale for why we did this, as I remember having this exact conversation before, but I need to go dig it up. Ideally, this rationale would be added to the document once you find it.
Sounds like a good idea.
I was able to find it - the concern was that if you offered a=recvonly, you could then potentially change that to a=sendrecv via transceiver.setDirection, so a=imageattr of [0, 0] provided a way to prevent any video from being sent without additional complexity. URL
I'm coming around to Adam's viewpoint on this one - not sure we should be inventing a new syntax for saying 'don't send me this video stream'.
Section 3.6.1 describes mandatory constraints applied to an incoming track resulting in a new offer-answer exchange. Since this is "action at a distance" (modify the track and the PeerConnection emits a negotiation-needed), I think this needs to be synced with the webrtc-1.0 API spec, and possibly even media-capture. Also, what's the state of the track between the changing of constraints at the receiver and the renegotiation? It seems to me that the track should be scaled at the receiver to fit the agreed-upon constraints.
OK, agreed we have moved away from this sort of approach. I guess we could add a new API to RtpReceiver if we decide we need this sort of functionality; we can either spec said API here in JSEP for future implementation, or drop discussion of it altogether. NAME wdyt?
Dropping discussion seems like the simplest approach; that will mean that the receiver hands whatever comes to it into the track, and the track processes it like it processes any other source. Simple is good.
See PR

Video size negotiation is the process through which a receiver can use the "a=imageattr" SDP attribute RFC6236 to indicate what video frame sizes it is capable of receiving.  A receiver may have hard  <ins> limits on what its video decoder can process, or it may have some maximum set by policy. </ins> Note that certain codecs support transmission of samples with aspect ratios other than 1.0 (i.e., non-square pixels).  JSEP 3.6.1.  <ins> The receiver will first intersect any known local limits (e.g., hardware decoder capababilities, local policy) to determine the absolute minimum and maximum sizes it can receive.  If there are no known local limits, the "a=imageattr" attribute SHOULD be omitted. </ins> Otherwise, an "a=imageattr" attribute is created with "recv"  <ins> direction, and the resulting resolution space formed from the aforementioned intersection is used to specify its minimum and </ins> maximum x= and y= values.  If the intersection is the null set, i.e.,  <ins> the degenerate case of no permitted resolutions, this MUST be represented by x=0 and y=0 values. </ins> The rules here express a single set of preferences, and therefore, the "a=imageattr" q= value is not important.  It SHOULD be set to The "a=imageattr" field is payload type specific.  When all video codecs supported have the same capabilities, use of a single attribute, with the wildcard payload type (*), is RECOMMENDED.  <ins> However, when the supported video codecs have different limitations, </ins> specific "a=imageattr" attributes MUST be inserted for each payload type. As an example, consider a system with a multiformat video decoder,  <ins> which is capable of decoding any resolution from 48x48 to 720p, In this case, the implementation would generate this attribute: </ins>  <ins> a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0] </ins> This declaration indicates that the receiver is capable of decoding  <ins> any image resolution from 48x48 up to 1280x720 pixels. </ins> 3.6.2.


of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. <del> However, not all parameters follow this rule; for example, the DTLS- SRTP parameters RFC5763 sent to a remote party indicate what certificate the local side will use in DTLS setup, and thereby what the remote party should expect to receive; the remote party will have to accept these parameters, with no option to choose different values. </del>  In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an

Originally raised by Christer Section 3.2 says: "the DTLS-SRTP parameters [RFC5763] sent to a remote party indicate what certificate the local side will use in DTLS setup" 1) I am not sure what "parameters" the text is referring to. If it¹s the fingerprint, I think the text should reference RFC 4572. 2) I think we should simply have a generic statement that, following the rules in RFC3264, parameters indicate receiving capabilities - unless explicitly indicated otherwise.
The parameters include a=setup and a=fingerprint. 5763 seems like it covers both.
NAME thoughts?
Authors believe this text is fine. NAME please send us a PR with the specific change you want if you disagree.
NAME said in email: certificate the local side will use in DTLS setup". >So, I would suggest to replace: “However, not all parameters follow this rule; for example, the DTLS- SRTP parameters [RFC5763] sent to a remote party indicate what certificate the local side will use in DTLS setup, and thereby what the remote party should expect to receive;” >…with: “However, not all parameters follow this rule; for example, the fingerprints sent to a remote party are calculated based on the local certificate(s) offered;” >If you agree with that understanding, I’m happy to submit a pull request.
OK, I now see what you are saying, and I think the text you propose looks reasonable. Thanks for offering to submit a PR!
[waiting on PR from NAME
It seems like I don't have rights to submit new branches (needed for the PR).
cd4u: fork the repo and push the branch to your fork, then submit the PR from there.
PR created: URL
Fixed by

of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send.  <ins> However, not all parameters follow this rule; for example, the fingerprints I-D.ietf-mmusic-4572-update sent to a remote party are calculated based on the local certificate(s) offered; the remote party MUST either accept these parameters or reject them altogether, with no option to choose different values. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an


If the RtpTransceiver has a sendrecv or sendonly direction: <del> An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. </del>  If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more If an RtpTransceiver has been stopped and is associated with an m= section, and the m= section is not being recycled as described above, an m= section MUST be generated for it with the port set to <del> zero and the "a=msid" line removed. </del>  <del> For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same if they are present in the current description. </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 m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted. <del> For RtpTransceivers that are still present, the "a=msid" line MUST stay the same. </del> For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same. MUST stay the same. If any RtpTransceiver has been stopped, the port MUST be set to <del> zero and the "a=msid" line MUST be removed. </del>  If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the If the RtpTransceiver has a sendrecv or sendonly direction: <del> An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. </del>  Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted. <del> For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same. </del>  5.3.3. specified in RFC3605, Section 2.1, but its value is ignored, as this information is superfluous when using ICE. <del> If present, a single "a=msid" attribute MUST be parsed as specified in I-D.ietf-mmusic-msid, Section 3.2, and its value stored. </del>  Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.

and Suggesting the same thing as mediacapture-streams, which is to generate UUIDs using the forms in section 4.4 or 4.5 of RFC4122.
About the reference: would it be preferable to reference mediacapture-streams directly, or reference RFC4122 (what I did here)? Also, is there any established ordering scheme for the references?
So two concerns on this ... 1) if multiple things are created with no track, I think it would be better to add them all to the same default track instead of creating separate tracks for them. 2) these are pretty big and there is no need for a globally unique track name. So I wonder if we could solve this by when the track is null setting the MSID to the string "NULL" or "DEFAULT". It seems like if we use the system in 4.5, if an app got a fixed node ID, that would end up in the UUID which might be sent in the clear in RTP SDES headers in some cases. This would allow correlation of different calls as being from the same node by on path attackers which seems to create some other privacy issue. So if we do go with the UUID, I'd rather restrict it to just the section 4.4 UUID and drop the 4.5 version.
Your suggestion to drop 4.5 UUIDs sounds fine to me. As for using the same track ID for multiple "m=" sections: That seems likely to cause problems. This ID is what's used to create the remote MediaStreamTracks when is called, so this means you'd get multiple tracks with the same ID, which may break the assumptions of applications that deal with MediaStreamTracks.
MSIDs (not MIDs) don't appear on the wire IIUC. Right?
I agree the trackID need to all be different - disregard previous comment, I was thinking about a default stream not track.
Hello, I totally agree with you in creating an msid "If no MediaStreamTrack is attached". Actually, we have already implemented this in our stack. Moreover, I would like to say that due to the msid can be generated internally, we should expose a way of getting this msid to can attach metainfo at application level like "The msid XYZ is the front-camera, and the msid TUV is the screen-share". I propose to add a readonly property in RtpSender that will have the value of the first MediaStreamTrack's msid or the value autogenerated internally as proposed in: URL We also have this implemented in our stack. I hope this can be useful ;) Best!!
Ready for another review. I also noticed that '"a=msid" line' was singular in some places where there may be multiple lines, so I fixed that as well.
On URL o For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same if they are present in the current description. and then in the same section, on URL o For RtpTransceivers that are still present, the "a=msid" line MUST stay the same. This needs to be unified. It might also be a good idea to mention that a=msid stays the same regardless of direction or track changes, and that a=msid can be added if it was not present in the previous description (i.e. because the transceiver was recvonly).

If the RtpTransceiver has a sendrecv or sendonly direction:  <ins> For each MediaStream that was associated with the transceiver when it was created via addTrack or addTransceiver, an "a=msid" 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. </ins> If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more If an RtpTransceiver has been stopped and is associated with an m= section, and the m= section is not being recycled as described above, an m= section MUST be generated for it with the port set to  <ins> zero and all "a=msid" lines removed. </ins>  <ins> For RtpTransceivers that are not stopped, the "a=msid" line(s) MUST stay the same if they are present in the current description, regardless of changes to the transceiver's direction or track.  If no "a=msid" line is present in the current description, "a=msid" 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, protocol, and address of the default candidate for the m= section, as m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted.  For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same. MUST stay the same. If any RtpTransceiver has been stopped, the port MUST be set to  <ins> zero and all "a=msid" lines MUST be removed. </ins> If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the If the RtpTransceiver has a sendrecv or sendonly direction:  <ins> For each MediaStream that was associated with the transceiver when it was created via addTrack or addTransceiver, an "a=msid" 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. </ins> Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted.  <ins> For RtpTransceivers that are not stopped, the "a=msid" line(s) MUST stay the same, regardless of changes to the transceiver's direction or track.  If no "a=msid" line is present in the current description, "a=msid" line(s) MUST be generated according to the same rules as for an initial answer. </ins> 5.3.3. specified in RFC3605, Section 2.1, but its value is ignored, as this information is superfluous when using ICE.  <ins> If present, "a=msid" attributes MUST be parsed as specified in I- D.ietf-mmusic-msid, Section 3.2, and their values stored. </ins> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.


lines, as specified in RFC4566, Section 6, and RFC3264, Section 5.1. <del> If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, indicating the maximum amount of media, specified in milliseconds, that can be encapsulated in each packet, as specified in RFC4566, Section 6.  This value is set to the smallest of the maximum duration values across all the codecs included in the m= section. If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </del> For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the specific usage for each media type is outlined in Sections 4 and 5.  For each supported RTP header extension, an "a=extmap" line, as specified in RFC5285, Section 5.  The list of header extensions that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp- feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. <del> If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section for this media type, an "a=bundle-only" line. </del> If the RtpTransceiver has a sendrecv or sendonly direction: An "a=msid" line, as specified in I-D.ietf-mmusic-msid, simulcast, Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section.  The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a unique address or which are associated with the bundle-tag.  (In above, an m= section MUST be generated for it with the port set to zero and the "a=msid" line removed. <del> For RtpTransceivers that are not stopped, the "a=msid" line MUST </del>  stay the same if they are present in the current description. Each "m=" and c=" line MUST be filled in with the port, protocol, lines, as specified in RFC4566, Section 6, and RFC3264, Section 6.1. <del> If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, as described in sec-create-offer. If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </del> If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an specific usage for each media type is outlined in Sections 4 and 5.  For each supported RTP header extension that is present in the offer, an "a=extmap" line, as specified in RFC5285, Section 5. The list of header extensions that SHOULD/MUST be supported is

It's a transport attribute, so it should come at the end, like other transport attribs
just checking ... this is just a style thing right? the code would accept SDP with these in any order ?
Of course. This is just how we order things in Section 5.
For createoffer, createanswer ordering of attribs
So SDP has no requirement on the ordering of the a= lines. I don't see how a parser, even a JSEP one can expect to get the a= lines in any specific order. I fear that even a "it is recommended to generate them in this order" will be misinterpreted. I think this is one of SDPs warts that you will have to live with.
Right, there isn't any need to mandate an order, I just think that in the text for generating an offer, the places that talk about adding a=rtpmap should be adjacent. This should be a fairly trivial editorial change.

lines, as specified in RFC4566, Section 6, and RFC3264, Section 5.1.  For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the specific usage for each media type is outlined in Sections 4 and 5. <ins> If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, indicating the maximum amount of media, specified in milliseconds, that can be encapsulated in each packet, as specified in RFC4566, Section 6.  This value is set to the smallest of the maximum duration values across all the codecs included in the m= section. If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> For each supported RTP header extension, an "a=extmap" line, as specified in RFC5285, Section 5.  The list of header extensions that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp- feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1.  If the RtpTransceiver has a sendrecv or sendonly direction: An "a=msid" line, as specified in I-D.ietf-mmusic-msid, simulcast, Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. <ins> If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section for this media type, an "a=bundle-only" line. </ins> The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a unique address or which are associated with the bundle-tag.  (In above, an m= section MUST be generated for it with the port set to zero and the "a=msid" line removed.  <ins> For RtpTransceivers that are not stopped, the "a=msid" lines MUST </ins> stay the same if they are present in the current description. Each "m=" and c=" line MUST be filled in with the port, protocol, lines, as specified in RFC4566, Section 6, and RFC3264, Section 6.1.  If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an specific usage for each media type is outlined in Sections 4 and 5. <ins> If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, as described in sec-create-offer. If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> For each supported RTP header extension that is present in the offer, an "a=extmap" line, as specified in RFC5285, Section 5. The list of header extensions that SHOULD/MUST be supported is


sctp-sdp.  The "fmt" value MUST be set to "webrtc-datachannel" as specified in I-D.ietf-mmusic-sctp-sdp, Section 4.1. <del> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </del>  Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST "application" and the <proto> and "fmt" fields MUST be set to exactly match the fields in the offer. <del> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", "a=candidate", "a=fingerprint", "a=dtls-id", and "a=setup" lines MUST be included under the conditions described above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp- sdp, Section 4.1. </del>  If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as

NAME revised
Fixed by
Maybe in create-answer as well
The "Initial Offers" section does not distinguish systematically between requirements that apply for any type of offer and the ones that apply only to mediastreams. For instance: I think this should apply both to mediastreamtrack and to datachannels. Then many of the rules described under "Each m= section MUST include the following attribute lines:" seem specific to mediastreams, but not all; and that set of rules is then followed by a statement that a m= section must be created for data channels. This could use some reorganization and clarification.
Agree this could be refactored a bit. Magnus had a similar comment in the past.
Suggest contact with Magnus or Jessep for potential language.
I think this is mostly editorial and as such probably needs to be resolved within the author team.
Can this be considered fixed now? The createOffer section has since been structured into "here's what you generate for each RtpTransceiver", "here's what you generate if there's a data channel". And the data channel requirements look complete to me:
I agree with NAME NAME shall we close this?
I think the concern was that the data channel paragraphs feel a bit like an afterthought. I think this could be improved, but I don't think the current situation is dire.
I can live with the current text as is. Done is a feature and I don't think this will cause any interoperability problems.
This text has been improved as of PR . If we can and this text still reads well, I think we can close this issue.
Pending resolution of
is it's own bug. I think we an just close this and any changes needed can be dealt with by
I want to take one last editorial pass over the text once lands. This is a purely editorial issue at this point.

sctp-sdp.  The "fmt" value MUST be set to "webrtc-datachannel" as specified in I-D.ietf-mmusic-sctp-sdp, Section 4.1.  <ins> Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line referencing the SCTP port number, as defined in I-D.ietf-mmusic-sctp- sdp, Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in I-D.ietf-mmusic-sctp-sdp, Section 6.1. As discussed above, the following attributes are included only if the m= section either has a unique address or is associated with the bundle-tag: "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup". </ins> Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST "application" and the <proto> and "fmt" fields MUST be set to exactly match the fields in the offer.  <ins> Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line referencing the SCTP port number, as defined in I-D.ietf-mmusic-sctp- sdp, Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in I-D.ietf-mmusic-sctp-sdp, Section 6.1. As discussed above, the following attributes are included only if the m= section is not bundled into another m= section: "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup". </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as


The SDP for |offer-B1| looks like: <del> The SDP for |candidate-B1| looks like: </del>  <del> The SDP for |candidate-B2| looks like: </del>  The SDP for |answer-B1| looks like: <del> The SDP for |candidate-B3| looks like: </del>  <del> The SDP for |candidate-B4| looks like: </del>  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

a=rtcp-mux-only LS groups
Relevant to , although there are a few nits remaining which will be handled in a followup PR
FWIW, this is atop
Added machine-filling of candidate artwork tags as well in this PR.
Follow new rules for a=rtcp, duplication of attributes Add dtls-id, rtcp-mux-only Maybe add imageattr
adds dtls-id, and I think follows the new rules for a=rtcp and attrib duplication. It doesn't yet handle the second example or do rtcp-mux-only.
Fixed by

The SDP for |offer-B1| looks like:  <ins> The SDP for |offer-B1-candidate-1| looks like: </ins>  <ins> The SDP for |offer-B1-candidate-2| looks like: </ins> The SDP for |answer-B1| looks like:  <ins> The SDP for |answer-B1-candidate-1| looks like: </ins>  <ins> The SDP for |answer-B1-candidate-2| looks like: </ins> 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


SRTP configurations, but an answer may only contain a single SRTP configuration.  [[OPEN ISSUE: See issue 10 above.]] <del> Lastly, while the exact media parameters are only known only after a </del>  offer and an answer have been exchanged, it is possible for the offerer to receive media after they have sent an offer and before they have received an answer.  To properly process incoming media in JSEP applications typically inform the browser to begin ICE gathering via the information supplied to setLocalDescription, as this is where <del> the app specifies the number of media streams to gather candidates for.  However, to accelerate cases where the browser knows the number of media streams to use ahead of time, the application MAY ask the browser to gather a pool of potential ICE candidates to help ensure rapid media setup.  When setLocalDescription is eventually called, and the browser 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 callback.  If the pool becomes depleted, either because a larger-than-expected number of media streams is used, or because the pool has not had enough time to RFC3261 defines both a "Parallel Search" and "Sequential Search". Although these are primarily signaling level issues that are outside the scope of JSEP, they do have some impact on the configuration of <del> the media plane which is relevant.  When forking happens at the </del>  signaling layer, the Javascript application responsible for the signaling needs to make the decisions about what media should be sent or received at any point of time, as well as which remote endpoint it Each m= section, provided it is not being bundled into another m= section, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Otherwise, it MUST use the same <del> ICE credentials and candidates that were used in the m= section that it is being bundled into.  Note that this means that for offers, any m= sections which are not bundle-only MUST have unique ICE credentials and candidates, since it is possible that the answerer will accept them without bundling them. </del>  For DTLS, all m= sections MUST use the certificate for the identity that has been specified for the PeerConnection; as a result, they <del> MUST all have the same RFC4572fingerprint value, or this value MUST </del>  be a session-level attribute. Each m= section should be generated as specified in RFC4566, For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the <del> payload type fo the primary codec, as specified in RFC4588, </del>  Section 8.1. For each supported FEC mechanism, a corresponding "a=rtpmap" line further processing for this m= section can be skipped. Provided that is not the case, each m= section in the answer should <del> then generated as specified in RFC3264, Section 6.1.  Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/ </del>  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 associated local MediaStreamTrack, the appropriate directionality attribute, as specified in RFC3264, Section 6.1.  If the offer was sendrecv, and the remote MediaStreamTrack is still "live", and <del> there a local MediaStreamTrack has been associated, the </del>  directionality MUST be set as sendrecv.  If the offer was sendonly, and the remote MediaStreamTrack is still "live", the directionality MUST be set as recvonly.  If the offer was For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264, Section 6.1.  For audio, the codecs specified in I- <del> D.ietf-rtcweb-audio, Section 3, MUST be be supported.  Note that for simplicity, the answerer MAY use different payload types for </del>  codecs than the offerer, as it is not prohibited by Section 6.1. If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an <del> "a=fmtp" line that references the payload type fo the primary </del>  codec, as specified in RFC4588, Section 8.1. For each supported FEC mechanism that is present in the offer, a gathering phase, an "a=candidate" line, as specified in RFC5245, Section 4.3., paragraph 3. <del> For the current default candidate, a "c=" line, as specific in </del>  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.

LGTM
LGTM with nit above
URL Justin to respond on the list and the changes to be attached to this issue.
Editorial changes: Section 3.2, Paragraph 4 Should read "only after an offer". yep Section 3.4.2, Paragraph 1 "... the number of media streams for which to gather candidates." ok, not a fan of ending a sentence with a preposition, I see. I'll go along with this one. Section 3.5, Paragraph 1 Should say, "... the media plane that is relevant." yep Section 4.1.5, Paragraph 2 and 3 Maybe I'm alone on this but I prefer the following: "Calling this API changes the local media state." The API doesn't do anything on its own, but is a mechanism for calling some action. (Same issue as above) "The candidate gathering process is indirectly controlled through this API." Will think this over. Overall, want to be consistent in how the term 'API' is used. Section 5.2.1, Paragraph 4 "into which it is being bundled." ok Section 5.2.1, Paragraph 5 Space needed after RFC reference. yep Section 5.2.1, Paragraph 7, bullet 6 "of" yep Section 5.2.1, Paragraph 7, bullet 11 "specified" yep Section 5.3.1, Paragraph 7 "URL then be generated..." yep Section 5.3.1, Paragraph 7, bullet 4 "... and there is a local MediaStreamTrack that has been associated ..." indeed, not my best work Section 5.3.1, Paragraph 7, bullet 5 "... Section 3, MUST be supported." yep Section 5.3.1, Paragraph 7, bullet 6 "... the payload type of the primary..." yep Section 5.3.1, Paragraph 7, bullet 11 "... as specified in ..." yep

SRTP configurations, but an answer may only contain a single SRTP configuration.  [[OPEN ISSUE: See issue 10 above.]]  <ins> Lastly, while the exact media parameters are only known only after an </ins> offer and an answer have been exchanged, it is possible for the offerer to receive media after they have sent an offer and before they have received an answer.  To properly process incoming media in JSEP applications typically inform the browser to begin ICE gathering via the information supplied to setLocalDescription, as this is where  <ins> the app specifies the number of media streams for which to gather candidates.  However, to accelerate cases where the browser knows the number of media streams to use ahead of time, the application MAY ask the browser to gather a pool of potential ICE candidates to help ensure rapid media setup.  When setLocalDescription is eventually called, and the browser 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 </ins> application immediately via the ICE candidate callback.  If the pool becomes depleted, either because a larger-than-expected number of media streams is used, or because the pool has not had enough time to RFC3261 defines both a "Parallel Search" and "Sequential Search". Although these are primarily signaling level issues that are outside the scope of JSEP, they do have some impact on the configuration of  <ins> the media plane that is relevant.  When forking happens at the </ins> signaling layer, the Javascript application responsible for the signaling needs to make the decisions about what media should be sent or received at any point of time, as well as which remote endpoint it Each m= section, provided it is not being bundled into another m= section, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Otherwise, it MUST use the same  <ins> ICE credentials and candidates as the m= section into which it is being bundled.  Note that this means that for offers, any m= sections which are not bundle-only MUST have unique ICE credentials and candidates, since it is possible that the answerer will accept them without bundling them. </ins> For DTLS, all m= sections MUST use the certificate for the identity that has been specified for the PeerConnection; as a result, they  <ins> MUST all have the same RFC4572 fingerprint value, or this value MUST </ins> be a session-level attribute. Each m= section should be generated as specified in RFC4566, For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the  <ins> payload type of the primary codec, as specified in RFC4588, </ins> Section 8.1. For each supported FEC mechanism, a corresponding "a=rtpmap" line 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.  Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/ </ins> 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 associated local MediaStreamTrack, the appropriate directionality attribute, as specified in RFC3264, Section 6.1.  If the offer was sendrecv, and the remote MediaStreamTrack is still "live", and  <ins> there is a local MediaStreamTrack that has been associated, the </ins> directionality MUST be set as sendrecv.  If the offer was sendonly, and the remote MediaStreamTrack is still "live", the directionality MUST be set as recvonly.  If the offer was For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264, Section 6.1.  For audio, the codecs specified in I-  <ins> D.ietf-rtcweb-audio, Section 3, MUST be supported.  Note that for simplicity, the answerer MAY use different payload types for </ins> codecs than the offerer, as it is not prohibited by Section 6.1. If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an  <ins> "a=fmtp" line that references the payload type of the primary </ins> codec, as specified in RFC4588, Section 8.1. For each supported FEC mechanism that is present in the offer, a gathering phase, an "a=candidate" line, as specified in RFC5245, Section 4.3., paragraph 3.  <ins> For the current default candidate, a "c=" line, as specified in </ins> 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.


The "a=rtcp-rsize" line MUST only be added if present in the most recent answer.  The "a=group:BUNDLE" attribute MUST include the mid identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or

BUNDLE S 6.
I think we should hold this until Taylor's mmusic comments are resolved.
cf. URL
It doesn't seem like BUNDLE is going to change at this point; the disadvantages of using "bundle-only" in subsequent offers are that non-BUNDLE-aware middleboxes may be unhappy with a port of "0", and also, the answerer can't reject the offerer BUNDLE-tag section without rejecting the whole group (URL). I think the latter restriction is unnecessary (and it actually breaks some WebRTC max-bundle corner cases), but it doesn't sound like it's going to be changed. Speaking of which, if we're being thorough, we should address those corner cases. In "creating an answer", we should specify that if the answer rejects all the offerered m= sections with nonzero ports, it must also reject the m= sections with "a=bundle-only". So, if you're offered transceivers A, B and C with "a=bundle-only", and you do , the answer will reject A and B/C.
talked to chairs and advice from chairs on this and similar things that depend on mmusic outcomes. We put in JSEP now what our best gueses is of how mmusic will end up and publish JSEP. At the same time we log a bug to check if we need to make any changes to line up with what mmusic decides. We can take changes to line up with mmusic as Last Call comments later on.
NAME NAME I think this should resolve it.
NAME this revised version needs your signoff + merge In an initial offer, if we want to communicate "this 'm=' section must be either bundled or rejected", that's accomplished with "a=bundle-only": a=group:BUNDLE A B m=audio 10000 ... a=mid:A ... m=video 0 ... a=mid:B a=bundle-only In subsequent offers, this is accomplished by duplicating the IP address/port (see section 8.3.3): a=group:BUNDLE A B m=audio 10000 ... a=mid:A ... m=video 10000 ... a=mid:B Is this initial vs. subsequent offer difference necessary? Both blobs of SDP are communicating the same information, so the "shared address" rules seem to only add complexity. Also, the approach of using a "shared address" to communicate something isn't extensible to protocols that don't use an address for identification, like ICE. We'd need to define additional rules for those cases, or allow them specifically to use "a=bundle-only" in subsequent offers.

The "a=rtcp-rsize" line MUST only be added if present in the most recent answer. <ins> An "a=bundle-only" line MUST NOT be added, as indicated in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 6.  Instead, JSEP implementations MUST simply omit parameters in the IDENTICAL and TRANSPORT categories for bundled m= sections, as described in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1. </ins> The "a=group:BUNDLE" attribute MUST include the mid identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or


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 <del> produce in an offer.  Because ICE can select either TCP or UDP transport depending on network conditions, this advertisement is consistent with ICE eventually selecting either either UDP or TCP. </del>  Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of

NAME I cleaned up as you suggested.
this is TCP Candidates with Interactive Connectivity Establishment (ICE)
We could have an informative reference for S 5.1.3 where we mention ICE can use UDP or TCP.
LGTM

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  <ins> produce in an offer.  Because ICE can select either UDP RFC5245 or TCP RFC6544 transport depending on network conditions, this advertisement is consistent with ICE eventually selecting either either UDP or TCP. </ins> Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of


the most preferred media format from the remote description that is also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the <del> underlying transport layers have been established.  If a SSRC </del>  has not already been chosen for this outgoing RTP stream, <del> choose a random one. </del>  The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams, including

URL
This doesn't affect SDP, but we could add some text to the para below indicating a SSRC switch is needed when changing to a codec with a different clockrate: If the directional attribute in the answer is of type "sendrecv" or "sendonly", choose the media format to send as the most preferred media format from the remote description that is also present in the answer, as described in [RFC3264], Sections 6.1 and 7, and start transmitting RTP media once the underlying transport layers have been established. If a SSRC has not already been chosen for this outgoing RTP stream, choose a random one.
(and add a reference)
Closing per

the most preferred media format from the remote description that is also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the  <ins> underlying transport layers have been established.  If an SSRC </ins> has not already been chosen for this outgoing RTP stream,  <ins> choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as specified in RFC7160, Section 3.1. </ins> The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams, including


support.  For codecs that have their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is <del> desired.  For example, when using the Opus codec, the "usedtx=1" parameter would be specified in the offer.  This option allows the endpoint to significantly reduce the amount of audio bandwidth it receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. </del>  If the "VoiceActivityDetection" option is specified, with a value of "false", the JSEP implementation MUST NOT emit "CN" codecs.  For

Since the second ref is so close to the first, I decided it wasn't needed.
Yes, we need a reference for 7587, since we talk about usedtx. It might make sense to have one for 6716 as well in S 5.2.3.2.
Looks good. Do you think we need a similar ref to 7587 in the para that discusses dtx=0?

support.  For codecs that have their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is  <ins> desired.  For example, when using the Opus codec RFC6716, the "usedtx=1" parameter, specified in RFC7587, would be used in the offer.  This option allows the endpoint to significantly reduce the amount of audio bandwidth it receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. </ins> If the "VoiceActivityDetection" option is specified, with a value of "false", the JSEP implementation MUST NOT emit "CN" codecs.  For


minimizing perceived post-dial-delay.  The second offer/answer exchange can also change the preferred codecs or other information.  The SDP for |offer-C1| looks like: The SDP for |offer-C1-candidate-1| looks like:

Good way of getting ICE going quickly, and shows off IceTransportPolicy. Consider ICE restart for second offer (shows off ICE restart handling). Could also go into complex example.
Started on this.

minimizing perceived post-dial-delay.  The second offer/answer exchange can also change the preferred codecs or other information. <ins> This example also makes use of the "relay" ICE candidate policy described in sec.ice-candidate-policy to minimize the ICE gathering and checking needed. </ins> The SDP for |offer-C1| looks like: The SDP for |offer-C1-candidate-1| looks like:


offerer to be maintained, and so the subsequent answer will contain an identical "LS" group. <del> The sec.normal-example example later in this document shows a more </del>  involved case of "LS" group generation. The next step is to generate m= sections for each m= section that is 7.1. This section shows a very simple example that sets up a minimal audio <del> / video call between two JSEP endpoints and does not use trickle ICE. The example in the following section provides a more realistic example of what would happen in a normal browser to browser connection. The flow shows Alice's endpoint initiating the session to Bob's endpoint.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server.  The JS on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete.  Trickle ICE is not used.  Both Alice and Bob are using the default policy of balanced. </del>  The SDP for |offer-A1| looks like: 7.2. <del> This section shows a typical example of a session between two JSEP endpoints setting up an audio channel and a data channel.  Trickle ICE is used in full trickle mode with a bundle policy of max-bundle, an RTCP mux policy of require, 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 endpoint initiating the session to Bob's endpoint.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server. </del>  The SDP for |offer-B1| looks like: <del> The SDP for |offer-B1-candidate-1| looks like: </del>  <del> The SDP for |offer-B1-candidate-2| looks like: </del>  <del> The SDP for |offer-B1-candidate-3| looks like: </del>  The SDP for |answer-B1| looks like: <del> The SDP for |answer-B1-candidate-1| looks like: </del>  <del> The SDP for |answer-B1-candidate-2| looks like: </del>  <del> The SDP for |answer-B1-candidate-3| looks like: </del>  <del> 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) </del>  <del> 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) </del>  8. sec.use-of-provisional-answer.  Here, Alice's endpoint sends an offer to Bob's endpoint to start an audio/video call.  Bob immediately responds with an answer that accepts the audio/video m= sections, but <del> marks them as sendonly (from its perspective), meaning that Alice </del>  will not yet send media.  This allows the JSEP implementation to start negotiating ICE and DTLS immediately.  Bob's endpoint then prompts him to answer the call, and when he does, his endpoint sends before the second offer is sent, then media can be transmitted immediately by the callee immediately upon answering the call, minimizing perceived post-dial-delay.  The second offer/answer <del> exchange can also change the preferred codecs or other information. </del>  This example also makes use of the "relay" ICE candidate policy described in sec.ice-candidate-policy to minimize the ICE gathering The SDP for |offer-C1| looks like: <del> The SDP for |offer-C1-candidate-1| looks like: </del>  The SDP for |answer-C1| looks like: <del> The SDP for |answer-C1-candidate-1| looks like: </del>  The SDP for |offer-C2| looks like:

a=simulcast, a=rid a=imageattr (maybe) differing codecs/preferences for either side
I started on this; should be straightforward

offerer to be maintained, and so the subsequent answer will contain an identical "LS" group.  <ins> The sec.detailed-example example later in this document shows a more </ins> involved case of "LS" group generation. The next step is to generate m= sections for each m= section that is 7.1. This section shows a very simple example that sets up a minimal audio  <ins> / video call between two JSEP endpoints without using trickle ICE. The example in the following section provides a more detailed example of what could happen in a JSEP session. The code flow below shows Alice's endpoint initiating the session to Bob's endpoint.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server.  The JS on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete; trickle ICE is not used.  Both Alice and Bob are using the default bundle policy of "balanced", and the default RTCP mux policy of "require". </ins> The SDP for |offer-A1| looks like: 7.2.  <ins> This section shows a more involved example of a session between two JSEP endpoints.  Trickle ICE is used in full trickle mode, with a bundle policy of "max-bundle", an RTCP mux policy of "require", and a single TURN server.  Initially, both Alice and Bob establish an audio channel and a data channel.  Later, Bob adds two video flows, one for his video feed, and one for screensharing, both supporting FEC, and with the video feed configured for simulcast.  Alice accepts these video flows, but does not add video flows of her own, so they are handled as recvonly.  Alice also specifies a maximum video decoder resolution. </ins> The SDP for |offer-B1| looks like:  <ins> |offer-B1-candidate-1| looks like: </ins>  <ins> |offer-B1-candidate-2| looks like: </ins>  <ins> |offer-B1-candidate-3| looks like: </ins> The SDP for |answer-B1| looks like:  <ins> |answer-B1-candidate-1| looks like: </ins>  <ins> |answer-B1-candidate-2| looks like: </ins>  <ins> |answer-B1-candidate-3| looks like: </ins>  <ins> The SDP for |offer-B2| is shown below.  In addition to the new m= sections for video, both of which are offering FEC, and one of which is offering simulcast, note the increment of the version number in the o= line, changes to the c= line, indicating the local candidate that was selected, and the inclusion of gathered candidates as a=candidate lines. </ins>  <ins> The SDP for |answer-B2| is shown below.  In addition to the acceptance of the video m= sections, the use of a=recvonly to indicate one-way video, and the use of a=imageattr to limit the received resolution, note the use of setup:passive to maintain the existing DTLS roles. </ins> 8. sec.use-of-provisional-answer.  Here, Alice's endpoint sends an offer to Bob's endpoint to start an audio/video call.  Bob immediately responds with an answer that accepts the audio/video m= sections, but  <ins> marks them as sendonly (from his perspective), meaning that Alice </ins> will not yet send media.  This allows the JSEP implementation to start negotiating ICE and DTLS immediately.  Bob's endpoint then prompts him to answer the call, and when he does, his endpoint sends before the second offer is sent, then media can be transmitted immediately by the callee immediately upon answering the call, minimizing perceived post-dial-delay.  The second offer/answer  <ins> exchange can also change the preferred codecs or other session parameters. </ins> This example also makes use of the "relay" ICE candidate policy described in sec.ice-candidate-policy to minimize the ICE gathering The SDP for |offer-C1| looks like:  <ins> |offer-C1-candidate-1| looks like: </ins> The SDP for |answer-C1| looks like:  <ins> |answer-C1-candidate-1| looks like: </ins> The SDP for |offer-C2| looks like: