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

Peter Thatcher <pthatcher@google.com> Fri, 08 March 2013 13:51 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 B421D21F863A for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 05:51:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.76
X-Spam-Level:
X-Spam-Status: No, score=-102.76 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 JfzAUTk2FlrB for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 05:50:58 -0800 (PST)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1B68621F85D9 for <rtcweb@ietf.org>; Fri, 8 Mar 2013 05:50:57 -0800 (PST)
Received: by mail-vc0-f178.google.com with SMTP id m8so929644vcd.9 for <rtcweb@ietf.org>; Fri, 08 Mar 2013 05:50:57 -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=0mal0eBwjUF+3ed3IAnmb7S0KLnalttq69OFSHuXdZY=; b=DkrOJyXEZX5GflG5ElRJZlWTpNT7s4UwA97I/VIFEuxlCUPHJqYqWOk1zl70U1O4vO qEg83Fvj+6zDVDF6n4X/4RCtPpNplGlPzlp+RW2riRX/h/uhnVfZZ/PqY4VE9dnV572i /8Py6hZm/bfNV/l2sApQhiq7Xk1RzXknnrS8SXkZ2SAz/w4M4xSC+9qQyZ1VpqhPWfJB vbWUGnaD+efB7zBlp6oTNV1qtmE6K8IS+fBiaOBK7B1hRki03uRFalrMgpdB7jQ9A6hc zU5q+j5htKUWOqn3oKXk+qe2mjWxc93Ni/hdbS/CPVdys7jAyWMvdT4J5te0OtDrUCdP KP7w==
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=0mal0eBwjUF+3ed3IAnmb7S0KLnalttq69OFSHuXdZY=; b=Qy1adlHGiOnE8besaZvLJhwKh9gG6W4d2SdLFQpcF+JHu7U9kmCFNAqwvg19nVX83B /RmLRigvfM9cphr5OsM1kGxmsZg1vwcAike0aaKeeNNDOyMrfeLWb6PvuTw5fOhYKswV iOltWZi+cuVsRIo8V5LcfF9RzdGhqHx+9lDkV3oZx8rENgdrUmlP0UdZIp+hE9cCRhbf VWQhb4AtVwwVgsBSo8kuVMgRAwNhsAr0Aap6wR8LuN+TdO4bkTDKsm7aOn29wnj0wpdU qFuaOCoXAvKRk2LD408w8mpZTtawW/28ym5WbTHtvP1gq/F68XyI7xIzrUtsNZlYhCl1 KIgg==
X-Received: by 10.58.48.166 with SMTP id m6mr906652ven.59.1362750657319; Fri, 08 Mar 2013 05:50:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Fri, 8 Mar 2013 05:50:17 -0800 (PST)
In-Reply-To: <5139AF4C.70109@ericsson.com>
References: <CD5D3F35.B22B%robin@hookflash.com> <5139AF4C.70109@ericsson.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 8 Mar 2013 05:50:17 -0800
Message-ID: <CAJrXDUFJBhvTzOcAhYPhEg9qgi8yZyFt-UeF60K7esA0+1v=PQ@mail.gmail.com>
To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQk8l4QhdLCompktwWKrynJFCgeFLJCXsamIUuOsqjXvQsKw3fn73xU2eOuQZmMaSM8Nn0TmINZXnesNbvqSOi5IeXXf9NTP7+NnvLONLgCm4t6TFzN3Omq1oeRfLirlDGEPtzAqheaKh3xEl+6ZOZ0L/6d8ad1+5LfZoRu4YkViWqGSbjF/xWO0iEp6ZI7ho3WAIRO9
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 13:51:02 -0000

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