Re: [rtcweb] SDP offer/answer vs. JSON

Magnus Westerlund <> Mon, 19 September 2011 15:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 356CF21F8C71 for <>; Mon, 19 Sep 2011 08:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.511
X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id euK0EiZndcaF for <>; Mon, 19 Sep 2011 08:44:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 099D621F8C6A for <>; Mon, 19 Sep 2011 08:44:32 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-20-4e7763ef493a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DD.95.02839.FE3677E4; Mon, 19 Sep 2011 17:46:55 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 19 Sep 2011 17:46:55 +0200
Message-ID: <>
Date: Mon, 19 Sep 2011 17:46:54 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Hadriel Kaplan <>
References: <> <> <> <> <> <20110915140248.4cc17977@lminiero-acer> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "<>" <>
Subject: Re: [rtcweb] SDP offer/answer vs. JSON
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: Mon, 19 Sep 2011 15:44:34 -0000


As we all low to discuss and nitpick each other arguments I do have a
comment on some of your points.

On 2011-09-16 20:29, Hadriel Kaplan wrote:

> But email's free... so for the sake of posterity (and email
> archiving) here're some reasons not to use SDP anyway:
> 1) Incorporating SDP and the offer/answer model into the Browser and
> W3C API inexorably ties the W3C to the IETF MMUSIC working group for
> all time. So far, I had been going on the assumption the IETF would
> be defining what the RTP library had to do/expose, while W3C would 
> define the API. But if the API includes SDP offer/answer, that 
> portion is the IETF's domain too, afaik. Anything the W3C wants to do
> in the future for that has to go through the IETF, not just IANA. 
> (right?)

Depends on what parts of SDP you want to extend. And in fact most things
can be done with not having to write an RFC.

SDP attributes (a=) has the registration policy of Specification
Required which means W3C can do what they want themselves an then ask
IANA for registration.

The Proto needs an RFC, but it can be RFC-editor or Informational.
However, as new proto is a new transport, I do expect some IETF
involvement anyway to make sure it works with the existing ones.

I guess these are the two most important. And I am not going to discuss
all of them, especially as some extensions may more properly belong in
other parts of IETF than MMUSIC. For the ones interested in IANA rules
for SDP, go look at section 8 in RFC4566.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: