- From: Emil Ivov <emcho@jitsi.org>
- Date: Sat, 21 Jun 2014 01:40:26 +0300
- To: Robin Raymond <robin@hookflash.com>, "public-ortc@w3.org" <public-ortc@w3.org>
Sounds good to me! Thanks! On 20.06.14, 21:53, Robin Raymond wrote: > > 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 > <mailto: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 -- https://jitsi.org
Received on Friday, 20 June 2014 22:40:59 UTC