idnits 2.17.00 (12 Aug 2021) /tmp/idnits38275/draft-rosen-ecrit-ecall-03.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 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 6, 2010) is 4459 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-sipcore-location-conveyance has been published as RFC 6442 == Outdated reference: draft-singh-geopriv-pidf-lo-dynamic has been published as RFC 5962 == Outdated reference: A later version (-03) exists of draft-tschofenig-ecrit-trustworthy-location-02 Summary: 1 error (**), 0 flaws (~~), 5 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 7, 2010 Nokia Siemens Networks 6 U. Dietz 7 Vodafone 8 March 6, 2010 10 Best Current Practice for IP-based In-Vehicle Emergency Calls 11 draft-rosen-ecrit-ecall-03.txt 13 Abstract 15 This document describes how to use a subset of the IETF-based 16 emergency call framework for accomplishing emergency calling support 17 in vehicles. Simplifications are possible due to the nature of the 18 functionality that is going to be provided in vehicles with the usage 19 of GPS. Additionally, further profiling needs to be done regarding 20 the encoding of location information. 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 September 7, 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. Protocol Profile . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 70 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 73 10.2. Informative references . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 Emergency calls made from vehicles can assist with the objective of 79 significantly reducing road deaths and injuries. Unfortunately, 80 drivers often have a poor location-awareness, especially on urban 81 roads (also during night) and abroad. In the most crucial cases, the 82 victim(s) may not be able to call because they have been injured or 83 trapped. 85 In Europe the European Commission has launched the eCall initiative 86 that may best be described as a user initiated or automatically 87 triggered system to provide notifications to Public Safety Answering 88 Point's (PSAP), by means of cellular communications, that a vehicle 89 has crashed, and to provide geodetic location information and where 90 possible a voice channel to the PSAP. The current specifications 91 being developed to offer the eCall solution are defined to work with 92 circuit switched telephony. This document details how the same 93 functionality can be accomplished using IP-based mechanisms. Since 94 cellular systems are being enhanced with IP-based infrastructure this 95 document complements the ambiguous goal to provide widespread 96 availability of in-vehicular emergency services solutions. 98 This document is organized as follows: Section 2 defines the 99 terminology, Section 3 illustrates the required protocol 100 functionality, Section 4 indicates the required data that has to be 101 transmitted within a PIDF-LO and Section 5 shows an example message 102 exchange. This document concludes with the security considerations 103 in Section 6 and IANA considerations in Section 7. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [1]. 111 This document re-uses a lot of the terminology defined in Section 3 112 of [9]. 114 3. Protocol Profile 116 The usage of in-vehicular emergency calls does not require the usage 117 of a Location Configuration Protocol since GPS is used. Furthermore, 118 since the GPS receiver is permanently turned on it can even provide 119 useful information in cases where the car entered a tunnel. 120 Consequently, there is no need to discover any LIS. 122 Since the emergency call within the car is either triggered by a 123 button or, in most cases, automatically thanks to sensors mounted in 124 the car there is no need to learn a dial string. This document 125 registers a separate Service URN, namely 'urn:service:ecall', used 126 specifically for emergency calls that are triggered by vehicles. 128 The following list provides information about the sections and 129 requires of [2] that are relevant to this specification: 131 Identifying an emergency call: Emergency calls are detected at the 132 end point, i.e., by the vehicle, and the Service URN 133 'urn:service:ecall' MUST be implemented by the end point and 134 recognized by the VSP. The requirements listed in Section 5 of 135 [2] are therefore irrelevant to this specification, as they deal 136 with identifying an emergency call based on dial strings. 138 Location: The encoding of the PIDF-LO [3] is described in Section 4. 139 In an emergency, the end point adds the available location 140 information to the initial SIP INVITE emergency call message. In 141 special cases a location update may be provided, using the 142 procedure described in requirement ED-38 of Section 6.8 of [2]; 143 all other aspects of Section 6.8 from that document are not 144 applicable to this specification. Section 6.2.1, 6.2.2, 6.2.4, 145 6.4, 6.5 and 6.6 of [2] are not applicable to this document. For 146 location conveyance in SIP [4] MUST be used. Further aspects that 147 are not relevant for this document are multiple locations (Section 148 6.9 of [2]), location validation (Section 6.10 of [2]), default 149 location (Section 6.11 of [2]) 151 LoST: Emergency call routing support, for example utilizing LoST, is 152 provided by VSP. As such, the description in Section 8 of [2] is 153 applicable to this document, except for requirement SP-25 and 154 SP-26 regarding legacy devices. 156 Signaling of emergency calls: Section 9 of [2] is applicable to this 157 document with the following exception: ED-60/AN-25 is not 158 applicable as HELD is not used. Video and real-time text may be 159 supported by end device in the future, although currently not 160 envisioned. The corresponding text paragraphs are relevant from 161 Section 9 of [2] when support is being provided. Additionally, 162 ED-62 dealing with "SIP signaling requirements for User Agents" is 163 simplified as follows. The initial SIP signaling method is an 164 INVITE request with the following setting: 166 1. The Request URI MUST be the service URN 'urn:service:ecall'. 168 2. The To header MUST be a service URN 'urn:service:ecall'. 170 3. The From header MUST be present and SHOULD be the AoR of the 171 caller. 173 4. A Via header MUST be present. 175 5. A Contact header MUST be present which MUST be globally 176 routable to permit an immediate call-back to the specific 177 device which placed the emergency call. 179 6. Other headers MAY be included as per normal SIP behavior. 181 7. A Supported header MUST be included with the 'geolocation' 182 option tag [4]. 184 8. The device MUST include location by-value into the call. 186 9. A normal SDP offer SHOULD be included in the INVITE. If 187 voice is supported the offer SHOULD include the G.711 codec, 188 if a voice channel can be established based on the equipment 189 in the car. 191 10. If the device includes location-by-value, the UA MUST support 192 multipart message bodies, since SDP will likely be also in 193 the INVITE. 195 11. The UAC MUST include a "inserted-by=endpoint" header 196 parameter on all Geolocation headers. This informs 197 downstream elements which device entered the location at this 198 URI (either cid-URL or location-by-reference URI). 200 12. SIP Caller Preferences [5] MAY be used to signal how the PSAP 201 should handle the call. For example, a language preference 202 expressed in an Accept-Language header may be used as a hint 203 to cause the PSAP to route the call to a call taker who 204 speaks the requested language. SIP Caller Preferences may 205 also be used to indicate a need to invoke a relay service for 206 communication with people with disabilities in the call. 208 Call backs: The description in Section 10 of [2] is relevant for 209 this document. 211 Mid-call behavior: The description in Section 11 of [2] is fully 212 applicable to this document. 214 Call termination: The description in Section 12 of [2] is fully 215 applicable to this document. 217 Disabling of features: The description in Section 13 of [2] is fully 218 applicable to this document. 220 Media: Real-time text and video may be supported in devices some 221 time in the future. If voice calls are supported then the 222 description in Section 14 is applicable to this document. 224 Testing: The description in Section 15 of [2] is fully applicable to 225 this document. 227 4. Data Profile 229 Due to the requirement for a built-in GPS receiver only geodetic 230 location information will be sent within an emergency call. 231 Furthermore, the number of location shapes is is restricted. Hence, 232 the following location shapes of [6] MUST be implemented: 2d and 3d 233 Point (see Section 5.2.1 of [6]), Circle (see Section 5.2.3 of [6]), 234 and Ellipsoid (see Section 5.2.7 of [6]). The coordinate reference 235 systems (CRS) specified in [6] are also mandatory for this document. 236 Furthermore, the direction of travel of the vehicle is important for 237 dispatch and hence it MUST be included in the PIDF-LO. The 238 element specified in [7] MUST be supported. 240 5. Example 242 Figure 1 shows an emergency call placed from a vehicle whereby 243 location information information is directly attached to the SIP 244 INVITE message itself. The call is marked as an emergency call using 245 the 'urn:service:ecall' service URN and the PSAP of the VoIP provider 246 determines which PSAP to contact based on the provided location 247 information. As shown in the figure, this route determination may be 248 based on LoST. Then, the emergency call continues towards the PSAP 249 and in this example it hits the ESRP, as the entry point to the PSAP 250 operators emergency services network. Finally, the emergency call 251 will be received by a call taker and first reponders will be 252 dispatched. 254 +--------+ 255 | LoST | 256 | Servers| 257 +--------+ 258 ^ +-------+ 259 | | PSAP2 | 260 | +-------+ 261 v 262 +-------+ +------+ +-------+ 263 Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 264 +-------+ +------+ +-------+ 266 +-------+ 267 | PSAP3 | 268 +-------+ 270 Figure 1: Example of In-Vehicular Emergency Call Message Flow 272 The following example, in Figure 2, shows location information 273 encoded in a PIDF-LO that is being conveyed in such an emergency 274 call. 276 277 282 283 284 285 286 42.5463 -73.2512 287 288 850.24 289 290 291 292 293 270.0 -60.0 294 295 296 297 298 GPS 299 300 301 303 Figure 2: Example of In-Vehicular Emergency Call Message Flow 305 6. Security Considerations 307 This document does not raise security considerations beyond those 308 described in [10]. As with emergency service systems with end host 309 provided location information there is the possibility that that 310 location is incorrect, either intentially (in case of an a denial of 311 service attack against the emergency services infrastructure) or due 312 to a malfunctioning devices. The reader is referred to [11] for a 313 discussion of some of these vulnerabilities. 315 7. IANA Considerations 317 IANA is requested to register the URN 'urn:service:ecall' under the 318 sub-services 'sos' registry defined in Section 4.2 of [8]. 320 urn:service:ecall This service identifier reaches a public safety 321 answering point (PSAP), which in turn dispatches aid appropriate 322 to the emergency related to accidents of vehicles. 324 8. Acknowledgements 326 We would like to thank Michael Montag for his feedback. 328 9. Open Issues 330 While working on this document a few aspects where discovered that 331 require further discussion: 333 o Today's work on the eCall system does not necessarily require a 334 voice call to be established; a voice call may be established 335 whenever possible by the functionality offered by the device. 336 From a protocol mechanims, however, the design for establishing an 337 emergency call including voice and without voice support are 338 somewhat different. Further discussion on the design aspects are 339 needed to align this aspect. 341 o This document currently defines a new service URN to differentiate 342 it from ordinary calls as in-vehicular emergency calls are, in 343 some countries, routed to different PSAPs than regular emergency 344 calls. More thoughts are needed to determine whether this is the 345 best approach. 347 o The current version of the document assumes the usage of LoST at 348 the VSP to perform call routing of the in-vehicular emergency 349 call. This is useful when there are no dial strings need to be 350 learned nor any other service URNs need to be discovered. Further 351 discussion is needed whether additional service URNs might be made 352 available to the vehicle, for example to request roadside 353 assistance or similar services. In that case the option might be 354 provided to run LoST at the end host as well as on the VSP. 356 10. References 358 10.1. Normative References 360 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 361 Levels", BCP 14, RFC 2119, March 1997. 363 [2] Rosen, B. and J. Polk, "Best Current Practice for 364 Communications Services in support of Emergency Calling", 365 draft-ietf-ecrit-phonebcp-14 (work in progress), January 2010. 367 [3] Peterson, J., "A Presence-based GEOPRIV Location Object 368 Format", RFC 4119, December 2005. 370 [4] Polk, J. and B. Rosen, "Location Conveyance for the Session 371 Initiation Protocol", draft-ietf-sipcore-location-conveyance-02 372 (work in progress), February 2010. 374 [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 375 Preferences for the Session Initiation Protocol (SIP)", 376 RFC 3841, August 2004. 378 [6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 379 Presence Information Data Format Location Object (PIDF-LO) 380 Usage Clarification, Considerations, and Recommendations", 381 RFC 5491, March 2009. 383 [7] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, 384 "Dynamic Extensions to the Presence Information Data Format 385 Location Object (PIDF-LO)", 386 draft-singh-geopriv-pidf-lo-dynamic-07 (work in progress), 387 August 2009. 389 [8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency 390 and Other Well-Known Services", RFC 5031, January 2008. 392 10.2. Informative references 394 [9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 395 Context Resolution with Internet Technologies", RFC 5012, 396 January 2008. 398 [10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, 399 "Security Threats and Requirements for Emergency Call Marking 400 and Mapping", RFC 5069, January 2008. 402 [11] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy 403 Location Information", 404 draft-tschofenig-ecrit-trustworthy-location-02 (work in 405 progress), July 2009. 407 Authors' Addresses 409 Brian Rosen 410 NeuStar, Inc. 411 470 Conrad Dr 412 Mars, PA 16046 413 US 415 Phone: 416 Email: br@brianrosen.net 418 Hannes Tschofenig 419 Nokia Siemens Networks 420 Linnoitustie 6 421 Espoo 02600 422 Finland 424 Phone: +358 (50) 4871445 425 Email: Hannes.Tschofenig@gmx.net 426 URI: http://www.tschofenig.priv.at 428 Ulrich Dietz 429 Vodafone 430 Chiemgaustrasse 116 431 Munich 81549 432 Germany 434 Email: Ulrich.Dietz@vodafone.com