W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2012

Re: PeerConnection lifecycle/navigation/page reloads

From: Randell Jesup <randell-ietf@jesup.org>
Date: Thu, 26 Jan 2012 15:54:57 -0800
Message-ID: <4F21E7D1.9090004@jesup.org>
To: public-webrtc@w3.org
On 1/26/2012 12:51 PM, Cullen Jennings wrote:
> I like to see what existing systems do as a model of what might work. I note that facebook/skype and gmail IM give you a warning dialog asking if you really want to close the page and if you do, it is gone. Hangouts, when you reload, it's just gone with no warning.
>
> I looked at designs  for this for webex and it seems that one way or another, bringing up a new peer connection is the the only thing I can figure out how to get it to work. Assuming the OS will give you the same ports for media as the previous time is uh, not going to work. The hard part even with a new peer connection is how the server can preserve things like permissions to access the camera. As you can imagine, I am not keen on giving webex a cookie that forever allows webex to access my camera any time it wants.

My immediate reaction was that you can't really rebuild the connection 
after as reload without permission from the user (perhaps from both 
ends; need to think about that).  This may interact with some of the 
privacy concerns around ICE and location - and we'd need to re-do 
ICE/etc setup.

My assumption would be a reload (or close/reopen, etc) would end any 
calls.  In particular, the other end of a call would be surprised if the 
call closed but then suddenly re-opened.  At most I'd expect both sides 
to be prompted to restart the call (and give permissions).

Perhaps the "least surprise" solution would be to not even reopen the 
call automatically.

The idea of holding the PC in a worker is interesting, but we need to be 
careful not to leak things, and I'm unsure of the ramifications of 
that.  How long do you hold it?  How well does that help across reloads?

-- 
Randell Jesup
randell-ietf@jesup.org
Received on Thursday, 26 January 2012 23:55:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:26 UTC