Re: The best API possible (Was: Teleco Integrators vs Web Developers vs Browser Implementers)

2013/7/6 Emil Ivov <emcho@jitsi.org>:
> Of course, one could expect a variety of JS stacks to appear and simplify
> the API for specific use cases. Web developers would then be able to use
> those and their lives would eventually be easier. Still, that's not going to
> happen overnight and until it does, you will be needing a substantial amount
> of RTC knowledge in order to build WebRTC applications.
>
> I assume that's part of the reason while a number of people have suggested
> finishing the current API as 1.0 and then going down the path of a
> lower-level API for 2.0.

Emil, regardless the "JS API" (which you mean should be enough not to
have to mangle the SDP) the SDP O/A mandates that every media
signaling protocol in any WebRTC application should imitate SIP model
(or you must use a gateway to transform the SDP into your desired
format).

Using SDP in WebRTC 1.0 means that we will have SDP in WebRTC 2.0 and
WebRTC 10.0. If now that there is no WebRTC Release Candidate we
cannot drop SDP (since people seem not to understand the monster they
are proposing) then we'll have real applications and commercial
deployments/devices implementing WebRTC 1.0, and later, when WebRTC
2.0 borns, the argument of "backward compatibility" will be enough to
keep SDP forever.

You don't need to mandate a media signaling protocol (in-the-wire) for
having a simple API, that's 100% false.

Anyhow, next week you will see a new API proposal that does the *same*
of the current API with the half of JS lines, does not mandate O/A
round trip (nor for the initial media negotiation nor for "refresh"
re-negotiations) and allows implementing *any* media signaling
protocol in-the-wire (which of course includes SDP).



> I assume that's part of the reason while a number of people have suggested
> finishing the current API as 1.0 and then going down the path of a
> lower-level API for 2.0.

No. That is the argument of telcos because they want WebRTC to satisfy
their current business model as fast as possible, regardless their
ugly proposed "API" kills any future media signaling model in WebRTC.
Period. They care no more and cannot imagine a RTC service/concept
which is not based in "telephony calls and webphones". They are afraid
of a "WebRTC without SDP" because they think, wrongly, that without
SDP they will loose SIP compatibility. They are *so* wrong... But this
problem occurs when telcos decide they are JS and API experts.





--
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Saturday, 6 July 2013 08:28:47 UTC