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

On Wed, Jul 3, 2013 at 3:03 PM, Parthasarathi R
<partha@parthasarathi.co.in>wrote:

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

Right now only WebRTC to WebRTC is truly supported. The rest can only be
implemented via a media proxy that terminates all the signaling from both
parties since a lot of common SIP or Jingle scenarios (like SIP hold)
cannot be easily translated to WebRTC. So failure here.

> **2)      **Develop WebRTC application with few lines of code. ****
>
> **a.       **This is not possible with API based approach
>
This strongly depends on the API. Right now only a simple party to party
call can be established easily, anything a little bit more complex is a lot
more complex then it should be. So failure here as well.


> ****
>
> **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.
>
There is only a need for one level of API. Anything simplified would be a
JavaScript library. There are multiple libraries to simplify WebRTC use
already, which proves that current API is neither simple no easy to use. So
failure here as well.


> ****
>
> **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 simple single channel audio call. Once
you start doing video things begin to break very quickly. Since webrtc is
adding a lot of new features (trickle ICE, DTLS, and bundle) SDP and O/A is
of no value here whatsoever.


> ****
>
> ** I have not seen any of the constraints changed till now. I agree that
> SDP has lot of known issues but it is the better known one.
>
> ** **
>
> One of the good example of issue in introducing new protocol/API mechanism
> is “PRACK in JSEP state”. As per Web developer, PRACK state in JSP is
> introduced for SIP O/A whereas it is fitting for SIP already and it took
> nearly 1 year for folks to understand.
>

The reason it took so long to understand is because it is broken. It can
implement one very limited scenario (serial forking) but breaks immediately
in real life (when for instance UPDATE for early dialog is present).
Connection cloning was needed instead of PRACK but was not implemented for
expediency. PRACK was implemented as a constellation prize which serves no
purpose except for putting a check mark against the use case.


> **
>
> 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.
>

Unless purpose of WebRTC is to implement API which supports simple calls we
are a long way away from the working standard (I would say a few years
away). Furthermore, unless WebRTC is reengineered away from offer/answer
and SDP now, it will hinder future development of the standard when new
features are introduced.
_____________
Roman Shpount