Re: CNAME use

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...

-- 
Robin Raymond

On June 6, 2014 at 6:14:24 PM, Emil Ivov (emcho@jitsi.org) wrote:

Hey Robin,  

Apologies for the delay. Replies inline:  

On 03.06.14, 21:00, Robin Raymond wrote:  
>  
> 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.  

This sounds perfectly reasonable to me.  

> 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?  

I can't think of one that's actually worrying me. This part is encrypted  
to the outside world and presumably the service already knows where you  
are anyway.  

> 2) Do you need to be able to override the CNAME defaulted by the system  
> (if so why)?  

I am sure that if it were possible people would use that option ... but  
I can't think of a use case where you can't get by with just being able  
to read it.  

> 3) Do you need to be able to read the CNAME from JS that will be used  
> for sending?  

I suppose so. You certainly need it if you want to be able to generate  
the kind of SDP that Chrome currently does.  

> 4) Do you need to know on the receiver side from JS what CNAME was used  
> by the remote sender?  

Same answer as 2. Possibly nice to have (e.g., for debugging purposes  
... or some signalling) but I can't think of an unsolvable problem if we  
didn't have it.  

> 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).  

Agreed!  

Thanks,  
Emil  
>  
> --  
> Robin Raymond  
>  
>  
> On May 31, 2014 at 4:26:44 AM, Emil Ivov (emcho@jitsi.org  
> <mailto: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  
>>  

--  
https://jitsi.org