Re: PeerConnection lifecycle/navigation/page reloads

Right. The PC lifetime is bound to the page, but with JSEP, you can get the
new PC back to the same state as the old one by cramming in the session
descriptions from the old PC.

On Thu, Jan 26, 2012 at 3:22 PM, Matthew Kaufman
<matthew.kaufman@skype.net>wrote:

> > -----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
>
>
>