idnits 2.17.00 (12 Aug 2021) /tmp/idnits24771/draft-ietf-ecrit-psap-callback-08.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 25, 2013) is 3371 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3966' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'RFC3969' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC4484' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'RFC5031' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 650, but no explicit reference was found in the text == Outdated reference: draft-ietf-sipcore-priority has been published as RFC 6878 ** Downref: Normative reference to an Informational RFC: RFC 3325 ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Schulzrinne 3 Internet-Draft Columbia University 4 Intended status: Standards Track H. Tschofenig 5 Expires: August 29, 2013 Nokia Siemens Networks 6 C. Holmberg 7 Ericsson 8 M. Patel 9 InterDigital Communications 10 February 25, 2013 12 Public Safety Answering Point (PSAP) Callback 13 draft-ietf-ecrit-psap-callback-08.txt 15 Abstract 17 After an emergency call is completed (either prematurely terminated 18 by the emergency caller or normally by the call taker) it is possible 19 that the call taker feels the need for further communication. For 20 example, the call may have been dropped by accident without the call 21 taker having sufficient information about the current situation of a 22 wounded person. A call taker may trigger a callback towards the 23 emergency caller using the contact information provided with the 24 initial emergency call. This callback could, under certain 25 circumstances, be treated like any other call and as a consequence it 26 may get blocked by authorization policies or may get forwarded to an 27 answering machine. 29 The IETF emergency services architecture specification already offers 30 a solution approach for allowing PSAP callbacks to bypass 31 authorization policies to reach the caller without unnecessary 32 delays. Unfortunately, the specified mechanism only supports limited 33 scenarios. This document discusses shortcomings of the current 34 mechanisms and illustrates additional scenarios where better-than- 35 normal call treatment behavior would be desirable. A solution based 36 on a new header field value, called "psap-callback", for the SIP 37 Priority header field is specified to accomplish the PSAP callback 38 marking. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on August 29, 2013. 57 Copyright Notice 59 Copyright (c) 2013 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Callback Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 77 3.1. Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 6 78 3.2. Multi-Stage Routing . . . . . . . . . . . . . . . . . . . 7 79 3.3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 8 80 3.4. Network-based Service URN Resolution . . . . . . . . . . . 10 81 3.5. PSTN Interworking . . . . . . . . . . . . . . . . . . . . 11 82 4. SIP PSAP Callback Indicator . . . . . . . . . . . . . . . . . 12 83 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 4.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 12 87 4.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 5.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 13 90 5.2. Security Requirements . . . . . . . . . . . . . . . . . . 13 91 5.3. Security Solution . . . . . . . . . . . . . . . . . . . . 13 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 98 1. Introduction 100 Summoning police, the fire department or an ambulance in emergencies 101 is one of the fundamental and most-valued functions of the telephone. 102 As telephone functionality moves from circuit-switched telephony to 103 Internet telephony, its users rightfully expect that this core 104 functionality will continue to work at least as well as it has for 105 the legacy technology. New devices and services are being made 106 available that could be used to make a request for help, which are 107 not traditional telephones, and users are increasingly expecting them 108 to be used to place emergency calls. 110 An overview of the protocol interactions for emergency calling using 111 the IETF emergency services architecture are described in [RFC6444] 112 and [I-D.ietf-ecrit-phonebcp] specifies the technical details. As 113 part of the emergency call setup procedure two important identifiers 114 are conveyed to the PSAP call taker's user agent, namely the Address- 115 Of-Record (AoR), and, if available, the Globally Routable User Agent 116 (UA) URIs (GRUU). RFC 3261 [RFC3261] defines the AoR as: 118 'An address-of-record (AOR) is a SIP or SIPS URI that points to a 119 domain with a location service that can map the URI to another URI 120 where the user might be available. Typically, the location 121 service is populated through registrations. An AOR is frequently 122 thought of as the "public address" of the user.' 124 In SIP systems a single user can have a number of user agents 125 (handsets, softphones, voicemail accounts, etc.) which are all 126 referenced by the same AOR. There are a number of cases in which it 127 is desirable to have an identifier which addresses a single user 128 agent rather than the group of user agents indicated by an AOR. The 129 GRUU is such a unique user- agent identifier, which is still globally 130 routable. RFC 5627 [RFC5627] specifies how to obtain and use GRUUs. 131 [I-D.ietf-ecrit-phonebcp] also makes use of the GRUU for emergency 132 calls. 134 Regulatory requirements demand that the emergency call setup 135 procedure itself provides enough information to allow the call taker 136 to initiate a call back to the emergency caller. This is desirable 137 in those cases where the call got dropped prematurely or when further 138 communication need arises. The AoR and the GRUU serve this purpose. 140 The communication attempt by the PSAP call taker back to the 141 emergency caller is called 'PSAP callback'. 143 A PSAP callback may, however, be blocked by user configured 144 authorization policies or may be forwarded to an answering machine 145 since SIP entities (SIP proxies as well as the SIP user equipment 146 itself) cannot differentiate the PSAP callback from any other SIP 147 call. "Call barring", "do not disturb", or "call diversion"(aka call 148 forwarding) are features that prevent delivery of a call. It is 149 important to note that these features may be implemented by SIP 150 intermediaries as well as by the user agent. 152 Among the emergency services community there is the desire to offer 153 PSAP callbacks a treatment such that chances are increased that it 154 reaches the emergency caller. At the same time a design must deal 155 with the negative side-effects of allowing certain calls to bypass 156 call forwarding or other authorization policies. Ideally, the PSAP 157 callback has to relate to an earlier emergency call that was made 158 "not too long ago". An exact time interval is difficult to define in 159 a global IETF standard due to the variety of national regulatory 160 requirements. 162 To nevertheless meet the needs from the emergency services community 163 a basic mechanism for preferential treatment of PSAP callbacks was 164 defined in Section 13 of [RFC6444]. The specification says: 166 'A UA may be able to determine a PSAP call back by examining the 167 domain of incoming calls after placing an emergency call and 168 comparing that to the domain of the answering PSAP from the 169 emergency call. Any call from the same domain and directed to the 170 supplied Contact header or AoR after an emergency call should be 171 accepted as a callback from the PSAP if it occurs within a 172 reasonable time after an emergency call was placed.' 174 This approach mimics a stateful packet filtering firewall and is 175 indeed helpful in a number of cases. It is also relatively simple to 176 implement even though it requires state to be maintained by the user 177 agent as well as by SIP intermediaries. Unfortunately, the solution 178 does not work in all deployment scenarios. In Section 3 we describe 179 cases where the currently standardized approach is insufficient. 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 Emergency services related terminology is borrowed from [RFC5012]. 188 This includes terminology like emergency caller, user equipment, and 189 call taker. 191 3. Callback Scenarios 193 This section illustrates a number of scenarios where the currently 194 specified solution, as specified in [I-D.ietf-ecrit-phonebcp], for 195 preferential treatment of callbacks fails. As explained in Section 1 196 a SIP entity examines an incoming PSAP call back by comparing the 197 domain of the PSAP with the destination domain of the emergency call. 199 3.1. Routing Asymmetry 201 In some deployment environments it is common to have incoming and 202 outgoing SIP messaging routed through different SIP entities. 203 Figure 1 shows this graphically whereby a VoIP provider uses 204 different SIP proxies for inbound and for outbound call handling. 205 Unless they two devices are state synchronized the callback hitting 206 the inbound proxy would get treated like any other call since the 207 emergency call established state information at the outbound proxy 208 only. 210 ,-------. 211 ,' `. 212 ,-------. / Emergency \ 213 ,' `. | Services | 214 / VoIP \ I | Network | 215 | Provider | n | | 216 | | t | | 217 | | e | | 218 | +-------+ | r | | 219 +--+---|Inbound|<--+-----m | | 220 | | |Proxy | | e | +------+ | 221 | | +-------+ | d | |PSAP | | 222 | | | i | +--+---+ | 223 +----+ | | | a-+ | | | 224 | UA |<---+ | | t | | | | 225 | |----+ | | e | | | | 226 +----+ | | | | | | | 227 | | | P | | | | 228 | | | r | | | | 229 | | +--------+ | o | | | | 230 +--+-->|Outbound|--+---->v | | +--+---+ | 231 | |Proxy | | i | | +-+ESRP | | 232 | +--------+ | d | | | +------+ | 233 | | e || | | 234 | | r |+-+ | 235 \ / | | 236 `. ,' \ / 237 '-------' `. ,' 238 '-------' 240 Figure 1: Example for Routing Asymmetry 242 3.2. Multi-Stage Routing 244 Consider the following emergency call routing scenario shown in 245 Figure 2 where routing towards the PSAP occurs in several stages. In 246 this scenario we consider a SIP UA that uses LoST to learn the next 247 hop destination closer to the PSAP. This call is then sent to the 248 user's VoIP provider. The user's VoIP provider receives the 249 emergency call and creates state based on the destination domain, 250 namely state.com. It then routes it to the indicated ESRP. When the 251 ESRP receives it it needs to decide what the next hop is to get it 252 closer to the PSAP. In our example the next hop is the PSAP with the 253 URI psap@town.com. 255 When a callback is sent from psap@town.com towards the emergency 256 caller the call will get normal treatment by the VoIP providers 257 inbound proxy since the domain of the PSAP does not match the stored 258 state information. 260 ,-------. 261 +----+ ,' `. 262 | UA |--- esrp1@foobar.com / Emergency \ 263 +----+ \ | Services | 264 \ ,-------. | Network | 265 ,' `. | | 266 / VoIP \ | +------+ | 267 ( Provider ) | |PSAP | | 268 \ / | +--+---+ | 269 `. ,' | | 270 '---+---' | | | 271 | |psap@town.com | 272 esrp@state.com | | | 273 | | | | 274 | | | | 275 | | +--+---+ | 276 +------------+---+ESRP | | 277 | +------+ | 278 | | 279 \ / 280 `. ,' 281 '-------' 283 Figure 2: Example for Multi-Stage Routing 285 3.3. Call Forwarding 287 Imagine the following case where an emergency call enters an 288 emergency network (state.org) via an ERSP but then gets forwarded to 289 a different emergency services network (in our example to police- 290 town.org, fire-town.org or medic-town.org). The same considerations 291 apply when the police, fire and ambulance networks are part of the 292 state.org sub-domains (e.g., police.state.org). 294 Similarly to the previous scenario the problem here is with the wrong 295 state information being established during the emergency call setup 296 procedure. A callback would originate in the police-town.org, fire- 297 town.org or medic-town.org domain whereas the emergency caller's SIP 298 UA or the VoIP outbound proxy has stored state.org. 300 ,-------. 301 ,' `. 302 / Emergency \ 303 | Services | 304 | Network | 305 | (state.org) | 306 | | 307 | | 308 | +------+ | 309 | |PSAP +--+ | 310 | +--+---+ | | 311 | | | | 312 | | | | 313 | | | | 314 | | | | 315 | | | | 316 | +--+---+ | | 317 ------------------+---+ESRP | | | 318 esrp-a@state.org | +------+ | | 319 | | | 320 | Call Fwd | | 321 | +-+-+---+ | 322 \ | | | / 323 `. | | | ,' 324 '-|-|-|-' ,-------. 325 Police | | | Fire ,' `. 326 +------------+ | +----+ / Emergency \ 327 ,-------. | | | | Services | 328 ,' `. | | | | Network | 329 / Emergency \ | Ambulance | | fire-town.org | 330 | Services | | | | | | 331 | Network | | +----+ | | +------+ | 332 |police-town.org| | ,-------. | +----+---+PSAP | | 333 | | | ,' `. | | +------+ | 334 | +------+ | | / Emergency \ | | | 335 | |PSAP +----+--+ | Services | | | , 336 | +------+ | | Network | | `~~~~~~~~~~~~~~~ 337 | | |medic-town.org | | 338 | , | | | 339 `~~~~~~~~~~~~~~~ | +------+ | | 340 | |PSAP +----+ + 341 | +------+ | 342 | | 343 | , 344 `~~~~~~~~~~~~~~~ 346 Figure 3: Example for Call Forwarding 348 3.4. Network-based Service URN Resolution 350 The IETF emergency services architecture also considers cases where 351 the resolution from the Service URN to the PSAP URI does not only 352 happen at the SIP UA itself but at intermediate SIP entities, such as 353 the user's VoIP provider. 355 Figure 4 shows this message exchange of the outgoing emergency call 356 and the incoming PSAP graphically. While the state information 357 stored at the VoIP provider is correct the state allocated at the SIP 358 UA is not. 360 ,-------. 361 ,' `. 362 / Emergency \ 363 | Services | 364 | Network | 365 |police-town.org| 366 | | 367 | +------+ | Invite to police.example.com 368 | |PSAP +<---+------------------------+ 369 | | +----+------------------+ ^ 370 | +------+ |Invite from | | 371 | ,police.example.com| | 372 `~~~~~~~~~~~~~~~ v | 373 +--------+ ++-----+-+ 374 | | query |VoIP | 375 | LoST |<-----------------------|Service | 376 | Server | police.example.com |Provider| 377 | |----------------------->| | 378 +--------+ +--------+ 379 | ^ 380 Invite| | Invite 381 from| | to 382 police.example.com| | urn:service:sos 383 V | 384 +-------+ 385 | SIP | 386 | UA | 387 | Alice | 388 +-------+ 390 Figure 4: Example for Network-based Service URN Resolution 392 3.5. PSTN Interworking 394 In case an emergency call enters the PSTN, as shown in Figure 5, 395 there is no guarantee that the callback some time later does leave 396 the same PSTN/VoIP gateway or that the same end point identifier is 397 used in the forward as well as in the backward direction making it 398 difficult to reliably detect PSAP callbacks. 400 +-----------+ 401 | PSTN |-------------+ 402 | Calltaker | | 403 | Bob |<--------+ | 404 +-----------+ | v 405 ------------------- 406 //// \\\\ +------------+ 407 | | |PSTN / VoIP | 408 | PSTN |---->|Gateway | 409 \\\\ //// | | 410 ------------------- +----+-------+ 411 ^ | 412 | | 413 +-------------+ | +--------+ 414 | | | |VoIP | 415 | PSTN / VoIP | +->|Service | 416 | Gateway | |Provider| 417 | |<------Invite----| Y | 418 +-------------+ +--------+ 419 | ^ 420 | | 421 Invite Invite 422 | | 423 V | 424 +-------+ 425 | SIP | 426 | UA | 427 | Alice | 428 +-------+ 430 Figure 5: Example for PSTN Interworking 432 Note: This scenario is considered outside the scope of this document. 433 The specified solution does not support this use case. 435 4. SIP PSAP Callback Indicator 437 4.1. General 439 This section defines a new header field value, called "psap- 440 callback", for the SIP Priority header field defined in [RFC3261]. 441 The value is used to inform SIP entities that the request is 442 associated with a PSAP callback SIP session. 444 4.2. Usage 446 SIP entities that receive the header field value within an initial 447 request for a SIP session can, depending on local policies, apply 448 PSAP callback specific procedures for the session or request. 450 The PSAP callback specific procedures may be applied by SIP-based 451 network entities and by the callee. The specific procedures taken 452 when receiving such a PSAP callback marked call, such as bypassing 453 services and barring procedures, are outside the scope of this 454 document. 456 4.3. Syntax 458 4.3.1. General 460 This section defines the ABNF for the new SIP Priority header field 461 value "psap-callback". 463 4.3.2. ABNF 465 priority-value /= "psap-callback" 467 Figure 6: ABNF 469 5. Security Considerations 471 5.1. Security Threat 473 The PSAP callback functionality described in this document allows 474 marked calls to bypass blacklists, ignore call forwarding procedures 475 and similar features to contact emergency callers and to raise their 476 attention. Regarding the latter aspect a callback, if understood by 477 the SIP UA would allow to override user interface configurations, 478 such as vibrate-only mode, to alert the caller of the incoming call. 480 5.2. Security Requirements 482 The requirement is to ensure that the mechanisms described in this 483 document can not be used for malicious purposes, including 484 telemarketing. 486 Furthermore, if the newly defined extension is not recognized, not 487 verified adequately, or not obeyed by SIP intermediaries or SIP 488 endpoints then it must not lead to a failure of the call handling 489 procedure. Such call must be treated like a call that does not have 490 any marking attached. 492 5.3. Security Solution 494 Figure 7 shows the architecture that utilizes the identity of the 495 PSAP to decide whether a preferential treatment of callbacks should 496 be provided. To make this policy decision the identity of the PSAP 497 is compared with a whitelist of valid PSAPs available to the SIP 498 entity. The identity assurance in SIP can come in different forms, 499 such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325]. 500 The former technique relies on a cryptographic assurance and the 501 latter on a chain of trust. Also the usage of TLS between 502 neighboring SIP entities may provide useful identity information. 504 +----------+ 505 | List of |+ 506 | valid || 507 | PSAPs || 508 +----------+| 509 +----------+ 510 * 511 * whitelist 512 * 513 V 514 Incoming +----------+ Normal 515 SIP Msg | SIP |+ Treatment 516 -------------->| Entity ||======================> 517 + Identity | ||(if not in whitelist) 518 Info +----------+| 519 +----------+ 520 || 521 || 522 || Preferential 523 || Treatment 524 ++========================> 525 (if successfully verified) 527 Figure 7: Identity-based Authorization 529 An important aspect from a security point of view is the relationship 530 between the emergency services network (containing PSAPs) and the VSP 531 (assuming that the emergency call travels via the VSP and not 532 directly between the SIP UA and the PSAP). 534 If there is some form of relationship between the emergency services 535 operator and the VSP then the identification of a PSAP call back is 536 less problematic than in the case where the two entities have not 537 entered in some form of relationship that would allow the VSP to 538 verify whether the marked callback message indeed came from a 539 legitimate source. 541 The establishment of a whitelist with PSAP identities maybe be 542 operationally complex. When there is a local relationship between 543 the VSP/ASP and the PSAP then populating the whitelist is fairly 544 simple. For SIP UAs there is no need to maintain a list of PSAPs. 545 Instead SIP UAs are assumed to trust the correct processing of their 546 VSP/ASP, i.e., the VSP/ASP processes the PSAP callback marking and, 547 if it cannot be verified, the PSAP callback marking is removed. If 548 it is left untouched then the SIP UA should assume that it has been 549 verified successfully by the VSP/ASP and it should therefore be 550 obeyed. 552 6. IANA Considerations 554 This document adds the "psap-callback" value to the SIP Priority 555 header IANA registry allocated by [I-D.ietf-sipcore-priority]. The 556 semantic of the newly defined "psap-callback" value is defined in 557 Section 4. 559 7. Acknowledgements 561 We would like to thank members from the ECRIT working group, in 562 particular Brian Rosen, for their discussions around PSAP callbacks. 563 The working group discussed the topic of callbacks at their virtual 564 interim meeting in February 2010 and the following persons provided 565 valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith 566 Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson, 567 Janet Gunn. 569 At IETF#81 a small group of people got to together to continue the 570 discussions started at the working group meeting to explore a GRUU- 571 based solution approach. Martin Thomson, Marc Linsner, Andrew Allen, 572 Brian Rosen, Martin Dolly, and Atle Monrad participated at this side- 573 meeting. 575 We would like to thank the following persons for their feedback on 576 the solution discussion in 2012: Paul Kyzivat, Martin Thomson, Robert 577 Sparks, Keith Drage, Brian Rosen, Roger Marshall, Martin Dolly, 578 Bernard Aboba, Andrew Allen, John-Luc Bakker, James Polk, John 579 Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight, Janet Gunn 581 8. References 583 8.1. Normative References 585 [I-D.ietf-sipcore-priority] Roach, A., "IANA Registry for the 586 Session Initiation Protocol (SIP) 587 "Priority" Header Field", 588 draft-ietf-sipcore-priority-00 (work in 589 progress), December 2012. 591 [RFC2119] Bradner, S., "Key words for use in RFCs 592 to Indicate Requirement Levels", BCP 14, 593 RFC 2119, March 1997. 595 [RFC3261] Rosenberg, J., Schulzrinne, H., 596 Camarillo, G., Johnston, A., Peterson, 597 J., Sparks, R., Handley, M., and E. 598 Schooler, "SIP: Session Initiation 599 Protocol", RFC 3261, June 2002. 601 [RFC3325] Jennings, C., Peterson, J., and M. 602 Watson, "Private Extensions to the 603 Session Initiation Protocol (SIP) for 604 Asserted Identity within Trusted 605 Networks", RFC 3325, November 2002. 607 [RFC3966] Schulzrinne, H., "The tel URI for 608 Telephone Numbers", RFC 3966, 609 December 2004. 611 [RFC3969] Camarillo, G., "The Internet Assigned 612 Number Authority (IANA) Uniform Resource 613 Identifier (URI) Parameter Registry for 614 the Session Initiation Protocol (SIP)", 615 BCP 99, RFC 3969, December 2004. 617 [RFC4474] Peterson, J. and C. Jennings, 618 "Enhancements for Authenticated Identity 619 Management in the Session Initiation 620 Protocol (SIP)", RFC 4474, August 2006. 622 [RFC5627] Rosenberg, J., "Obtaining and Using 623 Globally Routable User Agent URIs 624 (GRUUs) in the Session Initiation 625 Protocol (SIP)", RFC 5627, October 2009. 627 8.2. Informative References 629 [I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best Current 630 Practice for Communications Services in 631 support of Emergency Calling", 632 draft-ietf-ecrit-phonebcp-20 (work in 633 progress), September 2011. 635 [RFC4484] Peterson, J., Polk, J., Sicker, D., and 636 H. Tschofenig, "Trait-Based 637 Authorization Requirements for the 638 Session Initiation Protocol (SIP)", 639 RFC 4484, August 2006. 641 [RFC5012] Schulzrinne, H. and R. Marshall, 642 "Requirements for Emergency Context 643 Resolution with Internet Technologies", 644 RFC 5012, January 2008. 646 [RFC5031] Schulzrinne, H., "A Uniform Resource 647 Name (URN) for Emergency and Other Well- 648 Known Services", RFC 5031, January 2008. 650 [RFC5234] Crocker, D. and P. Overell, "Augmented 651 BNF for Syntax Specifications: ABNF", 652 STD 68, RFC 5234, January 2008. 654 [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, 655 H., Stark, B., and A. Kuett, "Location 656 Hiding: Problem Statement and 657 Requirements", RFC 6444, January 2012. 659 Authors' Addresses 661 Henning Schulzrinne 662 Columbia University 663 Department of Computer Science 664 450 Computer Science Building 665 New York, NY 10027 666 US 668 Phone: +1 212 939 7004 669 EMail: hgs+ecrit@cs.columbia.edu 670 URI: http://www.cs.columbia.edu 672 Hannes Tschofenig 673 Nokia Siemens Networks 674 Linnoitustie 6 675 Espoo 02600 676 Finland 678 Phone: +358 (50) 4871445 679 EMail: Hannes.Tschofenig@gmx.net 680 URI: http://www.tschofenig.priv.at 682 Christer Holmberg 683 Ericsson 684 Hirsalantie 11 685 Jorvas 02420 686 Finland 688 EMail: christer.holmberg@ericsson.com 690 Milan Patel 691 InterDigital Communications 693 EMail: Milan.Patel@interdigital.com