Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

Tim Panton <> Wed, 05 October 2011 13:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71C9521F8A7A for <>; Wed, 5 Oct 2011 06:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XICACQV515+O for <>; Wed, 5 Oct 2011 06:22:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EAF3421F8A6C for <>; Wed, 5 Oct 2011 06:22:20 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTP id 78B7437A903; Wed, 5 Oct 2011 14:38:11 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Tim Panton <>
In-Reply-To: <>
Date: Wed, 5 Oct 2011 14:25:17 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)
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: Wed, 05 Oct 2011 13:22:21 -0000

On 5 Oct 2011, at 13:51, Stefan Håkansson LK wrote:

> On 2011-10-05 12:03, Tim Panton wrote:
>> It seems to me that by calling WebRTC.SDP.answerFor() - getting the
>> native code
>> to do the 'compatibility matching' you've lost quite a lot of influence
>> over the selection process.
>> Lets say this is a conference app on an android phone - and lets say
>> that the phone supports
>> h 261, h263 and h264 but only has hardware accel for h264....
> To me it seems that the browser (at least the one integrated by the device manufacturer) has a much greater chance of knowing what codecs are HW accelerated than the application - or do you expect a large database where device, version, OS-version, browser, browser version etc. is stored?

I'd expect the app to be able to query the browser - possibly a 'cpu cost' field returned in the list of supported codecs ...

> My preference would rather be that the app hints (as Tim proposed in <>), the browser proposes (by some kind of offer where the codecs are listed in preference order). If the offers are available to the application (for transport to the other end) it can override it there are objections.

Which to my mind is putting the cart before the horse. The app (as the representative of the user) should take the lead here, not be reduced to
vetoing offers from the all-knowing browser. I know it is largely a philosophical difference, but I think we risk being stuck in a mindset derived from
a world where the core had no access to the user and there was only a single application, so the switch had to do the best it could without any
other input.