Change:
This Replaces PR URL This fixes URL
I cleaned up the text here.
The structure of this looks good - just think the text should be expanded a bit.
This should incorporate the change in - and reference URL there as well.
lgtm
While cname for offers is described quite clearly, the sections describing answers don't mention CNAME.
This should get handled in NAME
I don't think that is the place. Looking at section 5.3.1. Initial answer, there is text saying 'If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media.' There should be something about cname here as well, just as it is for the corresponding part in section 5.2.1 Initial Offer.
Right, but is making changes to 5.2.1, so that's probably the right place to change 5.3.1 as well.
I saw Ekr updated and closed this one. Makes sense. , Justin Uberti EMAIL wrote:
Section 5.2.1: in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs specified for MSTs? Are they randomly generated for each MediaStream? If so, can two MediaStreams be synced?]
Discussion on rtp usage more or less concluded that we'd use the same CNAME for an entire RTCPeerConnection, unless the tracks had different clock sources. And require different CNAMEs for different RTCPeerConnections, unless something had forced them to be the same. API affordances for this are TBD and for the W3C WG, Magnus suggested some sort of binding between RTCPeerConnection instances to allow for CNAME copying, rather than provide the footgun that direct overwriting permits (i.e., the browser is given the ability to mark unsynchronized tracks differently, rather than be forced to falsely claim synchronization).
Discussed in DC: this resolution is OK. Question about the use of LS groups for legacy gear, as opposed to MSID. See .
Related but URL
What are next steps here?
Propose browser generates one CNAME (or more if multiple clock sources). Later API may add ways to set the CNAME from JS.
That would be consistent with the RTP usage conclusions.

Discussion:
3.1. JSEP does not specify a particular signaling model or state machine, <del> other than the generic need to exchange SDP media descriptions in the </del> <ins> other than the generic need to exchange session descriptions in the </ins> fashion described by RFC3264 (offer/answer) in order for both sides of the session to know how to conduct the session.  JSEP provides mechanisms to create offers and answers, as well as to apply them to

3.5. <ins> RTP CNAME values provide a canonical name for the RTP endpoint, allowing other RTP endpoints to determine which RTP streams are using the same clock and thus which clock sources can be used that to synchronize media playout. Any MediaStreamTracks which have different clock sources MUST have different CNAMEs [TODO: need a reference for this.]  Any MediaStreamTracks which are in different PeerConnection objects MUST have different CNAMEs; this prevents peers from linking calls from multiple remote PeerConnections based on the CNAME.  For simplicity, MediaStreamTracks in the same PeerConnection which have the same clock source SHOULD have the same CNAME. 3.6. </ins> Some call signaling systems allow various types of forking where an SDP Offer may be provided to more than one device.  For example, SIP RFC3261 defines both a "Parallel Search" and "Sequential Search".

Start exchanging media with a given remote peer, and free any resources in the offer that are not being used. <del> 3.5.1. </del> <ins> 3.6.1. </ins> Sequential forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, but only one

with a timer; at this point, the application could reapply the existing remote description as a final answer. <del> 3.5.2. </del> <ins> 3.6.2. </ins> Parallel forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, and multiple

the offer-answer exchange should be considered complete, and any resources (decoders, candidates) that are no longer needed can be released.  A description used as an "answer" may be applied as a <del> response to a "offer", or an update to a previously sent "pranswer". </del> <ins> response to an "offer", or an update to a previously sent "pranswer". </ins> The only difference between a provisional and final answer is that the final answer results in the freeing of any unused resources that

4.1.5. The setLocalDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as its local configuration.  The type field indicates whether the blob should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </del> <ins> the supplied session description as its local configuration.  The type field indicates whether the description should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </ins> This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to

4.1.6. The setRemoteDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as the desired remote configuration.  As in setLocalDescription, the type field of the indicates how the blob should be processed. </del> <ins> the supplied session description as the desired remote configuration. As in setLocalDescription, the type field of the description indicates how it should be processed. </ins> This API changes the local media state; among other things, it sets up local resources for sending and encoding media.

the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME must be generated in <del> accordance with RFC7022.  [OPEN ISSUE: How are CNAMEs specified for MSTs?  Are they randomly generated for each MediaStream?  If so, can two MediaStreams be synced?  See: https://github.com/ rtcweb-wg/jsep/issues/4] </del> <ins> accordance with RFC7022 and sec.cname. </ins> If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in

If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating the SSRC to be <del> used for sending media. </del> <ins> used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME must be generated in accordance with RFC7022 and sec.cname. </ins> If a local MediaStreamTrack has been associated, and RTX has been negotiated for this m= section, another "a=ssrc" line with the RTX

Changes MUST NOT be silently ignored. <del> The following elements of the SDP media description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </del> <ins> The following elements of the session description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </ins> The number, type and port number of m= lines.