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

Stefan Håkansson LK <> Fri, 08 March 2013 14:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5432721F86EF for <>; Fri, 8 Mar 2013 06:11:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JgwPfzKVR6AD for <>; Fri, 8 Mar 2013 06:11:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 16B0F21F84F8 for <>; Fri, 8 Mar 2013 06:11:24 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-e9-5139f18aeb20
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 01.BB.10459.A81F9315; Fri, 8 Mar 2013 15:11:22 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 8 Mar 2013 15:11:22 +0100
Message-ID: <>
Date: Fri, 08 Mar 2013 15:11:22 +0100
From: Stefan Håkansson LK <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Peter Thatcher <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Rrfro2WgwbcZWhbXlr9mtVj7r53d gcljwaZSjyVLfjIFMEVx2aSk5mSWpRbp2yVwZfx7dpOxoN2j4vrBLuYGxkVWXYycHBICJhKb P3SwQ9hiEhfurWfrYuTiEBI4ySixZcdndghnDaPE5UVbGUGqeAW0JZavOcwKYrMIqEgcODKB DcRmEwiW2L8cpJuDQ1QgSuLKPkuIckGJkzOfsIDYIgKaEpMnN4O1MguoS9xZfA5ssTBQ+ddn P6AWf2eUWLNyLRNIglMgUGLp7n5GiAYLicVvDrJD2PISzVtnM4PYQgK6Eu9e32OdwCg4C8m+ WUhaZiFpWcDIvIqRPTcxMye93HATIzAkD275rbuD8dQ5kUOM0hwsSuK8Ya4XAoQE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUwMqpViy8LTlcIN4z/VvTM/pd2T0NZvtZKo5TKpyePNLBfen6z cdfro+cfRr74+vy2UK5zXrd3TmvgNMm5rq0KVx0jhcqlTwoYRXxcHVcxx82eJ2COd9hPu929 F0o/Fzm9Enml9t6Ev0rRckbV5ZViXtX5xe1/fRzbL7FW8jr4sx68J+bp8k6JpTgj0VCLuag4 EQBnnLlhFwIAAA==
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: Fri, 08 Mar 2013 14:11:34 -0000

On 2013-03-08 15:07, Peter Thatcher wrote:
> Is the blob format defined by the IETF or the W3C?

It is defined by the IETF currently.

> If the W3C decided
> not to use SDP as the blob, or not to use blobs at all, what would
> that mean for the IETF?

That is a good question, and something that could be discussed if the 
IETF fail to make progress on resolving the issues around the SDP blob 
format (in my personal opinion).

> On Fri, Mar 8, 2013 at 6:04 AM, Stefan Håkansson LK
> <> wrote:
>> On 2013-03-08 14:50, Peter Thatcher wrote:
>>> One the question of "what info do the two endpoints exchange to be
>>> able to set up connection(s) and send and receive audio, video and
>>> data", my  assumption has *not* been SDP, but rather that it has been
>>> left to the javascript application to decide what info to exhange.
>>> I've heard over and over at WebRTC meeting and conferences that
>>> "signalling is not defined; that's up to the javascript application".
>> I agree to the above - signaling is entirely up to the application. I'm
>> sorry if my message gave another impression. But we need to define the
>> format of the "blobs" (if we call them that) that browser A produces so that
>> they can be plumbed into browser B and things work. So far the assumption
>> has been that those blobs are SDP descriptions, and my point is that
>> changing that to something else may cost us more than we gain.
>>> I completely agree with that and think we should stick to it.  In
>>> Google Talk/Hangouts, for example, we use Jingle, not SDP.  SDP only
>>> serves as a javascript API surface, not as a format to exchange with
>>> the remote side.
>>> As an application developer I do not want to exchange SDP.  I only use
>>> it as an API surface.  And it looks like I'm not the only application
>>> developer that sees it this way:
>>> -
>>> -
>>> -
>>> -
>>> Again, for me, and many others it appears, SDP only serves as a
>>> javascript API surface.
>>> On Fri, Mar 8, 2013 at 1:28 AM, Stefan Håkansson LK
>>> <> wrote:
>>>> On 2013-03-07 00:45, 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).
>>>> I think we are mixing up two different things in the discussion. One is
>>>> "what info to the two endpoints exchange to be able to set up
>>>> connection(s)
>>>> and send and receive audio, video and data" and the other is "what APIs
>>>> should we use to control the settings".
>>>> For the first part, the assumption has so far been SDP. I think we've all
>>>> realized now that the legacy of SDP gives us quite a bit of headache. I
>>>> think that splitting up signaling about connections (ICE candidates) from
>>>> signaling for media stuff (codecs, how different ssrc's correlate to
>>>> MediaStreamTrack's, ...) would simplify things a lot. But on the other
>>>> hand,
>>>> it seems to me that we're really close to nailing those details. I'm
>>>> pretty
>>>> sure that switching to some other format would cost more in time than we
>>>> gain.
>>>> Also, remember that those session descriptions come with a flag saying
>>>> "sdp". This is intentional, it gives us the freedom to change format
>>>> without
>>>> affecting the application in the future (as long as the application can
>>>> follow the normal createOffer/setLocal etc. procedures).
>>>> When it comes to the API, that discussion is really for the W3C webrtc
>>>> WG.
>>>> But as has been said by Tim and Harald already, the session descriptions
>>>> should never be changed in normal cases - there should be (and are) other
>>>> APIs for setting up how a MediaStreamTrack is transported over the
>>>> network,
>>>> resolutions, etc. What is set in those APIs will be reflected in the SDP
>>>> created by "createOffer".
>>>> Stefan
>>>>> 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