Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

Peter Thatcher <pthatcher@google.com> Wed, 19 June 2013 16:41 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 1B16421F9CAC for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 09:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 ILyQAjDcoWak for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 09:41:38 -0700 (PDT)
Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0888D21F9C8F for <rtcweb@ietf.org>; Wed, 19 Jun 2013 09:41:37 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id t12so5224099pdi.7 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 09:41:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=en0KuSmihrtIC1EssnlryKUgjy8dstN+BSQAATTDmiQ=; b=KdECPIbr94ZUxR+o4IeOQdBPojoUcslM8isSrQURAxYJTmrPtFyK4+QbGPnbGvZc+h leGS538xOg4Nue+ce1BqBjvh1Ek+mfh9gYZkhlVQBAxWzsTZcJQ3SQWTdlVQbTYDrsHh 6vSbihGLMBhQsxFpFnkdkGX2qsGHeS7BXmFxVOLVOf67FRNB08OZUTZi/IIpeSbpAFtQ CPJQN0o3GUQ1E76e46MgUY+lDW7DQ0iYzSAvyiry9N6dTwqjlS6lDvOfkv5rBKk049CD cJEPJizVE8YrX/pA67wOlNnmeKh55oKkkv9pSDJreM0NnlKB5XlqzRQnwjbzaR5q/bCe pN7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=en0KuSmihrtIC1EssnlryKUgjy8dstN+BSQAATTDmiQ=; b=Ni75X54lrEtboSZ9wg/sW8Kxpr2g5/pyPHsZSVerw32dRB6toAIocSA1Lwc5iM2G+3 kX4HI6KGZolWmNufJcJ0hy5qFQSZE6hp1PPenfBBjJ6XelEhDkjJ5KgKrBaok0ZfxjGq zvIlGyzntVD8olsfyF2RawoXbDmk2sHq16+FY5jOO9S6O/qYq12ZIuUmoGfBxiKxioLq W3hZQpgCLu+b74bgjBQ5eWkqd+M08QZLrAIEipVCrUYvzLJPSnRw170DVc7SYBNGbfx3 lt6pkv5d0LuS0ro9w7ObPKe92LDEPepb7vAFtgH1CQw9yO8+0gaDDMgcxbLHz7mbMxeH iB3Q==
X-Received: by 10.66.250.164 with SMTP id zd4mr7579324pac.141.1371660097731; Wed, 19 Jun 2013 09:41:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 09:40:57 -0700 (PDT)
In-Reply-To: <CALiegf=GbR3K0dzMkaMWu88WdNY4JWQOmDPKeNfZQNuC5d4bog@mail.gmail.com>
References: <CALiegfkajJPxWZTzjYssP91VW+StStLpxoxGCkjOLKDMUWc0rA@mail.gmail.com> <CA+9kkMDk2L3SBPC08WU_5RcL16-Wzv8Mocj3-Qzmxz2E24ERGg@mail.gmail.com> <51C0C1A0.9010107@nostrum.com> <CAJrXDUGqSvsosZJhcRR-kCwEX1g_wvPnSZPmmcNwggk+Z9WNCA@mail.gmail.com> <CABkgnnWfV=5xBaRqAddqUURThs9J4T4+0HK4Ux07VA51r5oC3Q@mail.gmail.com> <CAJrXDUFNGKvWHw-yqeApEdTeuqMNPTDxvdKZ2DuzANmcR2y2CQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <CALiegfk39prkSinDCisSqOAD8yJZuGUwLAMBabao7eHuhnAYcA@mail.gmail.com> <CAJrXDUHe=vu2695xAkg2tKvQ7J5JNqraHCpY0rKx5rDQ0xCpiA@mail.gmail.com> <CALiegf=GbR3K0dzMkaMWu88WdNY4JWQOmDPKeNfZQNuC5d4bog@mail.gmail.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 19 Jun 2013 09:40:57 -0700
Message-ID: <CAJrXDUHG7ENOu12SkRpXOik3ArEShPHAJhtOwYyR3UaSDvQFOA@mail.gmail.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=047d7b15fea3e0d45804df848058
X-Gm-Message-State: ALoCoQkYDkc/g5o81iPkwDftenGjhcv6J3F8oPqAt74/oCleAIKnULsh4I2m1FhB6lFjZVRPicLQ2m7oZMrGCWAiGE0W/HcKGFImsSo5ta4s3perXuFXn+fdb4n8v4fIcoynhzLJOMpwb120vmgHXPvUdjTuB1mOrjpMgbgMLx6y2v8rfEZddxUPYTlMdQN8uBDKjCemp49k
Cc: "rtcweb_ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
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: Wed, 19 Jun 2013 16:41:43 -0000

