Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)

Hadriel Kaplan <> Fri, 11 November 2011 13:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F117F21F86A0 for <>; Fri, 11 Nov 2011 05:38:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.464
X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ukB1KyNqynCw for <>; Fri, 11 Nov 2011 05:38:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4B19921F863E for <>; Fri, 11 Nov 2011 05:38:07 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 11 Nov 2011 08:38:05 -0500
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Fri, 11 Nov 2011 08:38:05 -0500
From: Hadriel Kaplan <>
To: Roman Shpount <>
Thread-Topic: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)
Thread-Index: AQHMoHck3wWZ3aEzb0OPm0277r540g==
Date: Fri, 11 Nov 2011 13:38:05 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<>" <>
Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)
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: Fri, 11 Nov 2011 13:38:09 -0000

On Nov 11, 2011, at 7:02 AM, Roman Shpount wrote:

> Well, this is a perfect example when specifying mandatory security for wrong reasons is simply being ignored. All the reactions I've seen to this so far were "this is only a SHOULD, let's disregard this for now". Getting security requirements in the standard which are too high too be practical usually produces products which disregard security completely, reaching the exactly opposite effect. I think, in this particular case, the right course of action is to use AVT tones in RTP as the rest of the industry is doing now.

I think using in-band tones in RTP for DTMF instead of 4733 would be a really bad idea.  

It's not the case that "the rest of the industry" does this.  It's true that many media-servers/PSTN-gateways *also* support in-band tones, but I don't think I've ever seen one that didn't support either RFC 2833/4733 or some SIP-based message indication method, or both.  Have you seen such?  What kind of devices were they?

The only devices I've seen which support *only* in-band tones have been some MTA endpoints and some old gateways for the inbound-direction for media coming from PSTN into SIP.  Both of those aren't a use-case for WebRTC.  WebRTC browsers need to be able to send DTMF out, but they don't need to receive DTMF; and they only need to send it out to media servers/gateways, not to far-end MTA endpoints.

Conversely, I have seen gateways which do NOT support in-band tones, and only support 2833/4733 or SIP-based message indications or both.

> Finally, (going slightly off topic here) it would probably be a good idea to make key exchange part of the initial ICE transaction. This way we can use this key exchange as an additional verification of the remote party, and reduce the number of round trips required before the media flow is established.

That's an interesting idea.  The extra round trips of DTLS-SRTP, added to those of ICE, have had me worried about clipping when the user answers the call.  It's been an advantage of SDES not to worry about that.