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

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Tue, 02 July 2013 07:21 UTC

Return-Path: <stefan.lk.hakansson@ericsson.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 830AA11E8390 for <rtcweb@ietfa.amsl.com>; Tue, 2 Jul 2013 00:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.595
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01Beu6nEtd3E for <rtcweb@ietfa.amsl.com>; Tue, 2 Jul 2013 00:21:24 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85711E83F5 for <rtcweb@ietf.org>; Tue, 2 Jul 2013 00:21:20 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f586d000001a55-cf-51d27f6e4b01
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 09.9A.06741.E6F72D15; Tue, 2 Jul 2013 09:21:19 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Tue, 2 Jul 2013 09:21:18 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [rtcweb] New Draft - WebRTC JS Object API Model
Thread-Index: AQHOcibV+w71mSCXSkiQxLiPakqfXQ==
Date: Tue, 2 Jul 2013 07:21:17 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3098BA@ESESSMB209.ericsson.se>
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> <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> <CAD5OKxs3Zb2CMHsAGUA2hcdDA7tWxUCmH6RbnRt7MGU+JCknqw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
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: "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: 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
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> 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