RE: PeerConnection lifecycle/navigation/page reloads

> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: Thursday, January 26, 2012 12:15 PM
> To: public-webrtc@w3.org
> Subject: PeerConnection lifecycle/navigation/page reloads
> 
> 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?

I would hope that a mid-call reload can be restored by creating a new PeerConnection object and poking at it until you have media flowing again, as quickly as possible. One would hope that most of offer/answer can be shortcutted, all you need is a new ICE exchange and (maybe) rekeying, and you'd be back.

So you "lose the resources" in the browser context, but you don't "lose the call" because the call state lives in a server somewhere and the server and javascript can cooperate to bring your end back right away.

Matthew Kaufman

Received on Thursday, 26 January 2012 20:23:02 UTC