W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: VS: Teleco Integrators vs Web Developers vs Browser Implementers

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Thu, 4 Jul 2013 17:37:16 +0200
Message-ID: <CALiegfn3S2i_qASOxZDPSnBM47HG3tW3AtN=zM4LWeuQjzH3_w@mail.gmail.com>
To: Parthasarathi R <partha@parthasarathi.co.in>
Cc: cowwoc <cowwoc@bbs.darktech.org>, Christer Holmberg <christer.holmberg@ericsson.com>, Robin Raymond <robin@hookflash.com>, Roman Shpount <roman@telurix.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, Ted Hardie <ted.ietf@gmail.com>, "piranna_gmail.com" <piranna@gmail.com>, "public-webrtc_w3.org" <public-webrtc@w3.org>, Eric Rescorla <ekr@rtfm.com>
2013/7/3 Parthasarathi R <partha@parthasarathi.co.in>:

> SDP based API is selected after a lengthy discussion between low (RTP) level
> API, RFC 3264 O/A API (ROAP), SIP and the current JSEP. Some of the
> constraints favors JSEP are
> 1)      Multiple signaling protocol has to be supported like Jingle, SIP

For your information: Jingle does NOTt use plain SDP but XML based SDP:


So Jingle CAN NOT be implemented in browser side (unless you are
capable of making a JS code that perfectly parses the SDP blob
produced by the browser, converts it into multiple XML bodies, send
them in-the-wire, and the remote does the reverse process, and no info
is lost during those conversions).

> 2)      Develop WebRTC application with few lines of code.
> a.       This is not possible with API based approach

This is really wrong. You will see it soon.

> 3)      Only one level of API is allowed for WebRTC 1.0
> a.       It is possible to have two level API as I presented in Oct 2011
> Virtual IETF meeting but browser implementers are favoring it.
> 4)      Time to market: WebRTC 1.0 has to be released soon with reusing
> existing protcol. SDP is well proven protocol (for Telco & Enterprise).

SDP is a well proven protocol for single audio (+video?) calls. If it
was so good we wouldn't have debates like Plan-A versus Plan-B.

> I’m against new API based mechanism but to understand whether the proposed
> API works or not for all protocols takes more time before consolidation.
> This implies “time to market” constraint has to be removed for this
> activity.

Partha, two years ago you defended SIP as the only and mandated
network signaling protocol for WebRTC. If not (and it was not
mandated), you were fine if some other single protocol (i.e. XMPP,
MEGACO...) was mandated. At the same time you recognized that you have
no knowledge in JavaScript. And you build gateways.

WebRTC must be a technology for the Web, and its purpose must be to
provide the best mechanism for the Web to include powerful (and
future) RTC features. Extending the current telephony industry
business should not be the main target of WebRTC.

I'd really would like to know your opinion about WebRTC from the point
of view of a pure Web developer, with no SIP/SDP knowledge, who wants
to deploy a Web based RTC service without SIP interoperability at all.

Best regards.

Iñaki Baz Castillo
Received on Thursday, 4 July 2013 15:38:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC