Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Fri, 08 March 2013 14:11 UTC
Return-Path: <stefan.lk.hakansson@ericsson.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 5432721F86EF for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 06:11:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgwPfzKVR6AD for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 06:11:25 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 16B0F21F84F8 for <rtcweb@ietf.org>; Fri, 8 Mar 2013 06:11:24 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-e9-5139f18aeb20
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 01.BB.10459.A81F9315; Fri, 8 Mar 2013 15:11:22 +0100 (CET)
Received: from [150.132.141.119] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 8 Mar 2013 15:11:22 +0100
Message-ID: <5139F18A.6060100@ericsson.com>
Date: Fri, 08 Mar 2013 15:11:22 +0100
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
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 <pthatcher@google.com>
References: <CD5D3F35.B22B%robin@hookflash.com> <5139AF4C.70109@ericsson.com> <CAJrXDUFJBhvTzOcAhYPhEg9qgi8yZyFt-UeF60K7esA0+1v=PQ@mail.gmail.com> <5139EFF8.7040603@ericsson.com> <CAJrXDUFh0MtS3M6xvwvNBoY1EG6GKBGAoiKWHcOSrzZ1_mLWYw@mail.gmail.com>
In-Reply-To: <CAJrXDUFh0MtS3M6xvwvNBoY1EG6GKBGAoiKWHcOSrzZ1_mLWYw@mail.gmail.com>
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: "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: 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 > <stefan.lk.hakansson@ericsson.com> 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: >>> - http://s.phono.com/releases/0.6/jquery.phono.js >>> - https://github.com/lukeweber/webrtc-jingle-client >>> - >>> https://code.google.com/p/openfire-candy/source/browse/trunk/plugin/candy/plugins/voicebridge/webrtc-jingle.js >>> - https://github.com/mweibel/sdpToJingle >>> >>> 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 >>> <stefan.lk.hakansson@ericsson.com> 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 >>>> >>>> >>>>> >>>>> 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 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