Re: [rtcweb] Another reason not to use SDP (was: Draft agenda for IETF 87)

[Peter Thatcher <[e-mail]>]

On Fri, Jul 12, 2013 at 10:41 AM, Martin Thomson
<[e-mail]>wrote:

> On 12 July 2013 10:19, Peter Thatcher <[e-mail]> wrote:
> > I think advanced JS apps are going to use every control knob they can get
> > to, whether it's anticipated and well-supported or not.    I think
> there's a
> > good chance that a a popular WebRTC web app will use some SDP mangling
> that
> > wasn't anticipated, but happened to work, but then the browser can't
> remove
> > it because it will break certain websites.  It could get even worse if
> > someone writes a popular WebRTC wrapper library that uses tricky SDP
> > mangling that is then used by lots of websites.  Certain SDP mangling
> > techniques might end up becoming a defacto standard API that can't be
> > removed, even if it was originally a bug.  Or worse, one browser will
> have
> > to implement the SDP mangling or even the bugs of another, because WebRTC
> > apps have come to rely on them.
> >
> > In fact, it's already the case that Chrome and Firefox support far
> different
> > SDP manglings.  I don't think any web apps rely on that yet, but it's
> only a
> > matter of time before someone figures out "hey, if I mangle the SDP on
> this
> > browser this way and on that browser that way, I can do things I
> couldn't do
> > otherwise".  Or worse, an advanced web app developer says "hey, I can
> make
> > this work well on browser X via SDP mangling, but not on browser Y, so
> I'll
> > put a 'best used with Browser X' icon on my website". Then that someone
> > writes an abstraction on top of that, and then maybe shares that with
> > others, and it goes from there.
> >
> > I think we're in a race with web developers to see if they'll figure out
> SDP
> > mangling before we provide a way to avoid SDP mangling.   Who do you
> think
> > moves faster?
>
> This is one of the arguments we've made against the use of SDP.  There
> is a remedy for this (aside from comment 22 ;), but it's a fair amount
> of work:
>
>  - provide very explicit and detailed instructions on what SDP to
> produce under all starting conditions, and
>
>  - provide very explicit and detailed instructions on what to do with
> every single bit of SDP that is provided.
>

If we write it down with such detailed instructions, is a browser banned
from accepting more than the explicitly allowed SDP in calls to
setLocalDescription and setRemoteDescription?  For example, what if lots of
web apps get SDP from a particularly popular gateway device that adds a
particular SDP attribute, and if the browser "listens" to that SDP
attribute, things work better (for example, it might be a bandwidth-related
attribute).  Can the browser "listen" to that SDP attribute even though it
isn't explicitly supported by the WG?  Or does it have to wait for it to be
added to the explicit instructions?



> That is what I believe to be necessary if this API is to have any hope
> of real success.
>
>
It depends on how you define "real success".   I think the API has already
had success for simple use cases, seeing as two browsers have working,
interoperable implementations for the simple use cases.  It's the advanced
ones I see being problematic.





> Unfortunately, when I sat down to do this, I barely made it to t=
> sections.  I simply cannot justify spending the time required for that
> sort of chore.
>

Well, then you're almost finished.  All you really have left are the m=
sections :).