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

Stefan Håkansson LK <> Mon, 01 July 2013 17:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F76621F99D3 for <>; Mon, 1 Jul 2013 10:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.064
X-Spam-Status: No, score=-4.064 tagged_above=-999 required=5 tests=[AWL=-1.765, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7KNHj81BZL9s for <>; Mon, 1 Jul 2013 10:33:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5DBB111E80D7 for <>; Mon, 1 Jul 2013 10:33:37 -0700 (PDT)
X-AuditID: c1b4fb38-b7f456d000002e83-68-51d1bd6de52b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 3E.26.11907.D6DB1D15; Mon, 1 Jul 2013 19:33:33 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Mon, 1 Jul 2013 19:33:33 +0200
From: Stefan Håkansson LK <>
To: Iñaki Baz Castillo <>
Thread-Topic: [rtcweb] New Draft - WebRTC JS Object API Model
Thread-Index: AQHOcibV+w71mSCXSkiQxLiPakqfXQ==
Date: Mon, 01 Jul 2013 17:33:33 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvrW7u3ouBBi1nLCym77OxWPuvnd2i ca6dA7PHuYb37B47Z91l91iy5CdTAHMUl01Kak5mWWqRvl0CV0bn9bSCZ7IVh4/9YW5gbJfo YuTkkBAwkejomMgCYYtJXLi3nq2LkYtDSOAoo8Te3oWMEM5CRoklPzazg1SxCQRKbN23gA3E FhGwlLgx9yYziM0s4CEx7dZSVhBbWMBGou/DZ6YuRg6gGluJbW2sEOV6EnM+rwQbwyKgIrFs 7wd2kBJeAV+Jtgu5EKvusUi8ndANNpIR6KDvp9YwQYwXl7j1ZD4TxKECEkv2nGeGsEUlXj7+ xwphK0rsPNsOdY6exI2pU9ggbG2JZQtfg8V5BQQlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaW VYwcxanFSbnpRgabGIGxcXDLb4sdjJf/2hxilOZgURLn3aJ3JlBIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDY0Fu1jn5jh3X7uQtvnXw9/l7l/8u5+OZvbFwhd/OUhazHULLPqld2bbANHxS gqlq7ZOSqOXCvC/LvjXrqr6wuB5XOk/6RNCm+tuK3NEzPmSJLXtz0ej2wbYMrQUOPW0TpVbw nlEzfnOSR3rhwrOqH0tSdLv1XThfLCms+S16bdP8Qzn29/es81diKc5INNRiLipOBAA+b+Nm WwIAAA==
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 17:33:43 -0000

On 2013-07-01 19:22, Iñaki Baz Castillo wrote:
> 2013/7/1 Ted Hardie <>:
>>> 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?
> 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.
> - 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.

What if first browser generated a JS Object that said (for this example 
we assume one single audio track) it preferred to send audio using 
Opus2.0 but could also do Opus and G.711. If the second browser (which 
has not yet been upgraded) could only decode Opus and G.711, would it 
not have to tell the first browser about this?

Are you perhaps assuming a capability exchange of some sort before any 
media can be set up?

> But honestly, all of this is really well described and exposed in the draft:
>>> 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:
> Best regards.
> --
> Iñaki Baz Castillo
> <>