Internet DRAFT - draft-aboba-rtcweb-ecrit
draft-aboba-rtcweb-ecrit
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]
