Re: PeerConnection lifecycle/navigation/page reloads

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.


On Jan 26, 2012, at 1:14 PM, Eric Rescorla wrote:

> The JSEP draft raises an interesting point that I think is actually an API
> issue in part: what's the interaction of PeerConnection with navigation
> and especially page reloads:
> 
>   The browser environment also has its own challenges that cause
>   problems for an embedded signaling state machine. One of these is
>   that the user may reload the web page at any time. If this happens,
>   and the state machine is being run at a server, the server can simply
>   push the current state back down to the page and resume the call
>   where it left off. If instead the state machine is run at the browser
>   end, and is instantiated within, for example, the PeerConnection
>   object, that state machine will be reinitialized when the page is
>   reloaded and the JavaScript re-executed.
> 
> This sounds great for the call initiation sequence, but I'm a little more
> vague on what happens if you're in the middle of a call. I'd always
> assumed that the PeerConnection lifetime (and hence all
> the streams, etc.) was bound to the page, so that when you
> exited the page, all the resources were destroyed and you lost
> your call--and that if you didn't want that, you needed to somehow
> keep a handle to the PeerConnection in a worker or something to
> keep it alive.
> 
> What are people's views on the expected behavior here?
> 
> Thanks,
> -Ekr
>

Received on Thursday, 26 January 2012 20:51:47 UTC