Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP

Mary Barnes <> Thu, 07 March 2013 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AB8A21F89A6 for <>; Thu, 7 Mar 2013 09:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.727
X-Spam-Status: No, score=-103.727 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bd76TsVG2oY5 for <>; Thu, 7 Mar 2013 09:56:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4485F21F8996 for <>; Thu, 7 Mar 2013 09:56:34 -0800 (PST)
Received: by with SMTP id x7so459509qeu.3 for <>; Thu, 07 Mar 2013 09:56:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Bc0IU/bsO9B7nvclo0lXf4COgCLBYO4CtcPQtXdsbTM=; b=L/TV7s2pFRhwtZOuW48sP2+CHOFC4NOfYp92vGbMV0Ftcsz56NiUilu5c+O0UUCIhU 1Ann5iOgJKCKknOWxZz87awshmsZGoQXjm2pNTBwuQNRKhtrMDKNTwsM3jJh0J3gu1TH Tv9VBh/3Lyc9OWClSWaSxjwHF1X2pvOgauXBP1xcZoXhi0/zqsIdtDPquroHdQAhsiOG jDS6NKSPk6gNsk2bXH1Gv9J9q4t+1isvSN5y/7S84+oWaitaqfFHU9LQfgSIQywLesz3 prfrAVdQBfnG8YpAnH1J6NIdbZtKV/oFzg4luafbt/59s4dVasuRylZWZLzhfDsLM5av U31Q==
MIME-Version: 1.0
X-Received: by with SMTP id dl4mr4558163qab.85.1362678992837; Thu, 07 Mar 2013 09:56:32 -0800 (PST)
Received: by with HTTP; Thu, 7 Mar 2013 09:56:32 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 07 Mar 2013 11:56:32 -0600
Message-ID: <>
From: Mary Barnes <>
To: Martin Thomson <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "<>" <>
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
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: Thu, 07 Mar 2013 17:56:35 -0000

On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
<> wrote:
> Obviously I (and my employer) agree with these sentiments
> wholeheartedly.  Both Robin and Hadriel.
> That doesn't change the fact that a number of people are highly
> motivated to protect their investment in SDP offer/answer.  For those
> people, the pain that causes everyone else is clearly far less
> important than the pain they feel at this moment.  So here we are.

[MB] I originally thought that either approach could work.  I did see
the value that folks saw in using SDP offer/answer. But after sitting
through the interim meeting last month, I am very much of the mindset
that using SDP O/A is a bad idea.   I think many of us thought that
using the SDP blob would help with interoperability with "legacy" SIP
endpoints.  I don't see that now at all.  I think we will end up with
a very fragile solution that will be very difficult to extend/modify
later if we continue down the SDP O/A path.
> On 7 March 2013 08:50, Hadriel Kaplan <> wrote:
>> I knew there was a reason for posting an email for the archive machine to store for eternity... see this:
>> -hadriel
>> On Mar 6, 2013, at 6:45 PM, Robin Raymond <> wrote:
>>> Do we need SDP "blob" format in the exchange in the first place? All media
>>> can be done without SDP given an intelligent stream API. An API already
>>> exists to create these streams (albeit somewhat lacking if we remove the
>>> SDP 'blob'). This API helps "simplify" creating this blob for later
>>> exchange. But the blob is truly not needed. Each side could in fact create
>>> the desired streams, pass in the appropriate media information such as
>>> codecs and ICE candidates and chose the socket pair to multiplex upon.
>>> Yes, it's a bit more low level but it certainly can be done (and cleanly).
>>> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to take
>>> it from a totally different non-SDP angle. I have to say, the ideas
>>> presented are very good. I appreciate FEC, and synchronizing streams is
>>> cool. But SDP isn¹t needed to do it. Let me as the programmer worry about
>>> how to manage streams and the features on the streams and associations
>>> between the streams via an API only.
>>> Point 4, 5 and 6 in the specification all have to do with the complexities
>>> of having to describe the intentions of mixing in SDP. So no comment
>>> beyond ³don¹t use SDP².
>>> As for 7.1 ­ ³this is because the sender choses the SSRC² ­ only true
>>> because we are forced to use SDP and the assumptions is that it¹s SIP. We
>>> could have the receiver dictate what the sender should use in advance of
>>> any media. In our case, we establish in advance what we want from all
>>> parties before even ³ringing² the other party. We do not have SSRC
>>> collisions as we reversed the scenario allowing the receiver to pick the
>>> expected SSRC. Coordinating the streams is a problem with SIP because of
>>> how they do forking/conferencing. This specification forces this issue on
>>> those not using SIP. If SIP has problems with streams arriving early to
>>> their stateful offer/answer then let them worry about ³how² they intend to
>>> match the streams at a higher SDP layer and get this draft out of the
>>> RTCWEB track on the SIP track. To be clear, the proposal seems entirely
>>> reasonable and intelligent for SIP/SDP. But it¹s way to SIP centric for
>>> general use.
>>> On that note, what I do need in the API is an ability to dictate the SSRC
>>> when I create an RTP stream for sending (should I care to do that).
>>> 7.2 Multiple render
>>> Again this is an issue of SIP/SDP. We can control the SSRCs to split them
>>> out to allow multiplexing easily on the same RTP ports with multiple
>>> parties/sources. If given the primitives to control the streams just, this
>>> specification could be used to dictate how to negotiate issues in their
>>> space.
>>> 7.2.1 I¹m feeling the pain. How about just giving me an API where I can
>>> indicate what streams are FEC associated.
>>> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
>>> fingerprint and security myself beyond that.
>>> 8. Let's just say politely that I would not want to be the developer
>>> assigned to programming around all this stuff.
>>> Again, a perfect illustration why I don¹t want SDP.
>>> Media is complicated for good reason as there are many untold use cases.
>>> The entire IETF/W3C discussion around video constraints illustrates some
>>> of the complexities and competing desires for just one single media type.
>>> If we tie ourselves to SDP we are limiting ourselves big time, and some of
>>> the cool future stuff will be horribly hampered by it.
>>> My issues with SDP can be summarized as:
>>> - unneeded - much too high level an API
>>> - arcane format - legacy and problematic
>>> - offer/answer
>>> - incompatibilities
>>> - lack of API contact
>>> - doesn't truly solve goal of interoperability with legacy systems (eg.
>>> SIP)
>>> Regret that I did not have time for feedback earlier. As you can tell, I
>>> am not at all happy with where we sit today wrt requiring SDP. IMHO we
>>> need a lower level API if we are going to insist on using SDP.
>>> You can read my entire (long) rant against SDP here
>>> _______________________________________________
>>> rtcweb mailing list
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list