[rtcweb] RTCWEB and emergency services

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 26 September 2011 00:10 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 5FC2821F8AA8 for <rtcweb@ietfa.amsl.com>; Sun, 25 Sep 2011 17:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.975
X-Spam-Level:
X-Spam-Status: No, score=-100.975 tagged_above=-999 required=5 tests=[AWL=-1.106, BAYES_05=-1.11, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24, 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 1ipJxN2VIZ+X for <rtcweb@ietfa.amsl.com>; Sun, 25 Sep 2011 17:10:27 -0700 (PDT)
Received: from blu0-omc3-s12.blu0.hotmail.com (blu0-omc3-s12.blu0.hotmail.com [65.55.116.87]) by ietfa.amsl.com (Postfix) with ESMTP id 69E2021F8A97 for <rtcweb@ietf.org>; Sun, 25 Sep 2011 17:10:27 -0700 (PDT)
Received: from BLU152-W31 ([65.55.116.73]) by blu0-omc3-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Sep 2011 17:13:08 -0700
Message-ID: <BLU152-W318BAE2CE0C609B1BB45CD93F30@phx.gbl>
Content-Type: multipart/alternative; boundary="_7fa10192-4537-42a3-a018-098e126fdca9_"
X-Originating-IP: [98.203.198.61]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <rtcweb@ietf.org>
Date: Sun, 25 Sep 2011 17:13:08 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Sep 2011 00:13:08.0673 (UTC) FILETIME=[11FFB310:01CC7BE1]
Subject: [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: Mon, 26 Sep 2011 00:10:28 -0000





I'm putting together a draft on the subject of RTCWEB and emergency services.  However, before submitting this, it seemed useful to get some feedback from the group on the general direction of the document. 

1. The overall requirements for emergency services support will vary by jurisdiction and are likely to change.   Therefore the document, while citing ongoing regulatory proceedings within the US and EU, does not attempt to provide legal advice or offer a definitive statement of the regulatory requirements.  Instead, the document cites  documents from the ECRIT WG, such as the ECRIT Framework and Phone-BCP documents which provide guidance on best current or future practices.   

2.  The overall requirements for emergency services support also vary by the type of service that is being implemented.   For example,  adding support for real-time conferencing to a social networking service or a game (e.g. non-interconnected VoIP) will result in different requirements than say, implementing a phone dialing service that can both make outgoing calls and take incoming calls from E.164 numbers (e.g. interconnected VoIP).   

It should therefore be understood that the burden for implementation of emergency services falls principally upon the operator of the service, and that the role of the RTCWEB implementer is to deliver basic capabilities and to enable an operator to add to this functionality, rather than providing for every possible need natively ("I want a pony").   

3.  The emergency services capabilities of the browser are comprised of the functionality that is implemented in the browser, as well functionality that can be added via Javascript libraries.   In some circumstances, it may be viable to supplement functionality with plugins.  For example, a "webphone" intended for use with an IP PBX, whose firmware is controlled by the IP PBX vendor,  could include within its code load plugins to provide additional functionality, including signaling protocols and codecs.  As a result, it is not required for an RTCWEB implementation to natively satisfy every requirement of ECRIT Phone-BCP.    Examples of requirements which may not be satisfiable without plugins include some of the endpoint media requirements of PhoneBCP Section 14, such as ED-77 (video codec support).   However, it would appear that some of the requirements of that section such as ED-71 (RTP Support) and ED-73 (G.711 support) are appropriate.  

4. With respect to location capabilities, the W3C Location APIs and associated Location-Based Services are not adequate in terms of their support for emergency services 
location.  This gap exists in part because the requirements and scenarios for  Location-Based Services (LBS) are different from those of Location Information Services (LISes) used for emergency purposes.   While in the long-term it may be possible to close the gaps,  in the short term the gaps may be addressed via Javascript libraries implementing elements of the ECRIT 
architecture such as HELD, or even LoST.    







In addition, in some scenarios, it is quite feasible for this 

2.  Similarly, the requirements for native browser functionality will vary according to the scenario.  

2. In some scenarios, 


 In meeting the requirements for emergency services support, the important question to answer is what functionality MUST be present natively within the browser