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

Re: PeerConnection lifecycle/navigation/page reloads

From: Justin Uberti <juberti@google.com>
Date: Thu, 26 Jan 2012 15:59:12 -0500
Message-ID: <CAOJ7v-2fizobfZKgoCnW+2FauzP7SRsZ0-6YL0M_aiE5YjWLiQ@mail.gmail.com>
To: Cullen Jennings <fluffy@cisco.com>
Cc: Eric Rescorla <ekr@rtfm.com>, public-webrtc@w3.org
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
> > 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 21:07:12 UTC

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