idnits 2.17.00 (12 Aug 2021) /tmp/idnits35814/draft-rosen-ecrit-ecall-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 411. 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 Copyright Line does not match the current year -- 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 (July 7, 2008) is 5066 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-10 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: draft-ietf-geopriv-pdif-lo-profile has been published as RFC 5491 == Outdated reference: draft-singh-geopriv-pidf-lo-dynamic has been published as RFC 5962 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft NeuStar, Inc. 4 Intended status: BCP H. Tschofenig 5 Expires: January 8, 2009 Nokia Siemens Networks 6 July 7, 2008 8 Best Current Practice for IP-based In-Vehicle Emergency Calls 9 draft-rosen-ecrit-ecall-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 8, 2009. 36 Abstract 38 This document describes how to use a subset of the IETF-based 39 emergency call framework for accomplishing emergency calling support 40 in vehicles. Simplifications are possible due to the nature of the 41 functionality that is going to be provided in vehicles with the usage 42 of GPS. Additionally, further profiling needs to be done regarding 43 the encoding of location information. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. Protocol Profile . . . . . . . . . . . . . . . . . . . . . . . 5 50 4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 51 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 52 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 53 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 54 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 55 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 56 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 57 9.2. Informative references . . . . . . . . . . . . . . . . . . 14 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 59 Intellectual Property and Copyright Statements . . . . . . . . . . 16 61 1. Introduction 63 Emergency calls made from vehicles can assist with the objective of 64 significantly reducing road deaths and injuries. Unfortunately, 65 drivers often have a poor location-awareness, especially on urban 66 roads (also during night) and abroad. In the most crucial cases, the 67 victim(s) may not be able to call because they have been injured or 68 trapped. 70 In Europe the European Commission has launched the eCall initiative 71 that may best be described as a "user instigated or automatic system 72 to provide notification to 'Public Safety Answering Point's (PSAP), 73 by means of cellular communications, that a vehicle has crashed, and 74 to provide coordinates, a defined minimum set of data, and where 75 possible a voice link to the PSAP.". The current specifications 76 being developed to offer the eCall solution are defined to work with 77 circuit switched telephony. This document details how the same 78 functionality can be accomplished using IP-based mechanisms. Since 79 cellular systems are being replaced with IP-based infrastructure this 80 document complements the ambigous goal to provide widespread 81 availability of in-vehicular emergency services solutions. 83 This document is organized as follows: Section 2 defines the 84 terminology, Section 3 illustrates the required protocol 85 functionality, Section 4 indicates the required data that has to be 86 transmitted within a PIDF-LO and Section 5 shows an example message 87 exchange. This document concludes with the security consideratoins 88 in Section 6 and IANA considerations in Section 7. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [1]. 96 This document re-uses a lot of the terminology defined in Section 3 97 of [9]. 99 3. Protocol Profile 101 The usage of in-vehicular emergency calls does not require the usage 102 of a Location Configuration Protocol since GPS is used. Furthermore, 103 since the GPS receiver is permanently turned on it can even provide 104 useful information in cases where the car entered a tunnel. 105 Consequently, there is no need to discover any LIS. 107 Since the emergency call within the car is either triggered by a 108 button or, in most cases, automatically thanks to sensors mounted in 109 the car there is no need to learn a dial string. This document 110 registers a separate Service URN, namely 'urn:service:ecall', used 111 specifically for emergency calls that are triggered by vehicles. 113 The following list provides information about the sections and 114 requires of [2] that are relevant to this specification: 116 Identifying an emergency call: Emergency calls are detected at the 117 end point, i.e., by the vehicle, and the Service URN 118 'urn:service:ecall' MUST be implemented by the end point and 119 recognized by the VSP. The requirements listed in Section 5 of 120 [2] are therefore irrelevant to this specification, as they deal 121 with identifying an emergency call based on dial strings. 123 Location: The encoding of the PIDF-LO [3] is described in Section 4. 124 In an emergency, the end point adds the available location 125 information to the initial SIP INVITE emergency call message. In 126 special cases a location update may be provided, using the 127 procedure described in requirement ED-38 of Section 6.8 of [2]; 128 all other aspects of Section 6.8 from that document are not 129 applicable to this specification. Section 6.2.1, 6.2.2, 6.2.4, 130 6.4, 6.5 and 6.6 of [2] are not applicable to this document. For 131 location conveyance in SIP [4] MUST be used. Further aspects that 132 are not relevant for this document are multiple locations (Section 133 6.9 of [2]), location validation (Section 6.10 of [2]), default 134 location (Section 6.11 of [2]) 136 LoST: Emergency call routing support, for example utilizing LoST, is 137 provided by VSP. As such, the description in Section 8 of [2] is 138 applicable to this document, except for requirement SP-25 and 139 SP-26 regarding legacy devices. 141 Signaling of emergency calls: Section 9 of [2] is applicable to this 142 document with the following exceptions: video and real-time text 143 are not supported by the end device, ED-60/AN-25 is not applicable 144 as HELD is not used. Additionally, ED-62 dealing with "SIP 145 signaling requirements for User Agents" is simplified as follows. 146 The initial SIP signaling method is an INVITE request with the 147 following setting: 149 1. The Request URI MUST be the service URN 'urn:service:ecall'. 151 2. The To header MUST be a service URN 'urn:service:ecall'. 153 3. The From header MUST be present and SHOULD be the AoR of the 154 caller. 156 4. A Via header MUST be present. 158 5. A Contact header MUST be present which MUST be globally 159 routable to permit an immediate call-back to the specific 160 device which placed the emergency call. 162 6. Other headers MAY be included as per normal SIP behavior. 164 7. A Supported header MUST be included with the 'geolocation' 165 option tag [4]. 167 8. The device MUST include location by-value into the call. 169 9. A normal SDP offer SHOULD be included in the INVITE. If 170 voice is supported the offer SHOULD include the G.711 codec, 171 if a voice channel can be established based on the equipment 172 in the car. 174 10. If the device includes location-by-value, the UA MUST support 175 multipart message bodies, since SDP will likely be also in 176 the INVITE. 178 11. The UAC MUST include a "inserted-by=endpoint" header 179 parameter on all Geolocation headers. This informs 180 downstream elements which device entered the location at this 181 URI (either cid-URL or location-by-reference URI). 183 12. SIP Caller Preferences [5] MAY be used to signal how the PSAP 184 should handle the call. For example, a language preference 185 expressed in an Accept-Language header may be used as a hint 186 to cause the PSAP to route the call to a call taker who 187 speaks the requested language. SIP Caller Preferences may 188 also be used to indicate a need to invoke a relay service for 189 communication with people with disabilities in the call. 191 Call backs: The description in Section 10 of [2] is not relevant for 192 this document. 194 Mid-call behavior: The description in Section 11 of [2] is fully 195 applicable to this document. 197 Call termination: [This item is for further discussion.] 199 Disabling of features: The description in Section 13 of [2] is fully 200 applicable to this document. 202 Media: Real-time text and video are not supported. If voice calls 203 are supported then the description in Section 14 is applicable to 204 this document. 206 Testing: The description in Section 15 of [2] is fully applicable to 207 this document. 209 4. Data Profile 211 Due to the requirement for a built-in GPS receiver only geodetic 212 location information will be sent within an emergency call. 213 Furthermore, the number of location shapes is is restricted. Hence, 214 the following location shapes of [6] MUST be implemented: 2d and 3d 215 Point (see Section 5.2.1 of [6]), Circle (see Section 5.2.3 of [6]), 216 and Ellipsoid (see Section 5.2.7 of [6]). The coordinate reference 217 systems (CRS) specified in [6] are also mandatory for this document. 218 Furthermore, the direction of travel of the vehicle is important for 219 dispatch and hence it MUST be included in the PIDF-LO. The 220 element specified in [7] MUST be supported. 222 5. Example 224 Figure 1 shows an emergency call placed from a vehicle whereby 225 location information information is directly attached to the SIP 226 INVITE message itself. The call is marked as an emergency call using 227 the 'urn:service:ecall' service URN and the PSAP of the VoIP provider 228 determines which PSAP to contact based on the provided location 229 information. As shown in the figure, this route determination may be 230 based on LoST. Then, the emergency call continues towards the PSAP 231 and in this example it hits the ESRP, as the entry point to the PSAP 232 operators emergency services network. Finally, the emergency call 233 will be received by a call taker and first reponders will be 234 dispatched. 236 +--------+ 237 | LoST | 238 | Servers| 239 +--------+ 240 ^ +-------+ 241 | | PSAP2 | 242 | +-------+ 243 v 244 +-------+ +------+ +-------+ 245 Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 246 +-------+ +------+ +-------+ 248 +-------+ 249 | PSAP3 | 250 +-------+ 252 Figure 1: Example of In-Vehicular Emergency Call Message Flow 254 The following example, in Figure 2, shows location information 255 encoded in a PIDF-LO that is being conveyed in such an emergency 256 call. 258 259 264 265 266 267 268 42.5463 -73.2512 269 270 850.24 271 272 273 274 275 270.0 -60.0 276 277 278 279 280 GPS 281 282 283 285 Figure 2: Example of In-Vehicular Emergency Call Message Flow 287 6. Security Considerations 289 This document does not raise security considerations beyond those 290 described in [10]. 292 7. IANA Considerations 294 IANA is requested to register the URN 'urn:service:ecall' under the 295 sub-services 'sos' registry defined in Section 4.2 of [8]. 297 urn:service:ecall This service identifier reaches a public safety 298 answering point (PSAP), which in turn dispatches aid appropriate 299 to the emergency related to accidents of vehicles. 301 8. Acknowledgements 303 We would like to thank Michael Montag and Ulrich Dietz for their 304 feedback. 306 9. References 308 9.1. Normative References 310 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 311 Levels", BCP 14, RFC 2119, March 1997. 313 [2] Rosen, B. and J. Polk, "Best Current Practice for 314 Communications Services in support of Emergency Calling", 315 draft-ietf-ecrit-phonebcp-04 (work in progress), February 2008. 317 [3] Peterson, J., "A Presence-based GEOPRIV Location Object 318 Format", RFC 4119, December 2005. 320 [4] Polk, J. and B. Rosen, "Location Conveyance for the Session 321 Initiation Protocol", draft-ietf-sip-location-conveyance-10 322 (work in progress), February 2008. 324 [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 325 Preferences for the Session Initiation Protocol (SIP)", 326 RFC 3841, August 2004. 328 [6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 329 PIDF-LO Usage Clarification, Considerations and 330 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work 331 in progress), February 2008. 333 [7] Vishal, S., Schulzrinne, H., and H. Tschofenig, "Dynamic 334 Feature Extensions to the Presence Information Data Format 335 Location Object (PIDF-LO)", 336 draft-singh-geopriv-pidf-lo-dynamic-02 (work in progress), 337 November 2007. 339 [8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency 340 and Other Well-Known Services", RFC 5031, January 2008. 342 9.2. Informative references 344 [9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 345 Context Resolution with Internet Technologies", RFC 5012, 346 January 2008. 348 [10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, 349 "Security Threats and Requirements for Emergency Call Marking 350 and Mapping", RFC 5069, January 2008. 352 Authors' Addresses 354 Brian Rosen 355 NeuStar, Inc. 356 470 Conrad Dr 357 Mars, PA 16046 358 US 360 Phone: 361 Email: br@brianrosen.net 363 Hannes Tschofenig 364 Nokia Siemens Networks 365 Linnoitustie 6 366 Espoo 02600 367 Finland 369 Phone: +358 (50) 4871445 370 Email: Hannes.Tschofenig@gmx.net 371 URI: http://www.tschofenig.priv.at 373 Full Copyright Statement 375 Copyright (C) The IETF Trust (2008). 377 This document is subject to the rights, licenses and restrictions 378 contained in BCP 78, and except as set forth therein, the authors 379 retain all their rights. 381 This document and the information contained herein are provided on an 382 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 383 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 384 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 385 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 386 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 387 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 389 Intellectual Property 391 The IETF takes no position regarding the validity or scope of any 392 Intellectual Property Rights or other rights that might be claimed to 393 pertain to the implementation or use of the technology described in 394 this document or the extent to which any license under such rights 395 might or might not be available; nor does it represent that it has 396 made any independent effort to identify any such rights. Information 397 on the procedures with respect to rights in RFC documents can be 398 found in BCP 78 and BCP 79. 400 Copies of IPR disclosures made to the IETF Secretariat and any 401 assurances of licenses to be made available, or the result of an 402 attempt made to obtain a general license or permission for the use of 403 such proprietary rights by implementers or users of this 404 specification can be obtained from the IETF on-line IPR repository at 405 http://www.ietf.org/ipr. 407 The IETF invites any interested party to bring to its attention any 408 copyrights, patents or patent applications, or other proprietary 409 rights that may cover technology that may be required to implement 410 this standard. Please address the information to the IETF at 411 ietf-ipr@ietf.org.