idnits 2.17.00 (12 Aug 2021) /tmp/idnits37931/draft-rosen-ecrit-ecall-05.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 (March 12, 2012) is 3722 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: September 13, 2012 Nokia Siemens Networks 6 March 12, 2012 8 Internet Protocol-based In-Vehicle Emergency Call 9 draft-rosen-ecrit-ecall-05.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 September 13, 2012. 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. The current specifications 83 being developed to offer the eCall solution are defined to work with 84 circuit switched telephony. This document details how similar or 85 more extended functionality can be accomplished using IP-based 86 mechanisms. 88 This document is organized as follows: Section 2 defines the 89 terminology, Section 3 illustrates the required protocol 90 functionality, Section 4 indicates the required data that has to be 91 transmitted within a PIDF-LO and Section 5 shows an example message 92 exchange. This document concludes with the security considerations 93 in Section 6 and IANA considerations in Section 7. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [1]. 101 This document re-uses a lot of the terminology defined in Section 3 102 of [9]. 104 3. Protocol Profile 106 The usage of in-vehicular emergency calls does not require the usage 107 of a Location Configuration Protocol since GPS is used. Furthermore, 108 since the GPS receiver is permanently turned on it can even provide 109 useful information in cases where the car entered a tunnel. 110 Consequently, there is no need to discover any 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. 118 The following list provides information about the sections and 119 requires of [2] that are relevant to this specification: 121 Identifying an emergency call: Emergency calls are detected at the 122 end point, i.e., by the vehicle, and the Service URN 123 'urn:service:ecall' MUST be implemented by the end point and 124 recognized by the VSP. The requirements listed in Section 5 of 125 [2] are therefore irrelevant to this specification, as they deal 126 with identifying an emergency call based on dial strings. 128 Location: The encoding of the PIDF-LO [3] is described in Section 4. 129 In an emergency, the end point adds the available location 130 information to the initial SIP INVITE emergency call message. In 131 special cases a location update may be provided, using the 132 procedure described in requirement ED-38 of Section 6.8 of [2]; 133 all other aspects of Section 6.8 from that document are not 134 applicable to this specification. Section 6.2.1, 6.2.2, 6.2.4, 135 6.4, 6.5 and 6.6 of [2] are not applicable to this document. For 136 location conveyance in SIP [4] MUST be used. Further aspects that 137 are not relevant for this document are multiple locations (Section 138 6.9 of [2]), location validation (Section 6.10 of [2]), default 139 location (Section 6.11 of [2]) 141 LoST: Emergency call routing support, for example utilizing LoST, is 142 provided by VSP. As such, the description in Section 8 of [2] is 143 applicable to this document, except for requirement SP-25 and 144 SP-26 regarding legacy devices. 146 Signaling of emergency calls: Section 9 of [2] is applicable to this 147 document with the following exception: ED-60/AN-25 is not 148 applicable as HELD is not used. Video and real-time text may be 149 supported by end device in the future, although currently not 150 envisioned. The corresponding text paragraphs are relevant from 151 Section 9 of [2] when support is being provided. Additionally, 152 ED-62 dealing with "SIP signaling requirements for User Agents" is 153 simplified as follows. The initial SIP signaling method is an 154 INVITE request with the following setting: 156 1. The Request URI MUST be the service URN 'urn:service:ecall'. 158 2. The To header MUST be a service URN 'urn:service:ecall'. 160 3. The From header MUST be present and SHOULD be the AoR of the 161 caller. 163 4. A Via header MUST be present. 165 5. A Contact header MUST be present which MUST be globally 166 routable to permit an immediate call-back to the specific 167 device which placed the emergency call. 169 6. Other headers MAY be included as per normal SIP behavior. 171 7. A Supported header MUST be included with the 'geolocation' 172 option tag [4]. 174 8. The device MUST include location by-value into the call. 176 9. A normal SDP offer SHOULD be included in the INVITE. If 177 voice is supported the offer SHOULD include the G.711 codec, 178 if a voice channel can be established based on the equipment 179 in the car. 181 10. If the device includes location-by-value, the UA MUST support 182 multipart message bodies, since SDP will likely be also in 183 the INVITE. 185 11. The UAC MUST include a "inserted-by=endpoint" header 186 parameter on all Geolocation headers. This informs 187 downstream elements which device entered the location at this 188 URI (either cid-URL or location-by-reference URI). 190 12. SIP Caller Preferences [5] MAY be used to signal how the PSAP 191 should handle the call. For example, a language preference 192 expressed in an Accept-Language header may be used as a hint 193 to cause the PSAP to route the call to a call taker who 194 speaks the requested language. SIP Caller Preferences may 195 also be used to indicate a need to invoke a relay service for 196 communication with people with disabilities in the call. 198 Call backs: The description in Section 10 of [2] is relevant for 199 this document. 201 Mid-call behavior: The description in Section 11 of [2] is fully 202 applicable to this document. 204 Call termination: The description in Section 12 of [2] is fully 205 applicable to this document. 207 Disabling of features: The description in Section 13 of [2] is fully 208 applicable to this document. 210 Media: If hardware and software for real-time text, voice, and video 211 is available in the end device then the requirements regarding 212 multi-media support described in [2] are applicable. 214 Testing: The description in Section 15 of [2] is fully applicable to 215 this document. 217 4. Data Profile 219 Due to the requirement for a built-in GPS receiver only geodetic 220 location information will be sent within an emergency call. 221 Furthermore, the number of location shapes is is restricted. Hence, 222 the following location shapes of [6] MUST be implemented: 2d and 3d 223 Point (see Section 5.2.1 of [6]), Circle (see Section 5.2.3 of [6]), 224 and Ellipsoid (see Section 5.2.7 of [6]). The coordinate reference 225 systems (CRS) specified in [6] are also mandatory for this document. 226 Furthermore, the direction of travel of the vehicle is important for 227 dispatch and hence it MUST be included in the PIDF-LO. The 228 element specified in [7] MUST be supported. 230 5. Example 232 Figure 1 shows an emergency call placed from a vehicle whereby 233 location information information is directly attached to the SIP 234 INVITE message itself. The call is marked as an emergency call using 235 the 'urn:service:ecall' service URN and the PSAP of the VoIP provider 236 determines which PSAP to contact based on the provided location 237 information. As shown in the figure, this route determination may be 238 based on LoST. Then, the emergency call continues towards the PSAP 239 and in this example it hits the ESRP, as the entry point to the PSAP 240 operators emergency services network. Finally, the emergency call 241 will be received by a call taker and first reponders will be 242 dispatched. 244 +--------+ 245 | LoST | 246 | Servers| 247 +--------+ 248 ^ +-------+ 249 | | PSAP2 | 250 | +-------+ 251 v 252 +-------+ +------+ +-------+ 253 Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 254 +-------+ +------+ +-------+ 256 +-------+ 257 | PSAP3 | 258 +-------+ 260 Figure 1: Example of In-Vehicular Emergency Call Message Flow 262 The following example, in Figure 2, shows location information 263 encoded in a PIDF-LO that is being conveyed in such an emergency 264 call. 266 267 272 273 274 275 276 42.5463 -73.2512 277 278 850.24 279 280 281 282 283 270.0 -60.0 284 285 286 287 288 GPS 289 290 291 293 Figure 2: Example of Location Payload for In-Vehicular Emergency Call 295 6. Security Considerations 297 This document does not raise security considerations beyond those 298 described in [10]. As with emergency service systems with end host 299 provided location information there is the possibility that that 300 location is incorrect, either intentially (in case of an a denial of 301 service attack against the emergency services infrastructure) or due 302 to a malfunctioning devices. The reader is referred to [11] for a 303 discussion of some of these vulnerabilities. 305 7. IANA Considerations 307 IANA is requested to register the URN 'urn:service:ecall' under the 308 sub-services 'sos' registry defined in Section 4.2 of [8]. 310 urn:service:ecall This service identifier reaches a public safety 311 answering point (PSAP), which in turn dispatches aid appropriate 312 to the emergency related to accidents of vehicles. 314 8. Contributors 316 We would like to thank Ulrich Dietz for his help with earlier 317 versions of the document. 319 9. Acknowledgements 321 We would like to thank Michael Montag, Arnoud van Wijk, and Gunnar 322 Hellstroem for their feedback. 324 10. References 326 10.1. Normative References 328 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 329 Levels", BCP 14, RFC 2119, March 1997. 331 [2] Rosen, B. and J. Polk, "Best Current Practice for 332 Communications Services in support of Emergency Calling", 333 draft-ietf-ecrit-phonebcp-20 (work in progress), 334 September 2011. 336 [3] Peterson, J., "A Presence-based GEOPRIV Location Object 337 Format", RFC 4119, December 2005. 339 [4] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for 340 the Session Initiation Protocol", RFC 6442, December 2011. 342 [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 343 Preferences for the Session Initiation Protocol (SIP)", 344 RFC 3841, August 2004. 346 [6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 347 Presence Information Data Format Location Object (PIDF-LO) 348 Usage Clarification, Considerations, and Recommendations", 349 RFC 5491, March 2009. 351 [7] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, 352 "Dynamic Extensions to the Presence Information Data Format 353 Location Object (PIDF-LO)", RFC 5962, September 2010. 355 [8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency 356 and Other Well-Known Services", RFC 5031, January 2008. 358 10.2. Informative references 360 [9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 361 Context Resolution with Internet Technologies", RFC 5012, 362 January 2008. 364 [10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, 365 "Security Threats and Requirements for Emergency Call Marking 366 and Mapping", RFC 5069, January 2008. 368 [11] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy 369 Location Information", draft-ietf-ecrit-trustworthy-location-02 370 (work in progress), May 2011. 372 Authors' Addresses 374 Brian Rosen 375 NeuStar, Inc. 376 470 Conrad Dr 377 Mars, PA 16046 378 US 380 Phone: 381 Email: br@brianrosen.net 383 Hannes Tschofenig 384 Nokia Siemens Networks 385 Linnoitustie 6 386 Espoo 02600 387 Finland 389 Phone: +358 (50) 4871445 390 Email: Hannes.Tschofenig@gmx.net 391 URI: http://www.tschofenig.priv.at