Re: Proposal: Explicit "Get access to media" call

On 9/8/13 6:19 AM, Harald Alvestrand wrote:
> On 09/06/2013 06:20 PM, Jan-Ivar Bruaroey wrote:
>> Have we considered returning a stream with muted tracks until 
>> permission is given instead?
>
> We have considered it. The problem is that until permission is given, 
> the track does not have enough information to start negotiating 
> connections, and indeed to do much of anything with it - because we 
> can't negotiate the properties of the connection until we know 
> something about the stream that will be connected to it.
>
> Instead of speeding things up, it would slow things down - because 
> when we finally know the properties of the device, we have to 
> re-negotiate.

Thanks for the info. Yes, surely having those properties immediately 
will always be the fastest. But I would have guessed:

 1. Fastest: gUM returns remembered properties immediately, gets
    candidates + DTLS + negotiates once (visited before, Trusty?)
 2. Faster: gUM returns immediately, gets candidates + DTLS +
    negotiates, then re-negotiates after user input (first visit?)
 3. Slower: gUM waits on user input, then gets candidates + DTLS +
    negotiates once (first visit?)


For prompted visits, perceived time is likely to be: time it took to 
answer prompt + whatever happens after prompt (unless user is very 
quick). I think #2 wins, because (re)negotiating after prompt always 
beats (negotiating + getting candidates + DTLS) after prompt.

Subtract from advantage for users who are significantly faster than 
candidates + DTLS.

There's also a fourth case I hadn't considered before where (at least in 
Firefox) a user with unchanged hardware revisits a site, and still gets 
prompted (because we don't allow persistent permissions). In this case, 
concerns about information-leakage are minimal ("yes, 
site-I've-trusted-before, I have the same dinky webcam as before!"). 
Here we could now pick:

  * 4. Faster: gUM returns remembered muted properties immediately, gets
    candidates + DTLS + negotiates once, unmutes after user prompt
    (visited before, Paranoid-guy?)


> The parts we can do without knowing the device, such as getting 
> candidates assigned and initial DTLS handshakes out of the way, are 
> the same things we can do without adding a track to the connection at all.

Agreed, but our API steers people the wrong way then. Even IETF's own 
webrtc app found it easier to bluntly challenge my 3am privacy up-front. 
Flash won.

If web-developers feel they're circumventing our API to get the best 
performance, is that API fail?

.: Jan-Ivar :.