idnits 2.17.00 (12 Aug 2021) /tmp/idnits36195/draft-rosen-ecrit-ecall-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 461. 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 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 12, 2008) is 5061 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == 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-10 -- Possible downref: Normative reference to a draft: ref. '4' == 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-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 8 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: BCP H. Tschofenig 5 Expires: January 13, 2009 Nokia Siemens Networks 6 U. Dietz 7 Vodafone 8 July 12, 2008 10 Best Current Practice for IP-based In-Vehicle Emergency Calls 11 draft-rosen-ecrit-ecall-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 13, 2009. 38 Abstract 40 This document describes how to use a subset of the IETF-based 41 emergency call framework for accomplishing emergency calling support 42 in vehicles. Simplifications are possible due to the nature of the 43 functionality that is going to be provided in vehicles with the usage 44 of GPS. Additionally, further profiling needs to be done regarding 45 the encoding of location information. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Protocol Profile . . . . . . . . . . . . . . . . . . . . . . . 5 52 4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 53 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 56 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 57 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 60 10.2. Informative references . . . . . . . . . . . . . . . . . 15 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 62 Intellectual Property and Copyright Statements . . . . . . . . . . 18 64 1. Introduction 66 Emergency calls made from vehicles can assist with the objective of 67 significantly reducing road deaths and injuries. Unfortunately, 68 drivers often have a poor location-awareness, especially on urban 69 roads (also during night) and abroad. In the most crucial cases, the 70 victim(s) may not be able to call because they have been injured or 71 trapped. 73 In Europe the European Commission has launched the eCall initiative 74 that may best be described as a user initiated or automatically 75 triggered system to provide notifications to Public Safety Answering 76 Point's (PSAP), by means of cellular communications, that a vehicle 77 has crashed, and to provide geodetic location information and where 78 possible a voice channel to the PSAP. The current specifications 79 being developed to offer the eCall solution are defined to work with 80 circuit switched telephony. This document details how the same 81 functionality can be accomplished using IP-based mechanisms. Since 82 cellular systems are being enhanced with IP-based infrastructure this 83 document complements the ambiguous goal to provide widespread 84 availability of in-vehicular emergency services solutions. 86 This document is organized as follows: Section 2 defines the 87 terminology, Section 3 illustrates the required protocol 88 functionality, Section 4 indicates the required data that has to be 89 transmitted within a PIDF-LO and Section 5 shows an example message 90 exchange. This document concludes with the security considerations 91 in Section 6 and IANA considerations in Section 7. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [1]. 99 This document re-uses a lot of the terminology defined in Section 3 100 of [9]. 102 3. Protocol Profile 104 The usage of in-vehicular emergency calls does not require the usage 105 of a Location Configuration Protocol since GPS is used. Furthermore, 106 since the GPS receiver is permanently turned on it can even provide 107 useful information in cases where the car entered a tunnel. 108 Consequently, there is no need to discover any LIS. 110 Since the emergency call within the car is either triggered by a 111 button or, in most cases, automatically thanks to sensors mounted in 112 the car there is no need to learn a dial string. This document 113 registers a separate Service URN, namely 'urn:service:ecall', used 114 specifically for emergency calls that are triggered by vehicles. 116 The following list provides information about the sections and 117 requires of [2] that are relevant to this specification: 119 Identifying an emergency call: Emergency calls are detected at the 120 end point, i.e., by the vehicle, and the Service URN 121 'urn:service:ecall' MUST be implemented by the end point and 122 recognized by the VSP. The requirements listed in Section 5 of 123 [2] are therefore irrelevant to this specification, as they deal 124 with identifying an emergency call based on dial strings. 126 Location: The encoding of the PIDF-LO [3] is described in Section 4. 127 In an emergency, the end point adds the available location 128 information to the initial SIP INVITE emergency call message. In 129 special cases a location update may be provided, using the 130 procedure described in requirement ED-38 of Section 6.8 of [2]; 131 all other aspects of Section 6.8 from that document are not 132 applicable to this specification. Section 6.2.1, 6.2.2, 6.2.4, 133 6.4, 6.5 and 6.6 of [2] are not applicable to this document. For 134 location conveyance in SIP [4] MUST be used. Further aspects that 135 are not relevant for this document are multiple locations (Section 136 6.9 of [2]), location validation (Section 6.10 of [2]), default 137 location (Section 6.11 of [2]) 139 LoST: Emergency call routing support, for example utilizing LoST, is 140 provided by VSP. As such, the description in Section 8 of [2] is 141 applicable to this document, except for requirement SP-25 and 142 SP-26 regarding legacy devices. 144 Signaling of emergency calls: Section 9 of [2] is applicable to this 145 document with the following exception: ED-60/AN-25 is not 146 applicable as HELD is not used. Video and real-time text may be 147 supported by end device in the future, although currently not 148 envisioned. The corresponding text paragraphs are relevant from 149 Section 9 of [2] when support is being provided. Additionally, 150 ED-62 dealing with "SIP signaling requirements for User Agents" is 151 simplified as follows. The initial SIP signaling method is an 152 INVITE request with the following setting: 154 1. The Request URI MUST be the service URN 'urn:service:ecall'. 156 2. The To header MUST be a service URN 'urn:service:ecall'. 158 3. The From header MUST be present and SHOULD be the AoR of the 159 caller. 161 4. A Via header MUST be present. 163 5. A Contact header MUST be present which MUST be globally 164 routable to permit an immediate call-back to the specific 165 device which placed the emergency call. 167 6. Other headers MAY be included as per normal SIP behavior. 169 7. A Supported header MUST be included with the 'geolocation' 170 option tag [4]. 172 8. The device MUST include location by-value into the call. 174 9. A normal SDP offer SHOULD be included in the INVITE. If 175 voice is supported the offer SHOULD include the G.711 codec, 176 if a voice channel can be established based on the equipment 177 in the car. 179 10. If the device includes location-by-value, the UA MUST support 180 multipart message bodies, since SDP will likely be also in 181 the INVITE. 183 11. The UAC MUST include a "inserted-by=endpoint" header 184 parameter on all Geolocation headers. This informs 185 downstream elements which device entered the location at this 186 URI (either cid-URL or location-by-reference URI). 188 12. SIP Caller Preferences [5] MAY be used to signal how the PSAP 189 should handle the call. For example, a language preference 190 expressed in an Accept-Language header may be used as a hint 191 to cause the PSAP to route the call to a call taker who 192 speaks the requested language. SIP Caller Preferences may 193 also be used to indicate a need to invoke a relay service for 194 communication with people with disabilities in the call. 196 Call backs: The description in Section 10 of [2] is relevant for 197 this document. 199 Mid-call behavior: The description in Section 11 of [2] is fully 200 applicable to this document. 202 Call termination: The description in Section 12 of [2] is fully 203 applicable to this document. 205 Disabling of features: The description in Section 13 of [2] is fully 206 applicable to this document. 208 Media: Real-time text and video may be supported in devices some 209 time in the future. If voice calls are supported then the 210 description in Section 14 is applicable to this document. 212 Testing: The description in Section 15 of [2] is fully applicable to 213 this document. 215 4. Data Profile 217 Due to the requirement for a built-in GPS receiver only geodetic 218 location information will be sent within an emergency call. 219 Furthermore, the number of location shapes is is restricted. Hence, 220 the following location shapes of [6] MUST be implemented: 2d and 3d 221 Point (see Section 5.2.1 of [6]), Circle (see Section 5.2.3 of [6]), 222 and Ellipsoid (see Section 5.2.7 of [6]). The coordinate reference 223 systems (CRS) specified in [6] are also mandatory for this document. 224 Furthermore, the direction of travel of the vehicle is important for 225 dispatch and hence it MUST be included in the PIDF-LO. The 226 element specified in [7] MUST be supported. 228 5. Example 230 Figure 1 shows an emergency call placed from a vehicle whereby 231 location information information is directly attached to the SIP 232 INVITE message itself. The call is marked as an emergency call using 233 the 'urn:service:ecall' service URN and the PSAP of the VoIP provider 234 determines which PSAP to contact based on the provided location 235 information. As shown in the figure, this route determination may be 236 based on LoST. Then, the emergency call continues towards the PSAP 237 and in this example it hits the ESRP, as the entry point to the PSAP 238 operators emergency services network. Finally, the emergency call 239 will be received by a call taker and first reponders will be 240 dispatched. 242 +--------+ 243 | LoST | 244 | Servers| 245 +--------+ 246 ^ +-------+ 247 | | PSAP2 | 248 | +-------+ 249 v 250 +-------+ +------+ +-------+ 251 Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 252 +-------+ +------+ +-------+ 254 +-------+ 255 | PSAP3 | 256 +-------+ 258 Figure 1: Example of In-Vehicular Emergency Call Message Flow 260 The following example, in Figure 2, shows location information 261 encoded in a PIDF-LO that is being conveyed in such an emergency 262 call. 264 265 270 271 272 273 274 42.5463 -73.2512 275 276 850.24 277 278 279 280 281 270.0 -60.0 282 283 284 285 286 GPS 287 288 289 291 Figure 2: Example of In-Vehicular Emergency Call Message Flow 293 6. Security Considerations 295 This document does not raise security considerations beyond those 296 described in [10]. As with emergency service systems with end host 297 provided location information there is the possibility that that 298 location is incorrect, either intentially (in case of an a denial of 299 service attack against the emergency services infrastructure) or due 300 to a malfunctioning devices. The reader is referred to [11] for a 301 discussion of some of these vulnerabilities. 303 7. IANA Considerations 305 IANA is requested to register the URN 'urn:service:ecall' under the 306 sub-services 'sos' registry defined in Section 4.2 of [8]. 308 urn:service:ecall This service identifier reaches a public safety 309 answering point (PSAP), which in turn dispatches aid appropriate 310 to the emergency related to accidents of vehicles. 312 8. Acknowledgements 314 We would like to thank Michael Montag for his feedback. 316 9. Open Issues 318 While working on this document a few aspects where discovered that 319 require further discussion: 321 o Today's work on the eCall system does not necessary require a 322 voice call to be established; a voice call may be established 323 whenever possible by the functionality offered by the device. 324 From a protocol mechanims, however, the design for establishing an 325 emergency call including voice and without voice support are 326 somewhat different. Further discussion on the design aspects are 327 needed to align this aspect. 329 o This document currently defines a new service URN to differentiate 330 it from ordinary calls as in-vehicular emergency calls are, in 331 some countries, routed to different PSAPs than regular emergency 332 calls. More thoughts are needed to determine whether this is the 333 best approach. 335 o The current version of the document assumes the usage of LoST at 336 the VSP to perform call routing of the in-vehicular emergency 337 call. This is useful when there are no dial strings need to be 338 learned nor any other service URNs need to be discovered. Further 339 discussion is needed whether additional service URNs might be made 340 available to the vehicle, for example to request roadside 341 assistance or similar services. In that case the option might be 342 provided to run LoST at the end host as well as on the VSP. 344 10. References 346 10.1. Normative References 348 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 349 Levels", BCP 14, RFC 2119, March 1997. 351 [2] Rosen, B. and J. Polk, "Best Current Practice for 352 Communications Services in support of Emergency Calling", 353 draft-ietf-ecrit-phonebcp-05 (work in progress), July 2008. 355 [3] Peterson, J., "A Presence-based GEOPRIV Location Object 356 Format", RFC 4119, December 2005. 358 [4] Polk, J. and B. Rosen, "Location Conveyance for the Session 359 Initiation Protocol", draft-ietf-sip-location-conveyance-10 360 (work in progress), February 2008. 362 [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 363 Preferences for the Session Initiation Protocol (SIP)", 364 RFC 3841, August 2004. 366 [6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 367 PIDF-LO Usage Clarification, Considerations and 368 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work 369 in progress), February 2008. 371 [7] Vishal, S., Schulzrinne, H., and H. Tschofenig, "Dynamic 372 Feature Extensions to the Presence Information Data Format 373 Location Object (PIDF-LO)", 374 draft-singh-geopriv-pidf-lo-dynamic-02 (work in progress), 375 November 2007. 377 [8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency 378 and Other Well-Known Services", RFC 5031, January 2008. 380 10.2. Informative references 382 [9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 383 Context Resolution with Internet Technologies", RFC 5012, 384 January 2008. 386 [10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, 387 "Security Threats and Requirements for Emergency Call Marking 388 and Mapping", RFC 5069, January 2008. 390 [11] Tschofenig, H. and H. Schulzrinne, "Trustworthy Location 391 Information", draft-tschofenig-ecrit-trustworthy-location-00 392 (work in progress), July 2008. 394 Authors' Addresses 396 Brian Rosen 397 NeuStar, Inc. 398 470 Conrad Dr 399 Mars, PA 16046 400 US 402 Phone: 403 Email: br@brianrosen.net 405 Hannes Tschofenig 406 Nokia Siemens Networks 407 Linnoitustie 6 408 Espoo 02600 409 Finland 411 Phone: +358 (50) 4871445 412 Email: Hannes.Tschofenig@gmx.net 413 URI: http://www.tschofenig.priv.at 415 Ulrich Dietz 416 Vodafone 417 Chiemgaustrasse 116 418 Munich 81549 419 Germany 421 Email: Ulrich.Dietz@vodafone.com 423 Full Copyright Statement 425 Copyright (C) The IETF Trust (2008). 427 This document is subject to the rights, licenses and restrictions 428 contained in BCP 78, and except as set forth therein, the authors 429 retain all their rights. 431 This document and the information contained herein are provided on an 432 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 433 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 434 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 435 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 436 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 437 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 439 Intellectual Property 441 The IETF takes no position regarding the validity or scope of any 442 Intellectual Property Rights or other rights that might be claimed to 443 pertain to the implementation or use of the technology described in 444 this document or the extent to which any license under such rights 445 might or might not be available; nor does it represent that it has 446 made any independent effort to identify any such rights. Information 447 on the procedures with respect to rights in RFC documents can be 448 found in BCP 78 and BCP 79. 450 Copies of IPR disclosures made to the IETF Secretariat and any 451 assurances of licenses to be made available, or the result of an 452 attempt made to obtain a general license or permission for the use of 453 such proprietary rights by implementers or users of this 454 specification can be obtained from the IETF on-line IPR repository at 455 http://www.ietf.org/ipr. 457 The IETF invites any interested party to bring to its attention any 458 copyrights, patents or patent applications, or other proprietary 459 rights that may cover technology that may be required to implement 460 this standard. Please address the information to the IETF at 461 ietf-ipr@ietf.org.