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

Peter Thatcher <pthatcher@google.com> Thu, 07 March 2013 18:24 UTC

Return-Path: <pthatcher@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 B4E3021F8B1D for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 10:24:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 g-CHHBuU2kCg for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 10:24:29 -0800 (PST)
Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 70AE821F8ACA for <rtcweb@ietf.org>; Thu, 7 Mar 2013 10:24:29 -0800 (PST)
Received: by mail-ve0-f182.google.com with SMTP id ox1so636773veb.27 for <rtcweb@ietf.org>; Thu, 07 Mar 2013 10:24:29 -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:content-transfer-encoding; bh=koHVyROIWgsEXj8dmDrrQm9XdaAzEWeg9eQ/ktRpLhk=; b=OOmbMGhibDDLV+1HKP2rYAIhWw9Ty5k9COvnzryLuthKuqKxONkBUnYEfXc81/ARRf h6aizG3zCjEsEQ0SqUZlfQMhrqWLevA/nYhT+a63M25hr+7dCxJoeHlO8QwbeRzSylDa pefiyQB4DDwO7GW0xkgFKUM5nznTdGiq5h8BT7lrxSFUy5aSOe8NUKFM7nGFTAoX/D01 R76tR8T8wtvnLgW4mWjlLIOB4gstE6Wb00BxxDTlQmVWIfpbb25ooZsbMyJO8CPsDqAj T+RVElwaAUeClaxwWBqODr8QKHga+hk8c1MxJCdJTMIyuLvD4/4eqEo8mL5A561DsGl2 /pYA==
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:content-transfer-encoding :x-gm-message-state; bh=koHVyROIWgsEXj8dmDrrQm9XdaAzEWeg9eQ/ktRpLhk=; b=VUhT+kr5pu6bgum/9xDEiF1LqhWdn/Ly7CPRVekj1L1mGP0qLmlFgfL8H5RQz1OJh6 lkZiqNvJlsR7Fu6HqmHUv30iYt82uP1jH7Fn+EnRPYkTg6q0jw0rxyaqwdFj8dhKuqDx SGGn/Inpf+oqlaD0EfG+QAp5e/zW3TaUmAEynSXscYST0F7VkcJsn8BfT9RX/ptYF7/x G3cvDsv+1+LLb7wca61baSdoqELPyswIj8mVLpcHWLL0L1tbJtJQIthl6go7SlCOWQdV mQ71aiNDhtqPa1zM8L2+GUg+/zychcFr5mpn5t4LVUuyMnLQsmR3Cq0V13D8xFp/mIO5 A2ig==
X-Received: by 10.58.168.208 with SMTP id zy16mr3139997veb.3.1362680668914; Thu, 07 Mar 2013 10:24:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Thu, 7 Mar 2013 10:23:48 -0800 (PST)
In-Reply-To: <B9549E2E-6E68-4F34-A9C0-1F050285A70A@acmepacket.com>
References: <CD5D3F35.B22B%robin@hookflash.com> <B9549E2E-6E68-4F34-A9C0-1F050285A70A@acmepacket.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Thu, 7 Mar 2013 10:23:48 -0800
Message-ID: <CAJrXDUGSMfQ=SNrSxKVvay=4JUXHULy0cO2pRN9+iFJ23doWZQ@mail.gmail.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnhKV9vg0oajqVUS6WnScRpdA3NC2nnx93PJKBREt6WUvjnxV8XD2QZVP6Y9Y6bJFl3IWSOr3bf9rZFWzHDy9fKHEuQg+Bwx4X04hwGXvOTpCnsRSkOHx3iEKudrm9b+7qk4ahnIfClJ27KjmH9xtBLM9fmc8sb8qoyQl994dqQ6b9LAKYHv93ki3koZccRKz9/IHY+
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 18:24:30 -0000

Hadriel,

That email is great.  Thank you for preserving it and for bringing it
to our attention.  I am especially sympathetic to the argument that
it's undesirable to have the W3C tied to MMUSIC for all time.




On Thu, Mar 7, 2013 at 8:50 AM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:
>
> 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 mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb