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

Iñaki Baz Castillo <> Mon, 01 July 2013 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E88A011E825F for <>; Mon, 1 Jul 2013 13:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.634
X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GF5D56sCXuQe for <>; Mon, 1 Jul 2013 13:59:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9F21211E827F for <>; Mon, 1 Jul 2013 13:59:39 -0700 (PDT)
Received: by with SMTP id z10so3152733qcx.21 for <>; Mon, 01 Jul 2013 13:59:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=x6DIItagjYFaG3n8Cjs9NWMHv4+f3FeHoA2v3OalNyY=; b=XTkOCWb0Xud1B5gfGi5GkQGUUvRR9CSZUGJG+UrTIQozXV4wK+jkLfj92oDkPAjrt2 fqJtVOk/0j1atI4z1pB4jMsPcOUZ+JuMIJrY+nI7CGKtIMHGEpilKqNEmu+zDIfAAuJQ ZtpZYTNCzmzmdFpkgQmRkTGGRiWmQ/xhru/fL4uaRsjxyBXbxWcqBsxNNinW09EAOiGk URq4JOvDHCvJm+2Qwpdlr/TCdjlP2G/chAJPWPtZvBou4lvewmGImqJbAk9653YIYgmJ e15Vu5oH/BYdGWNO6Qz7jz6tnY9+Sb+y+dvg1YwkAcCFCjp8xHFUtOlgvon5BAKALZV/ J2CA==
X-Received: by with SMTP id bj9mr34731839qab.14.1372712378878; Mon, 01 Jul 2013 13:59:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 1 Jul 2013 13:59:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Iñaki Baz Castillo <>
Date: Mon, 01 Jul 2013 22:59:18 +0200
Message-ID: <>
To: Ted Hardie <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmkTp06rNJf5EpIMj7UFKN/3VgiZzBUFQj1L5KdepjeRsN+8b6+GQUMhy3O5BPGwcDA6eQ2
Cc: "" <>
Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Jul 2013 20:59:44 -0000

2013/7/1 Ted Hardie <>:
> On Mon, Jul 1, 2013 at 10:22 AM, Iñaki Baz Castillo <> 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.

Sure Ted, and thanks a lot for reading the draft.

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

I don't want to design an API in a few lines because I may be 100%
wrong, but (very) basically:

The JS app:
- Calls getUserMedia().
- Creates a PC instance.
- Provides the PC with the MediaTracks obtained from getUserMedia().
- Calls to some API method*s* in PC to retrieve ICE transport
information (which is obtained as JS Object, with attributes
representing the corresponding fields of a ICE "line").
- Calls to some other API method*s* in PC to get the list of supported
codecs and tells the PC, via another PC API method, the preference
- Calls to some other API method*s* in PC to get local MediaStream
and/or MediaTracks instances (i.e. to render local video).
- Calls to some other API method*s* in PC to get crypto/DTLS
information (an Object with the appropriate attributes fully defining
such an information).
- ...and so on.

And the the JS app serializes all the retrieved information and
encodes/serializes/whatever it into a JSON body, XML, etc etc, and
sends it in-the-wire (or splittes it into various chunks of
information to be send separately).

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

I don't understand the question. In the current SDP-based model you
get all the media/transport information when you get the SDP
(SessionDescription instance) from the PC, right? and then you send it
in-the-wire and ICE stuff starts.

Some here, but instead of passing a horrile opaque blob, let's use JS Objects.

NOTE: This is just one of the various changes/improvements the draft
describes. It is not all about the interface between the JS layer and
the WebRTC stack in the browser.

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

In fact the proposed API between the JS and the browser is what
encourages that the JS app can send whatever it wants in-the-wire.

Anyhow I don't fully understand what you mean with "the API which uses
SDP in the current design". Do you mean setLocalDescription (which is
provided with an opaque blob) and getLocalDescription (which provides
an opaque blob)?

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

Of course we need a standard interface (this is: API) between the JS
and browser. That's why we are proposing a "JS Object API rationale".
But we need a *real* JS API (which means functions that returns JS
Objects and are provided with JS Objects) rather than the current API
that just works by passing an opaque/unmanageable blob between JS and
browser (in both directions).

Best regards.

Iñaki Baz Castillo