Re: Additional requirement - audio-only communication

On Tue, 6 Sep 2011, Matthew Kaufman wrote:
> On 9/6/11 1:00 PM, Ian Hickson wrote:
> > On Mon, 5 Sep 2011, Matthew Kaufman wrote:
> > > We need something like:
> > >    getUserMediaCapabilities(options, successCallback);
> > This would be a privacy leak (whether I have audio/video capabilities
> > should not be broadcast to the whole Web).
> 
> TOTALLY disagree here. Whether or not your browser has A/V codecs and what
> they are is absolutely something that should be shared with the web site. This
> is exactly the same as the Accept header.

The Accept header is also a privacy violation, which is in part why 
browsers tend to be somewhat circumspect in what they send there.

In addition, both Accept: headers and a getUserMediaCapabilities() method 
would increase the fingerprinting risk.


> There is no use case that says that setting RTP parameters should be 
> done on an object that is associated with the media stream instead of 
> via SDP to/from an object that is associated with the network 
> connection.
> 
> But you could use the same argument to say that it would be equally 
> reasonable to get rid of the bgcolor attribute and instead require that 
> solid backgrounds be provided in the form of Javascript that paints the 
> background using canvas path APIs.

Changing the look of the page is a use case, so it's not the same at all.

(Also, we _have_ gotten rid of bgcolor as much as we can.)


> > Sounds horrible. Surely we want to make this as simple as possible for 
> > authors to use,
> 
> Is that really the goal? Or is the goal to create a platform for web 
> application development? Because we've gotten *way* too far in the "easy 
> to use" direction, in my opinion.

IMHO we are far too far in the "hard to use" direction. Things like video 
conferencing should just work -- authors shouldn't have to know about 
video codecs, NATs, SDP, SIP, etc.


> > which would mean making this completely opaque, so that they don't 
> > have to touch any of it, even if the remote endpoint is a tranditional 
> > SIP stack (e.g. an IP desk phone).
> 
> Sure. Why not just bake an entire SIP stack into the browser and have an 
> API for initiating SIP calls and a second one for hanging them up and 
> then forget about all the other possible use cases for real-time 
> audio/video communication using the browser as the runtime environment?

Because that wouldn't handle the use case of a site providing video 
conferencing in different contexts. For example, it would make it harder 
to have the user's multiple terminals (e.g. laptops, desktops, phones) all 
presented as one identity with the user in control of which received media 
at what time.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 6 September 2011 21:26:56 UTC