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

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Jul 2013 10:41:17 -0700

On 12 July 2013 10:19, Peter Thatcher <[email-masked]> 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.

That is what I believe to be necessary if this API is to have any hope
of real success.

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.

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 12 Jul 2013 11:21:21 -0700

> 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
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.

> sections.  I simply cannot justify spending the time required for that

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Jul 2013 11:28:41 -0700

> added to the explicit instructions?

That depends entirely on the nature of the instructions.  Allowing for
extensibility is always really, really hard, but maybe there is enough
experience with SDP now that this sort of scenario could be supported.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 12 Jul 2013 16:23:46 -0400

> experience with SDP now that this sort of scenario could be supported.
Unless my past 10 years of experience building SIP systems mislead me, the
current way of dealing with SDP extensibility is to define all features
supported by network or device, go through the interop with every new
network or device you need to connect to, and then, when in doubt, put an
SBC in front of it. We currently need to go through interop testing every
time we setup a new connection with a new VoIP service provider, and this
is for simple PSTN to VoIP G.711+RFC2833 calls. Adding an unusual codec,
like getting a direct interconnect in AMR-WB to cell phone networks, or
SILK to Skype, requires years of testing and still not typically available
commercially. SIP interworking for anything more complex (like even simple
video end points) is virtually non existent. So, I guess, we are building
on a very solid foundation of interprable solutions which require extensive
testing after every sneeze.
_____________
Roman Shpount

---

From: Matt Fredrickson <[email-masked]>
Date: Fri, 12 Jul 2013 17:02:32 -0500

> testing after every sneeze.

I think much of it goes back to supporting a specific subset of SDP for a
core set of use cases.  In the Asterisk world, we generally try to support
nearly anything and everything that operates within our set of core use
cases.  But once you trespass too far outside of them, you can only fall
back to support the parts of the session description that are interpretable
by your implementation.

Given all of the different devices that we have come to interoperate with
over the years (just with SDP, not even necessarily with SIP or other
higher layer signalling), I too fear that a lack of specific restraints on
what is permissible within SDP as utilized within WebRTC will cause
interoperability and fragmentation problems, at least in more advanced use
cases.

Matthew Fredrickson