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

Hadriel Kaplan <> Thu, 07 March 2013 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33B3B21F8A35 for <>; Thu, 7 Mar 2013 08:50:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p5Lm0hXb7d2J for <>; Thu, 7 Mar 2013 08:50:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0EF8821F8A42 for <>; Thu, 7 Mar 2013 08:50:47 -0800 (PST)
X-ASG-Debug-ID: 1362675046-03fc21725fd53f70001-4f8tJD
Received: from ( []) by with ESMTP id EFduSsnpYkeQHgRq (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 07 Mar 2013 11:50:46 -0500 (EST)
Received: from ([]) by ([]) with mapi id 14.02.0283.003; Thu, 7 Mar 2013 11:50:46 -0500
From: Hadriel Kaplan <>
To: Robin Raymond <>
Thread-Topic: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
X-ASG-Orig-Subj: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
Thread-Index: AQHOG1Ppn8Vr1MpYMkefVsymk7EOnQ==
Date: Thu, 07 Mar 2013 16:50:45 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Start-Time: 1362675046
X-Barracuda-Encrypted: AES128-SHA
X-Virus-Scanned: by bsmtpd at
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version Rule breakdown below pts rule name description ---- ---------------------- --------------------------------------------------
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:10:57 -0000

I knew there was a reason for posting an email for the archive machine to store for eternity... see this:


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