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

Tim Panton <> Wed, 12 October 2011 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB0D221F8BC4 for <>; Wed, 12 Oct 2011 07:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DWZfi1m8ugNK for <>; Wed, 12 Oct 2011 07:58:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 06EE921F8B87 for <>; Wed, 12 Oct 2011 07:58:17 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTP id 3E15D37A902; Wed, 12 Oct 2011 16:11:04 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Tim Panton <>
In-Reply-To: <>
Date: Wed, 12 Oct 2011 15:58:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <4E959D48.3090401@mozill>
To: Timothy B. Terriberry <>
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, 12 Oct 2011 14:58:18 -0000

On 12 Oct 2011, at 14:59, Timothy B. Terriberry wrote:

>> Lets assume we use a subset/variant of SDP as a codec capability
>> description 'language' - (i.e. we won't be using the parts that relate
>> to network properties).
> I've seen this proposed a couple of times now, and I would like to point out that this is a terrible assumption. There are many things that one might want to control about a codec that will never show up in SDP, because they don't require explicit negotiation between sender and receiver (e.g., the sender gets to make a unilateral decision and the receiver simply deals with it... like, say, the amount of time a video encoder is willing to spend doing a motion search, etc.).
> Limiting yourself to the parameters that do happen to show up in SDP is a pretty poor half-solution, if you really do think you need a low-level API of this kind, and may not have obvious extension points to get to a full solution.

Which leaves us with the choice of:
	a) having 2 different APIs - one for SDP params and one for everything else
	b) extending SDP to include things that will only be used locally 
	c) describing a mapping from SDP to javascript objects for a 'full' codec description object
	d) ?

Tim (P).