Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

[Iñaki Baz Castillo <[e-mail]>]

2013/7/9 Silvia Pfeiffer <[e-mail]>:
> I think there are two groups objecting and there are two things to
> object against.
>
> Here's what I'm reading...
>
> Web Developers really just want to be given functionality. They can
> build their own nice API on top of what browsers implement (jquery did
> a marvellous job of that). But they want functionality. Seeing as some
> things are not currently possible with SDP and O/A, they either want
> to extend those to allow their functionality, or - in particular where
> SDP & O/A are overkill - want an option to get out of using SDP & O/A
> and use something else.
>
> Telco engineers want their existing devices to be interoperable with
> browsers as well as the ability to develop new devices in the future
> with extended functionality. So, on behalf of the first goal, they
> object to including functionality into SDP that other devices don't
> already support, and on behalf of the second goal, they are torn
> between extending SDP & O/A and starting new.

Hi Silvia,

Another important point is that many of those telco engineers have
clearly recognized that they don't know Web, nor JS, nor designing JS
APIs for the Web, and that they just want WebRTC to be compatible with
their current business (literally: "I want browsers to be compatible
with SIP").

For example, two years ago the initial proposal by many of those telco
engineers was "allow plain RTP and mandate SIP as in-the-wire protocol
for WebRTC" (this is true). I also remember that somebody proposed
that the browser should include a "call history" panel, which clearly
shows a limited and wrong WWW vision.

They strongly think that by mandating SDP O/A they are done and have
accomplished their job in this WG on behalf of their big companies
(those that have never succeeded in the WWW). And of course, they are
much more used to IETF processes than Web guys (is Facebook
represented in this WG?), thus the only argument they expose
*nowadays* is: "SDP mandate was talked about and agreed two years ago
in a meeting full of telco engineers".

And then, the current spec is basically an opaque and unmanageable SDP
blob generated by the browser that must be sent by the JS to the peer.
The same "logic" within a phone. But here is the problem: a web
application is all but **fixed** code and **fixed** logic. Don't kill
the Web.




> I certainly want a simple API, but I am not sure whether what we
> currently have is already the simplest possible (given current
> circumstances),

What we have now is not a real API.


> nor am I sure whether it wouldn't just be possible to
> build a simple one on top the jquery way, which would be sufficient
> for now.

An API should be good enough to not require an extra layer on top of
it to make it feasible for developers.


As developer in JsSIP project I must say that we have properly
implemented SIP pure protocol on top of JS and WebSocket, no problems
at all (regardless how complex SIP becomes sometimes). The only real
problem we have if related to WebRTC "API". Tons of hours dealing with
unexpected/wrong specifications and behaviors (and yes, SDP blob
hackery). We would be very happy if we could generate our *own* SDP
with JS (which means we need to retrieve *real* JS Objects from the
WebRTC stack rather than an opaque SDP blob). And telcos, ey!!!, we
are doing SIP even much more than you !!! believe us !!!


Best regards.


--
Iñaki Baz Castillo
<[e-mail]>