- From: Emil Ivov <emcho@jitsi.org>
- Date: Fri, 25 Apr 2014 13:19:40 +0200
- To: Robin Raymond <robin@hookflash.com>
- CC: "public-ortc@w3.org" <public-ortc@w3.org>
(I don't suppose this was meant to be private so CCing the list again) On 25.04.14, 12:58, Robin Raymond wrote: > > see inline comments > > Emil Ivov wrote: >> >> A minor comment. Does this map 1:1 to an RTP session? I don't think so >> but if it doesn't then how about using a different name? RTCDialog? >> RTCContext? RTCConnection? RTCPeerConnection? > > [RR] Yes, RTCContext or something might be a better name. > >> Second, less minor, I understand the need for a default session and >> trying to spare users from having to mess with it, but am a bit >> worried that one default session per page might not work well. I am >> thinking about cases where one page establishes connections with >> different peers. There are many examples of this today. > > [RR] No, it's not an issue across different peers, at least for the > freezing case because the freezing is based on the combination of the > local and remote foundations being a match and different peers will > cause different local and remote foundation pair values. Thus freezing > only happens within the context of a single peer to peer connection and > never between different peers, i.e. that case not an issue. > >> So I am wondering if this shouldn't be a more obvious and mandatory >> part of the API. > > [RR] I hope we don't find a corner case to mandate a context object > being needed (beyond an auto defaulted one). Right now I don't think we do. Yes, I wasn't really that worried about the ICE part. During the last call however, Justin mentioned a few other reasons where we'd need to use such a context. Not sure I remember them all but synchronisation might have been one. CNAME generation too. Was there anything else? Emil -- https://jitsi.org
Received on Friday, 25 April 2014 11:20:11 UTC