Re: CNAME use

Traditional RFC CNAME it represents the user@host, i.e. it tracks with the user’s device. Thus all streams sent from the same host should have the same CNAME.

However, the RTC usage draft as Bernard quotes is not exactly helpful because it describes things in relation to the “peer connection”. So I suspect what will happen is that a random ID will be generated for the javascript sandbox instance. Thus all connections within the same sandbox will have the same random CNAME thus making synchronization theoretically possible.

So the question I have are:
1) Is there privacy issues if the CNAME is chosen by the system so long as it’s stable across all RTCRtpSender objects within the same javascript session?
2) Do you need to be able to override the CNAME defaulted by the system (if so why)?
3) Do you need to be able to read the CNAME from JS that will be used for sending?
4) Do you need to know on the receiver side from JS what CNAME was used by the remote sender?

We could also force all within the same RTCIceTransportController to share the same CNAME but not sure if that’s possible since RTCRtpSenders can be re-wired to a new RTCIceTransport object, which is why I think CNAME needs to be stable across the entire JS sandboxed session (at least by default).

-- 
Robin Raymond


On May 31, 2014 at 4:26:44 AM, Emil Ivov (emcho@jitsi.org) wrote:

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?  

Emil  



--  
https://jitsi.org