idnits 2.17.00 (12 Aug 2021) /tmp/idnits32712/draft-rosen-ecrit-ecall-06.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 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 15, 2012) is 3597 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 == Outdated reference: draft-ietf-ecrit-trustworthy-location has been published as RFC 7378 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: Informational H. Tschofenig 5 Expires: January 16, 2013 Nokia Siemens Networks 6 July 15, 2012 8 Internet Protocol-based In-Vehicle Emergency Call 9 draft-rosen-ecrit-ecall-06.txt 11 Abstract 13 This document describes how to use a subset of the IETF-based 14 emergency call framework for accomplishing emergency calling support 15 in vehicles. Simplifications are possible due to the nature of the 16 functionality that is going to be provided in vehicles with the usage 17 of GPS. Additionally, further profiling needs to be done regarding 18 the encoding of location information. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 16, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Protocol Profile . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 61 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 65 10.2. Informative references . . . . . . . . . . . . . . . . . 15 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 68 1. Introduction 70 Emergency calls made from vehicles can assist with the objective of 71 significantly reducing road deaths and injuries. Unfortunately, 72 drivers often have a poor location-awareness, especially on urban 73 roads (also during night) and abroad. In the most crucial cases, the 74 victim(s) may not be able to call because they have been injured or 75 trapped. 77 In Europe the European Commission has launched the eCall initiative 78 that may best be described as a user initiated or automatically 79 triggered system to provide notifications to Public Safety Answering 80 Point's (PSAP), by means of cellular communications, that a vehicle 81 has crashed, and to provide geodetic location information and where 82 possible a voice channel to the PSAP. At the time of writing the 83 suppor for eCall are focused on legacy technology. This document 84 details how emergency calls triggered by vehicles can be accomplished 85 in an Internet Protocol-based environment. 87 This document is organized as follows: Section 2 defines the 88 terminology, Section 3 illustrates the required protocol 89 functionality, Section 4 indicates the required data that has to be 90 transmitted within a PIDF-LO and Section 5 shows an example message 91 exchange. This document concludes with the security considerations 92 in Section 6 and IANA considerations in Section 7. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [1]. 100 This document re-uses a lot of the terminology defined in Section 3 101 of [9]. 103 3. Protocol Profile 105 The usage of in-vehicular emergency calls does not require the usage 106 of a Location Configuration Protocol since GPS is used. Furthermore, 107 since the GPS receiver is permanently turned on it can even provide 108 useful information in cases where the car entered a tunnel. 109 Consequently, there is no need to discover any Location Information 110 Server (LIS). 112 Since the emergency call within the car is either triggered by a 113 button or, in most cases, automatically thanks to sensors mounted in 114 the car there is no need to learn a dial string. This document 115 registers a separate Service URN, namely 'urn:service:ecall', used 116 specifically for emergency calls that are triggered by vehicles. 117 This URN comes with two sub-services to indicate how the emergency 118 call was triggered, namely 'automatic' for cases when the emergency 119 call was triggered due to a crash automatically without any user 120 involvement and 'manual' for cases where a driver or a passenger 121 triggered the emergency call. If the device initiating the emergency 122 call does not allow to differentiate these two cases then the Service 123 URN 'urn:service:ecall' is used. 125 The following list provides information about the sections and 126 requires of [2] that are relevant to this specification: 128 Identifying an emergency call: Emergency calls are detected at the 129 end point, i.e., by the vehicle, and the Service URN 130 'urn:service:ecall' MUST be implemented by the end point and 131 recognized by the VSP. The requirements listed in Section 5 of 132 [2] are therefore irrelevant to this specification, as they deal 133 with identifying an emergency call based on dial strings. 135 Location: The encoding of the PIDF-LO [3] is described in Section 4. 136 In an emergency, the end point adds the available location 137 information to the initial SIP INVITE emergency call message. In 138 special cases a location update may be provided, using the 139 procedure described in requirement ED-38 of Section 6.8 of [2]; 140 all other aspects of Section 6.8 from that document are not 141 applicable to this specification. Section 6.2.1, 6.2.2, 6.2.4, 142 6.4, 6.5 and 6.6 of [2] are not applicable to this document. For 143 location conveyance in SIP [4] MUST be used. Further aspects that 144 are not relevant for this document are multiple locations (Section 145 6.9 of [2]), location validation (Section 6.10 of [2]), default 146 location (Section 6.11 of [2]) 148 LoST: Emergency call routing support, for example utilizing LoST, is 149 provided by VSP. As such, the description in Section 8 of [2] is 150 applicable to this document, except for requirement SP-25 and 151 SP-26 regarding legacy devices. 153 Signaling of emergency calls: Section 9 of [2] is applicable to this 154 document with the following exception: ED-60/AN-25 is not 155 applicable as HELD is not used. Video and real-time text may be 156 supported by end device in the future, although currently not 157 envisioned. The corresponding text paragraphs are relevant from 158 Section 9 of [2] when support is being provided. Additionally, 159 ED-62 dealing with "SIP signaling requirements for User Agents" is 160 simplified as follows. The initial SIP signaling method is an 161 INVITE request with the following setting: 163 1. The Request URI MUST be the service URN 'urn:service:ecall' 164 or one of the sub-services. 166 2. The To header MUST be a service URN 167 'urn:service:ecall.automatic' or one of the sub-services. 169 3. The From header MUST be present and SHOULD be the AoR of the 170 caller. 172 4. A Via header MUST be present. 174 5. A Contact header MUST be present which MUST be globally 175 routable to permit an immediate call-back to the specific 176 device which placed the emergency call. 178 6. Other headers MAY be included as per normal SIP behavior. 180 7. A Supported header MUST be included with the 'geolocation' 181 option tag [4]. 183 8. The device MUST include location by-value into the call. 185 9. A normal SDP offer SHOULD be included in the INVITE. If 186 voice is supported the offer SHOULD include the G.711 codec, 187 if a voice channel can be established based on the equipment 188 in the car. 190 10. If the device includes location-by-value, the UA MUST support 191 multipart message bodies, since SDP will likely be also in 192 the INVITE. 194 11. The UAC MUST include a "inserted-by=endpoint" header 195 parameter on all Geolocation headers. This informs 196 downstream elements which device entered the location at this 197 URI (either cid-URL or location-by-reference URI). 199 12. SIP Caller Preferences [5] MAY be used to signal how the PSAP 200 should handle the call. For example, a language preference 201 expressed in an Accept-Language header may be used as a hint 202 to cause the PSAP to route the call to a call taker who 203 speaks the requested language. SIP Caller Preferences may 204 also be used to indicate a need to invoke a relay service for 205 communication with people with disabilities in the call. 207 Call backs: The description in Section 10 of [2] is relevant for 208 this document. 210 Mid-call behavior: The description in Section 11 of [2] is fully 211 applicable to this document. 213 Call termination: The description in Section 12 of [2] is fully 214 applicable to this document. 216 Disabling of features: The description in Section 13 of [2] is fully 217 applicable to this document. 219 Media: If hardware and software for real-time text, voice, and video 220 is available in the end device then the requirements regarding 221 multi-media support described in [2] are applicable. 223 Testing: The description in Section 15 of [2] is fully applicable to 224 this document. 226 4. Data Profile 228 Due to the requirement for a built-in GPS receiver only geodetic 229 location information will be sent within an emergency call. 230 Furthermore, the number of location shapes is is restricted. Hence, 231 the following location shapes of [6] MUST be implemented: 2d and 3d 232 Point (see Section 5.2.1 of [6]), Circle (see Section 5.2.3 of [6]), 233 and Ellipsoid (see Section 5.2.7 of [6]). The coordinate reference 234 systems (CRS) specified in [6] are also mandatory for this document. 235 Furthermore, the direction of travel of the vehicle is important for 236 dispatch and hence it MUST be included in the PIDF-LO. The 237 element specified in [7] MUST be supported. 239 5. Example 241 Figure 1 shows an emergency call placed from a vehicle whereby 242 location information information is directly attached to the SIP 243 INVITE message itself. The call is marked as an emergency call using 244 the 'urn:service:ecall.automatic' service URN and the PSAP of the 245 VoIP provider determines which PSAP to contact based on the provided 246 location information. As shown in the figure, this route 247 determination may be based on LoST. Then, the emergency call 248 continues towards the PSAP and in this example it hits the ESRP, as 249 the entry point to the PSAP operators emergency services network. 250 Finally, the emergency call will be received by a call taker and 251 first reponders will be dispatched. 253 +--------+ 254 | LoST | 255 | Servers| 256 +--------+ 257 ^ +-------+ 258 | | PSAP2 | 259 | +-------+ 260 v 261 +-------+ +------+ +-------+ 262 Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 263 +-------+ +------+ +-------+ 265 +-------+ 266 | PSAP3 | 267 +-------+ 269 Figure 1: Example of In-Vehicular Emergency Call Message Flow 271 The following example, in Figure 2, shows the SIP INVITE and location 272 information encoded in a PIDF-LO that is being conveyed in such an 273 emergency call. 275 INVITE urn:service:ecall.automatic SIP/2.0 276 To: 277 From: ;tag=9fxced76sl 278 Call-ID: 3848276298220188511@atlanta.example.com 279 Geolocation: 280 Geolocation-Routing: no 281 Accept: application/sdp, application/pidf+xml 282 CSeq: 31862 INVITE 283 Content-Type: multipart/mixed; boundary=boundary1 284 Content-Length: ... 286 --boundary1 288 Content-Type: application/sdp 290 ...Session Description Protocol (SDP) goes here 292 --boundary1 294 Content-Type: application/pidf+xml 295 Content-ID: 296 298 306 307 308 309 310 -34.407 150.883 311 312 313 278 314 315 316 317 gps 318 319 2012-04-5T10:18:29Z 320 vehicle-number 321 322 323 --boundary1-- 325 Figure 2: SIP INVITE indicating an In-Vehicular Emergency Call 327 6. Security Considerations 329 This document does not raise security considerations beyond those 330 described in [10]. As with emergency service systems with end host 331 provided location information there is the possibility that that 332 location is incorrect, either intentially (in case of an a denial of 333 service attack against the emergency services infrastructure) or due 334 to a malfunctioning devices. The reader is referred to [11] for a 335 discussion of some of these vulnerabilities. 337 7. IANA Considerations 339 IANA is requested to register the URN 'urn:service:ecall' under the 340 sub-services 'sos' registry defined in Section 4.2 of [8]. 342 This service identifier reaches a public safety answering point 343 (PSAP), which in turn dispatches aid appropriate to the emergency 344 related to accidents of vehicles. Two sub-services are registered as 345 well, namely 347 urn:service:ecall.manual This service URN indicates that an eCall 348 had been triggered based on the manual interaction of the driver 349 or a passenger. 351 urn:service:ecall.automatic This service URN indicates that an eCall 352 had been triggered automatically, for example, due to a crash. No 353 human involvement was detected. 355 8. Contributors 357 We would like to thank Ulrich Dietz for his help with earlier 358 versions of the document. 360 9. Acknowledgements 362 We would like to thank Michael Montag, Arnoud van Wijk, and Gunnar 363 Hellstroem for their feedback. 365 10. References 367 10.1. Normative References 369 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 370 Levels", BCP 14, RFC 2119, March 1997. 372 [2] Rosen, B. and J. Polk, "Best Current Practice for 373 Communications Services in support of Emergency Calling", 374 draft-ietf-ecrit-phonebcp-20 (work in progress), 375 September 2011. 377 [3] Peterson, J., "A Presence-based GEOPRIV Location Object 378 Format", RFC 4119, December 2005. 380 [4] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for 381 the Session Initiation Protocol", RFC 6442, December 2011. 383 [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 384 Preferences for the Session Initiation Protocol (SIP)", 385 RFC 3841, August 2004. 387 [6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 388 Presence Information Data Format Location Object (PIDF-LO) 389 Usage Clarification, Considerations, and Recommendations", 390 RFC 5491, March 2009. 392 [7] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, 393 "Dynamic Extensions to the Presence Information Data Format 394 Location Object (PIDF-LO)", RFC 5962, September 2010. 396 [8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency 397 and Other Well-Known Services", RFC 5031, January 2008. 399 10.2. Informative references 401 [9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 402 Context Resolution with Internet Technologies", RFC 5012, 403 January 2008. 405 [10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, 406 "Security Threats and Requirements for Emergency Call Marking 407 and Mapping", RFC 5069, January 2008. 409 [11] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy 410 Location Information", draft-ietf-ecrit-trustworthy-location-03 411 (work in progress), April 2012. 413 Authors' Addresses 415 Brian Rosen 416 NeuStar, Inc. 417 470 Conrad Dr 418 Mars, PA 16046 419 US 421 Phone: 422 Email: br@brianrosen.net 424 Hannes Tschofenig 425 Nokia Siemens Networks 426 Linnoitustie 6 427 Espoo 02600 428 Finland 430 Phone: +358 (50) 4871445 431 Email: Hannes.Tschofenig@gmx.net 432 URI: http://www.tschofenig.priv.at