Re: [rtcweb] RTCWEB and emergency services

Randell Jesup <> Wed, 28 September 2011 14:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0903121F8D56 for <>; Wed, 28 Sep 2011 07:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H2B8OaSo4iac for <>; Wed, 28 Sep 2011 07:34:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3F73421F8C9C for <>; Wed, 28 Sep 2011 07:34:17 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1R8vFx-0006tu-Cu for; Wed, 28 Sep 2011 09:37:05 -0500
Message-ID: <>
Date: Wed, 28 Sep 2011 10:33:21 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
References: <BLU152-W318BAE2CE0C609B1BB45CD93F30@phx.gbl>, <>, <BLU152-W39115E9C2A50B4A634789093F00@phx.gbl>, <>, <> <BLU152-W28C6CA1EDEEBDD0E78E9DB93F00@phx.gbl> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] RTCWEB and emergency services
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: Wed, 28 Sep 2011 14:34:18 -0000

On 9/28/2011 3:00 AM, Harald Alvestrand wrote:
> I'm waiting for the draft to read in context, but what I hear Bernard 
> saying is:
> "IF the RTCweb service falls within the scope of 911 regulations
> THEN here are some things it needs to consider...."
> Some RTCWeb services will certainly not fall within the scope of 911 
> regulations.
> If someone creates a service where it does matter (sets out to emulate 
> a phone perfectly in the browser, for instance) they may very well 
> find themselves in a situation where they do become subject to 
> regulation, and in that case, the implementor may have benefit from 
> reading Bernard's draft (or the document that eventually results from it).
> All other service implementors can disregard it.
> I hope....

I hope too.  I'll note that in the US the FCC has a history of changing 
the rules on 911 compliance (and other legal requirements like intercept 

VoIP was originally excluded; then it was included only for calls to the 
PSTN, then it was included for all calls if your "network" was attached 
to the PSTN (even if the call was totally on-net).  (This refers to 
CALEA.)  There's even been talk of extending it to non-PSTN-connected 
networks like XBox Live.

So I wouldn't assume that there won't (now or in the future) be a 
requirement for application developers to support either 911 or CALEA 
(in the US) or the equivalent in other countries.  And the requirement 
already exists for anyone who wants to connect an WebRTC client to the 
PSTN in the US.

As far as *we're* concerned, I think it just means we should make sure 
some basic functionalities are available to the applications so *they* 
can comply - and I think that's what Bernard is addressing.

For example, see
(Good article, BTW)

    Voice services that do not connect to the public telephone network.
    Google and Facebook both offer in-network audio chat to their users
    (Google also offers video). Microsoft's XBox 360 service, Blizzard
    and several other online video game platforms allow users to insult
    each other chat while they play against other users online. At least
    from published information, I'm not aware of any one of these
    companies offering interception capabilities -- and so law
    enforcement agencies almost certainly want access to this

I'll also note that browser<->browser WebRTC communication currently 
won't be covered by the CALEA requirement-to-decrypt even if the service 
provider's network attaches to the PSTN because (if we're using DTLS) 
the keys aren't known to the provider (or the app).

Randell Jesup