Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list

Saul Ibarra Corretge <> Sat, 08 October 2011 09:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27B2B21F8B27 for <>; Sat, 8 Oct 2011 02:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1puwSyOXx3IX for <>; Sat, 8 Oct 2011 02:15:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5B84821F8B2D for <>; Sat, 8 Oct 2011 02:15:29 -0700 (PDT)
Received: by (Postfix, from userid 5001) id DF4EEB01B8; Sat, 8 Oct 2011 11:18:44 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 9EEECB019E; Sat, 8 Oct 2011 11:18:43 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Saul Ibarra Corretge <>
In-Reply-To: <>
Date: Sat, 08 Oct 2011 11:18:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Colin Perkins <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list
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: Sat, 08 Oct 2011 09:15:30 -0000

On Oct 7, 2011, at 12:11 AM, Colin Perkins wrote:

> On 5 Oct 2011, at 18:20, Roman Shpount wrote:
>> On Wed, Oct 5, 2011 at 7:00 AM, Neil Stratford <> wrote:
>> I'm not sure I understand why this is such a problem. XMPP/Jingle defines it's own mapping, which is a common VoIP protocol that is widely supported. I'd much rather that the JS API is as expressive as possible in codec specific matters - for example even to the point of providing callbacks to the JS on certain codec level events, such as decoding a DTMF digit.
>> What we need is some way to expose all possible codec parameter combinations to JavaScript API. MMUSIC/PAYLOAD specifications for codec typically define CODEC parameters and how they are encoded in SDP/MIME content type, but they fall short of defining a way to list all the capabilities.
> I'm not convinced that exposing all possible codec parameter combinations is an appropriate goal. There is simply too much flexibility present with many of the codecs, especially in combination, for the signalling to be reasonable if all the flexibility is exposed. Better, I think, for the browser to expose a set of known-reasonable combinations, and parameter ranges, from which the most appropriate choice is picked.

Maybe capabilities could be expressed in terms of "codecs" and "profiles". A profile is a set of properties attached to a codec under a given name, lets say codec H264 with "HD" profile or "SD" profile. Having the ability to make a custom profile would be nice, for those who need/want to have a more fine grained control over it.

Saúl Ibarra Corretgé
AG Projects