Draft: draft-ietf-rtcweb-jsep

Commentary: This Replaces PR This fixes 
 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 there as well . 
 lgtm 
 While cname for offers is described quite clearly , the sections describing answers do n't mention CNAME . 
 This should get handled in 
 I do n'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 . ,   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 
 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 .
Paragraph (version A):
JSEP does not specify a particular signaling model or state machine,
other than the generic need to exchange SDP media descriptions in the
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
a session.  However, the browser is totally decoupled from the actual
mechanism by which these offers and answers are communicated to the
remote side, including addressing, retransmission, forking, and glare
handling.  These issues are left entirely up to the application; the
application has complete control over which offers and answers get
handed to the browser, and when.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
"answer" indicates that a description should be parsed as an answer,
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
response to a "offer", or an update to a previously sent "pranswer".
Paragraph (version A):
The setLocalDescription method instructs the PeerConnection to apply
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.
Paragraph (version A):
The setRemoteDescription method instructs the PeerConnection to apply
the supplied SDP blob as the desired remote configuration.  As in
setLocalDescription, the type field of the indicates how the blob
should be processed.
Paragraph (version B):
The setRemoteDescription method instructs the PeerConnection to apply
the supplied session description as the desired remote configuration.
As in setLocalDescription, the type field of the description
indicates how it should be processed.
Paragraph (version B):
An "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating
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
accordance with RFC7022 and sec.cname.
Paragraph (version A):
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.
Paragraph (version B):
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, 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.