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

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 28 Aug 2012 21:44:11 +0200
Message-ID: <503D1F8B.2070107@alvestrand.no>
To: Markus.Isomaki@nokia.com
CC: matthew.kaufman@skype.net, ekr@rtfm.com, martin.thomson@gmail.com, public-webrtc@w3.org
On 08/28/2012 09:00 PM, Markus.Isomaki@nokia.com wrote:
> Hi,
> 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.
We know that some browser will want to implement extensions. Not 
permitting them to do so would land us in the "can't evolve" situation 
that we don't want to be in.

So we have to define a minimum profile that all browsers will support, 
just like we do for codecs, and then use the extension rules that are 
defined for SDP to allow further extensions that don't cause harm.

Not saying it's trivial, but it's relatively clear what has to be done.
Received on Tuesday, 28 August 2012 19:44:43 UTC

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