Re: PeerConnection lifecycle/navigation/page reloads

On 1/26/2012 4:13 PM, Matthew Kaufman wrote:
>> -----Original Message-----
>> From: Randell Jesup []
>> My immediate reaction was that you can't really rebuild the connection after
>> as reload without permission from the user (perhaps from both ends; need
>> to think about that).
> You should be able to build a connection, just like you can build a data-only connection without permission from the user.

How long does the other side of the connection wait for it to be 
re-connected?  What does their UI experience look like?  What if the 
connection is slow to rebuild, or if the website changed the app during 
the call, etc?  What about local modifications to the peerconnection and 
related state?   Are they all preserved?  Mute state on a camera/mic?  
You don't want reload to change that!!!

I agree it's likely possible.  There are a lot of gotchas, though at 
least in theory they can all be dealt with - I think.  However, I'd be 
concerned how well a given app might do so, especially ephemeral state 
and the like (you'd need to make sure all of it was known to and 
restorable by the JS app).

> My assumption would be a reload (or close/reopen, etc) would end any calls.
> In particular, the other end of a call would be surprised if the call closed but
> then suddenly re-opened.  At most I'd expect both sides to be prompted to
> restart the call (and give permissions).
> I disagree. If I'm on a browser-to-PSTN call and I hit reload by accident, I expect that a well-constructed web site will be able to resume the in-progress PSTN call quite quickly, as it already knows what codecs my browser has and the renegotiation is just the STUN connectivity test against the PSTN gateway to confirm it is legal to send media there. Plus, if the user didn't consent to remember, a re-prompt for microphone access (though they'd already be able to hear the far end)

If I'm on a phone, and accidentally hit the hangup button or switch, and 
redial, I expect it to be a new call, and I expect to have to create it 

Randell Jesup

Received on Friday, 27 January 2012 00:45:35 UTC