Re: [rtcweb] About defining a signaling protocol for WebRTC (or not)

Harald Alvestrand <> Sun, 18 September 2011 08:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 153D621F8512 for <>; Sun, 18 Sep 2011 01:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -107.799
X-Spam-Status: No, score=-107.799 tagged_above=-999 required=5 tests=[AWL=2.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q0onPF4l3-1c for <>; Sun, 18 Sep 2011 01:07:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6F73321F84D8 for <>; Sun, 18 Sep 2011 01:07:04 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 107B339E0CD; Sun, 18 Sep 2011 10:09:22 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tYuuowgGQ-OO; Sun, 18 Sep 2011 10:09:21 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPS id 959C939E048; Sun, 18 Sep 2011 10:09:21 +0200 (CEST)
Message-ID: <>
Date: Sun, 18 Sep 2011 10:09:20 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: Matthew Kaufman <>
References: <> <> <> <> <> <20110915140248.4cc17977@lminiero-acer> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not)
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: Sun, 18 Sep 2011 08:07:05 -0000

On 09/16/2011 11:12 PM, Matthew Kaufman wrote:
> On 9/15/11 3:09 PM, Harald Alvestrand wrote:
>> The disadvantage of parsing to another structure (I am fond of JSON 
>> myself) is that one has to maintain a data definition for the format 
>> being parsed to, a defined transform between that and the "canonical 
>> SDP structure" has to be implemented in user space when one does SDP 
>> interoperability, both of those have to be updated for every SDP 
>> extension that someone defines somewhere, and one is still not free 
>> to define extensions on the non-SDP side if one still requires the 
>> ability to map them into SDP.
>> If one uses the "native" SDP format, which is the format in which 
>> every extension to the format gets documented, the browsers are the 
>> ones who *have* to parse it (although others are likely to).
> Of course what you're also saying here is that it takes a trip to the 
> IETF to make every extension. So if the *only* Javascript API for 
> controlling the codec (or getting its capabilities by triggering an 
> offer) is a pile of SDP in string form, then nothing that hasn't been 
> standardized can be described.
1) No reason that this should be the only interface. I've just argued 
that I think this interface needs to be supported
2) SDP has a relatively clean "ignore what you don't understand" 
extension model. It's not my impression that people who want to deploy 
stuff wait until the standards are done.
> For example: forcing the Opus codec to "music" mode no matter what the 
> input.
I haven't seen the definitions for signalling Opus in SDP, so don't know 
if such a capability is described there (which may or may not illustrate 
your point).
> Matthew Kaufman