W3C home > Mailing lists > Public > public-ortc@w3.org > June 2014

Re: CNAME use

From: Emil Ivov <emcho@jitsi.org>
Date: Sat, 07 Jun 2014 01:14:17 +0300
Message-ID: <53923D39.2070005@jitsi.org>
To: Robin Raymond <robin@hookflash.com>, "public-ortc@w3.org" <public-ortc@w3.org>
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
Received on Friday, 6 June 2014 22:14:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:18 UTC