idnits 2.17.00 (12 Aug 2021) /tmp/idnits44878/draft-aboba-rtcweb-ecrit-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (13 June 2013) is 3257 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.tschofenig-ecrit-xmpp-es' is defined on line 524, but no explicit reference was found in the text == Outdated reference: draft-ietf-rtcweb-overview has been published as RFC 8825 == Outdated reference: draft-ietf-rtcweb-rtp-usage has been published as RFC 8834 == Outdated reference: draft-ietf-rtcweb-security has been published as RFC 8826 == Outdated reference: draft-ietf-rtcweb-security-arch has been published as RFC 8827 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Aboba 3 INTERNET-DRAFT M. Thomson 4 Category: Informational Skype 5 Expires: December 30, 2013 13 June 2013 7 Emergency Services Support in WebRTC 8 draft-aboba-rtcweb-ecrit-01.txt 10 Abstract 12 The Web Real-Time Communication (WebRTC) framework supports 13 interactive communication between web-browsers, including support for 14 audio, video and text. This document describes how emergency 15 services functionality can be implemented within the WebRTC 16 framework, including support for location and call routing as well as 17 interoperability with Public Safety Answering Points (PSAPs) 18 supporting next generation emergency services. 20 Legal 22 THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON 23 AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 24 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 25 IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE, DISCLAIM ALL 26 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 27 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 28 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 29 FOR A PARTICULAR PURPOSE. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 30, 2013. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.2 Prior Work . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Location and Call Routing Requirements . . . . . . . . . . . 4 69 3 Media Requirements . . . . . . . . . . . . . . . . . . . . . 7 70 4. Accessibility . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . 9 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 8.2 Informative references . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 The Web Real-Time Communication (WebRTC) framework supports 82 interactive communication between web-browsers, including support for 83 audio, video and text. This document describes how emergency 84 services functionality can be implemented within the WebRTC 85 framework. Since signaling is out of scope of the WebRTC standards 86 suite as noted in "Overview: Real Time Protocols for Browser-based 87 Applications" [I-D.ietf-rtcweb-overview] Section 3, this document 88 focuses on other aspects such as location, call routing and media 89 support. 91 No guidance is provided as to whether a given WebRTC application or 92 service will be subject to emergency service obligations. As noted 93 in "Best Current Practice for Communications Services in support of 94 Emergency Calling" [RFC6881] Section 4: 96 Some jurisdictions have regulations governing which devices need 97 to support emergency calling and developers are encouraged to 98 ensure that devices they develop meet relevant regulatory 99 requirements. Unfortunately, the natural variation in those 100 regulations also makes it impossible to accurately describe the 101 cases when developers do or do not have to support emergency 102 calling. 104 It should also be understood that this document does not advocate use 105 of IP-based communication in all situations. For example, where 106 accurate location cannot be obtained, emergency callers could be 107 better served by utilizing the telephony capabilities of the 108 underlying platform (e.g., a mobile-device) where available, as 109 proposed in [WebTel]. This can enable location to be provided in 110 situations where it would not otherwise be available, as well as 111 permitting an emergency call to be placed even when the device does 112 not have access to the Internet. 114 The document is laid out as follows: Section 1 provides an 115 introduction and reviews prior work. Section 2 discusses 116 requirements relating to location and call routing. Section 3 117 discusses media requirements. Section 4 discusses accessibility. 118 Section 5 discusses security considerations. 120 1.1. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 This document uses terms from [RFC3261], [RFC5012] and [RFC6443]. 128 1.2. Prior Work 130 The IETF ECRIT WG has developed an overview of the emergency calling 131 architecture as well as a best current practice document detailing 132 implementation requirements. 134 "Framework for Emergency Calling using Internet Multimedia" [RFC6443] 135 provides an overview of how IETF specifications can be used to 136 support emergency calling using multimedia. At a high level, this 137 involves determination of the caller location, conveyance of the 138 location within a signaling protocol such as Session Initiation 139 Protocol (SIP) [RFC6442], routing of the call using the Location-to- 140 Service Translation (LoST) protocol [RFC5222], and exchange of media 141 using Real-time Transport Protocol (RTP) [RFC3550]. 143 "Best Current Practice for Communication Services in support of 144 Emergency Calling" [RFC6881] builds on [RFC6443] to describe the 145 requirements for end devices ("ED-" requirements), access networks 146 ("AN-"), service providers ("SP-"), Public Safety Answering Points 147 (PSAPs) and intermediate devices ("INT-") to achieve globally 148 interoperable emergency calling on the Internet. 150 Both [RFC6443] and [RFC6881] assume the use of SIP as the signaling 151 mechanism for emergency calling. As noted in [RFC6443] Section 1: 153 This document discusses the use of the Session Initiation Protocol 154 (SIP) [RFC3261] by PSAPs and calling parties. While other inter- 155 domain call signaling protocols may be used for emergency calling, 156 SIP is ubiquitous and possesses the proper support of this use 157 case. 159 Since standardization of signaling is out of scope of the WebRTC 160 standards effort, and WebRTC applications can utilize a wide variety 161 of signaling mechanisms, the requirements described in [RFC6881] do 162 not necessarily apply to WebRTC implementations, applications and 163 services. Therefore in this document, we focus on emergency calling 164 requirements that are independent of the signaling mechanism, such as 165 those relating to accessibility, location, call routing and media. 167 2. Location and Call Routing Requirements 169 Determination of caller location as well as call routing is an 170 essential aspect of emergency services support. Relevant 171 requirements from [RFC6881] include: 173 ED-15/INT-4/AN-4 Devices, intermediate Devices and/or access 174 networks SHOULD support a manual method to override the location 175 the access network determines. When the override location is 176 supplied in civic form, it MUST be possible for the resultant 177 Presence Information Data Format - Location Object (PIDF-LO) 178 received at the PSAP to contain any of the elements specified in 179 [RFC4119] and [RFC5139]. 181 ED-17/INT-9/AN-9 Devices that support endpoint measuring of 182 location MUST have at least a coarse location capability 183 (typically <1km accuracy) for routing of calls. The location 184 mechanism MAY be a service provided by the access network. 186 ED-24 Where the operating system supporting application programs 187 which need location for emergency calls does not allow access to 188 Layer 2 and Layer 3 functions necessary for a client application 189 to use DHCP location options and/or other location technologies 190 that are specific to the type of access network, the operating 191 system MUST provide a published API conforming to ED-12 through 192 ED-23 and ED-25 through ED-32. It is RECOMMENDED that all 193 operating systems provide such an API. 195 ED-41/SP-20 Location objects MUST be created with information 196 about the method by which the location was determined, such as 197 GPS, manually entered, or based on access network topology 198 included in a PIDF- LO "method" element. In addition, the source 199 of the location information MUST be included in a PIDF-LO 200 "provided-by" element. 202 ED-49 Endpoints MUST support one or more mechanisms that allow 203 them to determine their public IP address, for example, STUN 204 [RFC5389]. 206 ED-50 Endpoints MUST support LIS discovery as described in 207 [RFC5986], and the LoST discovery as described in [RFC5223]. 209 Since browser applications do not have direct access to operating 210 system location APIs, ED-24 is not applicable to WebRTC. 212 For reasons that will be described, automatically obtaining location 213 suitable for emergency use is challenging for WebRTC applications. 214 In order to ensure that location is available when needed, as well as 215 to provide resilience against errors in automated location 216 determination, WebRTC emergency service applications SHOULD support 217 manual override as recommended in ED-15. 219 The W3C Geolocation API [GeolocationAPI] was not developed with 220 emergency services location in mind, so that requirements ED-17 and 221 ED-41 are not well supported. [GeolocationAPI] does not provide 222 information on the source of the location information as required in 223 ED-41; attempting to infer the source from the accuracy parameter is 224 NOT RECOMMENDED. Currently, Location Based Services utilized by 225 Geolocation APIs do not warrant their use in emergency services and 226 do not consistently provide the accuracy required by emergency 227 services applications, so that emergency use of the W3C Geolocation 228 API is also NOT RECOMMENDED. 230 An alternative is to implement location configuration and call 231 routing in Javascript, using an HTTP-based protocol such as HELD 232 [RFC5985] and LoST [RFC5222]. While this approach can provide 233 location usable in emergency services applications, it is only 234 applicable on networks with a Location Information Server (LIS), such 235 as enterprise deployments subject to Multi-Line Telephone System 236 (MLTS) regulations [StateMLTS]. 238 In order to utilize location and call routing services, it is first 239 necessary to locate the appropriate servers. Since the discovery 240 mechanisms described in [RFC5986] and [RFC5223] are based on use of a 241 DHCP option, which cannot be assumed to be accessible in Javascript, 242 ED-50 is difficult to support within WebRTC-based emergency services 243 applications. 245 For LoST discovery, the emergency services application can determine 246 the appropriate LoST server(s) on its own. To avoid potential 247 issues, it is best to avoid pre-configuration of particular servers, 248 allowing the appropriate server to be determined dynamically. 250 LIS discovery requires determination of the domain name that can be 251 used for LIS discovery, as noted in [RFC5986] Section 3.4: 253 If a Device knows one or more alternative domain names that might 254 be used for discovery, it MAY repeat the U-NAPTR process using 255 those domain names as input. For instance, static configuration 256 of a Device might be used to provide a Device with a domain name. 258 While static configuration of the domain name can be used in 259 situations where device mobility is restricted, the appropriate LIS 260 depends on the network to which the host is attached, so that this is 261 not a general solution. 263 "Location Information Server (LIS) Discovery using IP address and 264 Reverse DNS" [I.D.ietf-geopriv-res-gw-lis-discovery] specifies a 265 means for a device to discover several alternative domain names that 266 can be used as input to the Dynamic Delegation Discovery Service 267 (DDDS). Since several of the techniques (such as use of PTR RRs and 268 Session Traversal Utilities for NAT (STUN) [RFC5389]) are potentially 269 implementable in WebRTC-based emergency services applications this 270 approach MAY be used. 272 3. Media Requirements 274 Within [RFC6881] media-related requirements are covered in Section 275 14. These include: 277 ED-71 Endpoints MUST send and receive media streams on RTP 278 [RFC3550]. 280 ED-72 Normal SIP offer/answer [RFC3264] negotiations MUST be used 281 to agree on the media streams to be used. 283 ED-73/SP-41 G.711 A law (and mu Law if they are intended be used 284 in North America) encoded voice as described in [RFC3551] MUST be 285 supported. If the endpoint cannot support G.711, a transcoder 286 MUST be used so that the offer received at the PSAP contains 287 G.711. It is desirable to include wideband codecs such as G.722 288 and AMR-WB in the offer. PSAPs SHOULD support narrowband codecs 289 common on endpoints in their area to avoid transcoding. 291 ED-74 Silence suppression (Voice Activity Detection methods) MUST 292 NOT be used on emergency calls. PSAP call takers sometimes get 293 information on what is happening in the background to determine 294 how to process the call. 296 ED-77 Endpoints supporting video MUST support H.264 per [RFC6184]. 298 Requirement ED-71 is satisfied by compliant WebRTC implementations 299 since "Web Real-Time Communication (WebRTC): Media Transport and Use 300 of RTP" [I-D.ietf-rtcweb-rtp-usage] Section 4.1 requires support for 301 RTP [RFC3550]. 303 Requirement ED-72 is specific to SIP and so does not apply generally 304 to WebRTC implementations, applications and services. However, it is 305 believed that the APIs under development within the W3C WebRTC WG can 306 support this requirement. 308 Requirement ED-74 is satisfied by compliant WebRTC implementations 309 since the WebRTC APIs under development within W3C [WEBRTC], support 310 silence suppression control via the "constraints" parameter. 312 [I.D.ietf-rtcweb-rtp-usage] Section 4.3 does not provide a 313 recommendation on a mandatory-to-implement set of codecs. While 314 ED-73 does not require implementation of G.711 if the service 315 supports transcoding, G.711 is not difficult to implement and is 316 widely supported, with a high level of interoperability. Therefore 317 it is recommended that G.711 be included as a mandatory-to-implement 318 audio codec within [I-D.ietf-rtcweb-rtp-usage] Section 4.3. 320 Currently the disposition of ED-77 is unclear. Discussion of 321 mandatory-to-implement video codecs is ongoing within the IETF RTCWEB 322 WG, but has not reached a conclusion. While there is a need to 323 support interoperable video within emergency services applications, 324 more options may be available within an emergency services context 325 than would be the case for general use. For example, within the 326 PSAP, it may be feasible to support multiple video codecs, either by 327 installation of browser plugins, or by use of multiple browsers. In 328 some emergency service applications (such as the VRS), codec 329 requirements may be specific to the service and may be satisfiable by 330 a custom device or browser approved for use with that service, which 331 may include the required codecs implemented natively or via plug-ins, 332 as the service provider sees fit. 334 4. Accessibility 336 By lowering the barriers to development of realtime-enabled browser 337 applications, as well as by building on accessibility support within 338 the browser, WebRTC promises to enable the development of a new 339 generation of accessible emergency applications and services. 341 In order to support accessibility, it is RECOMMENDED that WebRTC- 342 based emergency applications and services conform to the Web Content 343 Accessibility Guidelines (WCAG) v2.0 [WCAG]. 345 In order to support accessibility for individuals with hearing or 346 speech disabilities, support for textual communications is important. 348 Currently the W3C is developing a proposed charter for the Timed Text 349 Working Group [TTWG], which will potentially produce a second edition 350 of the timed Text Markup Language (TTML) 1.0 recommendation as well 351 as publishing a recommendation for a version 1.1 specification. 353 Text-related requirements in [RFC6881] are covered in Section 14, 354 including: 356 ED-75 Endpoints supporting Instant Messaging (IM) MUST support 357 either [RFC3428] and [RFC4975]. 359 ED-76 Endpoints supporting real-time text MUST use [RFC4103]. The 360 expectations for emergency service support for the real-time text 361 medium are described in [RFC5194], Section 7.1. 363 Since [RFC3428] and [RFC4975] are both based on SIP, ED-75 does not 364 apply to all WebRTC-based emergency applications and services. As 365 noted in "Emergency Services Functionality with the Extensible 366 Messaging and Presence Protocol (XMPP)" [I-D.tschofenig-ecrit-xmpp- 367 es], XMPP [RFC6120] is a potential alternative for emergency services 368 applications looking to support instant messaging [RFC6121] and 369 multi-user chat [XEP-045] functionality. 371 "RTP Payload for Text Conversation" [RFC4103] is typically 372 implemented along with SIP signaling as described in "Framework for 373 Real-Time Text over IP Using the Session Initiation Protocol (SIP)" 374 [RFC5194]. As a result, ED-76 does not apply to WebRTC 375 implementations. 377 Alternatives to support of real-time text functionality are 378 available, such as "In-Band Real Time Text" [XEP-0301], which 379 supports real-time text by addition of child elements within XMPP 380 message stanzas. The use of child elements to encapsulate real-time 381 text, as well as transmission of complete lines enables [XEP-0301] to 382 provide backward compatibility with existing XMPP instant-messaging 383 and Multi-User Chat (MUC) clients, with no changes required to XMPP 384 servers. Since XMPP can be encapsulated within HTTP via mechanisms 385 such as BOSH [XEP-0206] or WebSockets [RFC6455], [XEP-0301] can be 386 implemented in Javascript. Experience with Javascript implementation 387 using the [Strophe] XMPP library indicates that adequate performance 388 is achievable. In contrast, implementing real-time text as media as 389 in [RFC4103] requires native browser support, as well as requiring 390 changes to the configuration of intermediaries such as Session Border 391 Controllers (SBCs). Also, [RFC4103] is not backward compatible with 392 SIP instant messaging implementations supporting page-mode [RFC3428] 393 or session [RFC4975] approaches. 395 5. Security Considerations 397 Security requirements in [RFC6881] include: 399 ED-48/SP-24 TLS [RFC5746] MUST be used to protect location (but 400 see Section 9.1). All implementations MUST support TLS. 402 ED-58/SP-30 TLS is the primary mechanism used to secure the 403 signaling for emergency calls. IPsec [RFC4301] MAY be used 404 instead of TLS for any hop. Either TLS or IPSEC MUST be used when 405 attempting to signal an emergency call. 407 ED-59/SP-31 If TLS session establishment is not available, or 408 fails, the call MUST be retried without TLS. 410 ED-60/SP-32 [RFC5626] is RECOMMENDED to maintain persistent TLS 411 connections between entities when one of the entity is an 412 endpoint. Persistent TLS connection between proxies is 413 RECOMMENDED using any suitable mechanism. 415 ED-61/AN-28 TLS SHOULD be used when attempting to retrieve 416 location (configuration or dereferencing) with HELD. The use of 417 [RFC5077] is RECOMMENDED to minimize the time to establish TLS 418 sessions without keeping server-side state. IPsec MAY be used 419 instead of TLS. 421 ED-62/AN-29 When TLS session establishment fails, the location 422 retrieval MUST be retried without TLS. 424 For WebRTC, HTTPS MUST be used to protect signaling for an emergency 425 call, with potential fail-over to HTTP. HTTPS SHOULD be used to 426 protect location retrieval (HELD) and call routing (LoST). 428 WebRTC security considerations are discussed in "Security 429 Considerations for RTC-Web" [I-D.ietf-rtcweb-security]. The WebRTC 430 security architecture, described in "RTCWEB Security Architecture" 431 [I-D.ietf-rtcweb-security-arch], requires implementation of Secure 432 RTP [RFC3711] as well as DTLS/SRTP [RFC5764]. 434 While the security features of WebRTC exceed the requirements 435 outlined in [RFC6881], support for emergency services within WebRTC 436 raises concerns about potential attacks on the emergency services 437 infrastructure, given the potential for malicious code to be executed 438 within the browser. One way to lessen the likelihood of attacks by 439 untrusted Javascript applications is for PSAPs to put up their own 440 sites for emergency calling, protected by HTTPS. 442 While ICE [RFC5245] provides demonstration of liveness and consent to 443 receive, it is possible for an attacker to overwhelm the PSAP by 444 generating a large number of prank calls. IP relay services are also 445 potential targets since these don't require forging of Caller-Id nor 446 do they provide audio or video from the attacker. 448 Security threats to IP-based emergency services are described in 449 "Security Threats and Requirements for Emergency Call Marking and 450 Mapping" [RFC5069]. These include attacks on the emergency services 451 system, such as attempting to deny system services to all users in a 452 given area, to gain fraudulent use of services and to divert 453 emergency calls to non-emergency sites. [RFC5069] also describes 454 attacks against individuals, including attempts to prevent an 455 individual from receiving aid, or to gain information about an 456 emergency. 458 "Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats 459 against geographic location privacy, including protocol threats, 460 threats resulting from the storage of geographic location data, and 461 threats posed by the abuse of information. 463 Overall, experience indicates a relationship between anonymity and 464 the prevalence of prank calling. Therefore some protection may be 465 provided through authentication of the caller either in the signaling 466 or media plane. It is NOT RECOMMENDED that WebRTC-based emergency 467 applications and services support anonymous emergency calling. 469 6. IANA Considerations 471 This document does not require actions by IANA. 473 7. Acknowledgments 475 We would like to thank the members of the IETF RTCWEB Working Group 476 for discussions related to this topic. 478 8. References 480 8.1. Normative References 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 486 Communications Services in Support of Emergency Calling", 487 RFC 6881, March 2013. 489 [WCAG] Caldwell, B., Cooper, M., Reid, L.G. and G. Vanderheiden, 490 "Web Content Accessibility Guidelines (WCAG) 2.0", 491 http://www.w3.org/TR/WCAG20/, December 2008. 493 8.2. Informative References 495 [GeolocationAPI] 496 Popescu, A., "Geolocation API Specification", W3C, 497 http://dev.w3.org/geo/api/spec-source.html 499 [I.D.ietf-geopriv-res-gw-lis-discovery] 500 Thomson, M. and R. Bellis, "Location Information Server 501 (LIS) Discovery using IP address and Reverse DNS", draft- 502 ietf-geopriv-res-gw-lis-discovery-05 (work in progress), 503 April 2013. 505 [I-D.ietf-rtcweb-overview] 506 Alvestrand, H., "Overview: Real Time Protocols for Browser- 507 based Applications", draft-ietf-rtcweb-overview-06 (work in 508 progress), February 2013. 510 [I-D.ietf-rtcweb-rtp-usage] 511 Perkins, C., Westerlund, M. and J. Ott, "Web Real-Time 512 Communication (WebRTC): Media Transport and Use of RTP", 513 draft-ietf-rtcweb-rtp-usage-06 (work in progress), February 514 2013. 516 [I-D.ietf-rtcweb-security] 517 Rescorla, E., "Security Considerations for RTC-Web", draft- 518 ietf-rtcweb-security-04 (work in progress), January 2013. 520 [I-D.ietf-rtcweb-security-arch] 521 Rescorla, E., "RTCWEB Security Architecture", draft-ietf- 522 rtcweb-security-arch-06 (work in progress), July 2013. 524 [I-D.tschofenig-ecrit-xmpp-es] 525 Tschofenig. H., "Emergency Services Functionality with the 526 Extensible Messaging and Presence Protocol (XMPP)", draft- 527 tschofenig-ecrit-xmpp-es-00 (work in progress), March 2012. 529 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 530 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 531 Session Initiation Protocol", RFC 3261, June 2002. 533 [RFC3264] Rosenberg, J. and R. Schulzrinne, "An Offer/Answer Model 534 with the Session Description Protocol (SDP)", RFC 3264, June 535 2002. 537 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. 538 and D. Gurle, "Session Initiation Protocol (SIP) Extension 539 for Instant Messaging", RFC 3428, December 2002. 541 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 542 Jacobson, "RTP: A Transport Protocol for Real-Time 543 Applications", STD 64, RFC 3550, July 2003. 545 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 546 Video Conferences with Minimal Control", STD 65, RFC 3551, 547 July 2003. 549 [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, 550 "Threat Analysis of the Geopriv Protocol", RFC 3694, 551 February 2004. 553 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. 554 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 555 RFC 3711, March 2004. 557 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 558 Conversation", RFC 4103, June 2005. 560 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 561 Format", RFC 4119, December 2005. 563 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet 564 Protocol", RFC 4301, December 2005. 566 [RFC4975] Campbell, B., Mahy, R. and C. Jennings, "The Message Session 567 Relay Protocol (MSRP)", RFC 4975, September 2007. 569 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 570 Context Resolution with Internet Technologies", RFC 5012, 571 January 2008. 573 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. 574 Shanmugam, "Security Trheats and Requirements for Emergency 575 Call Marking and Mapping", RFC 5069, January 2008. 577 [RFC5077] Salowey, J., Zhou, H., Eronen, P. and H. Tschofenig, 578 "Transport Layer Security (TLS) Session Resumption without 579 Server-Side State", RFC 5077, January 2008. 581 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 582 Format for Presence Information Data Format Location Object 583 (PIDF-LO)", RFC 5139, February 2008. 585 [RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text 586 over IP Using the Session Initiation Protocol (SIP)", RFC 587 5194, June 2008. 589 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H. and H. Tschofenig, 590 "LoST: A Location-to-Service Translation Protocol", RFC 591 5222, August 2008. 593 [RFC5223] Schulzrinne, H., Polk, J. and H. Tschofenig, "Discovering 594 Location-to-Service Translation (LoST) Servers Using the 595 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 596 August 2008. 598 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 599 (ICE): A Protocol for Network Address Translator (NAT) 600 Traversal for Offer/Answer Protocols", RFC 5245, April 2010. 602 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 603 Traversal Utilities for NAT", RFC 5389, October 2008. 605 [RFC5626] Jennings, C., Mahy, R. and F. Audet, "Managing Client- 606 Initiated Connections in the Session Initiation Protocol 607 (SIP)", RFC 5626, October 2009. 609 [RFC5746] Rescorla, E., Ray, M., Dispensa, S. and N. Oskov, "Transport 610 Layer Security (TLS) Renegotiation Indication Extension", 611 RFC 5746, February 2010. 613 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 614 Security (DTLS) Extension to Establish Keys for the Secure 615 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 617 [RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 618 5985, September 2010. 620 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 621 Location Information Server (LIS)", RFC 5986, September 622 2010. 624 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol 625 (XMPP): Core", RFC 6120, March 2011. 627 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol 628 (XMPP): Instant Messaging and Presence", RFC 6121, March 629 2011. 631 [RFC6184] Wang, Y.-K., Even, R., Kristensen, T. and R. Jesup, "RTP 632 Payload Format for H.264 Video", RFC 6184, May 2011. 634 [RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance 635 for the Session Initiation Protocol", RFC 6442, December 636 2011. 638 [RFC6443] Rosen, B., Schulzrinne. H., Polk, J. and A. Newton, 639 "Framework for Emergency Calling Using Internet Multimedia", 640 RFC 6443, December 2011. 642 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 643 6455, December 2011. 645 [StateMLTS] "State E911 Legislation", 646 http://www1.911enable.com/resource-center/state- 647 e911-legislation 649 [Strophe] "Libraries for XMPP Poets", http://strophe.im 651 [TTWG] "Proposed Timed Text Working Group Charter", 652 http://www.w3.org/2012/02/timed-text-wg-charter.html 654 [WEBRTC] Bergkvist, A., Burnett, D., Jennings, C. and A. Narayanan, 655 "WebRTC 1.0: Real-time Communication Between Browsers", W3C 656 Editor's Draft (work in progress), 657 http://dev.w3.org/2011/webrtc/editor/webrtc.html, June 2013. 659 [WebTel] WebAPI/WebTelephony, 660 https://wiki.mozilla.org/WebAPI/WebTelephony 662 [XEP-0206] Paterson, I. and P. Saint-Andre, "XMPP Over BOSH", XEP-0206 663 version 1.3, http://xmpp.org/extensions/xep-0206.html, July 664 2010. 666 [XEP-0301] Rejhon, M., "In-Band Real Time Text", XEP-0301 version 0.2, 667 http://xmpp.org/extensions/xep-0301.html, March 2012. 669 [XEP-045] Saint-Andre, P., "Multi-User Chat", XEP 0045 version 1.25, 670 http://xmpp.org/extensions/xep-0045.html, February 2012. 672 Authors' Addresses 674 Bernard Aboba 675 Skype 676 Redmond, WA 98052 677 US 679 EMail: bernard_aboba@hotmail.com 681 Martin Thomson 682 Skype 683 3210 Porter Drive 684 Palo Alto, CA 94304 685 US 687 Phone: +1 650-353-1925 688 Email: martin.thomson@gmail.com