Re: Additional requirement - audio-only communication

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.

If I can't tell whether or not you can decode H.264 from Javascript, 
then I suppose I'll be just looking at the User-Agent header and 
guessing, which is even worse.

>   Also, it wouldn't handle cases
> such as a user plugging in a device in response to a site's request.
It would if we had events that fired when users plugged in devices, 
which I believe was already in a previous use case.

>
>> 3. RTP choices should be exposed by allowing RTP media streams to exist,
>> rather than putting the RTP parameter setting in the PeerConnection (and
>> controlling the encoding using SDP to/from that PeerConnection object)
>>
>> Example from above continues:
>>
>>      rtpStream = new RTPMediaStream(encodedStream);
>>      rtpStream.payloadType = 131;
>>      rtpStream.ssrc = 15;
>>
>>      // note that if we tried to combine A+V into a single stream, we need a
>> more expressive (and yet uglier) way to set the PT and SSRC for each
>>
>>      // and we created our peerConnection earlier...
>>
>>     peerConnection.addStream(rtpStream);  // the only other alternative to this
>> part of my proposal is to change addStream to take the PT and SSRC as
>> parameters, but that's not nearly as clean
> What's the use case?

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.
>
>> Note that all of this still allows for passing SDP around if you want.
>> You simply need to write Javascript to convert the capabilities into an
>> offer and the answer back into explicit settings for the encoder(s) as
>> well as the RTP bits. But more likely, you'd pass SDP around *only* for
>> federation, and use something else (like just passing a JSON blob that
>> came out of the configuration check right up to the web server to be
>> handled there).
> 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.

>   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?

Sometimes I really can't tell whether people are serious about making 
the web browser a real runtime environment for building applications, or 
if they just want to glue toys onto the side that are good demos.

Matthew Kaufman

Received on Tuesday, 6 September 2011 21:09:30 UTC