W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2012

Re: Poll for preferred API alternative

From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 4 Sep 2012 08:24:07 -0700
Message-ID: <CABcZeBNgH8E4PXs+5n-jm+q-KOtkCmYnHc0WmOgK+eGHsvDLkw@mail.gmail.com>
To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Aug 29, 2012 at 5:30 AM, Stefan Hakansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> The discussions of Aug 28 showed that there are people with differing
> opinions on the structure of the API this WG should design.
> Most of the work in front of this group currently is dependent on a basic
> decision between those two approaches - the issues to be resolved (for
> example congestion control and RTP stream mapping) are in many cases present
> in both proposals, but the API specifications that need to be developed look
> a lot different.
> It is not efficient use of the groupís time to work out detailed,
> implementable proposals that then are thrown away because of a later
> decision - nor is it a working environment conducive to inspiring
> volunteers.
> The two alternatives, as the chairs see them, are the following:
> 1) Continue with a design based on the PeerConnection object, using SDP as
> part of the API, roughly in the style of the current API description.

My preference is for option 1.

The decision between a low-level API (e.g., CU-RTC-Web) and mid-level
API (e.g., the current API) is to a great extent a matter of moving
complexity between the browser implementor and the site implementor.
In general, given the small number of browsers and the large number of
sites, this should be pushing us in the direction of having the
complexity in the browsers. We have already seen that it is possible
for relatively naive site implementors to build stuff on the current
API without having to learn much about VoIP. This would clearly not be
the case with a low-level API absent the existence of some
high-quality library, which then itself creates another problematic

It is of course possible that these considerations would be outweighed
if there were a large class of use cases that were possible with a
low-level API but not the existing API. However, MS hasn't really
presented any such use cases. Given that, and given that it will
certainly cause very significant delay (at least a year and probably
more) in terms of having a completed standard, I don't think it's a
good idea to start over with a low-level API.

Received on Tuesday, 4 September 2012 15:25:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:30 UTC