Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
Hadriel Kaplan <HKaplan@acmepacket.com> Thu, 07 March 2013 16:50 UTC
Return-Path: <btv1==77867126054==HKaplan@acmepacket.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B3B21F8A35 for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 08:50:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5Lm0hXb7d2J for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 08:50:51 -0800 (PST)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF8821F8A42 for <rtcweb@ietf.org>; Thu, 7 Mar 2013 08:50:47 -0800 (PST)
X-ASG-Debug-ID: 1362675046-03fc21725fd53f70001-4f8tJD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id EFduSsnpYkeQHgRq (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 07 Mar 2013 11:50:46 -0500 (EST)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.30]) with mapi id 14.02.0283.003; Thu, 7 Mar 2013 11:50:46 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Robin Raymond <robin@hookflash.com>
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: <B9549E2E-6E68-4F34-A9C0-1F050285A70A@acmepacket.com>
References: <CD5D3F35.B22B%robin@hookflash.com>
In-Reply-To: <CD5D3F35.B22B%robin@hookflash.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <20CD67D6E4DEFC42972C64CB73EE1FC7@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1362675046
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
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 3.2.2.124527 Rule breakdown below pts rule name description ---- ---------------------- --------------------------------------------------
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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: http://www.ietf.org/mail-archive/web/rtcweb/current/msg01256.html -hadriel On Mar 6, 2013, at 6:45 PM, Robin Raymond <robin@hookflash.com> 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). > > https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/ > > 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 > http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/ > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Proposed Plan for Usage of SDP and RTP -… Robin Raymond
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Hadriel Kaplan
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Martin Thomson
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Mary Barnes
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Eric Rescorla
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Roman Shpount
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Eric Rescorla
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Mary Barnes
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Erik Lagerway
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Silvia Pfeiffer
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Iñaki Baz Castillo
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Iñaki Baz Castillo
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Silvia Pfeiffer
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Silvia Pfeiffer
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Iñaki Baz Castillo
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Roman Shpount
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Matthew Kaufman
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Iñaki Baz Castillo
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Silvia Pfeiffer
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Matthew Kaufman
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Silvia Pfeiffer
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Timothy B. Terriberry
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Silvia Pfeiffer
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Timothy B. Terriberry
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Harald Alvestrand
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Stefan Håkansson LK
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Robin Raymond
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Stefan Håkansson LK
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Stefan Håkansson LK
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Stefan Håkansson LK
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Matthew Kaufman (SKYPE)
- [rtcweb] Division of labor (Re: Proposed Plan for… Harald Alvestrand
- Re: [rtcweb] Division of labor (Re: Proposed Plan… Matthew Kaufman
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Justin Uberti
- [rtcweb] Separating stream manipulation from the … Harald Alvestrand
- Re: [rtcweb] Separating stream manipulation from … Peter Thatcher
- Re: [rtcweb] Separating stream manipulation from … Stefan Håkansson LK
- Re: [rtcweb] Separating stream manipulation from … Harald Alvestrand
- Re: [rtcweb] Separating stream manipulation from … Ted Hardie
- Re: [rtcweb] Separating stream manipulation from … Martin Thomson
- Re: [rtcweb] Separating stream manipulation from … Silvia Pfeiffer
- Re: [rtcweb] Separating stream manipulation from … Suhas Nandakumar
- Re: [rtcweb] Separating stream manipulation from … Silvia Pfeiffer
- Re: [rtcweb] Separating stream manipulation from … Harald Alvestrand
- Re: [rtcweb] Separating stream manipulation from … Dale R. Worley