Re: [rtcweb] RTCWEB and emergency services

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 27 September 2011 22:00 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BE921F8F01 for <rtcweb@ietfa.amsl.com>; Tue, 27 Sep 2011 15:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.528
X-Spam-Level:
X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG2pGVcc8E3Y for <rtcweb@ietfa.amsl.com>; Tue, 27 Sep 2011 15:00:02 -0700 (PDT)
Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by ietfa.amsl.com (Postfix) with ESMTP id 778DC21F8D4C for <rtcweb@ietf.org>; Tue, 27 Sep 2011 15:00:00 -0700 (PDT)
Received: from BLU152-W61 ([65.55.111.72]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 15:02:47 -0700
Message-ID: <BLU152-W615D593D3F3E23492CA84F93F00@phx.gbl>
Content-Type: multipart/alternative; boundary="_24853ae6-2b57-47a5-a00d-f3b8a080be09_"
X-Originating-IP: [131.107.0.72]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <ted.ietf@gmail.com>
Date: Tue, 27 Sep 2011 15:02:46 -0700
Importance: Normal
In-Reply-To: <CA+9kkMBAy2AXi+DwKjqJOr1yFaXYiG96iDPi1oZGuU6HwbBDkA@mail.gmail.com>
References: <BLU152-W318BAE2CE0C609B1BB45CD93F30@phx.gbl>, <CA+9kkMA5zZe7D+2F_MmfJgkJCS9CRpDMN3zn=uTjMina-pGaAw@mail.gmail.com>, <BLU152-W39115E9C2A50B4A634789093F00@phx.gbl>, <CA+9kkMBAy2AXi+DwKjqJOr1yFaXYiG96iDPi1oZGuU6HwbBDkA@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Sep 2011 22:02:47.0167 (UTC) FILETIME=[30D818F0:01CC7D61]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWEB and emergency services
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2011 22:00:03 -0000

Ted Hardie said: 


"Speaking personally, I don't think that is the right model.  I can see an emergency service provider providing an RTCWeb service as part of its efforts, just as it may accept IMs, text messages, and other non-traditional communications.  But assuming that any provider of an RTCWeb application must provide a method to reach emergency services does not make sense to me. "

[BA] I believe that is what I said in my original message.  The obligations of the RTCWeb application will depend on what it is doing, as well as the country/state and possibly the device it is running on.   Some applications (e.g. realtime enablement of a game or social network) may not have an emergency service obligation.  Others (such as service enabling phone calls to and from the PSTN) may have such an obligation.  YMMV.  

An emergency service provider or PSAP could also use RTCWeb as part of their efforts, of course.   Dispatcher workstations often do support browsers, although the sites that can be accessed may be controlled for security reasons.  That is definitely worth mentioning. 

Ted Hardie also said: 

"Downloaded javascript from a system presumed to be malicious is not how you want to make your 911/112 calls."

[BA] Indeed, this does raise potential issues, given concerns over attacks such as "swatting".   Currently this kind of attack isn't covered in the RTCWEB security document.  In addition to the malicious Javascript concern, there is experience with SIM-less calls, for example, which indicates that lack of authentication tends to lead to an increase in prank calls.  


Ted Hardie said:

"Can the poker site require that emergency services folks have a login to its system in monitor state in order to provide this service?"

[BA] I'm not aware of any jurisdiction which currently imposes an emergency services obligation on an online game.  Is this a real use case?

Ted Hardie said:

"Despite our re-use, it is vitally important to remember that these applications are not phones."

[BA] We've already seen a demo of a handset utilizing RTCWEB technology.   However, just because some applications *are* phones doesn't imply that *all* RTCWeb applications will have emergency service obligations, that an RTCWeb-enabled browser needs to natively support every potential emergency service scenario, or even that RTCWeb needs to handle all the obligations that do arise.   After all, many of the major issues in emergency services (like location determination) don't have that much to do with RTCWeb, and there are other APIs (such as the Mozilla WebAPI proposal) that could provide emergency services functionality based on the underlying telephony platform, distinct from RTCWeb.

Ted Hardie said:


"If you must describe in the terms of telephony, please circumscribe your terms--"For RTCWeb applications intended to provide telephony services, the following considerations apply...."  

[BA] I would prefer not to give advice as to what applications do and do not have emergency service obligations.  Given some of the proceedings now in progress that is a complex subject and I'm not a lawyer.  But we can say "For those RTCWeb applications that have emergency services obligations, the following considerations apply.... "  leaving it up to the reader (and their lawyer) to parse through the existing and future regulations to figure out what their obligations might be.