Change:
fixes URL fixes URL
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 shouldn'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). RTP middleboxes 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 don'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).
NAME "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 NAME proposal is the right one here.
OK - we will move the draft to that
Have a look at URL

Discussion:
3.5. <del> 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. </del> 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

constrain what it receives due to application preferences, e.g. a specific size for the window in which the video will be displayed. <del> 3.6.1. </del> <ins> 3.5.1. </ins> In order to determine the limits on what video resolution a receiver wants to receive, it will intersect its decoder hard limits with any

a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] <del> 3.6.2. </del> <ins> 3.5.2. </ins> RFC6236 defines "a=imageattr" to be an advisory field.  This means that it does not absolutely constrain the video formats that the

In the special case of receiving a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the track. <del> 3.7. </del> <ins> 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

Start exchanging media with a given remote peer, and free any resources in the offer that are not being used. <del> 3.7.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.7.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

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 <del> the CNAME for the source.  The CNAME must be generated in accordance with RFC7022 and sec.cname. </del> <ins> the CNAME for the source.  The CNAME MUST be generated in accordance with Section 4.9 of I-D.ietf-rtcweb-rtp-usage. </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

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 <del> the source.  The CNAME must be generated in accordance with RFC7022 and sec.cname. </del> <ins> the source.  The CNAME MUST be generated in accordance with Section 4.9 of I-D.ietf-rtcweb-rtp-usage. </ins> If a local MediaStreamTrack has been associated, and RTX has been negotiated for this m= section, another "a=ssrc" line with the RTX