- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Tue, 24 Jan 2012 12:44:17 -0800
- 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