Re: [rtcweb] New Draft - WebRTC JS Object API Model

Ted Hardie <ted.ietf@gmail.com> Mon, 01 July 2013 18:17 UTC

Return-Path: <ted.ietf@gmail.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 8094111E81A1 for <rtcweb@ietfa.amsl.com>; Mon, 1 Jul 2013 11:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 LngWlLYfVGtb for <rtcweb@ietfa.amsl.com>; Mon, 1 Jul 2013 11:17:50 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4A32111E81EB for <rtcweb@ietf.org>; Mon, 1 Jul 2013 11:17:50 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id ey16so3378674wid.4 for <rtcweb@ietf.org>; Mon, 01 Jul 2013 11:17:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pD4rfFReN48WEajFo4Q8kXvS36hEhjcff3HmexGMOXA=; b=wQz2dFdZ3QlGDshUDO8lUUyQrF21VxODuVw04gmY7DmqmFIzr42bi3d8SKjnBvvLp0 jpdL1weYT2iKJA2LnCBGcPoAL2H4W8ylkOAP2ujAO8riTmzPcNPpFia+7iO5ZEodh1fC coBuwiq981DYTOfcFPDCmmeG4S7ZSknUC9pMnHcRxI6kigIM/NCZQLKaNC4qQ/PNsYyE i3HEvFz8ISZS8grgtfTWtcAkf9TWw1j2ZJwOUpBKm17wjKnNS+QYcLGmV3SNvck/G7I7 trcsbvikNc/rsscTW7nBSo9UFTadJIq9p5IUtNdmsU9xUZYyG9ASQoGhlZsqnzWyGVKC r1PQ==
MIME-Version: 1.0
X-Received: by 10.180.108.129 with SMTP id hk1mr12895337wib.56.1372702669387; Mon, 01 Jul 2013 11:17:49 -0700 (PDT)
Received: by 10.227.164.137 with HTTP; Mon, 1 Jul 2013 11:17:49 -0700 (PDT)
In-Reply-To: <CALiegfkei-dS-EHt2vqofft_uhKNz+UuK7R5LX3bgDkh=0ZwqQ@mail.gmail.com>
References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <CALiegfmsahUM6w00thQSCu3CpKse2C3LKSb1LzkwodNgKTOK0g@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> <CALiegfnAN9SJx0nLyegFJoQscG-18Gs4umd-pe7S3y6xREpByQ@mail.gmail.com> <CA+9kkMC5FoxKSz7DuHxN8cEO=0PDpoAGrLshpFmnDe3gco06cw@mail.gmail.com> <CALiegfnpj+nBdhn0g8A7iTdXKZdqvwyffjdLAOuM_qQkhTuKew@mail.gmail.com> <CA+9kkMA1PhoJB9qGUnXDUHRJNac5OszM4o5O7-6aCU-ahszMNw@mail.gmail.com> <CALiegfkei-dS-EHt2vqofft_uhKNz+UuK7R5LX3bgDkh=0ZwqQ@mail.gmail.com>
Date: Mon, 1 Jul 2013 11:17:49 -0700
Message-ID: <CA+9kkMCDXpZ99Gu85eRcyCbwW1M-4uacKPvU8R1zFbKiCfde2g@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=e89a8f3bb04ffdbdaf04e0773ee9
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model
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: Mon, 01 Jul 2013 18:17:51 -0000

On Mon, Jul 1, 2013 at 10:22 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

Preface:  I have read the document you refer to, and I find it personally a
lot less clear than you do.  While I would welcome specific pointers when I
ask questions, more elucidation is needed for me.  Thanks for understanding.

More questions in-line.


> Of course, I mean "the media signaling". But that is not just about
> "in-the-wire". Current WebRTC specs mandate that the information unit
> exchanged between the JS app and the WebRTC stack must be a SDP blob.
>
> What I mean is:
>
> - The JS app uses the WebRTC API to retrieve a JS Object (or Objects)
> with transport and media info.
>
>
Retrieve from where?  Does the browser generate these at the direction of
the JS application,
or do you believe it generates them when media sources are connected.  How
are data sources
created?


> - The JS app serializes such a information in any custom way defined
> by the website developer (this can be a JSON body, XML, SDP! or
> whatever).
>
> - The JS app sends the information to the remote peer.
>
> - The JS app of the remote peer decodes the information (since it is a
> JS app designed by the same domain/website) and extracts all the
> transport/media fields.
>
> - The JS app of the remote peer creates a local PC and makes calls to
> API methods of PC for passing those transport/media fields.
>
> - ...and remove O/A mandate.
>
> But honestly, all of this is really well described and exposed in the
> draft:
>
>
> http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00
>
>
>
>
None of the above appears to touch on the API which uses SDP in the current
design; that's between the JS and the browser.

>
>
> >> The receiver JS app parses the information (i.e. converts from JSON to
> >> an Object), extracts the media/transport fields and pass them to the
> >> PeerConnection via API methods.
> >>
> >>
> >> It is really so hard? this is how WWW works (in contrast to how SIP
> >> works).
> >>
> >
> > As has been repeatedly mentioned, you have a peer communication here that
> > has to be implemented by the browser.  That means the downloaded
> javascript
> > application must tell a browser what transports it needs so that it can
> > create the appropriate connections.  If it is using RTP/UDP, it ends up
> > needing to tell the browser what enough detail to construct the RTP/UPD
> > streams.  What payload format, for example, is needed.  As I said before,
> > that means that having no standard format across the API between the JS
> > application and the browser has very poor scaling characteristics.  You
> > might replace SDP as the interface between them, but not specifying
> anything
> > there doesn't seem to work, at least in my personal opinion.
>
> I invite you to read the draft which describes how your concerns can
> be perfectly accomplished without mandating SDP or any other format:
>
>
> http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00
>
>
Honestly, I have read it and I don't see how you avoid mandating some
standard
interface between the JS and browser.  That needn't be SDP, but if it is
causing the
two sides to negotiate candidate transports and emit RTP, it's going to be
hard going
to avoid it being SDPNG.

Ted


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