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

Peter Thatcher <> Fri, 08 March 2013 14:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E591521F85D9 for <>; Fri, 8 Mar 2013 06:02:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.752
X-Spam-Status: No, score=-102.752 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PxBWi7fsf++H for <>; Fri, 8 Mar 2013 06:02:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C65D721F8596 for <>; Fri, 8 Mar 2013 06:02:25 -0800 (PST)
Received: by with SMTP id da11so1307233veb.10 for <>; Fri, 08 Mar 2013 06:02:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=3glyFVvL1EwncjFCAtH+5BrU93aQW/RY5bKJuFFOeBM=; b=AhYUN7KvwWP5ya8dJOvV88/fV1I5Lw1Y5/xaE9VFRqQEVVhFdAuA3L4yCOV5px+MCi 4obwt9IE2HJ1mXBAj8TA/XsZDU/vQhdpKMc68QCm8N9Jn8FmYtk/viDA93XMYph1WPFY afjFdddvRa/6PzUt95BkmhqnI6m2sjBuxUP0LKwzHqLPQ2HWrDfZisE5sO06LudKquNT HhA5pNGevqZ2tpm5zEQQtiEdyKz6GinE8Ei5BWKKCUG8nLoSdVVDLiHbPGBF37yed6/p EkIJj1ePT7WMD02841Ikqu1ts41XxFZQpl2Z24kKGzVX9gPYHfXNmbbXORTRe2qMKkfx H14g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=3glyFVvL1EwncjFCAtH+5BrU93aQW/RY5bKJuFFOeBM=; b=imyifNnPJBqMNbcCWeI724ZSzAlNukLnOrfojGVduln3Uc9pAWKFSFlj6KYaQ2DbWO bYrN0gb1e1g9jLqurTWEIQS9fFUaLVk5aaejdozbng6I5j7SrrqQLN26Evi+qJ73lzwY 0N5Nt5/wapYFltMRaOnuWvDYkt7oK+BtVtrfuVOpoVn2s8tGrBI07qeqGg4C3eY2Jt6Y vnxX3YlE69z9brvsIT5xgLISefH9xqXfCTp0Hi3YgJSBfNO2kUKHhC28s++RYaobilVV NRWXRmuTuiyupA3AzDHq3jGDFXb4Xi5rzCwEqxknGK0NEWjy4gz9RqT5dvMHcga9vYZ1 dCTQ==
X-Received: by with SMTP id p4mr784341vdi.125.1362751345108; Fri, 08 Mar 2013 06:02:25 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 8 Mar 2013 06:01:45 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Peter Thatcher <>
Date: Fri, 08 Mar 2013 06:01:45 -0800
Message-ID: <>
To: Stefan Håkansson LK <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkNuiaAx/UrJxY9RGwfktMNBZ0K7UcQXR8/2f8uvSCqeIXI9up4DsVbyKLhUUUMevEqkTjLC/RPtgFzG5kJgYL5sLRA33XA8Sael0r4JFW8qDqyQewu06jFbuh+4L3Gn5G+gKHV1pehscDuW8s6mmdXjmHzd1xpB7degf7dwX9CJJR5Zh80HQcCKSa2xxHVCnWz3RdY
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:02:30 -0000

Stefan, that is a very good point about the W3C.  Should Robin share
his input with the W3C WG rather than this one?

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