On Wed, Jun 19, 2013 at 9:10 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> Hi Peter, for now just some comments (I agree that more use cases and
> other considerations must be provided):
>
>
>
>
> >> I don't think that the discussion is just about "SDP O/A usage in the
> >> API". We don't want a replacement for SDP, nor a new representation of
> >> SDP, nor to deal with blob strings between the JS layer and the WebRTC
> >> layer.
> >
> >
> > Please at least agree with Christer that this is about the API, not about
> > the signalling wire format.  The API already allows whatever signalling
> wire
> > format you want,
>
>
> IMHO that is not entirely true.
>
> First of all, whichever the signaling protocol is, it must accomplish
> with SDP O/A semantics (since it must carry a SDP and receive a SDP to
> establish the communication).
>

API calls must use the SDP O/A, but what goes on the wire doesn't have to
be.  With enough SDP hackery, you can do whatever you want over the wire,
including not use O/A semantics.


>
> Second: Indeed the current spec does not mandate what should be sent
> in the wire. In practice that means we can use SIP over WebSocket,
> XMPP/Jingle over HTTP, or whatever. But in practice it also means that
> we must send a SDP in the wire. The SDP blob string can be
> hex-encoded/escaped/mangled/whatever by the JS app, but the SDP blob
> string generated by PeerConnection-A should arrive to
> PeerConnection-B.


A sufficiently smart chunk of JS could call
setLocalDescription/setRemoteDescription with SDP that it completely
created itself, and send whatever it wants over the wire.


> And since such a SDP is generated by the WebRTC
> stack and passed to the JS as an unmanageable blob string, the JS app
> cannot properly deal with it.
>

The JS parse the SDP from createOffer/createAnswer, get the info it needs,
make decisions and then serialize different SDP back down in
setLocalDescription/setRemoteDescription.  It's terribly ugly, but it works.


> So, currently WebRTC does not mandate the signaling protocol
> in-the-wire, but it does mandate the media signaling protocol
> in-the-wire (you need to pass a working SDP to the remote, sure),
> something that constrains the signaling protocol itself.
>

It does not mandate SDP over the wire.  It's possible to write a JS app
that gets everything working with no SDP on the wire.  It's anything but
pretty, but it works.




> and everything you mention from here on out is just the
> API.  So please just say to Christer "yes, this is all about the API".  It
> will make the rest of the discussion much more clear.

> Ok, this is all about the API :)

>> In short we want something like a JS wrapper of the native
>> WebRTC API,
>
>
> I work on the WebRTC implementation in Chrome, and I don't know what you
> mean by "native WebRTC API".  Such a thing does not really exist.  The
> implementation has three different layers of abstraction, each of which
you
> might be referring to, but none of them which will give you what you want.
> The highest level uses SDP.  The lowest level gives you media bits, but no
> ICE, SRTP, DTLS, or SCTP.  The middle layer gives you all those things
> without SDP, but it still uses an abstract offer/answer for transport and
> RTP setup (and even has a Jingle implementation on top of that).  None of
> those give you what you want.  The "native WebRTC API" that you want to
wrap
> doesn't exist.

> Ok, IMHO nobody is still requesting a specific JS API but just
> describing the features and capabilities such an API must provide. The
> "similar to native WebRTC API" is just a comment to help understanding
> what we mean, but of course each browser is free to implement its
> native API(s) as it prefers so the "JS wrapper" concept does not make
> sense.

But you can't say "similar to native WebRTC API" because no such thing
exists.  You can't be similar to something that doesn't exist :).


>> to directly manage media/transport parameters and media
>> streams without having to pass a monolithic and unmanageable SDP blob
>> between the JS and the WebRTC layer.
>
>
> That boils down to "the same power of the current API, without going
through
> SDP".  I think that's a clear requirement.  So why don't you just say
that?
> Would save everyone a lot of reading and misunderstanding.

> You are right.



>> calls to get the required media parameters, the JS can send them to
>> the remote peer in the way it prefers (which may be via a SDP created
>> by the JS app, or via an AJAX request for sending codecs/media-types
>> info followed by a WebSocket connection for sending ICE candidates one
>> by one, or serialized in JSON via a previously open DataChannel
>> session... or whatever mechanism available in the Web and browsers).
>>
>
> You already have that.

> Can I first send my codecs list, then (once the peer notifies me
> codecs compatibility) send the codecs preference order, then my ICE
> candidates and later (not just when ICE process terminates) signal the
> peer a "OK" message so we both start the multimedia audio/video/data
> communication, all of this with the current API?

I think so, yes.

> (I mean without parsing the SDP blob and splitting it into blob
fragments).

Maybe... I don't know for sure.  But generally, anything beyond the most
basic uses of the API requires at least some SDP hackery, and advanced uses
require a lot.


Best regards.




--
Iñaki Baz Castillo
<ibc@aliax.net>