idnits 2.17.00 (12 Aug 2021) /tmp/idnits59399/draft-patel-ecrit-sos-parameter-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2010) is 4477 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) == Missing Reference: 'RFCXXXX' is mentioned on line 268, but not defined == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT Working Group M. Patel 3 Internet-Draft InterDigital Communications 4 Intended status: Standards Track February 15, 2010 5 Expires: August 19, 2010 7 SOS Uniform Resource Identifier (URI) Parameter for Marking of Session 8 Initiation Protocol (SIP) Requests related to Emergency Services 9 draft-patel-ecrit-sos-parameter-08.txt 11 Abstract 13 This document defines a new Session Initiation Protocol (SIP) Uniform 14 Resource Identifier (URI) parameter intended for marking SIP 15 registration requests related to emergency services. The URI 16 parameter is extensible to allow future values to be defined if 17 required by other use cases that require specific SIP registrations 18 to be distinctly identified. The usage of this new URI parameter 19 complements the usage of the Service Uniform Resource Name (URN) and 20 is not intended to replace it. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on August 19, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. The "reg-type" URI Parameter . . . . . . . . . . . . . . . . . 4 66 4.1. REGISTER Request . . . . . . . . . . . . . . . . . . . . . 5 67 4.2. 2xx Response to REGISTER Request . . . . . . . . . . . . . 5 68 4.3. Backwards compatibility issues . . . . . . . . . . . . . . 5 69 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 One way to differentiate a SIP-based emergency call from an ordinary 81 call is by the presence of the Service URN as defined in RFC 5031 82 [RFC5031] (and used in the IETF emergency services architecture 83 described in PhoneBCP[I-D.ietf-ecrit-phonebcp]). The 3GPP IP 84 Multimedia Subsystem (IMS) emergency services architecture, 85 illustrated in 3GPP TS 23.167 [3GPP.23.167], specifies that the User 86 Equipment (UE) performs emergency registration prior to or during the 87 initiation of an emergency call. The circumstances where such an 88 emergency registration is beneficial are listed below: 90 - the UE is not registered with its home network; 92 - the UE is currently registered but roaming (to ensure that the 93 emergency call is handled in the visited network, as required by some 94 jurisdictions). 96 Emergency registration is possible only when the UE has sufficient 97 credentials to register with its home network and can detect that an 98 emergency session is initiated. Unfortunately, marking of the 99 emergency registration cannot be fulfilled by the use of the Service 100 URN. 102 In some countries, it is a regulatory requirement that devices be 103 able to place emergency calls in circumstances where other calls may 104 not be permitted. When a UAC issues an emergency marked REGISTER 105 request it informs the registrar that the contact address and the 106 address-of-record being registered are to be used for emergency 107 calls, and roaming and barring restrictions should not be applied for 108 the registered address-of-record. 110 Furthermore, distinguishing emergency registration from non-emergency 111 registration allows the registrar to ensure that the contact address 112 associated with previous registration of the address-of-record 113 included in the emergency REGISTER request is not replaced. For 114 incoming calls, for example, a PSAP call back to a previously made 115 emergency call, addressed to the emergency registered address-of- 116 record can be correctly routed to the contact address and UA from 117 which the original emergency call was placed. In addition, any 118 network based services or UA endpoint based services which may 119 prevent the emergency call or PSAP call back from being successful 120 can be disabled if it can be distinguished that the registered 121 contact address and address-of-record pertain to emergency calls. 123 This document concentrates on a use case defined by 3GPP as described 124 above. However, the solution proposed does not preclude other 125 systems that require emergency registration to occur prior to placing 126 an emergency call. 128 This document proposes a way to mark a REGISTER request as an 129 emergency registration. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119] 137 3. Requirements 139 Req: Where emergency registration is required prior to placing an 140 emergency call, it shall be possible to distinguish emergency 141 registration from non-emergency registration. 143 4. The "reg-type" URI Parameter 145 This section provides an overview of the proposed new URI parameter 146 to be used for marking REGISTER requests related to emergency 147 services. 149 A new URI parameter "reg-type" is defined in this document. The 150 "reg-type" parameter is appended to a URI consistent with RFC 3261 151 [RFC3261]. It is proposed that use of this URI parameter is 152 restricted to the Contact header included in the REGISTER request 153 (and the 2xx response to the REGISTER request) related to an 154 emergency call only. 156 The "reg-type" URI parameter SHALL take a value of "sos" to indicate 157 that the REGISTER request pertains to emergency registration. The 158 "reg-type" URI parameter with value "sos" MUST NOT be considered as a 159 replacement for the Service URN for emergency calls originated by a 160 UA. 162 Other use cases where specific instances of SIP registration need to 163 be identified are also possible. One such case may be by an end-user 164 registering their address-of-record with the specific purpose of 165 making "test" calls within a network. Such cases not specific to the 166 use case identified in this draft for identifying emergency 167 registration are not dealt with in this document. However the "reg- 168 type" URI parameter is extensible to allow other "reg-type" values to 169 be defined in the future. 171 4.1. REGISTER Request 173 In networks where the UA sends a REGISTER request for emergency 174 registration prior to placing an emergency call, the "reg-type" URI 175 parameter with value "sos" MUST be appended to the URI in the Contact 176 header. This serves as an indication to the registrar that the 177 request is for emergency registration. 179 Example: 181 Contact: "Alice" ;q=0.7; 182 expires=3600 184 In the event that more than one Contact header field is included in 185 the REGISTER request, only the contact addresses that include the 186 "reg-type" URI parameter with value "sos" shall be considered as 187 emergency registered contact addresses. 189 The "reg-type" URI parameter with value "sos" MUST NOT be included in 190 non-REGISTER requests, and MUST NOT be included in REGISTER requests 191 that do not pertain to emergency calls. 193 4.2. 2xx Response to REGISTER Request 195 If the registrar receives a REGISTER request that includes the "reg- 196 type" URI parameter with value "sos" in the Contact heade field, the 197 registrar MUST include the "reg-type" URI parameter with value "sos" 198 in the Contact header field in the 200 (OK) response sent by the 199 registrar upon successful registration. The "reg-type" URI parameter 200 with value "sos" is appended to the URI included in the Contact 201 header, thus indicating to the UA that it needs to include this 202 contact address in the Contact header of an INVITE request for 203 emergency call initiation. 205 4.3. Backwards compatibility issues 207 The backwards compatibility scenario considered in this document is 208 where a legacy registrar does not support the "reg-type" URI 209 parameter with value "sos". In this case, if the registrar receives 210 a REGISTER request that includes the "reg-type" URI parameter with 211 value "sos" in the Contact header field, the registrar proceeds with 212 registration procedures and silently ignores the URI-parameter in 213 accordance with RFC 3261[RFC3261]. This ensures the user is 214 registered and thus can successfully initiate an emergency call. 216 The drawback of proceeding with registration is if the address-of- 217 record is for example barred or has roaming restrictions applied, 218 then these restrictions will not be lifted and thus registration will 219 be unsuccessful. This can limit the UAC's ability to successfully 220 place an emergency call. 222 If registration is successful, the 200 (OK) response from a legacy 223 registrar includes the "reg-type" URI parameter with value "sos" in 224 the Contact header field. Thus the UA is unaware that the registrar 225 does not support the "reg-type" URI parameter with value "sos". 226 Providing the registration was successful, the UA's ability to place 227 an emergency call is not compromised. The UA need not know that the 228 registrar does not support the URI parameter. 230 The consequence of the registrar not supporting the "reg-type" URI 231 parameter with value "sos", in addition to the drawback pertaining to 232 restrictions applied to the address-of-record, are as follows: 234 - the risk of the registrar overwriting previous registrations of the 235 registered address-of-record, and thus disrupting any on-going non- 236 emergency sessions associated with the UA, its address-of-record and 237 previously registered contact address. 239 - incoming calls, such as a PSAP call back (to a previously made 240 emergency call) to the registered address-of-record might not be 241 routed correctly to the UA that placed the emergency call, due to not 242 suppressing any network based services such as call forwarding, or UA 243 based services which can divert the call elsewhere, or if the 244 address-of-record is associated to more than one contact address. 246 5. Formal Syntax 248 The following syntax specification uses the augmented Backus-Naur 249 Form (BNF) as described in RFC 5234 [RFC5234]. 251 The "reg-type" URI parameter is a "uri-parameter", as defined by RFC 252 3261[RFC3261]. 254 uri-parameter =/ reg-type-param 256 reg-type-param = "reg-type=" ("sos" / genvalue) 258 genvalue = 1*(alphanum / "-" / "." ) 260 6. IANA Considerations 262 This specification defines one new SIP URI parameter, as per the 263 registry created by RFC 3969 [RFC3969] 264 Parameter Name: reg-type 266 Predefined Values: sos 268 Reference: [RFCXXXX] 270 [NOTE TO IANA: Please replace XXXX with the RFC number of this 271 specification.] 273 7. Security Considerations 275 As an identifier, the "reg-type" parameter itself does not raise any 276 particular security issues. The semantic described by the "reg-type" 277 parameter are meant to be well-known so privacy considerations do not 278 apply to the URI parameter. The main possibility of attack involves 279 use of the "reg-type" parameter to bypass the normal procedures in 280 order to achieve fraudulent use of services or to bypass security 281 procedures. The usage of this parameter as described in this 282 document is purely for the purpose of the REGISTER request and hence 283 in presence of user authentication it is ensured that the respective 284 user can be held accountable. 286 It is RECOMMENDED to log events of misuse of the "reg-type" URI 287 parameter with value "sos", for example by including it in a request 288 or response not related to an emergency call. 290 8. Acknowledgements 292 The author would like to thank Keith Drage, Milo Orsic, Deb Barclay, 293 John-Luc Bakker, Andrew Allen, Hiroshi Ishikawa, Sean Schneyer, Peter 294 Leis, Georg Mayer, Marvin Bienn, Ricky Kaura, Steve Norreys, Laura 295 Liess, AC Mahendran, Roozbeh Atarius, Ramachandran Subramanian and 296 Sandeep Sharma, Brian Rosen, Hannes Tschofenig, Christer Holmberg and 297 Henning Schulzrinne for the discussions and contributions that led to 298 this work. 300 9. References 302 9.1. Normative References 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 308 A., Peterson, J., Sparks, R., Handley, M., and E. 310 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 311 June 2002. 313 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 314 Specifications: ABNF", STD 68, RFC 5234, January 2008. 316 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 317 (IANA) Uniform Resource Identifier (URI) Parameter 318 Registry for the Session Initiation Protocol (SIP)", 319 BCP 99, RFC 3969, December 2004. 321 9.2. Informative References 323 [I-D.ietf-ecrit-phonebcp] 324 Rosen, B. and J. Polk, "Best Current Practice for 325 Communications Services in support of Emergency Calling", 326 draft-ietf-ecrit-phonebcp-14 (work in progress), 327 January 2010. 329 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 330 Emergency and Other Well-Known Services", RFC 5031, 331 January 2008. 333 [3GPP.23.167] 334 3GPP, "IP Multimedia Subsystem (IMS) emergency sessions", 335 3GPP TS 23.167 7.12.0, December 2009. 337 Author's Address 339 Milan Patel 340 InterDigital Communications 342 Email: Milan.Patel@interdigital.com