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

PeerConnection lifecycle/navigation/page reloads

From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 26 Jan 2012 12:14:44 -0800
Message-ID: <CABcZeBOzYh=Q3zaavP1ENaGz0xzo2=ZS52jmjMoE0EbAaZUXOQ@mail.gmail.com>
To: public-webrtc@w3.org
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:15:52 UTC

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