Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

"Matthew Kaufman (SKYPE)" <> Tue, 18 June 2013 20:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20EDA11E8100 for <>; Tue, 18 Jun 2013 13:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.328
X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y42lqbmEA9oO for <>; Tue, 18 Jun 2013 13:56:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8EF6B21E8054 for <>; Tue, 18 Jun 2013 13:56:29 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 18 Jun 2013 20:56:26 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 18 Jun 2013 20:56:26 +0000
Received: from ([]) by ([]) with mapi id 14.03.0136.001; Tue, 18 Jun 2013 20:56:09 +0000
From: "Matthew Kaufman (SKYPE)" <>
To: Ted Hardie <>, Iñaki Baz Castillo <>
Thread-Topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
Thread-Index: AQHObEI8XC7enqULikaWynaBYkCsupk76I4AgAAJ1AA=
Date: Tue, 18 Jun 2013 20:56:08 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C7D79TK5EX14MBXC273r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(377454002)(31966008)(54356001)(74366001)(76786001)(77096001)(561944002)(69226001)(81342001)(66066001)(81542001)(74706001)(63696002)(49866001)(74502001)(65816001)(46102001)(47446002)(512934002)(56776001)(51856001)(74662001)(74876001)(55846006)(79102001)(50986001)(77982001)(76796001)(76482001)(33656001)(47976001)(56816003)(16406001)(6806003)(54316002)(20776003)(80022001)(59766001)(71186001)(53806001)(47736001)(4396001)(16236675002); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB005;; CLIP:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0881A7A935
Cc: "" <>
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
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: Tue, 18 Jun 2013 20:56:36 -0000

The good news is that I co-authored and Microsoft published a nice starting point for discussing a specification that doesn't have SDP O/A.

The bad news is that it was voted down for future consideration at W3C.

The good news is that W3C has apparently abdicated the entire responsibility for producing a browser API to IETF, where it has not yet been voted down.

More good news is that if and when the W3C considers the current specification that the IETF produces, if it is not complete enough to independently replicate without looking at other browser's source code (in other words, if the SDP that is produced is not fully specified in an interoperable way in either the W3C specification itself or, worst case, in the entire stack of normative references), I will also have the pleasure of co-authoring a formal objection to publishing that specification.

One might consider that since the current SDP-based path we are on does not have anywhere near a complete set of implementable normative references, and that producing such might actually be harder than using something that doesn't rely on SDP as the API surface, you might be a lot farther from something that finishes the entire W3C process than you think.

Matthew Kaufman

From: [] on behalf of Ted Hardie []
Sent: Tuesday, June 18, 2013 1:15 PM
To: Iñaki Baz Castillo
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

I've read the messages on this thread up to lunchtime in California on June 18th.  I have not consulted with the other chairs, because we are still somewhat out of synch, so this is my personal response, rather than a chair response.

SDP occurs as an API control surface in this protocol, and it may also be used in O/A semantics between endpoints.  The request does not clearly state which aspect is asking for reconsideration.  Since one is handled in a different group, that is critical.  Secondly, the requirement the group has is that the solution *provides support sufficient to allow O/A semantics*, not that these must be used between two parties using the same signalling.   Being clear on what you would like to see by writing a draft proposal, rather than simply asking to re-open concluded discussions would be helpful.

Speaking very personally, I would like to see the group close having completed its milestones.  While I am very aware that re-using a syntax like SDP makes for some unpleasant moments, I'm not sure that any system that actual has any level of interoperability with existing SIP deployments as a goal will avoid that unpleasantness--at best, you have a mechanism on one end that looks different *but must be mapped to SDP* in the interoperability case.   Creating something new that accomplishes that and is substantially better than SDP seems like a long task to me.

Again, not as a chair decision or statement, but to give some response to the points made.


Ted Hardie