W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2012

RE: The main issue with SDP - Was: Initial notes on MS proposal

From: Suhas Nandakumar (snandaku) <snandaku@cisco.com>
Date: Tue, 28 Aug 2012 19:13:52 +0000
To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>, "matthew.kaufman@skype.net" <matthew.kaufman@skype.net>, "ekr@rtfm.com" <ekr@rtfm.com>
CC: "harald@alvestrand.no" <harald@alvestrand.no>, "martin.thomson@gmail.com" <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <37D91FC30D69DE43B61E5EEADD959F180715D1@xmb-aln-x12.cisco.com>
As a RTCWeb browser developer/ application developer, I don't think this has to be a issue with allowing SDP to modify it or not. If the spec provides me a way to verify the changes as valid, I am more than willing to support offer/answer.

Verifying changes requires a way for the browser to check "given its current state - ice, codec state" will applying the new changes make it in-sane. It seem not a tough task in my opinion. 

Browser's are becoming more powerful and state-oriented as we speak. Servers and Browsers , Browsers & Browsers should coo-ordinate to make things happen.

My 2 cents.


From: Markus.Isomaki@nokia.com [Markus.Isomaki@nokia.com]
Sent: Tuesday, August 28, 2012 12:00 PM
To: matthew.kaufman@skype.net; ekr@rtfm.com
Cc: harald@alvestrand.no; martin.thomson@gmail.com; public-webrtc@w3.org
Subject: The main issue with SDP - Was: Initial notes on MS proposal


Matthew Kaufman wrote:
>When a browser generates an SDP offer and then the developer modifies
>that SDP and calls "setLocalDescription", how will the developer know *what*
>SDP is permitted by the particular browser context they are running in? Not
>just "which codecs are supported" but what various permutations of legal SDP
>from which particular RFCs will and will not be allowed as modifications? And if
>it doesn't work, how is that signaled? Are we going to pop up an "SDP line 5
>syntax error after semicolon" alert for the user?
>And that's just for compatibility within a single browser. Then, when we take
>that SDP to another browser, after modifying it, will *that* be accepted at the
>far end? And will the changes we need to make to the SDP offer/answer
>mechanism to enable things like "setLocalDescription" leave this compatible
>with legacy SIP endpoints or not?

This is also the main issue I have with the current JSEP and SDP offer/answer based approach. We haven't defined exactly what SDP O/A functionality is mandatory to be supported by each browser, and whether the browser may also implement other extensions of SDP. It has not been very easy to get this part interoperable in SIP.


Received on Tuesday, 28 August 2012 19:14:21 UTC

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