Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list

[Matthew Kaufman <[e-mail]>]

On 9/30/2011 12:46 PM, Iñaki Baz Castillo wrote:
> 2011/9/28 Tim Panton<[e-mail]>:
>> I just want to ask folks to take a look at a proposal Neil Stratford wrote for the
>> Low Level Javascript API and sent to the webrtc list.
>>
>> It  is based on his and my experience of web based audio plugins and on a
>> proposal of Cullen's a while back.
>>
>> http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/0106.html
>>
>> We'd appreciate any feedback either here or on the webrtc list as appropriate.
> Hi, the API in that document is just valid for a few specific
> scenarios (make a call, receive a call and maybe putting a session on
> hold).

Totally disagree. The API in that document can be used to build every 
single VoIP application you can build with SIP *plus a bunch more*.

This is like claiming that DirectSound is "just valid for a few specific 
scenarios" when in fact it is a low-level audio API for Win32 systems 
that can be used to build pretty much anything that wants to play sound.

>   That is a very limited subset of what any VoIP protocol can
> offer, so I don't think it's a good idea for rtcweb to assume a custom
> protocol like that for inclusion in WebRTC JS API (as native JS code
> within the browser).

I think you're saying that the JS API should be some existing protocol 
standard like SIP and SDP here, yes?

It is much easier to discuss if we keep "the wire protocol" and "the JS 
API" separate... and realize that just like my above Win32 example, a 
"low level" JS API could in fact be used in conjunction with *any* wire 
protocol (that you can send/receive within the browser context) plus 
server behavior.

This is also true of the "high level" JS API proposals... it is just 
more annoying, as you need to do things like trick them into generating 
an SDP offer, then decode it locally or send it to a server for 
processing, and then kill that and start the actual connection you 
wanted while lying to the browser about what the other end has claimed.

I'd rather have the API that lets me do what I want directly.

>
> Of course, a simple API like that would be useful for lot of people
> offering basic media services to the web site users (basic scenarios
> in which there is no call transfer, parallel forking and so).

Yes. And it would also be useful for people offering all types of 
complex telephony services, including call transfer, parallel forking, 
and the like... as well as all types of complex *non-telephony* RTC 
applications, like games.

Matthew Kaufman