RE: PeerConnection lifecycle/navigation/page reloads

> -----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.

What you can't do is send camera + microphone, unless of course they have remembered a privacy setting for your domain that allows access.

> This may interact with some of the privacy concerns
> around ICE and location - and we'd need to re-do ICE/etc setup.

Obviously if a user forbids their browser from doing ICE before camera and microphone are allowed, that might be a problem... except that I would still think that we would allow server-relayed calls to proceed no matter what... so we should be able to start with that (or, in some cases, that's where the call is going anyway)

> 
> 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)

> 
> Perhaps the "least surprise" solution would be to not even reopen the call
> automatically.

The "least surprise" solution is to make it hard for the user to close/reload the page. But that's a user experience problem, not an API design problem.

Matthew Kaufman

Received on Friday, 27 January 2012 00:14:14 UTC