Re: PeerConnection lifecycle/navigation/page reloads

On Thu, Jan 26, 2012 at 7:44 PM, Randell Jesup <randell-ietf@jesup.org>wrote:

> On 1/26/2012 4:13 PM, Matthew Kaufman wrote:
>
>>
>>  -----Original Message-----
>>> From: Randell Jesup [mailto:randell-ietf@jesup.org**]
>>> 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
> myself.


This is the web though, and we have to deal with things like pushing of new
servers, failover, and similar cases that will trigger an automatic page
reload. This shouldn't cause the call to drop.