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

Roman Shpount <roman@telurix.com> Thu, 07 March 2013 18:44 UTC

Return-Path: <roman@telurix.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 A02DE21F8945 for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 10:44:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.845
X-Spam-Level:
X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB18=0.131]
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 D0BPOmUUr3ob for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 10:44:30 -0800 (PST)
Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id A3D0D21F854E for <rtcweb@ietf.org>; Thu, 7 Mar 2013 10:44:29 -0800 (PST)
Received: by mail-ee0-f52.google.com with SMTP id b15so595243eek.39 for <rtcweb@ietf.org>; Thu, 07 Mar 2013 10:44:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=VeQp8h3xJ7q6QTpSmVgTnPQi9FeVXxWh3b9nPNP/6ao=; b=Pp/wg7D2bPoBvdy8Qsj5GEOf2OpZa0W6IoCgL4PAMzjtY2ZGdt1qIkUYGDsWsBOXjp dYbr1EaepwT1iGvSnV4cW77tMre8u3kI3xKAEIFSSDAhyIs1UkfkIN43WecllP2FFmqS hVGJ/LA5bHpf9ppr4FkTlrlkLxdquWftPMhqXdqBDg+kRPkU9+W5trYgdfJE6g6STUx5 uRxUMVpsC9PoDm6Go9gbP5xjY86fN1Y4KN9/C+0Gtt24Wuo5ctq8SSyQncRpJEJOk9oX zMqLJzJt5BaL8Hs9+YH4J3cAeTPfL0btsY0121TS8Yc0bauzQpg5Z+Z043tbRBxSS7t0 51Gw==
X-Received: by 10.194.158.161 with SMTP id wv1mr57014106wjb.38.1362681868602; Thu, 07 Mar 2013 10:44:28 -0800 (PST)
Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]) by mx.google.com with ESMTPS id eo1sm34853204wib.8.2013.03.07.10.44.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Mar 2013 10:44:27 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id hm14so515666wib.16 for <rtcweb@ietf.org>; Thu, 07 Mar 2013 10:44:26 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.91.106 with SMTP id cd10mr35702702wib.6.1362681866290; Thu, 07 Mar 2013 10:44:26 -0800 (PST)
Received: by 10.217.107.135 with HTTP; Thu, 7 Mar 2013 10:44:26 -0800 (PST)
In-Reply-To: <CAJrXDUHvcsuN6vXs8wku_aUrs-siHdn2wBDOJBgpgDPJySgdSg@mail.gmail.com>
References: <CD5D3F35.B22B%robin@hookflash.com> <B9549E2E-6E68-4F34-A9C0-1F050285A70A@acmepacket.com> <CAJrXDUGSMfQ=SNrSxKVvay=4JUXHULy0cO2pRN9+iFJ23doWZQ@mail.gmail.com> <CAJrXDUHvcsuN6vXs8wku_aUrs-siHdn2wBDOJBgpgDPJySgdSg@mail.gmail.com>
Date: Thu, 7 Mar 2013 13:44:26 -0500
Message-ID: <CAD5OKxvAm=ES6c+ryJ4kBpM7JiOOxDs8YxLt-92XjKDFt1xO9Q@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Peter Thatcher <pthatcher@google.com>
Content-Type: multipart/alternative; boundary=f46d043be11a95317604d75a18c6
X-Gm-Message-State: ALoCoQm5z+TP3KY1yZAPU3Wmp8cXjIhjuiqG9I3I/g35MnEci6XSg+PpcQGEgXMRMpmYy7gJoVsU
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:44:31 -0000

I very strongly agree. I think having an API independent from SDP will
allow the group to concentrate on the actual features instead of arguing
about the useless blob syntax. I was initially proponent of Offer/Answer
but once I started using the actual API, I saw offer/answer presenting
nothing but problems. I actually see current WebRTC SDP offer/answer
implementation as a hindrance to SIP interop. It provides a much more
coarse API then typically present in SIP client. That in turns forces
WebRTC implementer to make decision for a developer that create interop
problems (like no way to switch send codecs without changing transport
parameters).
_____________
Roman Shpount


On Thu, Mar 7, 2013 at 1:33 PM, Peter Thatcher <pthatcher@google.com> wrote:

> A question for all of you in the "please don't make us use SDP as an
> API forever" crowd (and I include myself): Would it be acceptable to
> you to have an intermediate step where we keep createOffeer,
> setRemoteDescription and setLocalDescription as-is, but allow a JSON
> argument?  It seems to be that such a thing could provide all the same
> low-level of control as any other setup of methods, but may be much
> more likely to be accepted by the group as a whole.  And, it would
> still be a lot more pleasant for application developers, and leave
> more flexibility for a future where low-level methods might be added.
>
> As both an application developer and a browser implementor, I think a
> good SessionDescription JSON format would be easy to implement,
> pleasant to use, a small incremental step from what we currently have,
> and would relieve the standards body of so much fighting over what the
> SDP should look like.
>
> I know it wouldn't be exactly what you're looking for, but I think it
> would be achievable and much better than what we have.
>
> If you're interested in such a thing, let me know.  I might be able to
> provide something a little more concrete idea as to what such a format
> could be.
>
> On Thu, Mar 7, 2013 at 10:23 AM, Peter Thatcher <pthatcher@google.com>
> wrote:
> > 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>