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

Justin Uberti <juberti@google.com> Fri, 08 March 2013 22:57 UTC

Return-Path: <juberti@google.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 20B8721F8578 for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 14:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level:
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 9UA54FUsafdc for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 14:57:11 -0800 (PST)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B784021F8576 for <rtcweb@ietf.org>; Fri, 8 Mar 2013 14:57:10 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id 13so2714929iea.14 for <rtcweb@ietf.org>; Fri, 08 Mar 2013 14:57:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=bdkEa8Ko37jF2hOrYnxPCZ6hdN3ysy8oGYnQtFmYQDA=; b=epVyGa6FtHP9uTTxYf9Bw1+ZHQqVom3QB8mTwHYEYNPwPCTomGiufzM7TQ8Z3goiEf 2T3CcOqQxHndpzvX9cNLKFeNrpZ6NgeYZOyeyunu4gJHBp6xV0izuTsWeUPzNeBViYEL QqnYmfj1KLFbSw+AAkykRATjmm2M7vexTBL425CIBaDeZi78yk+ww8tdmMd186BVTm8i WJVq0VYgYJ1/6Tw8chgxDm9GTz+69TW1QReKduvTdDk2nbDjGi1O+1qTD8kLL4e5VNLX ImEQPkyUpGo42wN8pF/jQomkb28MT4r7vaiEXH+AxdnAqETb0k0qD9Y0kZB3261tNowJ ClFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=bdkEa8Ko37jF2hOrYnxPCZ6hdN3ysy8oGYnQtFmYQDA=; b=Md1n5KvojeswzwMLIpM+pIP8jcRi8nS+QclHbVrO1XlZ+o61aJ5k2MaYgb7XYt7Jyb 1V9KthVfppDb9De5rpRIXQbin60DAAMjVKXh88daGkC4WIjtHiP2c1ge0n2QPiUgWK2U AlrGYiiyLhpcYMULtSGXpla4OpR5CMg1EOVkxCoxY5yMOKtb7GpOVvNhfv/eBwP+1Hr+ GnmSSMEgmZerMnz0SYNytJ4ZRL6IUCfI/ItMe05/cY9y+bZaIP8OeNXIb/2hiENa55PA dHMnWl9TV5CZLgMHHn/cfpbxhf7jN4Y4xaDbPN3dG079Qs0WxyBMM1WHaY/YYY07b0qu WYJQ==
X-Received: by 10.43.8.200 with SMTP id ot8mr2738595icb.11.1362783430071; Fri, 08 Mar 2013 14:57:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.250.18 with HTTP; Fri, 8 Mar 2013 14:56:50 -0800 (PST)
In-Reply-To: <CD5D3F35.B22B%robin@hookflash.com>
References: <CD5D3F35.B22B%robin@hookflash.com>
From: Justin Uberti <juberti@google.com>
Date: Fri, 8 Mar 2013 14:56:50 -0800
Message-ID: <CAOJ7v-1oW1v+=dyF_nf3-MO2_iKufjV2Y83hCmiAHZN5oP4fgA@mail.gmail.com>
To: Robin Raymond <robin@hookflash.com>
Content-Type: multipart/alternative; boundary=bcaec5161fff41713404d771befc
X-Gm-Message-State: ALoCoQmTbtZ4PgPUsEMbhLRGdRPTUbhpdL4LwkTCQxls1m4EVJ1eHaRlJ0OLapf1K3QlwGzL3br/SMAqX8D9YZ7UR89nd9wBDQaKJpZk2Jwr5kPCtWd1MvjV5lWXEoqhAgl8Iwh6YBGvdapsn3n4R3wXGtp5VeYdJpuY9l5SgMt0qKGgUscN4DwmrL0o0tpabBgDssH9+9rn
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 22:57:12 -0000

I sympathize with the concerns originally posted by Robin, and I am glad to
see this kind of application developer feedback in this forum.

The current model has many compromises, to be sure. But in this WG, we have
been able to resolve many tough decisions, and get to a point where we have
multiple interoperating implementations, spanning desktop and mobile, which
means we must be doing at least something right. So, with apologies to the
Beatles, when you talk about destruction, don't you know that you can count
me out.

Rather, as I look at Robin's comments, which are directed toward
https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/, I see them as
an indication that "Plan A" ties us more deeply to SDP and legacy
behaviors. He wants the ability to make his own decisions about how these
things should be handled, including setting the SSRC for a stream, setting
FEC, crypto keys, multiplexing, etc. This is more akin to the "Plan B"
approach, which Chrome currently implements (and in which these things are
possible, albeit through SDP).

I certainly agree that SDP is a terrible thing to have to work with from
within a Javascript application, and as Peter has mentioned, there are a
number of ways in which we could improve that. But that is a question about
the API surface, and we can (and should) deal with this separately in the
W3C.



On Wed, Mar 6, 2013 at 3: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
>