Re: [rtcweb] No Interim on SDES at this juncture

Tim Panton <> Thu, 13 June 2013 11:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93B7F21F99E9 for <>; Thu, 13 Jun 2013 04:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id svNZ54-PkOiZ for <>; Thu, 13 Jun 2013 04:07:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1219E21F9A5C for <>; Thu, 13 Jun 2013 04:07:40 -0700 (PDT)
Received: (qmail 45320 invoked from network); 13 Jun 2013 11:07:39 -0000
X-AV-Scan: clean
Received: from unknown (HELO ( by with SMTP; 13 Jun 2013 11:07:39 -0000
Received: from (localhost []) by (Postfix) with ESMTP id 8320718A01DC; Thu, 13 Jun 2013 12:07:39 +0100 (BST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 5DD5D18A0169; Thu, 13 Jun 2013 12:07:39 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Tim Panton <>
In-Reply-To: <>
Date: Thu, 13 Jun 2013 12:07:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: "Hutton, Andrew" <>
X-Mailer: Apple Mail (2.1283)
Cc: "" <>
Subject: Re: [rtcweb] No Interim on SDES at this juncture
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: Thu, 13 Jun 2013 11:07:46 -0000

I fear it just _looks_like_ the primary interop issue.

As I recall when we last , the main reason that SDES is required is to facilitate sane multiuser conference video switching without
the hub box having to decrypt-encrypt every channel. (I vaguely remember Hadriel had a centerbox with flames coming out of it in his diagram in Paris)
Unfortunately the plan-a-plan-b-no-plan discussion shows that usecase isn't gonna work trivially even if we do have SDES.

The other reason I can see is that there is an additional round-trip in the call setup, which does add some delay.

I'm not convinced by the 'interop with older devices' argument. Anything that has been upgraded to deal with ICE and the fattened SDP can also have DTLS added at the same time. Anything that isn't upgraded isn't going to work anyway.
Based on my experience adding DTLS isn't a huge amount of work. ICE and SDP changes were much more time consuming.


On 13 Jun 2013, at 11:56, Hutton, Andrew wrote:

> Also agree with Hadriel and Martin here we seem to have been talking about an interim to discuss SDES for a long time and the IETF86 minutes stated that a virtual interim was the way forward. The last time we actually discussed this was at IETF83 about 15 months ago.
> Personally I think we need to find a way to accommodate SDES in RTCWEB even if it requires some user authorization and/or indication in the browser regarding the risks. It is probably the primary interop issue that exists today regarding interop of WebRTC with the rest of the VoIP world.
> Regards
> Andy
>> -----Original Message-----
>> From: [] On
>> Behalf Of Martin Thomson
>> Sent: 12 June 2013 18:08
>> To: Hadriel Kaplan
>> Cc:
>> Subject: Re: [rtcweb] No Interim on SDES at this juncture
>> On 12 June 2013 09:29, Hadriel Kaplan <>
>> wrote:
>>> We've had a lot of discussions on the list about this over the past
>> couple
>>> years.  I thought the general feeling was at this point we needed to
>> discuss
>>> it live - either in person or on a con call - because it was hard to
>> follow
>>> all the arguments in email.  Maybe that was just my feeling, but I
>> could
>>> swear some other people said the same thing at the last IETF 86
>> meeting or
>>> Boston interim.
>> That's consistent with my understanding.  This seems far less
>> contentious than the video MTI discussion, but continuously deferring
>> discussion hasn't helped.
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list