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%20P
ri%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