Re: PeerConnection lifecycle/navigation/page reloads

On Thu, Jan 26, 2012 at 3:51 PM, Cullen Jennings <fluffy@cisco.com> 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.


Right; it's implicit that the ICE process needs to happen again here, but
the rest of the call state can be preserved.


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

Agree that that's not going to fly. Even so, you could still be rejoined to
the meeting and just have to ack again to turn on your video.

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