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

On 08/28/2012 09:13 PM, Suhas Nandakumar (snandaku) wrote:
> 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.
I think this is already supported in the API; there is an error callback 
if the browser could not use the SDP applied to it.

>
> 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.
>
> ./Suhas
>
> ________________________________________ 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
>
> 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.
>
> Markus
>
>

Received on Tuesday, 28 August 2012 22:10:39 UTC