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

Hadriel Kaplan <> Sun, 13 November 2011 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1751F21F8BA4 for <>; Sun, 13 Nov 2011 06:01:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.319
X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jM1AGxX7CiB8 for <>; Sun, 13 Nov 2011 06:01:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6E85A21F8B9E for <>; Sun, 13 Nov 2011 06:01:16 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Sun, 13 Nov 2011 09:01:15 -0500
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Sun, 13 Nov 2011 09:01:15 -0500
From: Hadriel Kaplan <>
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <>
Thread-Topic: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)
Thread-Index: AQHMogy0oPY+iIKWa0aledDcjGopdA==
Date: Sun, 13 Nov 2011 14:01:14 +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: Sun, 13 Nov 2011 14:01:17 -0000

On Nov 13, 2011, at 7:28 AM, Iñaki Baz Castillo wrote:

> 2011/11/13 Hadriel Kaplan <>om>:
>> So long as the mechanisms needed to do so don't hurt WebRTC or force a specific architectural model, why do you care?
> Some telcos in this WG (and I could find exact mails) would accept
> even if WebRTC uses a pure SIP stack.

I'm not sure we have the same understanding of the word "telco".  A "telco" for me is a telephone-company/telecommunications provider/communications service provider (wireless, landline, cable MSOs, etc.).  As far as I can tell, of the 482 members of this mailing list, there are about 32 with email addresses that imply they work for "telcos", and none of them have advocated embedding a SIP stack in the browser.  Lots of people on this mailing list work for companies that sell products to "telco's", but most of them do not advocate putting a SIP stack in the browser either.[1]

Also I really think you're being unfair to people who work for telco's.  I have personally spoken off-line with several of the "telco's" that monitor this mailing list, and all of them believed that whatever's needed to interwork to non-WebRTC must not hurt/degrade WebRTC.  For example most of them actually *want* SRTP to be used, and even think ICE is needed.  Of course they would also prefer to be able to interface to WebRTC with as least cost/complexity as possible, but they know it's not all going to be possible.

> and all of them ask for non mandatory

I don't think that's a fair assessment.  I don't recall a single one of the people who work for telco's ask for non-mandatory SRTP, and even if one did he/she does not represent "all of them".

> Soon, they will also ask non mandatory ICE (they will argue "ICE
> mandatory to implement in WebRTC client, but not mandatory to use").
> DTMF's via RTP is just the less important subject. What I care is all
> the rest,

But DTMF was the topic of the email.

> and the fact that 75% of mails in this WG are about PSTN
> legacy interoperability.

No, they're not.  75% might be about SIP-related interoperability, but SIP is not just the PSTN.  The SRTP/RTP debate, for example, is not about the PSTN.  The forking debate is not about the PSTN.  The ICE and media consent debates were about both PSTN and Enterprise SIP.  The ROAP vs. real API debate was not about the PSTN nor even SIP.  The congestion control threads were not either.  The TURN URI scheme thread is not about it.  The data channel thread is not about it.  ...