idnits 2.17.1 draft-holmberg-ecrit-emergency-callback-id-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5627]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (October 24, 2011) is 4561 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track October 24, 2011 5 Expires: April 26, 2012 7 Session Initiation Protocol (SIP) emergency call back identification 8 draft-holmberg-ecrit-emergency-callback-id-00.txt 10 Abstract 12 This specification define a new type of Globally Routable User Agent 13 URI (GRUU) [RFC5627], called emergency GRUU (eGRUU). When a User 14 Agent (UA) provides makes an emergency call, it can provide the eGRUU 15 to a PSAP, which can then use it to make a PSAP callback call. The 16 specification also defines a new URI parameter, "psapcb", which can 17 be used to indicate that a URI can be used for PSAP callback calls. 18 A registrar will provide the URI parameter as part of the generated 19 eGRUU value. Later, when a PSAP makes a PSAP callback call the URI, 20 including the "psapcb" URI parameter, can be used by SIP entities to 21 identity callback calls. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 26, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Applicability and Limitation . . . . . . . . . . . . . . . . . 3 60 4. Overview of operation . . . . . . . . . . . . . . . . . . . . 4 61 5. RFC 5627 Support . . . . . . . . . . . . . . . . . . . . . . . 4 62 6. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 5 63 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.2. Generating a REGISTER Request . . . . . . . . . . . . . . 5 65 6.3. Learning eGRUUs from REGISTER Responses . . . . . . . . . 6 66 6.4. Constructing a Self-Made eGRUU . . . . . . . . . . . . . . 6 67 6.5. Using One's Own eGRUU . . . . . . . . . . . . . . . . . . 6 68 6.5.1. Considerations for Multiple AORs . . . . . . . . . . . 7 69 6.6. Dereferencing an eGRUU . . . . . . . . . . . . . . . . . . 7 70 6.7. Rendering eGRUUs on a User Interface . . . . . . . . . . . 7 71 7. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . . 8 72 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7.2. Processing a REGISTER Request . . . . . . . . . . . . . . 8 74 7.3. Generating a REGISTER Response . . . . . . . . . . . . . . 8 75 7.4. Timing Out a Registration . . . . . . . . . . . . . . . . 8 76 7.5. Creation of an eGRUU . . . . . . . . . . . . . . . . . . . 9 77 7.6. Registration Event Support . . . . . . . . . . . . . . . . 9 78 7.7. PSAP callback call . . . . . . . . . . . . . . . . . . . . 9 79 8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 9.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 10. Message Flow Examples . . . . . . . . . . . . . . . . . . . . 10 83 10.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 12.2. Header Field Parameter . . . . . . . . . . . . . . . . . . 10 88 12.3. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 10 89 12.4. SIP option-tag . . . . . . . . . . . . . . . . . . . . . . 11 90 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 91 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 15.1. Normative References . . . . . . . . . . . . . . . . . . . 12 94 15.2. Informational References . . . . . . . . . . . . . . . . . 12 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 97 1. Introduction 99 EDITOR'S NOTE: We can probably add text from an existing draft here, 100 once we decide how to move forward documentation wise. 102 This specification define a new type of Globally Routable User Agent 103 URI (GRUU) [RFC5627], called emergency GRUU (eGRUU). When a User 104 Agent (UA) provides makes an emergnecy call, it can provide the eGRUU 105 to a PSAP, which can then use it to make a PSAP callback call. The 106 specification also defines a new URI parameter, "psapcb", which can 107 be used to indicate that a URI can be used for PSAP callback calls. 108 A registrar will provide the URI parameter as part of the generated 109 eGRUU value. Later, when a PSAP makes a PSAP callback call the URI, 110 including the "psapcb" URI parameter, can be used by SIP entities to 111 identity callback calls. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 The terms defined in RFC 5627 apply, with the following additional 120 terms defined in this specification: 122 Public Safety Answering Point (PSAP): A call center responsible for 123 answering calls to an emergency telephone number (referred to as 124 emergency call), and dispatching them to the appropriate emergency 125 services (e.g. police, firefighting or ambulance). 127 PSAP callback: A call made back from a PSAP to a user who previously 128 made an emergency call, in case the emergency call dropped, or the 129 PSAP needs additional information associated with the emergency call. 131 3. Applicability and Limitation 133 If a PSAP callback call comes from a Public Switched Telephony 134 Network (PSTN), or from another interworking network, the UAC 135 representing the PSAP will normally be located in a network 136 interworking gateway controller, such as a in a Media Gateway 137 Controller (MGC). The interworking gateway will normally not have 138 knowledge of the eGRUU, neither will it be able to determine that the 139 call is a PSAP callback call. 141 4. Overview of operation 143 The procedures defined in section 3 of RFC 5627 apply also to an 144 eGRUU, with the following limitations: 146 - An eGRUU MUST be constructed following the same principles and 147 rules that apply for constructing a public GRUU. 149 OPEN ISSUE: It still needs to be decided whether an eGRUU should be 150 constructed as a public GRUU, or whether a temporary GRUU is more 151 appropriate. 153 - A UA MUST obtain an eGRUU either as part of a REGISTER transaction, 154 or via some locally specified administrative mechanism. A UA MUST 155 NOT construct an eGRUU locally. 157 - A UA that wants to obtain an eGRUU via its REGISTER request MUST, 158 in addition to providingan instance ID in the "+sip.instance" Contact 159 header field parameter of the request, also include an "egruu" 160 option-tag in the Supported header field. 162 NOTE: The "egruu" option-tag will only request for an eGRUU. If a UA 163 also wants to obtain a gruu type defined in RFC 5627, it needs to 164 include an "gruu" option-tag in addition to the "egruu" option-tag. 166 - A UA, when not acting a PSAP, MUST NOT use an eGRUU in any other 167 requests than in an initial INVITE requests for a call that the UA 168 determines to be an emergency call. 170 - A UA, when acting a PSAP, MUST NOT use an eGRUU in any other 171 requests than in an initial INVITE requests for a PSAP callback call. 173 - A UA MUST NOT use the "psapcb" URI parameter in any other requests 174 than in an initial INVITE requests for a call that the UA determines 175 to be an emergency call. 177 - Unless a UA is acting as a PSAP, initiating a PSAP callback call, 178 it MUST NOT dereference an eGRUU. 180 5. RFC 5627 Support 182 An entity that requests, or generates, an eGRUU MUST support the 183 procedures defined in RFC 5627. However, the "egruu" option-tag only 184 requests an eGRUU. If a UA, in addtion to the eGRUU, also wants to 185 request a gruu type defined in 5627, it also needs to use the "gruu" 186 option-tag, as defined in RFC 5627. 188 The UA, registrar and proxy procedures in this specification are 189 based on the procedures defined in sections 4, 5 and 6 of RFC 5627, 190 with the deviations explicitly described. 192 6. User Agent Behavior 194 6.1. General 196 This section defines the normative behavior for user agents. 198 6.2. Generating a REGISTER Request 200 The general procedures, not associated with a specific type of GRUU, 201 in section 4.1 of RFC 5627 also apply to an eGRUU. 203 When a UA compliant to this specification generates a REGISTER 204 request (initial or refresh), it MUST include an "egruu" option-tag 205 in the Supported header field in the request. This informs the 206 registrar for the domain that the UA supports the eGRUU mechanism. 208 A UA MUST NOT insert an "emg-gruu" header field in the Contact header 209 field of a REGISTER request. 211 If the Call-ID changes in a register refresh, the server will 212 invalidate all eGRUUs associated with that UA instance; the only 213 valid one will be the new one returned in that REGISTER response. 214 When the mechanism defined in RFC 5626 [RFC5626] is used, this rule 215 applies to the reg-ids: If the Call-ID changes for the registration 216 refresh for a particular reg-id, the server will invalidate all 217 eGRUUs associated with that UA instance as a whole. Consequently, if 218 a UA wishes its previously obtained eGRUUs to remain valid, it MUST 219 utilize the same Call-ID in REGISTER refreshes. 221 A UA SHOULD NOT request a new eGRUU during the lifetime of a 222 registration, as the eGRUU might be used by an PSAP making a PSAP 223 callback call using the previous eGRUU value. However, it MAY change 224 the Call-ID in a refresh if invalidation is the desired objective. 226 If a UA wishes to guarantee that the REGISTER request is not 227 processed unless the domain supports and uses this extension, it MAY 228 include a Require header field in the request with a value that 229 contains the "egruu" option-tag. This is in addition to the presence 230 of the Supported header field, also containing the "egruu" option- 231 tag. The use of the Proxy-Require header field is not necessary and 232 is NOT RECOMMENDED. 234 6.3. Learning eGRUUs from REGISTER Responses 236 The general procedures, not associated with a specific type of GRUU, 237 in section 4.2 of RFC 5627 also apply to an eGRUU. 239 If the REGISTER response is a 2xx, each Contact header field that 240 contains the "+sip.instance" Contact header field parameter can also 241 contain an "emg-gruu" Contact header field parameter. This header 242 field parameter conveys the eGRUU for the UA instance. The eGRUU 243 will be valid for the duration of the registration (that is, through 244 refreshes). The UA can receive a new eGRUU in each successful 245 REGISTER response. If a UA changed its Call-ID in this REGISTER 246 request, or did not include an "egruu" option-tag in the Supported 247 header field, compared to a previous REGISTER request for the same 248 contact or reg-id, the UA MUST discard all eGRUUs learned through 249 prior REGISTER responses. A UA MAY retain zero, one, some, or all of 250 the eGRUUs that it is provided during the time over which at least 251 one contact or reg-id remains continuously registered. If a UA 252 stores any eGRUUs for use during its registration, it needs to be 253 certain that the registration does not accidentally lapse due to 254 clock skew between the UA and registrar. Consequently, the UA MUST 255 refresh its registration such that the REGISTER refresh transaction 256 will either complete or timeout prior to the expiration of the 257 registration. For default transaction timers, this would be at least 258 32 seconds prior to expiration, assuming the registration expiration 259 is larger than 64 seconds. If the registration expiration is less 260 than 64 seconds, the UA SHOULD refresh its registration halfway prior 261 to expiration. 263 Note that, when the mechanism defined in RFC 5626 is in use, and the 264 UA is utilizing multiple flows for purposes of redundancy, the eGRUUs 265 remain valid as long as at least one flow is registered. Thus, even 266 if the registration of one flow expires, the eGRUUs learned 267 previously remain valid. 269 The mechanism defined in RFC 3680 [RFC3680] and RFC 5628 [RFC5628]can 270 not be used for eGRUUs, as RFC 5628 does not define a mechanism for 271 conveying eGRUU information. 273 6.4. Constructing a Self-Made eGRUU 275 A UA MUST NOT construct a self-made eGRUU. 277 6.5. Using One's Own eGRUU 279 The procedures defined in section 4.4 of RFC 5627 apply also to an 280 eGRUU, with the limitations defined in this section. 282 When a UAC sends an initial SIP INVITE request [RFC3261] for an 283 emergency call, it MUST insert the eGRUU in the Contact header field 284 of the request. The UAC MUST use the same eGRUU value that it has 285 obtained for the registration associated with the emergency call. 287 OPEN ISSUE: It still needs to be decided whether a UA can use the 288 "psapcb" parameter if it does not support, or is able to retrieve, 289 eGRUU. 291 A UA MUST NOT insert an eGRUU in the Contact header field of a SIP 292 response, or in any other SIP request than an initial INVITE request 293 for calls that it determines as emergency calls. 295 NOTE: There might be cases where the UAC does not know that the call 296 it is establishing is an emergency call, and will therefor not 297 include an eGRUU in the initial SIP INVITE request for the call. In 298 some networks suchs calls will be determined as an emergency call by 299 the network. 301 6.5.1. Considerations for Multiple AORs 303 The procedures in section 4.4.1 of RFC 5627 also apply to an eGRUU. 305 6.6. Dereferencing an eGRUU 307 The procedures in section 4.5 of RFC 5627 also apply to an eGRUU. 309 When a UA, representing a PSAP, sends an initial SIP INVITE request 310 for an PSAP callback call, it MUST insert the eGRUU that it received 311 in the associated emergency call in the Request-URI [RFC3261] of the 312 request. 314 NOTE: If the Contact header field of an initial SIP INVITE request 315 for an emergency call did not contain a "psabcb" parameter, a UA, 316 representing a PSAP, can insert the "psapcb" parameter in the 317 Request-URI of the initial SIP INVITE request for an PSAP callback 318 call. 320 If a UA does not represent a PSAP, making a PSAP callback call, it 321 MUST NOT insert an eGRUU and a "psapcb" parameter in the Request-URI 322 of the intial SIP INVITE request for the call. 324 6.7. Rendering eGRUUs on a User Interface 326 An eGRUU MUST NOT be rendered to a user. The reasons is to prevent a 327 user from e.g. using the eGRUU for non-emergency calls. 329 7. Registrar Behavior 331 7.1. General 333 This section defines the normative behavior for registrars. 335 7.2. Processing a REGISTER Request 337 A REGISTER request might contain a Require header field with an 338 "egruu" option-tag; this indicates that the registrar has to 339 understand the eGRUU extension in order to process the request. It 340 does not require the registrar to create an eGRUU, however. 342 Next, the registrar MUST check the Contact header fields, and compare 343 the contact URIs with the AOR, as defined in section 5.1 of RFC 5627. 345 Next, the registrar MUST create a new eGRUU for the AOR and instance, 346 according to the procedures in section 7.5 of this specification. 348 If the contact contained a "emg-gruu" Contact header field parameter, 349 the header field parameter MUST be ignored by the registrar. A UA 350 cannot suggest or otherwise provide an eGRUU to the registrar. 352 7.3. Generating a REGISTER Response 354 When generating the 200 (OK) response to the REGISTER request, the 355 procedures of step 8 of Section 10.3 of RFC 3261 are followed. 356 Furthermore, the registrar includes the instance ID in the Contact 357 header field, as defined in section 5.2 of RFC 5627. 359 If the REGISTER request contained a Supported header field that with 360 an "egruu" option-tag, and the registrar has an eGRUU assigned to the 361 instance ID and AOR, the registrar MUST add an "emg-gruu" Contact 362 header field parameter to that Contact header field. The value of 363 the "emg-gruu" header field parameter MUST contain and MUST contain 364 the most recently created eGRUU for that AOR and instance ID. 366 The registrar MUST NOT include an "egruu" option-tag in the Require 367 or Supported header field of the response. 369 7.4. Timing Out a Registration 371 The procedures in section 5.3 of RFC 5627 that apply to public gruus 372 also apply to an eGRUU. 374 7.5. Creation of an eGRUU 376 The procedures in section 5.4 of RFC 5627 that apply to public gruus 377 also apply to an eGRUU, with the following addition: 379 The eGRUU value MUST contain a SIP-URI [RFC3261], which includes a 380 "psapcb" SIP-URI parameter. 382 7.6. Registration Event Support 384 The procedures defined in section 5.5 of RFC 5627 also apply to an 385 eGRUU. 387 7.7. PSAP callback call 389 When a registrar receives an initial SIP INVITE request for a call, 390 and the Request-URI of the request contains an eGRUU (including a 391 "psapcb" parameter) that the registrar has previously assigned to the 392 called user, the registrar can decide that the call is a PSAP 393 callback call. 395 NOTE: A registrar might give special treatment to a call identified 396 as a PSAP callback call. Such treatment is outside the scope of this 397 specification. 399 8. Proxy Behavior 401 The procedures defined in section 6 of RFC 5627 also apply to an 402 eGRUU. 404 9. Grammar 406 9.1. ABNF 408 This specification defines a new Contact header field parameter, 409 "emg-gruu", by extending the grammar for "contact-params" as defined 410 in RFC 3261. It also defines a new URI parameter, "psapcb", by 411 extending the grammar for "uri-parameter" as defined in RFC 3261. 412 The ABNF [RFC5234] is as follows: 414 contact-params =/ emg-gruu 416 emg-gruu = "emg-gruu" EQUAL quoted-string 418 uri-parameter =/ psap-callback-parameter 419 psap-callback-parameter = "psapcb" 421 10. Message Flow Examples 423 10.1. Example 425 TBD 427 Add example flow 429 Figure 1: Example call flow 431 11. Security Considerations 433 The security considerations defined in RFC 5627 also apply to eGRUUs. 435 12. IANA Considerations 437 12.1. General 439 This specification defines a new Contact header field parameter, a 440 new and URI parameter, and a new SIP option-tag. 442 12.2. Header Field Parameter 444 This specification defines a new header field parameter, as per the 445 registry created by RFC 3968 [RFC3968]. The required information is 446 as follows: 448 Header field in which the parameter can appear: Contact 449 Name of the Parameter: emg-gruu 450 Predefined Values: none 451 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace 452 XXXX with the RFC number of this specification]] 454 12.3. URI Parameter 456 This specification defines a new SIP URI parameter, as per the 457 registry created by RFC 3968 [RFC3968]. The required information is 458 as follows: 460 Name of the Parameter: psapcb 461 Predefined Values: none 462 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace 463 XXXX with the RFC number of this specification]] 465 12.4. SIP option-tag 467 This specification registers a new SIP option tag, as per the 468 guidelines in Section 27.1 of RFC 3261 [RFC3261]. The required 469 information is as follows: 471 Name: egruu 473 Description: This option-tag is used to identify the 474 emergency Globally Routable User Agent URI (eGRUU) 475 extension. When used in a Supported header, it 476 indicates that a User Agent understands the 477 extension. When used in a Require header field 478 of a REGISTER request, it indicates that the 479 registrar is not expected to process the 480 registration unless it supports the eGRUU 481 extension. 483 13. Acknowledgements 485 The original idea of using a token based mechanism to associate PSAP 486 callback calls with emergency calls was presented by Cullen Jennings. 488 Thanks to Fredrik Lindholm, Jan Holm and Ivo Sedlacek for their 489 comments and feedbacks on the initial draft. 491 Thanks to everyone who took part, and provided input and feedback, in 492 the discussions at the IETF#81 meeting. 494 14. Change Log 496 [RFC EDITOR NOTE: Please remove this section when publishing] 498 Changes from draft-holmberg-ecrit-callback-00 499 o Draft file name changed to 500 draft-holmberg-ecrit-emergency-callback-id. 501 o New type of GRUU, instead of a feature tag, is used as callback 502 identifier. 504 15. References 505 15.1. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 511 A., Peterson, J., Sparks, R., Handley, M., and E. 512 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 513 June 2002. 515 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 516 (IANA) Header Field Parameter Registry for the Session 517 Initiation Protocol (SIP)", BCP 98, RFC 3968, 518 December 2004. 520 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 521 Specifications: ABNF", STD 68, RFC 5234, January 2008. 523 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 524 Agent URIs (GRUUs) in the Session Initiation Protocol 525 (SIP)", RFC 5627, October 2009. 527 15.2. Informational References 529 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 530 Package for Registrations", RFC 3680, March 2004. 532 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 533 Initiated Connections in the Session Initiation Protocol 534 (SIP)", RFC 5626, October 2009. 536 [RFC5628] Kyzivat, P., "Registration Event Package Extension for 537 Session Initiation Protocol (SIP) Globally Routable User 538 Agent URIs (GRUUs)", RFC 5628, October 2009. 540 Author's Address 542 Christer Holmberg 543 Ericsson 544 Hirsalantie 11 545 Jorvas 02420 546 Finland 548 Email: christer.holmberg@ericsson.com