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:05 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 DF78221F8626 for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 06:05:56 -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 SoixV9uvJJHI for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 06:05:51 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2752321F85E0 for <rtcweb@ietf.org>; Fri, 8 Mar 2013 06:05:50 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-99-5139f03ee90b
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AF.44.32353.E30F9315; Fri, 8 Mar 2013 15:05:50 +0100 (CET)
Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Fri, 8 Mar 2013 15:05:49 +0100
Message-ID: <5139F03D.1010009@ericsson.com>
Date: Fri, 8 Mar 2013 15:05:49 +0100
From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= <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> <CAJrXDUGV_nxPBTxhPJezGMoHNb+zSfC9Nhj7nyimGZMN=dFiOA@mail.gmail.com>
In-Reply-To: <CAJrXDUGV_nxPBTxhPJezGMoHNb+zSfC9Nhj7nyimGZMN=dFiOA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Rtfug2Wgwe8OYYtry1+zWqz9187u wOSxYFOpx5IlP5kCmKK4bFJSczLLUov07RK4MpqP7WErmGxS0fzqP3sD4w/NLkZODgkBE4k7 81ayQdhiEhfurQeyuTiEBE4ySvSdXwjlrGGUuLCrixWkildAW+J42xVmEJtFQEVi+f9zYDab QLDE/uUg3RwcogJRElf2WUKUC0qcnPmEBcQWEdCUmDy5GWwMs4C6xJ3F59hBbGGg8q/PfkDt msQo8fFJM1gDp0CgxOKFjewQDRYSi98chLLlJZq3zgbbKySgK/Hu9T3WCYyCs5Dsm4WkZRaS lgWMzKsY2XMTM3PSy803MQJD8uCW3wY7GDfdFzvEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QD4+TiLbUr/bapP9gQNSlR+U+9V+f/KVv+d/1YG7T51tGjjSqhR55VXOF7 E6fTl1n25bbip/MBkw59C7257+aFj06vLTe/PvTPsZ6547pj0nrzZ4ceSOb8FXm6d0uDdlCf pUTThZCc9tyawwGPtri9jw7Q6T54OHha9K4zayK+8Wi8ts+wnpvNPUuJpTgj0VCLuag4EQCA MfaHFwIAAA==
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:05:57 -0000

On 2013-03-08 15:01, Peter Thatcher wrote:
> Stefan, that is a very good point about the W3C.  Should Robin share
> his input with the W3C WG rather than this one?

He should at least send his input there as well.

Stefan

>
> 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