idnits 2.17.00 (12 Aug 2021) /tmp/idnits33236/draft-rosen-ecrit-ecall-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 is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (February 25, 2013) is 3372 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: '7' is defined on line 283, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 286, but no explicit reference was found in the text == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 == Outdated reference: draft-ietf-ecrit-additional-data has been published as RFC 7852 == Outdated reference: draft-ietf-ecrit-trustworthy-location has been published as RFC 7378 Summary: 1 error (**), 0 flaws (~~), 6 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: Standards Track H. Tschofenig 5 Expires: August 29, 2013 Nokia Siemens Networks 6 R. Gellens 7 QUALCOMM Incorporated 8 February 25, 2013 10 Internet Protocol-based In-Vehicle Emergency Call 11 draft-rosen-ecrit-ecall-08.txt 13 Abstract 15 This document describes how to re-use the emergency services 16 mechanisms specified for the Session Initiation Protocol (SIP) to 17 accomplishing emergency calling support in vehicles. Profiling and 18 simplifications are possible due to the nature of the functionality 19 that is going to be provided in vehicles with the usage of Global 20 Positioning System (GPS). 22 Status of this Memo 24 This Internet-Draft is submitted 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). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on August 29, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 66 9.2. Informative references . . . . . . . . . . . . . . . . . . 12 67 Appendix A. Matching Functionality with eCall Minimum Set of 68 Data (MSD) . . . . . . . . . . . . . . . . . . . . . 14 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 71 1. Introduction 73 Emergency calls made from vehicles can assist with the objective of 74 significantly reducing road deaths and injuries. Unfortunately, 75 drivers often have a poor location-awareness, especially on urban 76 roads (also during night) and abroad. In the most crucial cases, the 77 victim(s) may not be able to call because they have been injured or 78 trapped. 80 In Europe the European Commission has launched the 'eCall' initiative 81 that may best be described as a user initiated or automatically 82 triggered system to provide notifications to Public Safety Answering 83 Point's (PSAP), by means of cellular communications, that a vehicle 84 has crashed, and to provide geodetic location information and where 85 possible a voice channel to the PSAP. At the time of writing the 86 support for eCall is focused on legacy mobile circuit switched voice 87 technology. This document details how the same functionality (and 88 even more) can be accomplished using Internet protocols and SIP. The 89 goal is to re-use existing specifications in the area of SIP-based 90 emergency calling. 92 This document is organized as follows: Section 2 defines the 93 terminology, Section 3 describes how the required functionality can 94 be accomplished by combining several already existing standards, and 95 Section 4 shows an example message exchange. This document concludes 96 with the security considerations in Section 5 and IANA considerations 97 in Section 6. Appendix A illustrates how to map the functionality in 98 this document to the eCall Minimum Set of Data (MSD) specified for 99 mobile circuit switched voice. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [1]. 107 This document re-uses terminology defined in Section 3 of [9]. 109 3. Profile 111 In the context of emergncy calls placed from a vehicle it is assumed 112 that the car is equipped with a built-in GPS receiver. For this 113 reason only geodetic location information will be sent within an 114 emergency call. The following location shapes MUST be implemented: 115 2d and 3d Point (see Section 5.2.1 of [2]), Circle (see Section 5.2.3 116 of [2]), and Ellipsoid (see Section 5.2.7 of [2]). The coordinate 117 reference systems (CRS) specified in [2] are also mandatory for this 118 document. The element, as defined in [3] which indicates 119 the direction of travel of the vehicle, is important for dispatch and 120 hence it MUST be included in the PIDF-LO . The element 121 specified in [3] MUST be implemented and MAY be included. 123 This specification also inherits the ability to utilize test call 124 functionality from Section 15 of [4]. 126 4. Example 128 Figure 1 shows an emergency call placed from a vehicle whereby 129 location information information is directly attached to the SIP 130 INVITE message itself. The call is marked as an emergency call using 131 the 'urn:service:sos.ecall.automatic' service URN and the PSAP of the 132 VoIP provider determines which PSAP to contact based on the provided 133 location information. The emergency call continues towards the PSAP 134 and in this example it hits the ESRP, as the entry point to the PSAP 135 operators emergency services network. Finally, the emergency call 136 will be received by a call taker and first reponders will be 137 dispatched. 139 +--------+ 140 | LoST | 141 | Server | 142 +--------+ 143 ^ +-------+ 144 | | PSAP2 | 145 | +-------+ 146 v 147 +-------+ +------+ +-------+ 148 Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 149 +-------+ +------+ +-------+ 151 +-------+ 152 | PSAP3 | 153 +-------+ 155 Figure 1: Example of In-Vehicular Emergency Call Message Flow 157 The example, shown in Figure 2, illustrates a SIP INVITE and location 158 information encoded in a PIDF-LO that is being conveyed in such an 159 emergency call. 161 INVITE urn:service:sos.ecall.automatic SIP/2.0 162 To: urn:service:sos.ecall.automatic 163 From: ;tag=9fxced76sl 164 Call-ID: 3848276298220188511@atlanta.example.com 165 Geolocation: 166 Geolocation-Routing: no 167 Accept: application/sdp, application/pidf+xml 168 CSeq: 31862 INVITE 169 Content-Type: multipart/mixed; boundary=boundary1 170 Content-Length: ... 172 --boundary1 174 Content-Type: application/sdp 176 ...Session Description Protocol (SDP) goes here 178 --boundary1 180 Content-Type: application/pidf+xml 181 Content-ID: 182 183 191 192 193 194 195 -34.407 150.883 196 197 198 278 199 200 201 202 203 gps 204 205 2012-04-5T10:18:29Z 206 1M8GDM9A_KP042788 207 208 209 --boundary1-- 211 Figure 2: SIP INVITE indicating an In-Vehicular Emergency Call 213 5. Security Considerations 215 This document does not raise security considerations beyond those 216 described in [10]. As with emergency service systems with end host 217 provided location information there is the possibility that that 218 location is incorrect, either intentially (in case of an a denial of 219 service attack against the emergency services infrastructure) or due 220 to a malfunctioning devices. The reader is referred to [11] for a 221 discussion of some of these vulnerabilities. 223 6. IANA Considerations 225 IANA is requested to register the URN 'urn:service:sos.ecall' under 226 the sub-services 'sos' registry defined in Section 4.2 of [5]. 228 This service identifier reaches a public safety answering point 229 (PSAP), which in turn dispatches aid appropriate to the emergency 230 related to accidents of vehicles. Two sub-services are registered as 231 well, namely 233 urn:service:sos.ecall.manual 235 This service URN indicates that an eCall had been triggered based 236 on the manual interaction of the driver or a passenger. 238 urn:service:sos.ecall.automatic 240 This service URN indicates that an eCall had been triggered 241 automatically, for example, due to a crash. No human involvement 242 was detected. 244 7. Contributors 246 We would like to thank Ulrich Dietz for his help with earlier 247 versions of the document. 249 8. Acknowledgements 251 We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri, 252 and Gunnar Hellstroem for their feedback. 254 9. References 256 9.1. Normative References 258 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 259 Levels", BCP 14, RFC 2119, March 1997. 261 [2] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 262 Presence Information Data Format Location Object (PIDF-LO) 263 Usage Clarification, Considerations, and Recommendations", 264 RFC 5491, March 2009. 266 [3] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, 267 "Dynamic Extensions to the Presence Information Data Format 268 Location Object (PIDF-LO)", RFC 5962, September 2010. 270 [4] Rosen, B. and J. Polk, "Best Current Practice for 271 Communications Services in support of Emergency Calling", 272 draft-ietf-ecrit-phonebcp-20 (work in progress), 273 September 2011. 275 [5] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency 276 and Other Well-Known Services", RFC 5031, January 2008. 278 [6] Rosen, B., Tschofenig, H., Marshall, R., and R. Randy, 279 "Additional Data related to an Emergency Call", 280 draft-ietf-ecrit-additional-data-06 (work in progress), 281 February 2013. 283 [7] Peterson, J., "A Presence-based GEOPRIV Location Object 284 Format", RFC 4119, December 2005. 286 [8] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for 287 the Session Initiation Protocol", RFC 6442, December 2011. 289 9.2. Informative references 291 [9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 292 Context Resolution with Internet Technologies", RFC 5012, 293 January 2008. 295 [10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, 296 "Security Threats and Requirements for Emergency Call Marking 297 and Mapping", RFC 5069, January 2008. 299 [11] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy 300 Location", draft-ietf-ecrit-trustworthy-location-04 (work in 301 progress), October 2012. 303 [12] CEN, "Intelligent transport systems - eSafety - eCall minimum 304 set of data (MSD), EN 15722", June 2011. 306 [13] Schulzrinne, H., "Timed Presence Extensions to the Presence 307 Information Data Format (PIDF) to Indicate Status Information 308 for Past and Future Time Intervals", RFC 4481, July 2006. 310 Appendix A. Matching Functionality with eCall Minimum Set of Data (MSD) 312 [12] outlines a number of data elements that are transmitted in an 313 emergency call triggered by a vehicle. Note that the work on eCall 314 for mobile circuit switched voice is constrained in a number of ways. 315 For example, eCall uses an inband voice modem to transmit data from a 316 vehicle to a PSAP. Since the functionality in this document is based 317 on the Session Initiation Protocol these limitations do not exist. 318 As such, it is not useful to transmit the MSD inband in the voice 319 channel but to rather use the SIP-designed mechanisms. Any voice, 320 video, or real-text communication will be negotiated using the 321 Session Description Protocol (SDP), as shown in Figure 2, and the 322 actual media stream will then take place in RTP packets. 324 The following list compares the eCall minimum set of data with the 325 functionality provided in this document. 327 Version of the MSD Format 329 Message Identifier: Every SIP INVITE message contains a Call-ID, 330 which is a globally unique identifier for this call. 332 Vehicle Type Encoding: [Editor's Note: Description to be added.]. 334 Test Call Indication A service URN starting with "test." indicates a 335 request for an automated test. For example, 336 "urn:service:test.sos.ecall.automatic" indicates such a test 337 feature. This functionality is defined in [4]. 339 Automatic Activation Indication: This document registers new service 340 URNs, which allow the differentiation between manually and 341 automatically triggered emergency calls. The two service URNs 342 are: urn:service:sos.ecall.automatic and 343 urn:service:sos.ecall.manual 345 Vehicle Identification: The PIDF data structure contains a deviceID 346 field that holds the Vehicle Identification Number (VIN). 348 Vehicle Propulsion Storage type: These parameters identify the type 349 of vehicle energy storage(s) present. [Editor's Note: 350 Description to be added.] 352 Timestamp of Incident Event: The PIDF-LO element contains the 353 timestamp when the PIDF-LO was created, which is at the time of 354 the incident. 356 Vehicle Location: The location of the vehicle is conveyed using the 357 PIDF location objection, as described in Section 3. 359 Vehicle Direction: The direction of the vehicle is part of location 360 information, as described in Section 3. 362 Recent Vehicle Location: With this optional functionality multiple 363 location objects may be required to be transported simultaneously. 364 This can be achieved using , defined in RFC 4481 365 [13]. 367 Number of Passengers: Minimum known number of fastened seatbelts. 368 [Editor's Note: Description to be added.] 370 Additional Data: [6] provides the ability to carry additional data 371 for an emergency call. 373 Authors' Addresses 375 Brian Rosen 376 NeuStar, Inc. 377 470 Conrad Dr 378 Mars, PA 16046 379 US 381 Phone: 382 Email: br@brianrosen.net 384 Hannes Tschofenig 385 Nokia Siemens Networks 386 Linnoitustie 6 387 Espoo 02600 388 Finland 390 Phone: +358 (50) 4871445 391 Email: Hannes.Tschofenig@gmx.net 392 URI: http://www.tschofenig.priv.at 394 Randall Gellens 395 QUALCOMM Incorporated 396 5775 Morehouse Drive 397 San Diego 92651 398 US 400 Email: rg+ietf@qualcomm.com