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

     I'm hearing a mixed message.

 1. This is the first time I hear of someone referring to SDP as an API.
    It is no more an API than JSON. It is simply a collection of
    key-value pairs.
 2. I was personally told by the WebRTC specification editors that users
    are not meant to interact with SDP directly.


     I think everyone would benefit from the specification editors to 
stand up and give some official responses.

PS: This is precisely the reason I am pushing for the editors to publish 
a Design Document justifying the design decisions. This document would 
spell out once and for all whether their intention was for users to 
interact with SDP directly (and if not, how they are meant to mutate its 
content).

Gili

On 03/07/2013 3:03 PM, Parthasarathi R wrote:
>
> Hi all,
>
> 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
>
> 2)Develop WebRTC application with few lines of code.
>
> a.This is not possible with API based approach
>
> 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).
>
> 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.
>
> 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.
>
> Thanks
>
> Partha
>
> *From:*cowwoc [mailto:cowwoc@bbs.darktech.org]
> *Sent:* Wednesday, July 03, 2013 10:53 PM
> *To:* Christer Holmberg
> *Cc:* Iñaki Baz Castillo; Robin Raymond; Roman Shpount; Adam 
> Bergkvist; Ted Hardie; piranna_gmail.com; public-webrtc_w3.org; Eric 
> Rescorla
> *Subject:* Re: VS: Teleco Integrators vs Web Developers vs Browser 
> Implementers
>
>
>     FYI, here is a perfect example of how SDP is being abused:
>
>  1. I ask for the ability to constrain the minimum/maximum bandwidth
>     used by WebRTC:
>     https://code.google.com/p/webrtc/issues/detail?id=1327
>     <https://code.google.com/p/webrtc/issues/detail?id=1327&can=4&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20Area%20Status%20Owner%20Summary>
>  2. This issue is "blocked by":
>     https://code.google.com/p/webrtc/issues/detail?id=1349
>  3. https://code.google.com/p/webrtc/issues/detail?id=1349 is closed
>     with the following comments
>
>      1. "These are not actually exposed through PeerConnection, only
>         through the C++ API, right?  Maybe we should adjust the title
>         of the bug."
>      2. "Those are exposed to JS through SDP already."
>
>     Someone needs to communicate to the Chrome committers that 
> exposing functionality to JS "through SDP" is not acceptable. Meaning, 
> https://code.google.com/p/webrtc/issues/detail?id=1349 should be reopened.
>
> Gili
>