CNAME and synchronization contexts #94

aboba opened this Issue Jun 2, 2014 · 6 comments


None yet

2 participants

aboba commented Jun 2, 2014

From: Emil Ivov
Date: Sat, 31 May 2014 10:25:55 +0200
To: ""

We have been looking at recording WebRTC conferences lately and have
noticed how Chrome sends different CNAMEs for every media source.

CNAMEs have traditionally been used to determine whether two streams are
synchronise-able so having unique CNAMEs for an audio and a video flow
originating at the same host is kind of awkward.

Do we have a position on this for ORTC implementations? Should they be
encouraged to share CNAMEs within the same session (page). If not, then
should we provide a way for the page to control that?

aboba commented Jun 6, 2014

Based on Emil's response, it would appear that developers can live without additional functionality:

aboba commented Jun 9, 2014

Given that there does not appear to be an API requirement here, I am going to close this. If you feel that is wrong, please reopen and give your idea of the requirements.

@aboba aboba closed this Jun 9, 2014
aboba commented Jun 20, 2014

From Robin:

So based on this, I suggest we add a “cname" property to the “parameters.rtcp” dictionary.

Developer could then override and force a cname on a sender/receiver:
parameter.rtcp.cname = “myvalue”;

and to learn the defaulted value, get the ‘parameters’ object to get the default value:
var cname = sender.getParameters().rtcp.cname;

Assuming others think the “rtcp” dictionary is the appropriate spot for getting/setting the cname...

@aboba aboba reopened this Jun 20, 2014

We need to define the behaviour in the specification for cname.

@robin-raymond robin-raymond added the 1.1 label Jun 28, 2014
aboba commented Jul 14, 2014

How about this for Section 9.6.1?

"cname of type DOMString

The Canonical Name (CNAME) used by RTCP (e.g. in SDES messages). Guidelines for CNAME generation are provided in [RTP-USAGE] Section 4.9. By default, ORTC implementations should set the CNAME to be the same within all RTCRtcpParameter objects created within the same Javascript sandbox. However, for backward compatibility with WebRTC 1.0, applications may set the cname to an alternative value."

@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Jul 16, 2014
Robin Raymond Added section on WebRTC 1.0 compatibility issues, responding to Issue #…

Added Identity support, as described in Issue #78
Reworked getStats method, as described in Issue #85
Removed ICE restart method described in Issue #93
Addressed CNAME and synchronization context issues described in Issue #94
Fixed WebIDL issues noted in Issue #97
Addressed NITs described in Issue #99
DTLS transport issues fixed as described in Issue #100
ICE transport issues fixed as described in Issue #101
ICE transport controller fixes made as described in Issue #102
Sender and Receiver object fixes made as described in Issue #103
Fixed RTCRtpEncodingParameter default issues described in Issue #104
Fixed 'Big Picture' issues descibed in Issue #105
Fixed RTCRtpParameter default issues described in Issue #106
Added a multi-stream capability, as noted in Issue #108
Removed quality scalability capabilities and parameters, as described in Issue #109
Added scalability examples as requested in Issue #110
Addressed WebRTC 1.0 Data Channel compatibility issue described in Issue #111
Removed header extensions from RTCRtpCodecParameters as described in Issue #113
Addressed RTP/RTCP non-mux issues with IdP as described in Issue #114
Added getParameter methods to RTCRtpSender and RTCRtpReceiver objects, as described in Issue #116
Added layering diagrams as requested in Issue #117
Added a typedef for payload type, as described in Issue #118
Moved onerror from the RTCIceTransport object to the RTCIceListener object as described in Issue #121
Added explanation of Voice Activity Detection (VAD), responding to Issue #129
Clarified the meaning of maxTemporalLayers and maxSpatialLayers, as noted in Issue #130
Added RFC 6051 to the list of header extensions and removed RFC 5450, as noted in Issue #131
Addressed ICE terminology issues, as described in Issue #132
Separated references into Normative and Informative, as noted in Issue #133
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment