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

Stefan Håkansson LK <> Tue, 02 July 2013 07:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 830AA11E8390 for <>; Tue, 2 Jul 2013 00:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.595
X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 01Beu6nEtd3E for <>; Tue, 2 Jul 2013 00:21:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5A85711E83F5 for <>; Tue, 2 Jul 2013 00:21:20 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f586d000001a55-cf-51d27f6e4b01
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 09.9A.06741.E6F72D15; Tue, 2 Jul 2013 09:21:19 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Tue, 2 Jul 2013 09:21:18 +0200
From: Stefan Håkansson LK <>
To: Roman Shpount <>
Thread-Topic: [rtcweb] New Draft - WebRTC JS Object API Model
Thread-Index: AQHOcibV+w71mSCXSkiQxLiPakqfXQ==
Date: Tue, 02 Jul 2013 07:21:17 +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+NgFjrKLMWRmVeSWpSXmKPExsUyM+JvrW5+/aVAg2VdzBbT99lYzLgwldli 7b92dgdmj3MN79k9liz5yeRxa0pBAHMUl01Kak5mWWqRvl0CV8bia5UFb0Qqjt2YwNzA+EWg i5GTQ0LARGLuhe2MELaYxIV769m6GLk4hAQOM0p0/v7MCpIQEljIKDH1uyWIzSYQKLF13wI2 EFtEQFXi7/fJTCA2s0CCxPsZl5lBbGEBG4m+D5+B4hxANbYS29pYIcr1JOZ8XskOYrMIqEgc Pd7EDlLCK+ArMWlzJsSml6wSJ7oMQGxGoHO+n1oDNV1c4taT+UwQZwpILNlznhnCFpV4+fgf K4StJPFjwyUWiHo9iRtTp7BB2NoSyxa+BqvnFRCUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZ VjGy5yZm5qSXG25iBEbFwS2/dXcwnjoncohRmoNFSZx3k96ZQCGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2MkqpOu4IDJGLzQ660JzFovtOZpNZhm/lRhttkiUSGcMKrBzYZhyd8uHfE371P /fL6qybcxyRnJ6b+Mr7Ztyr4/dy0FoNL27bf8MpO3ssy93RLkmnYgdyCMouTfAzx8YxrHi6/ qCikfY7nTayt2pL+53xBH7pW7i+QP+sU2v86WP34s1TBZapKLMUZiYZazEXFiQAOdBPmWAIA AA==
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: Tue, 02 Jul 2013 07:21:35 -0000

On 2013-07-01 20:24, Roman Shpount wrote:
> On Mon, Jul 1, 2013 at 1:33 PM, Stefan Håkansson LK
> <
> <>> wrote:
>     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?
> Any API that we propose would include methods to expose browser
> capabilities (ie list of available codecs, with default payload type,
> payload name, clock rate, number of channels, and preferred codec
> parameters). Generation of SDP c line, rtpmap, and fmtp lines from this
> would be trivial, as well as generation of other media descriptions for
> XMPP or other negotiation protocols.
> In other words, we are not removing the need for negotiation. All we
> want is to unbundle it from single offer/answer exchange with single
> string blob into separate methods where transport negotiation (ie DTLS,
> SRTP, and ICE candidates), mapping transport to streams (ie any sort of
> bundle related mapping remote address, SSRC, payload or others), and
> media encoding/decoding (ie send and receive codecs, codec parameters,
> payload times, etc) are all negotiated separately and independently.

Roman, thanks for clarifying. Personally (wearing no hat) I think 
splitting things up makes a lot of sense. In fact, our first prototype 
browser (back in early 2011) was sort of implemented this way: each 
MediaStream was described and negotiated separately. We used SDPs for 
the purpose though (each addStream lead to a separate SDP O/A setting up 
that unidirectional MediaStream with its tracks).

But I think we should not underestimate the work needed to describe all 
the nitty gritty details using another "language" than SDP.

> This is what is happening with the API anyway with trickle ICE and
> no-plan proposal adding ability to update transport and media parameters
> once the initial connection is established. All we want is to extend the
> same logic to the initial connection establishment,
> _____________
> Roman Shpount