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

Have we considered returning a stream with muted tracks until permission 
is given instead? - Given that we'll need to mute tracks on/off in 
response to over-constrained situations caused by live 
constraint-changes anyways, this seems like a fit.

This decoupling should speed up many calls by letting connections 
establish without blocking on the user answering the (somewhat 
unrelated) gUM permission prompt. (e.g. it would speed up all calls in 
Firefox because it doesn't implement persistent permissions, and all new 
calls in Chrome).

With this "Assume Success" pattern, webpages that don't want the 
overhead (e.g. because listen-only is common) can of course initiate the 
call without gUM, and maybe (someday hopefully) addStream later during 
the call.

With calls no longer blocked by permissions, bundling permission 
requests seems as easy as waiting a sub-second to aggregate tag-along 
requests.

If we can work out the ramifications on the outgoing SDP, I see a 
design-win here:

A decoupling avoids conflating the permission question with "start 
call", and seems to fit better with the experience users expect:

The current conflation is unfortunate because it looks to users like 
permission is required to make any call at all, which is often untrue, 
but the choice to proceed without video is hidden! (when's the last time 
something fun happened after pressing "Deny"?)

I know, lazy webpage, but I experienced this myself a few weeks ago when 
I tried to dogfood webrtc to dial into an IETF meeting... I balked at 
the gUM prompt and ended up instead using the less dangerous flash 
version which didn't ask anything of me (hey, it was 3 am, I was not 
appropriately dressed, and I was sleepy ok?)

.: Jan-Ivar :.

On 8/29/13 2:24 PM, Rachel Blum wrote:
> At some point the DAP WG was working on a unified permissions thingy - 
> http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
>
> They discontinued it because there wasn't a clear use case outside of 
> notifications, but it might be worth looking at.
>
>  - rachel
>
>
> On Thu, Aug 29, 2013 at 7:09 AM, Stefan Håkansson LK 
> <stefan.lk.hakansson@ericsson.com 
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     I think something along these lines could be the right thing to
>     do. The
>     dual role of getUserMedia is not ideal.
>
>     On 2013-08-29 14:38, Harald Alvestrand wrote:
>     > One of the problems with the current method of getting access to
>     media
>     > is that it occurs as a side effect of a call done for other purposes
>     > (GetUserMedia).
>     >
>     > The parameters for this aren't ideal to determine the full range of
>     > permissions that a page would want - for instance, a page might
>     first
>     > open a video device, and later open an audio device separately;
>     in our
>     > current models, that would give 2 permissions prompts.
>     >
>     > Instead of doing it this way, we could make an explicit call:
>     >
>     > void GetMediaPermissions(Permissions permissions,
>     >                              successCallback, errorCallback)
>     >
>     > Permissions = enum(
>     >    "videoInputDevices",
>     >    "audioInputDevices",
>     >    // and maybe extend this to
>     >    "deviceEnumeration",
>     >    "screenCapture",
>     >    "windowCapture",
>     >    ....
>     > )
>     >
>     > The UA could then use the list of permissions requested to
>     construct an
>     > appropriate UI element for asking permission from the user (or use a
>     > stored permissions model to grant access immediately, if that's the
>     > Right Thing).
>     > In any case, all programs that know what class of permissions
>     they want
>     > can get those permissions with one call, one prompt, no matter
>     what they
>     > do later.
>     >
>     > For backwards compatibility, getUserMedia would be documented to
>     have an
>     > implicit call to GetMediaPermissions "behind the curtains".
>     >
>     > Does this make more sense?
>     >
>     > Harald
>