W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Moving forward with SDP control

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Tue, 16 Jul 2013 21:37:18 -0400
Message-ID: <51E5F54E.6000206@bbs.darktech.org>
To: public-webrtc@w3.org

     Replies below.

> On Wed, Jul 17, 2013 at 9:04 AM, Peter Thatcher <pthatcher@google.com 
> <mailto:pthatcher@google.com>> wrote:
>     On Tue, Jul 16, 2013 at 11:53 AM, Martin Thomson
>     <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>         This should, at least initially, be a very constrained
>         specification.
>         (I believe that is what Roman is stating.)  In fact, this
>         could go so
>         far as to categorically state that the input to
>         setLocalDescription()
>         is precisely the output of createOffer or createAnswer.
>     That's equivalent to saying the browser should reject calls to
>     setLocalDescription that have mangled SDP.  But some browsers
>     already accept mangling of SDP before calling setLocalDescription.
>      What if WebRTC apps already rely on that?  Would the spec require
>     breaking such apps?

     If you are going to disallow users modifying the SDP, then 
setLocalDescription() should be removed altogether. The implementation 
can then pass the SDP from one component to another on the user's 
behalf. Never force the user to do anything which you can do on their 
behalf. Also, "When in doubt, leave it out".

On 16/07/2013 9:09 PM, Eric Rescorla wrote:
> The JSEP spec is supposed to list what manipulations are permissible.
> That seems to be a work in progress...
> -Ekr

     This contradicts what I heard from Cullin and Adam (spec editors) 
at WebRTC World. I was told that users are never supposed to manipulate 
the SDP; rather, they are meant to drive changes using the Constraints 
API. The only reason they are allowed to do so today is because the 
Constraints API hasn't been completed yet.

     Does the Working Group agree with this interpretation?

Received on Wednesday, 17 July 2013 01:37:52 UTC

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