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

Ted Hardie <ted.ietf@gmail.com> Mon, 01 July 2013 17:14 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 27D0421F99A6 for <rtcweb@ietfa.amsl.com>; Mon, 1 Jul 2013 10:14:00 -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 L3cf8refDA7c for <rtcweb@ietfa.amsl.com>; Mon, 1 Jul 2013 10:13:59 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8363A21F9F38 for <rtcweb@ietf.org>; Mon, 1 Jul 2013 10:13:53 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id hq4so3310269wib.12 for <rtcweb@ietf.org>; Mon, 01 Jul 2013 10:13:52 -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=nBAuyGG8ogv4rATreRqp10nYfQSJpMGEw35EoCcxg/M=; b=HJ0NLGQpEOFt8Hw2Wm1u4HkApkmVhwkVK4YWtlqd/wyaASM4cj8T7N69ov7bnxAsQT /S2r0N/DeDdL28V0Ego0JTdInUbZcNBbnKYNTMipAprcvta9c8bhWGq9DdUr6A66SUA4 GAflnWQCNA1rbgeIKl226hECtSjSHi2bJylhJm/QXHvGqL0+IPz6E74z8KzvcP8SS5oT LAkEwrmFTD7yF7SYGRPyzEb6k2Q8mw7xwIDXgIcA3ZevTw0rMkJOHZn1aWoid9pN6Nv5 nIZaYhX16mwLo6ZIuq+xajmflm+Z1tCx6/D3NDmuNWtWRIfCl3IfVtispDkpvU2JFwJA zl5Q==
MIME-Version: 1.0
X-Received: by 10.180.108.129 with SMTP id hk1mr12723635wib.56.1372698832232; Mon, 01 Jul 2013 10:13:52 -0700 (PDT)
Received: by 10.227.164.137 with HTTP; Mon, 1 Jul 2013 10:13:52 -0700 (PDT)
In-Reply-To: <CALiegfnpj+nBdhn0g8A7iTdXKZdqvwyffjdLAOuM_qQkhTuKew@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>
Date: Mon, 1 Jul 2013 10:13:52 -0700
Message-ID: <CA+9kkMA1PhoJB9qGUnXDUHRJNac5OszM4o5O7-6aCU-ahszMNw@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=e89a8f3bb04f47672d04e0765aa8
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 17:14:00 -0000

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

> 2013/7/1 Ted Hardie <ted.ietf@gmail.com>om>:
> > On Mon, Jul 1, 2013 at 7:28 AM, Iñaki Baz Castillo <ibc@aliax.net>
> wrote:
> >>
> >> Stefan, the media/transport info will be sent from browser A to
> >> browser B using the custom format the developer of the website chose,
> >> period. I don't understand why you think that the format of the
> >> media/transport info must be constant/fixed for any website using
> >> WebRTC.
> >
> >
> > Because ultimately the media is sent via transports set up by the
> browser.
> > If the browser must understand every custom format, the system cannot
> scale.
>
>
> Ted, the media can be *perfectly* sent in-the-wire with any custom
> format the web developer builts (JSON, XML, plain SDP or whatever).
>

I'm sorry, I think I must misunderstand you.  You are planning to take
media from a source  and encode it using json, xml, or SDP and send that
over the wire?  Or you mean the media *signalling* can use json, xml, or
SDP and go over the wire?


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

regards,

Ted Hardie


If it is possible, please take a look to
>
> http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00
> .
>
> Best regards.
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>