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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7321B21F8CC7 for <>; Wed, 12 Oct 2011 05:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bTcXLKNSJesY for <>; Wed, 12 Oct 2011 05:14:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6D36E21F8CC3 for <>; Wed, 12 Oct 2011 05:14:20 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTP id D0C8137A902; Wed, 12 Oct 2011 13:26:23 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-27-811995111
From: Tim Panton <>
In-Reply-To: <>
Date: Wed, 12 Oct 2011 13:13:31 +0100
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Harald Alvestrand <>
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 12:14:21 -0000

On 12 Oct 2011, at 12:39, Harald Alvestrand wrote:

> On 10/12/11 12:31, Tim Panton wrote:
>> On 12 Oct 2011, at 11:00, Harald Alvestrand wrote:
>>> On 10/12/11 11:46, Neil Stratford wrote:
>>>> On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand <> wrote
>>>> One of the worries I have with doing a "low level spec" unconstrained by our present competence (ignorance?) in  is that I'm reasonably sure we have the knowledge to generate and parse SDP, because the codebases we are building on already generate and parse SDP, and the information present there is enough to set up calls, because we're already setting up calls using that information.
>>>> I'm less sure of our "getting things right" if we start off by describing the capabilities and control knobs to be exposed in an unconstrained API.
>>>> As a counter argument, those very same codebases that generate and parse SDP also contain internal APIs that look a lot like a low level spec API, and the information they present is enough to generate and parse SDP and set up calls.
>>>> Maybe we don't like those APIs and perhaps they expose too much as they were never intended to be made public, but they do exist already.
>>> Yup. And I suspect they're all subtly different.
>> You could look at that in a positive light - 
>> as evidence that there are multiple ways to solve this problem and deduce:
>>  a) it isn't impossibly hard
>>  b) there isn't one 'correct' way of doing it.
>> Which would lead me back to specifying as _little_ as possible and letting innovation take place.
> We have to specify enough for interoperation in at least the use cases of the scenarios document.
> In enough detail for interoperation to happen.
> That could turn out to be a lot, especially if we can't point to existing specs and say "use that".

So, to paraphrase (and make sure I understand) - your argument is that if we don't use SDP,
we will have to specify all the fields and associated meanings for every codec we expect to support.

If we do use SDP, then we just point at existing usage and say - 'there, use that' .

If we use a subset or variant on SDP we can say - 'use that, except for this bit to do with port allocation'.

Is that a fair (if informal) summary?


>               Harald