Draft: draft-ietf-rtcweb-jsep

Commentary:   
 The CNAME section said nothing by the time I had removed the stuff that was wrong so I just removed the section and updated the relevant references to point at rtp - usage 
 lgtm 
 LGTM 
 H. Section 5.2.1 : o 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 Section 3.5 . I think this document should n't make normative statement to how CNAMEs shall be generated . That last sentence points to RFC7022 , but that is not the whole story . If you like to point to how CNAMEs are to be generated then say that Section 4.9 of RTP - usage is the place to determine that . 
 Agree that JSEP should point at the relevant sections in rtp - usage , and any redundant text in JSEP should be removed . 
 A. Section 3.5 : RTP CNAME Semantics 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 . The main problem is that this is out - of - synch ( Pardon the pun ) with what RTP - usage specifies . See Section 4.9 : I think the relevant is the following : Taking the discussion in Section 11 into account , a WebRTC Endpoint MUST NOT use more than one RTCP CNAME in the RTP sessions belonging to single RTCPeerConnection ( that is , an RTCPeerConnection forms a synchronisation context ) .   MAY generate RTP packet streams associated with more than one RTCP CNAME , to allow them to avoid having to resynchronize media from multiple different endpoints part of a multi - party RTP session . So lets look at the normative statements in JSEP : " Any MediaStreamTracks which have different clock sources MUST have different CNAMEs [ TODO : need a reference for this . ] " This is not allowed by an WebRTC endpoint , which must use only a single CNAME . Although a RTP middlebox can forward multiple CNAMEs , the WebRTC endpoint is instead required to perform re - synchronization into the used clock based of the other streams . " 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 . " This one is correct , but I do n't quite understand the " this prevents peers from linking calls from multiple remote PeerConnections based on the CNAME . " part . First of all what is a " call " . Secondly , what type of linking are you considering here ? " For simplicity , MediaStreamTracks in the same PeerConnection which have the same clock source SHOULD have the same CNAME . " The SHOULD needs to be a MUST . Main conclusion , point more to section 4.9 of RTP - usage . 
 So lets separate out a few things here . There is what a webrtc browser generates , and there is what it needs to be able to receive . I think we are mostly talking about what it needs to generate here . I 'm wondering if perhaps we have to clarify a bit of that . I 'm not sure I agree with RTP Usage on one PC MUST use just one CNAME . What do you do if you have video from two camera with different clock sources in a single PC ? I think the case people were thinking about was where the camera each had their own clock source and they drifted independent of each other . Not sure if I think this case is relevant or not but I suspect that is where it was coming from . We need to sort this out and get the two specs in sync . On the linking ... this was a privacy concern . If I call both facebook ( not anonymous ) and also FBI tip line in an anonymous way , can Facebook and FBI collude to link the two together and realize that the person who called FBI was same person that called Facebook . That was all that was meant by linking . Agree we need to phrase this in some clearer way . 
 Agree with OP ; related to ; I think we should point to 4.9 from our section on CNAMEs , remove redundant text from JSEP , and possibly , remove our section altogether ( if no longer useful ) . 
 " What do you do if you have video from two camera with different clock sources in a single PC ? " We had discussion about this . I am fairly certain that I was a proponent for supporting multiple CNAMEs , but we got push - back . What RTP - usage defines means that the implementation will have to synchronize that second time domain with its local and manage offsets and clock drift . Regarding the linking , there is text in RTP usage about that security issue and there are requirements on CNAME generation to handle that in RTP - usage . I think proposal is the right one here . 
 OK - we will move the draft to that 
 Have a look at
Paragraph (version A):
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 A):
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):
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 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 Section 4.9 of I-D.ietf-rtcweb-rtp-usage.
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, 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 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
Section 4.9 of I-D.ietf-rtcweb-rtp-usage.