idnits 2.17.00 (12 Aug 2021) /tmp/idnits37030/draft-rosen-ecrit-ecall-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 7, 2009) is 4823 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: A later version (-13) exists of draft-ietf-sip-location-conveyance-12 == 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 == Outdated reference: A later version (-03) exists of draft-tschofenig-ecrit-trustworthy-location-01 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: Informational H. Tschofenig 5 Expires: September 8, 2009 Nokia Siemens Networks 6 U. Dietz 7 Vodafone 8 March 7, 2009 10 Best Current Practice for IP-based In-Vehicle Emergency Calls 11 draft-rosen-ecrit-ecall-02.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and 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 September 8, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document describes how to use a subset of the IETF-based 50 emergency call framework for accomplishing emergency calling support 51 in vehicles. Simplifications are possible due to the nature of the 52 functionality that is going to be provided in vehicles with the usage 53 of GPS. Additionally, further profiling needs to be done regarding 54 the encoding of location information. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Protocol Profile . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 66 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 69 10.2. Informative references . . . . . . . . . . . . . . . . . 15 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 72 1. Introduction 74 Emergency calls made from vehicles can assist with the objective of 75 significantly reducing road deaths and injuries. Unfortunately, 76 drivers often have a poor location-awareness, especially on urban 77 roads (also during night) and abroad. In the most crucial cases, the 78 victim(s) may not be able to call because they have been injured or 79 trapped. 81 In Europe the European Commission has launched the eCall initiative 82 that may best be described as a user initiated or automatically 83 triggered system to provide notifications to Public Safety Answering 84 Point's (PSAP), by means of cellular communications, that a vehicle 85 has crashed, and to provide geodetic location information and where 86 possible a voice channel to the PSAP. The current specifications 87 being developed to offer the eCall solution are defined to work with 88 circuit switched telephony. This document details how the same 89 functionality can be accomplished using IP-based mechanisms. Since 90 cellular systems are being enhanced with IP-based infrastructure this 91 document complements the ambiguous goal to provide widespread 92 availability of in-vehicular emergency services solutions. 94 This document is organized as follows: Section 2 defines the 95 terminology, Section 3 illustrates the required protocol 96 functionality, Section 4 indicates the required data that has to be 97 transmitted within a PIDF-LO and Section 5 shows an example message 98 exchange. This document concludes with the security considerations 99 in Section 6 and IANA considerations in Section 7. 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 a lot of the terminology defined in Section 3 108 of [9]. 110 3. Protocol Profile 112 The usage of in-vehicular emergency calls does not require the usage 113 of a Location Configuration Protocol since GPS is used. Furthermore, 114 since the GPS receiver is permanently turned on it can even provide 115 useful information in cases where the car entered a tunnel. 116 Consequently, there is no need to discover any LIS. 118 Since the emergency call within the car is either triggered by a 119 button or, in most cases, automatically thanks to sensors mounted in 120 the car there is no need to learn a dial string. This document 121 registers a separate Service URN, namely 'urn:service:ecall', used 122 specifically for emergency calls that are triggered by vehicles. 124 The following list provides information about the sections and 125 requires of [2] that are relevant to this specification: 127 Identifying an emergency call: Emergency calls are detected at the 128 end point, i.e., by the vehicle, and the Service URN 129 'urn:service:ecall' MUST be implemented by the end point and 130 recognized by the VSP. The requirements listed in Section 5 of 131 [2] are therefore irrelevant to this specification, as they deal 132 with identifying an emergency call based on dial strings. 134 Location: The encoding of the PIDF-LO [3] is described in Section 4. 135 In an emergency, the end point adds the available location 136 information to the initial SIP INVITE emergency call message. In 137 special cases a location update may be provided, using the 138 procedure described in requirement ED-38 of Section 6.8 of [2]; 139 all other aspects of Section 6.8 from that document are not 140 applicable to this specification. Section 6.2.1, 6.2.2, 6.2.4, 141 6.4, 6.5 and 6.6 of [2] are not applicable to this document. For 142 location conveyance in SIP [4] MUST be used. Further aspects that 143 are not relevant for this document are multiple locations (Section 144 6.9 of [2]), location validation (Section 6.10 of [2]), default 145 location (Section 6.11 of [2]) 147 LoST: Emergency call routing support, for example utilizing LoST, is 148 provided by VSP. As such, the description in Section 8 of [2] is 149 applicable to this document, except for requirement SP-25 and 150 SP-26 regarding legacy devices. 152 Signaling of emergency calls: Section 9 of [2] is applicable to this 153 document with the following exception: ED-60/AN-25 is not 154 applicable as HELD is not used. Video and real-time text may be 155 supported by end device in the future, although currently not 156 envisioned. The corresponding text paragraphs are relevant from 157 Section 9 of [2] when support is being provided. Additionally, 158 ED-62 dealing with "SIP signaling requirements for User Agents" is 159 simplified as follows. The initial SIP signaling method is an 160 INVITE request with the following setting: 162 1. The Request URI MUST be the service URN 'urn:service:ecall'. 164 2. The To header MUST be a service URN 'urn:service:ecall'. 166 3. The From header MUST be present and SHOULD be the AoR of the 167 caller. 169 4. A Via header MUST be present. 171 5. A Contact header MUST be present which MUST be globally 172 routable to permit an immediate call-back to the specific 173 device which placed the emergency call. 175 6. Other headers MAY be included as per normal SIP behavior. 177 7. A Supported header MUST be included with the 'geolocation' 178 option tag [4]. 180 8. The device MUST include location by-value into the call. 182 9. A normal SDP offer SHOULD be included in the INVITE. If 183 voice is supported the offer SHOULD include the G.711 codec, 184 if a voice channel can be established based on the equipment 185 in the car. 187 10. If the device includes location-by-value, the UA MUST support 188 multipart message bodies, since SDP will likely be also in 189 the INVITE. 191 11. The UAC MUST include a "inserted-by=endpoint" header 192 parameter on all Geolocation headers. This informs 193 downstream elements which device entered the location at this 194 URI (either cid-URL or location-by-reference URI). 196 12. SIP Caller Preferences [5] MAY be used to signal how the PSAP 197 should handle the call. For example, a language preference 198 expressed in an Accept-Language header may be used as a hint 199 to cause the PSAP to route the call to a call taker who 200 speaks the requested language. SIP Caller Preferences may 201 also be used to indicate a need to invoke a relay service for 202 communication with people with disabilities in the call. 204 Call backs: The description in Section 10 of [2] is relevant for 205 this document. 207 Mid-call behavior: The description in Section 11 of [2] is fully 208 applicable to this document. 210 Call termination: The description in Section 12 of [2] is fully 211 applicable to this document. 213 Disabling of features: The description in Section 13 of [2] is fully 214 applicable to this document. 216 Media: Real-time text and video may be supported in devices some 217 time in the future. If voice calls are supported then the 218 description in Section 14 is applicable to this document. 220 Testing: The description in Section 15 of [2] is fully applicable to 221 this document. 223 4. Data Profile 225 Due to the requirement for a built-in GPS receiver only geodetic 226 location information will be sent within an emergency call. 227 Furthermore, the number of location shapes is is restricted. Hence, 228 the following location shapes of [6] MUST be implemented: 2d and 3d 229 Point (see Section 5.2.1 of [6]), Circle (see Section 5.2.3 of [6]), 230 and Ellipsoid (see Section 5.2.7 of [6]). The coordinate reference 231 systems (CRS) specified in [6] are also mandatory for this document. 232 Furthermore, the direction of travel of the vehicle is important for 233 dispatch and hence it MUST be included in the PIDF-LO. The 234 element specified in [7] MUST be supported. 236 5. Example 238 Figure 1 shows an emergency call placed from a vehicle whereby 239 location information information is directly attached to the SIP 240 INVITE message itself. The call is marked as an emergency call using 241 the 'urn:service:ecall' service URN and the PSAP of the VoIP provider 242 determines which PSAP to contact based on the provided location 243 information. As shown in the figure, this route determination may be 244 based on LoST. Then, the emergency call continues towards the PSAP 245 and in this example it hits the ESRP, as the entry point to the PSAP 246 operators emergency services network. Finally, the emergency call 247 will be received by a call taker and first reponders will be 248 dispatched. 250 +--------+ 251 | LoST | 252 | Servers| 253 +--------+ 254 ^ +-------+ 255 | | PSAP2 | 256 | +-------+ 257 v 258 +-------+ +------+ +-------+ 259 Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 260 +-------+ +------+ +-------+ 262 +-------+ 263 | PSAP3 | 264 +-------+ 266 Figure 1: Example of In-Vehicular Emergency Call Message Flow 268 The following example, in Figure 2, shows location information 269 encoded in a PIDF-LO that is being conveyed in such an emergency 270 call. 272 273 278 279 280 281 282 42.5463 -73.2512 283 284 850.24 285 286 287 288 289 270.0 -60.0 290 291 292 293 294 GPS 295 296 297 299 Figure 2: Example of In-Vehicular Emergency Call Message Flow 301 6. Security Considerations 303 This document does not raise security considerations beyond those 304 described in [10]. As with emergency service systems with end host 305 provided location information there is the possibility that that 306 location is incorrect, either intentially (in case of an a denial of 307 service attack against the emergency services infrastructure) or due 308 to a malfunctioning devices. The reader is referred to [11] for a 309 discussion of some of these vulnerabilities. 311 7. IANA Considerations 313 IANA is requested to register the URN 'urn:service:ecall' under the 314 sub-services 'sos' registry defined in Section 4.2 of [8]. 316 urn:service:ecall This service identifier reaches a public safety 317 answering point (PSAP), which in turn dispatches aid appropriate 318 to the emergency related to accidents of vehicles. 320 8. Acknowledgements 322 We would like to thank Michael Montag for his feedback. 324 9. Open Issues 326 While working on this document a few aspects where discovered that 327 require further discussion: 329 o Today's work on the eCall system does not necessarily require a 330 voice call to be established; a voice call may be established 331 whenever possible by the functionality offered by the device. 332 From a protocol mechanims, however, the design for establishing an 333 emergency call including voice and without voice support are 334 somewhat different. Further discussion on the design aspects are 335 needed to align this aspect. 337 o This document currently defines a new service URN to differentiate 338 it from ordinary calls as in-vehicular emergency calls are, in 339 some countries, routed to different PSAPs than regular emergency 340 calls. More thoughts are needed to determine whether this is the 341 best approach. 343 o The current version of the document assumes the usage of LoST at 344 the VSP to perform call routing of the in-vehicular emergency 345 call. This is useful when there are no dial strings need to be 346 learned nor any other service URNs need to be discovered. Further 347 discussion is needed whether additional service URNs might be made 348 available to the vehicle, for example to request roadside 349 assistance or similar services. In that case the option might be 350 provided to run LoST at the end host as well as on the VSP. 352 10. References 354 10.1. Normative References 356 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 357 Levels", BCP 14, RFC 2119, March 1997. 359 [2] Rosen, B. and J. Polk, "Best Current Practice for 360 Communications Services in support of Emergency Calling", 361 draft-ietf-ecrit-phonebcp-08 (work in progress), February 2009. 363 [3] Peterson, J., "A Presence-based GEOPRIV Location Object 364 Format", RFC 4119, December 2005. 366 [4] Polk, J. and B. Rosen, "Location Conveyance for the Session 367 Initiation Protocol", draft-ietf-sip-location-conveyance-12 368 (work in progress), November 2008. 370 [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 371 Preferences for the Session Initiation Protocol (SIP)", 372 RFC 3841, August 2004. 374 [6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 375 PIDF-LO Usage Clarification, Considerations and 376 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 (work 377 in progress), November 2008. 379 [7] Vishal, S., Schulzrinne, H., and H. Tschofenig, "Dynamic 380 Feature Extensions to the Presence Information Data Format 381 Location Object (PIDF-LO)", 382 draft-singh-geopriv-pidf-lo-dynamic-04 (work in progress), 383 October 2008. 385 [8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency 386 and Other Well-Known Services", RFC 5031, January 2008. 388 10.2. Informative references 390 [9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 391 Context Resolution with Internet Technologies", RFC 5012, 392 January 2008. 394 [10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, 395 "Security Threats and Requirements for Emergency Call Marking 396 and Mapping", RFC 5069, January 2008. 398 [11] Tschofenig, H. and H. Schulzrinne, "Trustworthy Location 399 Information", draft-tschofenig-ecrit-trustworthy-location-01 400 (work in progress), March 2009. 402 Authors' Addresses 404 Brian Rosen 405 NeuStar, Inc. 406 470 Conrad Dr 407 Mars, PA 16046 408 US 410 Phone: 411 Email: br@brianrosen.net 413 Hannes Tschofenig 414 Nokia Siemens Networks 415 Linnoitustie 6 416 Espoo 02600 417 Finland 419 Phone: +358 (50) 4871445 420 Email: Hannes.Tschofenig@gmx.net 421 URI: http://www.tschofenig.priv.at 423 Ulrich Dietz 424 Vodafone 425 Chiemgaustrasse 116 426 Munich 81549 427 Germany 429 Email: Ulrich.Dietz@vodafone.com