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

Peter Thatcher <pthatcher@google.com> Wed, 19 June 2013 18:44 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 D514821F99F0 for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 11:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 YucPMxzhrEvO for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 11:44:17 -0700 (PDT)
Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB1421F9935 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 11:44:17 -0700 (PDT)
Received: by mail-pd0-f180.google.com with SMTP id 10so5369328pdi.11 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 11:44:17 -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=86HXfZ8ztEUZVDMDbBOPeQ2Jd2+YL/HwBI1Mu0+3MnU=; b=I9tUI9omLSG/jCjgTKEeLWJw10mh7eOKoT47QQK7mE7iBDJDR9irKaSJdtd/keE2Ir xNqzkly0pXCGw6kJl8F4KdW5VnayUDdcgtEvzgOi+OGPebUbSCZpMUBjNjli6feNBMf4 1MNBy6lC+e0inwhMW+ZnF0Hlje6EmH42UE60AaVIV1F40Etv/JQq7q8lxQCq7bOA5VYG +FOJIPx6PVnmgfLNn/mLcEpy/OL45Rzv5Kgx9dAaMm1q2H4MziIeAZE8Lh8DnpQMHwXS oz9SlkRwb8368CNKT8e2C5vh4OqbL81RQKN17vRLrJp6iqQ3vavUP7wVoPEs0MGnUrpg khTQ==
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=86HXfZ8ztEUZVDMDbBOPeQ2Jd2+YL/HwBI1Mu0+3MnU=; b=Si7A58hNyj1Nsj7Uj0pnSiyIKGtkUZTrJFhIWHHVIoSwCKNwJUdIth0ZttbzUHVKLd phBqYQq87eby91F3p8pjgOJbsA3XqOJEFqOCZYCwNRvDS1L8rgUyjCgBwlHM3jzt026+ y9Z8zCsi0ZelcDhK342VXKcha6Fp6XmPFAkb86I4J9997kmut7rItUgvVh7L7eLcZqEe I0si4FIGrQQcKtMJQciz8GYixdaiKz2T5hhdFzIDhLj8C0IJOsDsUEp+G3CGuJ54FVNr 36PesEZV5KnchoVOYno6LCzKLctE4q/AvI8KdxT9zJKh0ahx8kDlKHw2MOUIopDWHsO4 pOrg==
X-Received: by 10.68.1.226 with SMTP id 2mr4104853pbp.150.1371667457281; Wed, 19 Jun 2013 11:44:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 11:43:37 -0700 (PDT)
In-Reply-To: <0867CEB4-2983-4B48-92A3-2E96CF74D8CD@skype.net>
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> <CAJrXDUHG7ENOu12SkRpXOik3ArEShPHAJhtOwYyR3UaSDvQFOA@mail.gmail.com> <0867CEB4-2983-4B48-92A3-2E96CF74D8CD@skype.net>
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 19 Jun 2013 11:43:37 -0700
Message-ID: <CAJrXDUHr5nTEgcaM4DkzsGCx+9H7nmR2HVGO+V--L+QFzagmUQ@mail.gmail.com>
To: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
Content-Type: multipart/alternative; boundary=bcaec53148178aa7b704df863739
X-Gm-Message-State: ALoCoQnf/i+tg+PLghkqdAZi2Uz3rr8rULx8ikgMNEcj4HzjyDGJ4XvipobHJIszzmTnCaXYyHlT5UbpIEC+Q/bHnkiJrJgM9Ks+rH+n6FFTPHu5oIL3twj4UmId2EpUPhuKl8WghAQ5ACtk4dZjsQ/LOBasoZ09dymliVArxk7PqNXLVAz0Qm6rj/IecZbKRCVlOIg13W41
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 18:44:22 -0000

On Wed, Jun 19, 2013 at 11:04 AM, Matthew Kaufman (SKYPE) <
matthew.kaufman@skype.net> wrote:

>  All of what you say below is true, but this is entirely backwards from
> how web page authors are supposed to interact with the browser.
>
>

>  Imagine if displaying JPEG images in the page were equally possible, if
> you wanted to munge a bunch of strings, but otherwise you were out of luck.
>


Web page authors currently interact with the browser by munging lots of
URLs, HTML, CSS, and JS.  Why not SDP?  It's one more buzz word to add to
your resume.


(I'm trolling)


> Matthew Kaufman
>
> (Sent from my iPhone)
>
> On Jun 19, 2013, at 9:41 AM, "Peter Thatcher" <pthatcher@google.com>
> wrote:
>
>
>
>
> 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>
>
>    _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>