Re: PeerConnection lifecycle/navigation/page reloads

On 1/26/2012 11:05 PM, Timothy B. Terriberry wrote:
> Harald Alvestrand wrote:
>> I suspect that some people will try webworkers, so we should make sure
>> the semantics of having a PC in a webworker are well-defined. I'm not
>> knowledgeable enough about webworkers to know whether we need to do
>> anything special to accomodate them.
>
> Web workers don't have access to the DOM, so they can't keep a 
> reference to the PeerConnection object at all, and certainly won't 
> keep it alive across page reloads. Assuming you can even keep the 
> worker alive. They get closed once all their controlling Documents 
> disappear.

Thanks Tim; I didn't think it would work but hadn't directly played with 
workers yet.

At best the app can store state data in session storage and then on 
reload (or back, or forward, etc - returning to the app in any way in 
that tab) it could read the saved state and use that to rebuild any 
active call (perhaps starting with "do you wish to redial the call?")  
I'd suggest that all of this lives in the application space; the only 
thing that touches on us is whether the permission state tied to a 
peerconnection/getusermedia could persist at either end across this.  I 
think it's a lot simpler/safer to say "no".


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Friday, 27 January 2012 10:28:14 UTC