Re: [rtcweb] Use of offer / answer semantics

Cullen Jennings <> Wed, 07 September 2011 00:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E6C621F8D6F for <>; Tue, 6 Sep 2011 17:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.288
X-Spam-Status: No, score=-103.288 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j1GyiVYxHwmb for <>; Tue, 6 Sep 2011 17:48:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5D8BA21F8D66 for <>; Tue, 6 Sep 2011 17:48:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1433; q=dns/txt; s=iport; t=1315356644; x=1316566244; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nPReBDpFHe1kzxa34tUPLJjkxQwO62jrKSb84K202PI=; b=MGzkQjoox5vLc97kZU0QaI5wmVUan9YwXCR9NqjeIGLKayz+mUzolblh pnsKUGPYqBQgXbIhcjyk8/CQIVKSihQedx8nZ7vrhL/I7GKXmghU2I2sa wQwQq0e+apeuUD/CGWdr62KG+j7LO04MMO+T9LJW/rrtBjw59lp/K7yfP c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EACC/Zk6rRDoI/2dsb2JhbABDqAp4gUYBAQEBAgESASc/EAsOOFcGNYdRmSYBn1WGCmAEh2uLQ4UPjB0
X-IronPort-AV: E=Sophos;i="4.68,342,1312156800"; d="scan'208";a="554375"
Received: from ([]) by with ESMTP; 07 Sep 2011 00:50:44 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p870ogH9020716; Wed, 7 Sep 2011 00:50:43 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <>
In-Reply-To: <>
Date: Tue, 06 Sep 2011 18:50:42 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Colin Perkins <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [rtcweb] Use of offer / answer semantics
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, 07 Sep 2011 00:49:00 -0000

On Sep 6, 2011, at 9:12 AM, Colin Perkins wrote:

>> 3) When a new codec is specified, and the SPD for the new codec is specified in the MMUSIC WG, no other standardization would should be required for it to be possible to use that in the web browsers. Adding a new codecs which might have new SDP parameters should not change the APIs between the browser and javascript application. As soon as the browsers support the new codec, old applications written before the codecs was specified should automatically be able to use the new codec where appropriate with no changes to the JS applications. 
> To be clear on this last point: when RTP payload formats are defined for new codecs, they define a MIME media type and its parameters, and then a mapping of those onto SDP syntax in a standard way. If it was desirable, we could define a mapping from MIME media type names and parameters onto some non-SDP syntax without losing the investment in RTP payload formats and parameters for signalling. 
> And, given that other parts of the browser rely on media types, we should be clear that codec names/parameters are drawn from the same namespace.
> Colin

Just sloppy on my part - what I was trying to get at was that whatever happens, it is basically algorithmic to map it into the API specs we and we don't have to write any new specs for the JS API.