Re: [rtcweb] RTCWEB and emergency services

Bernard Aboba <> Wed, 28 September 2011 15:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66BB721F8BAD for <>; Wed, 28 Sep 2011 08:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hikb2cDTNmp6 for <>; Wed, 28 Sep 2011 08:42:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2283621F8512 for <>; Wed, 28 Sep 2011 08:42:45 -0700 (PDT)
Received: from BLU152-W4 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Sep 2011 08:45:30 -0700
Message-ID: <BLU152-W48CF43940505BF3D2E1D693F10@phx.gbl>
Content-Type: multipart/alternative; boundary="_3d93d776-d596-4a49-940a-b320e325235f_"
X-Originating-IP: []
From: Bernard Aboba <>
Date: Wed, 28 Sep 2011 08:45:29 -0700
Importance: Normal
In-Reply-To: <>
References: <BLU152-W318BAE2CE0C609B1BB45CD93F30@phx.gbl>, , <>, , <BLU152-W39115E9C2A50B4A634789093F00@phx.gbl>, , <>, , <>, <BLU152-W28C6CA1EDEEBDD0E78E9DB93F00@phx.gbl>, <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Sep 2011 15:45:30.0220 (UTC) FILETIME=[A695DAC0:01CC7DF5]
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 15:42:46 -0000

Randall said: 

> 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 
> (CALEA)).

[BA] The draft isn't going to cover CALEA, and won't provide guidelines on
when an RTCWEB application would or would not be subject to emergency
services obligations.  

Although the draft can cite some existing rules and the rulemakings now in progress, 
trying to summarize the situation globally is difficult even for existing rules, let alone
future ones. 

> 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.

[BA]  As you say, the rules change over time, which is a good reason not to
try to summarize them in an IETF document.  At best, the document could
summarize them accurately prior to publication, after which the rules would
change and the document would become out of date and misleading.  

> 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. 

[BA] Predicting the future is always challenging, which is a good reason to
avoid doing so in an IETF document. 

> And the requirement already exists for anyone who wants to connect an WebRTC client to the 
> PSTN in the US.

[BA] The exact nature of this requirement may potentially change, so even
for this case, it is probably best to avoid making statements.  For example, 
see the questions relating to an amendment to the definition of "interconnected
VoIP" included in the Location NPRM:

Also, note the questions relating to accessibility in the NG911 NPRM:

> 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)

[BA] Yes, that is the question -- but I'm only planning to address emergency
services issues, not CALEA.