W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2012

Re: Do we need capabilities?

From: Randell Jesup <randell-ietf@jesup.org>
Date: Tue, 24 Jan 2012 12:44:17 -0800
Message-ID: <4F1F1821.7030305@jesup.org>
To: public-webrtc@w3.org
On 1/24/2012 1:18 AM, Neil Stratford wrote:
> On 24/01/2012 03:04, Anant Narayanan wrote:
>
>> 2. Assuming we modify getCapabilities() to be a "trusted" call, i.e.
>> requires user consent before returning, I do not think we will be
>> able to satisfy application requirements. The primary reason for this
>> is that the getCapabilities() call is done separately from
>> getUserMedia(), and in the interim there might be changes to user
>> hardware. Thus the application is not guaranteed to get what it
>> wanted from the list of capabilities, anyway. This implies that UI
>> affordances in applications *cannot* be made solely on the basis of a
>> response from getCapabilities(), the application risks providing
>> functionality that may not be present at the time the user actually
>> initiates action.
>
> Changes to hardware can equally happen after a call to getUserMedia() 
> but before the session is actually established. A user could connect 
> or disconnect a webcam at any point. However, I don't see this as a 
> problem - especially if we can provide some kind of callback 
> notification mechanism on any such changes that enables the UI to be 
> updated. If I plug in a webcam after loading a web page I expect the 
> UI to be updated to reflect that I can now make video calls.

Someone should make a note: we need to detail out what should happen 
when devices are added or removed (and for removed, what happens when 
those devices are active).  This is actually a fairly common case - plug 
in or remove headset, and plugging in cameras after starting a call (or 
after starting the app but before a call) will not be uncommon.


>
>> 4. The primary reason that a 'hints' based approach does not reveal
>> as many bits as a capabilities based approach is that the result from
>> getUserMedia() given a static set of hints is not guaranteed to be
>> the same. It is temporal, and thus more unreliable that
>> getCapabilities() -- which will always return the same value for a
>> given hardware configuration. In a large number of cases, it is
>> possible that getUserMedia will always return the same kind of
>> stream, but I don't believe that justifies the need for
>> getCapabilities().
>
> If I provide a hint of "best possible", won't the resulting SDP 
> payload (containing full codec list and associated parameters) leak 
> far more information than a list of high-level profiles from 
> getCapabilities()?
>
> There are things that users expect that would not be possible without 
> capabilities - for example rich presence displaying camera icons next 
> to contacts who are available for video calls, or hiding the ability 
> to call entirely if no microphone is available. I find it difficult to 
> imagine a good UI that has no information about what may or may not be 
> possible before an actual call is attempted.

Well, one possible way to address this is to provide that information 
(without user interaction) only to "trusted" apps (we have a bunch of 
issues involving privacy and security that are tied to this concept, or 
can't be addressed except through something equivalent).  In theory the 
permissions could be fine-grained, or could expose capabilities by 
default to trusted apps unless the user overrode that at "trust" time 
(installing it as a webapp, or what have you).

>
> My concern is primarily providing a good end user experience that 
> doesn't require hacks like attempting dummy call setups to retrieve 
> capability information - which is likely what developers will resort 
> to if we don't provide such an API.

Agreed - especially if they end up forcing the user to ok the call twice.

-- 
Randell Jesup
randell-ietf@jesup.org
Received on Tuesday, 24 January 2012 20:44:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:26 UTC