Network Working Group B. Aboba INTERNET-DRAFT M. Thomson Category: Informational Skype Expires: December 30, 2013 13 June 2013 Emergency Services Support in WebRTC draft-aboba-rtcweb-ecrit-01.txt Abstract The Web Real-Time Communication (WebRTC) framework supports interactive communication between web-browsers, including support for audio, video and text. This document describes how emergency services functionality can be implemented within the WebRTC framework, including support for location and call routing as well as interoperability with Public Safety Answering Points (PSAPs) supporting next generation emergency services. Legal THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 30, 2013. Aboba & Thomson Informational [Page 1] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Prior Work . . . . . . . . . . . . . . . . . . . . . . . 4 2. Location and Call Routing Requirements . . . . . . . . . . . 4 3 Media Requirements . . . . . . . . . . . . . . . . . . . . . 7 4. Accessibility . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2 Informative references . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Aboba & Thomson Informational [Page 2] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 1. Introduction The Web Real-Time Communication (WebRTC) framework supports interactive communication between web-browsers, including support for audio, video and text. This document describes how emergency services functionality can be implemented within the WebRTC framework. Since signaling is out of scope of the WebRTC standards suite as noted in "Overview: Real Time Protocols for Browser-based Applications" [I-D.ietf-rtcweb-overview] Section 3, this document focuses on other aspects such as location, call routing and media support. No guidance is provided as to whether a given WebRTC application or service will be subject to emergency service obligations. As noted in "Best Current Practice for Communications Services in support of Emergency Calling" [RFC6881] Section 4: Some jurisdictions have regulations governing which devices need to support emergency calling and developers are encouraged to ensure that devices they develop meet relevant regulatory requirements. Unfortunately, the natural variation in those regulations also makes it impossible to accurately describe the cases when developers do or do not have to support emergency calling. It should also be understood that this document does not advocate use of IP-based communication in all situations. For example, where accurate location cannot be obtained, emergency callers could be better served by utilizing the telephony capabilities of the underlying platform (e.g., a mobile-device) where available, as proposed in [WebTel]. This can enable location to be provided in situations where it would not otherwise be available, as well as permitting an emergency call to be placed even when the device does not have access to the Internet. The document is laid out as follows: Section 1 provides an introduction and reviews prior work. Section 2 discusses requirements relating to location and call routing. Section 3 discusses media requirements. Section 4 discusses accessibility. Section 5 discusses security considerations. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document uses terms from [RFC3261], [RFC5012] and [RFC6443]. Aboba & Thomson Informational [Page 3] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 1.2. Prior Work The IETF ECRIT WG has developed an overview of the emergency calling architecture as well as a best current practice document detailing implementation requirements. "Framework for Emergency Calling using Internet Multimedia" [RFC6443] provides an overview of how IETF specifications can be used to support emergency calling using multimedia. At a high level, this involves determination of the caller location, conveyance of the location within a signaling protocol such as Session Initiation Protocol (SIP) [RFC6442], routing of the call using the Location-to- Service Translation (LoST) protocol [RFC5222], and exchange of media using Real-time Transport Protocol (RTP) [RFC3550]. "Best Current Practice for Communication Services in support of Emergency Calling" [RFC6881] builds on [RFC6443] to describe the requirements for end devices ("ED-" requirements), access networks ("AN-"), service providers ("SP-"), Public Safety Answering Points (PSAPs) and intermediate devices ("INT-") to achieve globally interoperable emergency calling on the Internet. Both [RFC6443] and [RFC6881] assume the use of SIP as the signaling mechanism for emergency calling. As noted in [RFC6443] Section 1: This document discusses the use of the Session Initiation Protocol (SIP) [RFC3261] by PSAPs and calling parties. While other inter- domain call signaling protocols may be used for emergency calling, SIP is ubiquitous and possesses the proper support of this use case. Since standardization of signaling is out of scope of the WebRTC standards effort, and WebRTC applications can utilize a wide variety of signaling mechanisms, the requirements described in [RFC6881] do not necessarily apply to WebRTC implementations, applications and services. Therefore in this document, we focus on emergency calling requirements that are independent of the signaling mechanism, such as those relating to accessibility, location, call routing and media. 2. Location and Call Routing Requirements Determination of caller location as well as call routing is an essential aspect of emergency services support. Relevant requirements from [RFC6881] include: ED-15/INT-4/AN-4 Devices, intermediate Devices and/or access networks SHOULD support a manual method to override the location the access network determines. When the override location is Aboba & Thomson Informational [Page 4] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 supplied in civic form, it MUST be possible for the resultant Presence Information Data Format - Location Object (PIDF-LO) received at the PSAP to contain any of the elements specified in [RFC4119] and [RFC5139]. ED-17/INT-9/AN-9 Devices that support endpoint measuring of location MUST have at least a coarse location capability (typically <1km accuracy) for routing of calls. The location mechanism MAY be a service provided by the access network. ED-24 Where the operating system supporting application programs which need location for emergency calls does not allow access to Layer 2 and Layer 3 functions necessary for a client application to use DHCP location options and/or other location technologies that are specific to the type of access network, the operating system MUST provide a published API conforming to ED-12 through ED-23 and ED-25 through ED-32. It is RECOMMENDED that all operating systems provide such an API. ED-41/SP-20 Location objects MUST be created with information about the method by which the location was determined, such as GPS, manually entered, or based on access network topology included in a PIDF- LO "method" element. In addition, the source of the location information MUST be included in a PIDF-LO "provided-by" element. ED-49 Endpoints MUST support one or more mechanisms that allow them to determine their public IP address, for example, STUN [RFC5389]. ED-50 Endpoints MUST support LIS discovery as described in [RFC5986], and the LoST discovery as described in [RFC5223]. Since browser applications do not have direct access to operating system location APIs, ED-24 is not applicable to WebRTC. For reasons that will be described, automatically obtaining location suitable for emergency use is challenging for WebRTC applications. In order to ensure that location is available when needed, as well as to provide resilience against errors in automated location determination, WebRTC emergency service applications SHOULD support manual override as recommended in ED-15. The W3C Geolocation API [GeolocationAPI] was not developed with emergency services location in mind, so that requirements ED-17 and ED-41 are not well supported. [GeolocationAPI] does not provide information on the source of the location information as required in ED-41; attempting to infer the source from the accuracy parameter is Aboba & Thomson Informational [Page 5] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 NOT RECOMMENDED. Currently, Location Based Services utilized by Geolocation APIs do not warrant their use in emergency services and do not consistently provide the accuracy required by emergency services applications, so that emergency use of the W3C Geolocation API is also NOT RECOMMENDED. An alternative is to implement location configuration and call routing in Javascript, using an HTTP-based protocol such as HELD [RFC5985] and LoST [RFC5222]. While this approach can provide location usable in emergency services applications, it is only applicable on networks with a Location Information Server (LIS), such as enterprise deployments subject to Multi-Line Telephone System (MLTS) regulations [StateMLTS]. In order to utilize location and call routing services, it is first necessary to locate the appropriate servers. Since the discovery mechanisms described in [RFC5986] and [RFC5223] are based on use of a DHCP option, which cannot be assumed to be accessible in Javascript, ED-50 is difficult to support within WebRTC-based emergency services applications. For LoST discovery, the emergency services application can determine the appropriate LoST server(s) on its own. To avoid potential issues, it is best to avoid pre-configuration of particular servers, allowing the appropriate server to be determined dynamically. LIS discovery requires determination of the domain name that can be used for LIS discovery, as noted in [RFC5986] Section 3.4: If a Device knows one or more alternative domain names that might be used for discovery, it MAY repeat the U-NAPTR process using those domain names as input. For instance, static configuration of a Device might be used to provide a Device with a domain name. While static configuration of the domain name can be used in situations where device mobility is restricted, the appropriate LIS depends on the network to which the host is attached, so that this is not a general solution. "Location Information Server (LIS) Discovery using IP address and Reverse DNS" [I.D.ietf-geopriv-res-gw-lis-discovery] specifies a means for a device to discover several alternative domain names that can be used as input to the Dynamic Delegation Discovery Service (DDDS). Since several of the techniques (such as use of PTR RRs and Session Traversal Utilities for NAT (STUN) [RFC5389]) are potentially implementable in WebRTC-based emergency services applications this approach MAY be used. Aboba & Thomson Informational [Page 6] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 3. Media Requirements Within [RFC6881] media-related requirements are covered in Section 14. These include: ED-71 Endpoints MUST send and receive media streams on RTP [RFC3550]. ED-72 Normal SIP offer/answer [RFC3264] negotiations MUST be used to agree on the media streams to be used. ED-73/SP-41 G.711 A law (and mu Law if they are intended be used in North America) encoded voice as described in [RFC3551] MUST be supported. If the endpoint cannot support G.711, a transcoder MUST be used so that the offer received at the PSAP contains G.711. It is desirable to include wideband codecs such as G.722 and AMR-WB in the offer. PSAPs SHOULD support narrowband codecs common on endpoints in their area to avoid transcoding. ED-74 Silence suppression (Voice Activity Detection methods) MUST NOT be used on emergency calls. PSAP call takers sometimes get information on what is happening in the background to determine how to process the call. ED-77 Endpoints supporting video MUST support H.264 per [RFC6184]. Requirement ED-71 is satisfied by compliant WebRTC implementations since "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP" [I-D.ietf-rtcweb-rtp-usage] Section 4.1 requires support for RTP [RFC3550]. Requirement ED-72 is specific to SIP and so does not apply generally to WebRTC implementations, applications and services. However, it is believed that the APIs under development within the W3C WebRTC WG can support this requirement. Requirement ED-74 is satisfied by compliant WebRTC implementations since the WebRTC APIs under development within W3C [WEBRTC], support silence suppression control via the "constraints" parameter. [I.D.ietf-rtcweb-rtp-usage] Section 4.3 does not provide a recommendation on a mandatory-to-implement set of codecs. While ED-73 does not require implementation of G.711 if the service supports transcoding, G.711 is not difficult to implement and is widely supported, with a high level of interoperability. Therefore it is recommended that G.711 be included as a mandatory-to-implement audio codec within [I-D.ietf-rtcweb-rtp-usage] Section 4.3. Aboba & Thomson Informational [Page 7] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 Currently the disposition of ED-77 is unclear. Discussion of mandatory-to-implement video codecs is ongoing within the IETF RTCWEB WG, but has not reached a conclusion. While there is a need to support interoperable video within emergency services applications, more options may be available within an emergency services context than would be the case for general use. For example, within the PSAP, it may be feasible to support multiple video codecs, either by installation of browser plugins, or by use of multiple browsers. In some emergency service applications (such as the VRS), codec requirements may be specific to the service and may be satisfiable by a custom device or browser approved for use with that service, which may include the required codecs implemented natively or via plug-ins, as the service provider sees fit. 4. Accessibility By lowering the barriers to development of realtime-enabled browser applications, as well as by building on accessibility support within the browser, WebRTC promises to enable the development of a new generation of accessible emergency applications and services. In order to support accessibility, it is RECOMMENDED that WebRTC- based emergency applications and services conform to the Web Content Accessibility Guidelines (WCAG) v2.0 [WCAG]. In order to support accessibility for individuals with hearing or speech disabilities, support for textual communications is important. Currently the W3C is developing a proposed charter for the Timed Text Working Group [TTWG], which will potentially produce a second edition of the timed Text Markup Language (TTML) 1.0 recommendation as well as publishing a recommendation for a version 1.1 specification. Text-related requirements in [RFC6881] are covered in Section 14, including: ED-75 Endpoints supporting Instant Messaging (IM) MUST support either [RFC3428] and [RFC4975]. ED-76 Endpoints supporting real-time text MUST use [RFC4103]. The expectations for emergency service support for the real-time text medium are described in [RFC5194], Section 7.1. Since [RFC3428] and [RFC4975] are both based on SIP, ED-75 does not apply to all WebRTC-based emergency applications and services. As noted in "Emergency Services Functionality with the Extensible Messaging and Presence Protocol (XMPP)" [I-D.tschofenig-ecrit-xmpp- es], XMPP [RFC6120] is a potential alternative for emergency services Aboba & Thomson Informational [Page 8] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 applications looking to support instant messaging [RFC6121] and multi-user chat [XEP-045] functionality. "RTP Payload for Text Conversation" [RFC4103] is typically implemented along with SIP signaling as described in "Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)" [RFC5194]. As a result, ED-76 does not apply to WebRTC implementations. Alternatives to support of real-time text functionality are available, such as "In-Band Real Time Text" [XEP-0301], which supports real-time text by addition of child elements within XMPP message stanzas. The use of child elements to encapsulate real-time text, as well as transmission of complete lines enables [XEP-0301] to provide backward compatibility with existing XMPP instant-messaging and Multi-User Chat (MUC) clients, with no changes required to XMPP servers. Since XMPP can be encapsulated within HTTP via mechanisms such as BOSH [XEP-0206] or WebSockets [RFC6455], [XEP-0301] can be implemented in Javascript. Experience with Javascript implementation using the [Strophe] XMPP library indicates that adequate performance is achievable. In contrast, implementing real-time text as media as in [RFC4103] requires native browser support, as well as requiring changes to the configuration of intermediaries such as Session Border Controllers (SBCs). Also, [RFC4103] is not backward compatible with SIP instant messaging implementations supporting page-mode [RFC3428] or session [RFC4975] approaches. 5. Security Considerations Security requirements in [RFC6881] include: ED-48/SP-24 TLS [RFC5746] MUST be used to protect location (but see Section 9.1). All implementations MUST support TLS. ED-58/SP-30 TLS is the primary mechanism used to secure the signaling for emergency calls. IPsec [RFC4301] MAY be used instead of TLS for any hop. Either TLS or IPSEC MUST be used when attempting to signal an emergency call. ED-59/SP-31 If TLS session establishment is not available, or fails, the call MUST be retried without TLS. ED-60/SP-32 [RFC5626] is RECOMMENDED to maintain persistent TLS connections between entities when one of the entity is an endpoint. Persistent TLS connection between proxies is RECOMMENDED using any suitable mechanism. ED-61/AN-28 TLS SHOULD be used when attempting to retrieve Aboba & Thomson Informational [Page 9] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 location (configuration or dereferencing) with HELD. The use of [RFC5077] is RECOMMENDED to minimize the time to establish TLS sessions without keeping server-side state. IPsec MAY be used instead of TLS. ED-62/AN-29 When TLS session establishment fails, the location retrieval MUST be retried without TLS. For WebRTC, HTTPS MUST be used to protect signaling for an emergency call, with potential fail-over to HTTP. HTTPS SHOULD be used to protect location retrieval (HELD) and call routing (LoST). WebRTC security considerations are discussed in "Security Considerations for RTC-Web" [I-D.ietf-rtcweb-security]. The WebRTC security architecture, described in "RTCWEB Security Architecture" [I-D.ietf-rtcweb-security-arch], requires implementation of Secure RTP [RFC3711] as well as DTLS/SRTP [RFC5764]. While the security features of WebRTC exceed the requirements outlined in [RFC6881], support for emergency services within WebRTC raises concerns about potential attacks on the emergency services infrastructure, given the potential for malicious code to be executed within the browser. One way to lessen the likelihood of attacks by untrusted Javascript applications is for PSAPs to put up their own sites for emergency calling, protected by HTTPS. While ICE [RFC5245] provides demonstration of liveness and consent to receive, it is possible for an attacker to overwhelm the PSAP by generating a large number of prank calls. IP relay services are also potential targets since these don't require forging of Caller-Id nor do they provide audio or video from the attacker. Security threats to IP-based emergency services are described in "Security Threats and Requirements for Emergency Call Marking and Mapping" [RFC5069]. These include attacks on the emergency services system, such as attempting to deny system services to all users in a given area, to gain fraudulent use of services and to divert emergency calls to non-emergency sites. [RFC5069] also describes attacks against individuals, including attempts to prevent an individual from receiving aid, or to gain information about an emergency. "Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats against geographic location privacy, including protocol threats, threats resulting from the storage of geographic location data, and threats posed by the abuse of information. Overall, experience indicates a relationship between anonymity and Aboba & Thomson Informational [Page 10] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 the prevalence of prank calling. Therefore some protection may be provided through authentication of the caller either in the signaling or media plane. It is NOT RECOMMENDED that WebRTC-based emergency applications and services support anonymous emergency calling. 6. IANA Considerations This document does not require actions by IANA. 7. Acknowledgments We would like to thank the members of the IETF RTCWEB Working Group for discussions related to this topic. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", RFC 6881, March 2013. [WCAG] Caldwell, B., Cooper, M., Reid, L.G. and G. Vanderheiden, "Web Content Accessibility Guidelines (WCAG) 2.0", http://www.w3.org/TR/WCAG20/, December 2008. 8.2. Informative References [GeolocationAPI] Popescu, A., "Geolocation API Specification", W3C, http://dev.w3.org/geo/api/spec-source.html [I.D.ietf-geopriv-res-gw-lis-discovery] Thomson, M. and R. Bellis, "Location Information Server (LIS) Discovery using IP address and Reverse DNS", draft- ietf-geopriv-res-gw-lis-discovery-05 (work in progress), April 2013. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser- based Applications", draft-ietf-rtcweb-overview-06 (work in progress), February 2013. [I-D.ietf-rtcweb-rtp-usage] Perkins, C., Westerlund, M. and J. Ott, "Web Real-Time Aboba & Thomson Informational [Page 11] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 Communication (WebRTC): Media Transport and Use of RTP", draft-ietf-rtcweb-rtp-usage-06 (work in progress), February 2013. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for RTC-Web", draft- ietf-rtcweb-security-04 (work in progress), January 2013. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "RTCWEB Security Architecture", draft-ietf- rtcweb-security-arch-06 (work in progress), July 2013. [I-D.tschofenig-ecrit-xmpp-es] Tschofenig. H., "Emergency Services Functionality with the Extensible Messaging and Presence Protocol (XMPP)", draft- tschofenig-ecrit-xmpp-es-00 (work in progress), March 2012. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and R. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005. Aboba & Thomson Informational [Page 12] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4975] Campbell, B., Mahy, R. and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008. [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam, "Security Trheats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008. [RFC5077] Salowey, J., Zhou, H., Eronen, P. and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008. [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008. [RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)", RFC 5194, June 2008. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H. and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008. [RFC5223] Schulzrinne, H., Polk, J. and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT", RFC 5389, October 2008. [RFC5626] Jennings, C., Mahy, R. and F. Audet, "Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009. Aboba & Thomson Informational [Page 13] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 [RFC5746] Rescorla, E., Ray, M., Dispensa, S. and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010. [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. [RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985, September 2010. [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010. [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011. [RFC6184] Wang, Y.-K., Even, R., Kristensen, T. and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, May 2011. [RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011. [RFC6443] Rosen, B., Schulzrinne. H., Polk, J. and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, December 2011. [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. [StateMLTS] "State E911 Legislation", http://www1.911enable.com/resource-center/state- e911-legislation [Strophe] "Libraries for XMPP Poets", http://strophe.im [TTWG] "Proposed Timed Text Working Group Charter", http://www.w3.org/2012/02/timed-text-wg-charter.html [WEBRTC] Bergkvist, A., Burnett, D., Jennings, C. and A. Narayanan, "WebRTC 1.0: Real-time Communication Between Browsers", W3C Editor's Draft (work in progress), Aboba & Thomson Informational [Page 14] INTERNET-DRAFT Emergency Services Support in WebRTC 13 June 2013 http://dev.w3.org/2011/webrtc/editor/webrtc.html, June 2013. [WebTel] WebAPI/WebTelephony, https://wiki.mozilla.org/WebAPI/WebTelephony [XEP-0206] Paterson, I. and P. Saint-Andre, "XMPP Over BOSH", XEP-0206 version 1.3, http://xmpp.org/extensions/xep-0206.html, July 2010. [XEP-0301] Rejhon, M., "In-Band Real Time Text", XEP-0301 version 0.2, http://xmpp.org/extensions/xep-0301.html, March 2012. [XEP-045] Saint-Andre, P., "Multi-User Chat", XEP 0045 version 1.25, http://xmpp.org/extensions/xep-0045.html, February 2012. Authors' Addresses Bernard Aboba Skype Redmond, WA 98052 US EMail: bernard_aboba@hotmail.com Martin Thomson Skype 3210 Porter Drive Palo Alto, CA 94304 US Phone: +1 650-353-1925 Email: martin.thomson@gmail.com Aboba & Thomson Informational [Page 15]