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

Matt Fredrickson <> Fri, 12 July 2013 22:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B546421F9E24 for <>; Fri, 12 Jul 2013 15:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mzEUsE-yOoJt for <>; Fri, 12 Jul 2013 15:02:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4B3B021F9D7C for <>; Fri, 12 Jul 2013 15:02:34 -0700 (PDT)
Received: by with SMTP id 13so7950344lba.2 for <>; Fri, 12 Jul 2013 15:02:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=bRMU/RLolbjTRRUfCgj+pWy/JILV7Kr9paGM5O/Eems=; b=KENo0nM+600GpdW+A1e+03nzpbYEpIWN21aL/PdUrrcKlhpwuofw28MWdcvNjNL/JO C9TmCTp2WczandHVmw+1+IjPgOkQu5ffVVxwyIfG+ISb7gi0QlJ0ad+oI2DoRiuyfGH6 6QWeRDE2KRxOzwlOphdXxMSvEQgNVwJ1Y1gGmQhUHl3I8qll1UvWR7rW+XIMZnVlFHQJ vU0o9h4G/ctwWKCchXXVL7MiAJgsJmP6XvswDOOGtFqaqQC4ovLe3iCk1Gza3LzRbmnf antsIbRWoWAWeeuQl/nG12+HAzsHuZHfaYQBHfZMBd8s3oEzAZQAahUhfWhjbmknP8IT Jmmw==
MIME-Version: 1.0
X-Received: by with SMTP id ul8mr19988413lbc.36.1373666552901; Fri, 12 Jul 2013 15:02:32 -0700 (PDT)
Received: by with HTTP; Fri, 12 Jul 2013 15:02:32 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 12 Jul 2013 17:02:32 -0500
Message-ID: <>
From: Matt Fredrickson <>
To: Roman Shpount <>
Content-Type: multipart/alternative; boundary="001a11c3c96eed040104e157aa1e"
X-Gm-Message-State: ALoCoQmCXKxxcSwVb29gzsSLH4Cr9lyvsbj/uNg3OXDjYeFC4/0g6a6PtA6Z8kAs8z0erEGD8pSC
Cc: "Cullen Jennings (fluffy)" <>, "<>" <>
Subject: Re: [rtcweb] Another reason not to use SDP (was: Draft agenda for IETF 87)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jul 2013 22:02:41 -0000

On Fri, Jul 12, 2013 at 3:23 PM, Roman Shpount <> wrote:

> On Fri, Jul 12, 2013 at 2:28 PM, Martin Thomson <>wrote:
>> 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.
> 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.

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

Matthew Fredrickson