- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Mar 2019 19:36:39 +0000
- To: public-webrtc-logs@w3.org
The CNAME has been reasonably controversial for a long time. It's been suggested (among other things) that it represent a MediaStream, because a MediaStream also tries to impose the requirement to synchronize. But it got rejected because the WebRTC client is free to move tracks between MediaStreams - so we ended up with the current language saying "all tracks from a WebRTC client must have the same CNAME" - indicating to anyone who cares about CNAME as a source of sync info that the WebRTC client has taken responsibility for all the synchronization that needs to be done. The discussions also indicated that the actual use of CNAME to indicate synchronization contexts was not very widespread - it was in the spec, but people didn't care much. When receiving an RTCP packet with a CNAME in it, I think you are in one of two situations: - You're able to assign it to a media section. In that case, all tracks are supposed to represent the same source, which means they're either synchronized, or you have a problem on your hands. - You're not able to assign it to a media section, in which case you've lost anyway. Short version: CNAME is a feature mentioned in the specs, but a) sending the same CNAME on all RTP streams solves the problem for outgoing, and b) ignoring the CNAME entirely on incoming does no harm. So I don't see a problem that needs solving here. -- GitHub Notification of comment by alvestrand Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2114#issuecomment-470245744 using your GitHub account
Received on Wednesday, 6 March 2019 19:36:40 UTC