idnits 2.17.1 draft-rosen-ecrit-ecall-10.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines 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 (July 14, 2013) is 3937 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 226 -- Looks like a reference, but probably isn't: 'RFC5012' on line 227 -- Looks like a reference, but probably isn't: 'RFC5491' on line 254 -- Looks like a reference, but probably isn't: 'RFC5962' on line 258 -- Looks like a reference, but probably isn't: 'RFC6881' on line 575 -- Looks like a reference, but probably isn't: 'RFC5069' on line 369 -- Looks like a reference, but probably isn't: 'RFC5031' on line 382 -- Looks like a reference, but probably isn't: 'RFC4288' on line 404 -- Looks like a reference, but probably isn't: 'RFC3023' on line 418 -- Looks like a reference, but probably isn't: 'I-D.ietf-ecrit-additional-data' on line 606 -- Looks like a reference, but probably isn't: 'RFC4481' on line 599 == Unused Reference: '10' is defined on line 475, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 515, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 519, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 524, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 528, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 533, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 498, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 503, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 506, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 509, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-ecrit-trustworthy-location-05 ** Obsolete normative reference: RFC 3023 (ref. '7') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (ref. '8') (Obsoleted by RFC 6838) == Outdated reference: A later version (-38) exists of draft-ietf-ecrit-additional-data-09 Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 13 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: January 13, 2014 Nokia Siemens Networks 6 R. Gellens 7 QUALCOMM Incorporated 8 July 14, 2013 10 Internet Protocol-based In-Vehicle Emergency Call 11 draft-rosen-ecrit-ecall-10.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 January 13, 2014. 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 (http://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Overview of Current Deployment Models . . . . . . . . . . 3 56 1.2. Migration to IP-based Models . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 6.1. Service URN Registration . . . . . . . . . . . . . . . . . 9 63 6.2. MIME Content-type Registration for 64 'application/emergencyCall.VEDS+xml' . . . . . . . . . . . 9 65 6.3. Registration of the 'VEDS' entry in the Emergency Call 66 Additional Data registry . . . . . . . . . . . . . . . . . 10 67 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 9.2. Informative references . . . . . . . . . . . . . . . . . . 11 72 Appendix A. Matching Functionality with eCall Minimum Set of Data 73 (MSD) . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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 Points (PSAPs), 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. 92 The general term for such systems is Automatic Crash Notification 93 (ACN). ACN systems transmit some amount of data specific to the 94 incident, referred to generally as "crash data." While different 95 systems transmit different amounts of crash data, standardized 96 formats, structures, and mechanisms are needed to provide 97 interoperability among systems and PSAPs. 99 This document describes how existing IETF mechanisms are used to 100 provide the realization of next-generation ACN in general, including 101 European eCall. 103 This document registers the 'application/emergencyCall.VEDS+xml' MIME 104 content-type, and registers the 'VEDS' entry in the Emergency Call 105 Additional Data registry. 107 The Vehicle Emergency Data Set (VEDS) is an XML structure defined by 108 the Association of Public-Safety Communications Officials (APCO) and 109 the National Emergency Number Association (NENA). The 'application/ 110 emergencyCall.VEDS+xml' MIME content-type is used to identify it. 111 The 'VEDS' entry in the Emergency Call Additional Data registry is 112 used to construct a 'purpose' parameter value for conveying VEDS data 113 in a Call-Info header. 115 Circuit-switched eCall systems transmit crash data as a defined set, 116 the Minimum Set of Data (MSD) [eCall-MSD].The MSD for circuit- 117 switched eCall is a binary format defined by CEN, the European 118 Committee for Standardization. It is expected that CEN will choose 119 to define the XML schema for the eCall MSD for use in next-generation 120 systems. Once this done, a MIME content-type (e.g., 'application/ 121 emergencyCall.eCall.MSD+xml') and Emergency Call Additional Data 122 entry (e.g., 'eCall.MSD') need to be registered for the MSD. Note 123 that Appendix Appendix A explains how the functionality available in 124 IETF specifications maps to the functionality required for the MSD of 125 the mobile circuit switched voice solution. 127 CEN and/or other entities may define additional sets of data in the 128 same manor: a standardized format, such as XML, is defined, and a 129 MIME content-type and Emergency Call Additional Data entry 130 registered. 132 An In-Vehicle System (IVS) transmits crash data by encoding it in one 133 of the standardized and registered formats (such as VEDS or 134 eCall.MSD) and attaching it to an INVITE as a data block. The block 135 is identified by its MIME content-type, and pointed to by a CID URL 136 in a Call-Info header with a 'purpose' parameter value corresponding 137 to the block. 139 The mechanisms described here can be used to deploy ACN systems in 140 general including eCall by providing for emergency calls that are 141 identifiable as ACN calls or specifically eCall calls and that carry 142 one or more defined crash data objects. 144 1.1. Overview of Current Deployment Models 146 Current (circuit-switched or legacy) systems for placing emergency 147 calls from vehicles, including automatic crash notification system, 148 generally use one of three architectural models: Telematics Service 149 Provider (TSP), direct, and paired handset. These three models are 150 illustrated below. 152 In the TSP model the IVS transmits crash data to the TSP using 153 proprietary means. The TSP operator bridges in the PSAP and 154 communicates location, crash, and other data to the call taker 155 verbally (there is a three-way voice call between the vehicle, the 156 TSP, and the PSAP). 158 ///----\\\ proprietary +------+ 911 trunk +------+ 159 ||| IVS |||-------------->+ TSP +------------------>+ PSAP | 160 \\\----/// crash data +------+ +------+ 162 In the paired model the IVS uses a Bluetooth link to a previously- 163 paired handset to establish an emergency call with the PSAP and then 164 communicates location data to the PSAP via text-to-speech; crash data 165 is not conveyed. 167 ++ 168 ///----\\\ || 911 voice call via handset +------+ 169 ||| IVS |||--->|+----------------------------------->+ PSAP | 170 \\\----/// ++ location via text-to-speech +------+ 172 In the direct model the IVS communicates crash data to the PSAP via 173 the eCall in-band modem (in the voice call). 175 ///----\\\ 112/911 voice call via IVS +------+ 176 ||| IVS |||---------------------------------------->+ PSAP | 177 \\\----/// crash data via eCall in-band modem +------+ 179 1.2. Migration to IP-based Models 181 The migration to next-generation (all-IP) would then look like as 182 follows. 184 In the TSP model The IVS transmits crash data to the TSP using either 185 proprietary or standard means. The TSP bridges in the PSAP and 186 transmits crash and other data to the PSAP using IETF specifications. 187 There is a three-way call between the vehicle, the TSP, and the PSAP. 189 proprietary 190 ///----\\\ or standard +------+ standard +------+ 191 IVS ------------->+ TSP +------------------->+ PSAP | 192 \\\----/// crash data +------+ crash + other data +------+ 194 In the paired model, the IVS uses a Bluetooth link to a previously- 195 paired handset to establish an emergency call with the PSAP; it is 196 not clear what facilities are or will be available for transmitting 197 crash data. 199 ++ 200 ///----\\\ || IP-based Emergency Call +------+ 201 IVS --->|+----------------------------------->+ PSAP | 202 \\\----/// ++ +------+ 204 In the direct model the IVS communicates crash data to PSAP using 205 Internet protocols. 207 ///----\\\ NG1-1-2/NG9-1-1 call +------+ 208 IVS ----------------------------------------->+ PSAP | 209 \\\----/// crash data +------+ 211 This document is focused on the interface to the PSAP, that is, how 212 an emergency call (including location and crash data) is setup and 213 data is transmitted to the PSAP using existing IETF specifications. 214 The goal is to re-use existing specifications rather than to invent 215 new. For the direct model (such as the European eCall), this is the 216 end-to-end description. For the TSP model, this describes the right- 217 hand side, leaving the left-hand side up to the entities involved 218 (e.g., IVS and TSP vendors) who are then free to use the same 219 mechanism as for the right-hand side or not. 221 2. Terminology 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 225 document are to be interpreted as described in [RFC2119]. 227 This document re-uses terminology defined in Section 3 of [RFC5012]. 229 Additionally, we use the following abbreviations: 231 IVS: In-Vehicle System 233 TSP: Telematics Service Provider 235 MSD: Minimum Set of Data 237 VEDS: Vehicle Emergency Data Set 239 NENA: National Emergency Number Association 241 APCO: Association of Public-Safety Communications Officials 243 CEN: European Committee for Standardization 245 ESInet: Emergency Services IP network 247 3. Profile 248 In the context of emergncy calls placed from a vehicle it is assumed 249 that the car is equipped with a built-in GPS receiver. For this 250 reason only geodetic location information will be sent within an 251 emergency call. The following location shapes MUST be implemented: 252 2d and 3d Point (see Section 5.2.1 of [RFC5491]), Circle (see Section 253 5.2.3 of [RFC5491]), and Ellipsoid (see Section 5.2.7 of [RFC5491]). 254 The coordinate reference systems (CRS) specified in [RFC5491] are 255 also mandatory for this document. The element, as 256 defined in [RFC5962] which indicates the direction of travel of the 257 vehicle, is important for dispatch and hence it MUST be included in 258 the PIDF-LO . The element specified in [RFC5962] MUST be 259 implemented and MAY be included. 261 This specification also inherits the ability to utilize test call 262 functionality from Section 15 of [RFC6881]. 264 4. Example 266 Figure 7 shows an emergency call placed from a vehicle whereby 267 location information information is directly attached to the SIP 268 INVITE message itself. The call uses the request URI 269 'urn:service:sos.ecall.automatic' service URN and is recognized as an 270 emergency call because the request URI starts with 'urn:service:sos'. 271 The VoIP provider routes the call to an Emergency services IP Network 272 (ESInet), as for any emergency call. The ESInet routes the call to 273 an appropriate PSAP using location information and the fact that that 274 it is an eCall carrying crash data. (In deployments where there is 275 no ESInet, the VoIP provider may route directly to an appropriate 276 PSAP.) The emergency call continues towards the PSAP and in this 277 example it hits the ESRP, as the entry point to the ESInet. Finally, 278 the emergency call will be received by a call taker and first 279 reponders will be dispatched. 281 +--------+ 282 | LoST | 283 | Server | +-----------------------------------------+ 284 +--------+ | | 285 ^ | +-------+ | 286 | | | PSAP2 | | 287 | | +-------+ | 288 v | | 289 +-------+ | +------+ +-------+ | 290 Vehicle ------>| Proxy |--+->| ESRP |---->| PSAP1 |-----> Call-Taker| 291 +-------+ | +------+ +-------+ | 292 | | 293 | +-------+ | 294 | | PSAP3 | | 295 | +-------+ | 296 | | 297 | | 298 | | 299 | ESInet | 300 +-----------------------------------------+ 302 The example, shown in Figure 8, illustrates a SIP emergency call 303 eCall INVITE that is being conveyed with location information encoded 304 in a PIDF-LO and VEDS data. 306 INVITE urn:service:sos.ecall.automatic SIP/2.0 307 To: urn:service:sos.ecall.automatic 308 From: ;tag=9fxced76sl 309 Call-ID: 3848276298220188511@atlanta.example.com 310 Geolocation: 311 Geolocation-Routing: no 312 Call-Info: cid:1234567890@atlanta.example.com; 313 purpose=emergencyCallData.VEDS 314 Accept: application/sdp, application/pidf+xml 315 CSeq: 31862 INVITE 316 Content-Type: multipart/mixed; boundary=boundary1 317 Content-Length: ... 319 --boundary1 321 Content-Type: application/sdp 323 ...Session Description Protocol (SDP) goes here 325 --boundary1 327 Content-Type: application/pidf+xml 328 Content-ID: 329 330 338 339 340 341 342 -34.407 150.883 343 344 345 278 346 347 348 349 350 gps 351 352 2012-04-5T10:18:29Z 353 1M8GDM9A_KP042788 354 355 357 --boundary1 359 Content-Type: application/emergencyCall.VEDS+xml 360 Content-ID: 1234567890@atlanta.example.com 362 ...eCall VEDS data object goes here 364 --boundary1-- 366 5. Security Considerations 368 This document does not raise security considerations beyond those 369 described in [RFC5069]. As with emergency service systems with end 370 host provided location information there is the possibility that that 371 location is incorrect, either intentially (in case of an a denial of 372 service attack against the emergency services infrastructure) or due 373 to a malfunctioning devices. The reader is referred to [I-D.ietf- 374 ecrit-trustworthy-location] for a discussion of some of these 375 vulnerabilities. 377 6. IANA Considerations 379 6.1. Service URN Registration 381 IANA is requested to register the URN 'urn:service:sos.ecall' under 382 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 384 This service identifier reaches a public safety answering point 385 (PSAP), which in turn dispatches aid appropriate to the emergency 386 related to accidents of vehicles. Two sub-services are registered as 387 well, namely 389 urn:service:sos.ecall.manual 391 This service URN indicates that an eCall had been triggered based 392 on the manual interaction of the driver or a passenger. 394 urn:service:sos.ecall.automatic 396 This service URN indicates that an eCall had been triggered 397 automatically, for example, due to a crash. No human involvement 398 was detected. 400 6.2. MIME Content-type Registration for 'application/ 401 emergencyCall.VEDS+xml' 403 This specification requests the registration of a new MIME type 404 according to the procedures of RFC 4288 [RFC4288] and guidelines in 405 RFC 3023 [RFC3023]. 407 MIME media type name: application 409 MIME subtype name: emergencyCall.VEDS+xml 411 Mandatory parameters: none 412 Optional parameters: charset 414 Indicates the character encoding of enclosed XML. 416 Encoding considerations: Uses XML, which can employ 8-bit 417 characters, depending on the character encoding used. See Section 418 3.2 of RFC 3023 [RFC3023]. 420 Security considerations: This content type is designed to carry 421 vehicle crash data during an emergency call. This data may 422 contains personal information including vehicle VIN, location, 423 direction, etc. appropriate precautions need to be taken to limit 424 unauthorized access, inappropriate disclosure to third parties, 425 and eavesdropping of this information. Please refer to Section 7 426 and Section 8 of [I-D.ietf-ecrit-additional-data] for more 427 information. 429 Interoperability considerations: None 431 Published specification: [TBD: This specification] 433 Applications which use this media type: Emergency Services 435 Additional information: None 437 Magic Number: None 439 File Extension: .xml 441 Macintosh file type code: 'TEXT' 443 Person and email address for further information: Hannes 444 Tschofenig, Hannes.Tschofenig@gmx.net 446 Intended usage: LIMITED USE 448 Author: This specification is a work item of the IETF ECRIT 449 working group, with mailing list address . 451 Change controller: The IESG 453 6.3. Registration of the 'VEDS' entry in the Emergency Call Additional 454 Data registry 456 This specification requests IANA to add the 'VEDS' entry to the 457 Emergency Call Additional Data registry, with a reference to this 458 document. The Emergency Call Additional Data registry has been 459 established by [I-D.ietf-ecrit-additional-data]. 461 7. Contributors 463 We would like to thank Ulrich Dietz for his help with earlier 464 versions of the document. 466 8. Acknowledgements 468 We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri, 469 and Gunnar Hellstroem for their feedback. 471 9. References 473 9.1. Normative References 475 [10] Schulzrinne, H., "A Uniform Resource Name (URN) for 476 Emergency and Other Well-Known Services", RFC 5031, 477 January 2008. 479 [1] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, March 1997. 482 [2] Peterson, J., "A Presence-based GEOPRIV Location Object 483 Format", RFC 4119, December 2005. 485 [3] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV 486 Presence Information Data Format Location Object (PIDF-LO) 487 Usage Clarification, Considerations, and Recommendations", 488 RFC 5491, March 2009. 490 [4] Rosen, B. and J. Polk, "Best Current Practice for 491 Communications Services in Support of Emergency Calling", 492 BCP 181, RFC 6881, March 2013. 494 [5] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance 495 for the Session Initiation Protocol", RFC 6442, December 496 2011. 498 [6] Schulzrinne, H., Singh, V., Tschofenig, H. and M. Thomson, 499 "Dynamic Extensions to the Presence Information Data 500 Format Location Object (PIDF-LO)", RFC 5962, September 501 2010. 503 [7] Murata, M., St. Laurent, S. and D. Kohn, "XML Media 504 Types", RFC 3023, January 2001. 506 [8] Freed, N. and J. Klensin, "Media Type Specifications and 507 Registration Procedures", RFC 4288, December 2005. 509 [9] Rosen, B., Tschofenig, H., Marshall, R. and R. Randy, 510 "Additional Data related to an Emergency Call", Internet- 511 Draft draft-ietf-ecrit-additional-data-09, May 2013. 513 9.2. Informative references 515 [1] Schulzrinne, H. and R. Marshall, "Requirements for 516 Emergency Context Resolution with Internet Technologies", 517 RFC 5012, January 2008. 519 [2] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. 520 Shanmugam, "Security Threats and Requirements for 521 Emergency Call Marking and Mapping", RFC 5069, January 522 2008. 524 [3] Tschofenig, H., Schulzrinne, H. and B. Aboba, "Trustworthy 525 Location", Internet-Draft draft-ietf-ecrit-trustworthy- 526 location-05, March 2013. 528 [4] Schulzrinne, H., "Timed Presence Extensions to the 529 Presence Information Data Format (PIDF) to Indicate Status 530 Information for Past and Future Time Intervals", RFC 4481, 531 July 2006. 533 [5] CEN, , "Intelligent transport systems - eSafety - eCall 534 minimum set of data (MSD), EN 15722", June 2011. 536 Appendix A. Matching Functionality with eCall Minimum Set of Data (MSD) 538 [eCall-MSD] outlines a number of data elements that are transmitted 539 in an emergency call triggered by a vehicle. Note that the work on 540 eCall for mobile circuit switched voice is constrained in a number of 541 ways since legacy eCall uses an inband voice modem for backwards 542 compatibility with the already deployed cellular infrastructure to 543 transmit data from a vehicle to a PSAP. Since the functionality in 544 this document is based on the Session Initiation Protocol (SIP) these 545 limitations do not exist. As such, it is not useful to transmit the 546 MSD inband in the voice channel but to rather use the SIP mechanisms 547 standardized for emergency call handling. Any voice, video, or real- 548 text communication will be negotiated using the Session Description 549 Protocol (SDP), as shown in Figure 8, and the actual media stream 550 will then take place in RTP packets. For transmitting location 551 information an XML-based data structure had been defined, the so- 552 called Presence Information Data Format Location Object (PIDF-LO). 554 The following list compares the eCall minimum set of data with the 555 functionality provided in this document. 557 Version of the MSD Format: Conveying information in a SIP-based 558 emergency call is accomplished by using XML payloads and XML 559 provides namespace declarations that allow a receipient of that 560 information to distinguish different versions and additional 561 extensions. For example, if additional data about a vehicle is 562 defined and can be transmitted by vehicle then a respective 563 extension can be defined for use inside a previously-defined XML 564 structure. One or more top-level structures can be transmitted 565 using the mechanism defined in [I-D.ietf-ecrit-additional-data]. 566 Selecting the appropriate extension point depends on the type of 567 extension envisioned. 569 Message Identifier: Every SIP INVITE message contains a Call-ID, 570 which is a globally unique identifier for this call. 572 Test Call Indication A service URN starting with "test." indicates a 573 request for an automated test. For example, 574 "urn:service:test.sos.ecall.automatic" indicates such a test 575 feature. This functionality is defined in [RFC6881]. 577 Automatic Activation Indication: This document registers new service 578 URNs, which allow the differentiation between manually and 579 automatically triggered emergency calls. The two service URNs 580 are: urn:service:sos.ecall.automatic and 581 urn:service:sos.ecall.manual 583 Vehicle Identification: The PIDF data structure contains a deviceID 584 field that holds the Vehicle Identification Number (VIN). 586 Timestamp of Incident Event: The PIDF-LO element contains the 587 timestamp when the PIDF-LO was created, which is at the time of 588 the incident. 590 Vehicle Location: The location of the vehicle is conveyed using the 591 PIDF location object, as described in Section 3. 593 Vehicle Direction: The direction of the vehicle is part of location 594 information, as described in Section 3. 596 Recent Vehicle Location: With this optional functionality multiple 597 location objects may be required to be transported simultaneously. 598 This can be achieved using , defined in RFC 4481 599 [RFC4481]. 601 Additional Data: [I-D.ietf-ecrit-additional-data] provides the 602 ability to carry additional data for an emergency call. 604 While most fields have an equivalent already in the corresponding SIP 605 emergency signaling payloads there are currently no fields defined in 606 [I-D.ietf-ecrit-additional-data] that allow information about the 607 "Vehicle Type Encoding", "Number of Passengers", and "Vehicle 608 Propulsion Storage type" to be conveyed. Extensions for those fields 609 will have to be defined. 611 Authors' Addresses 613 Brian Rosen 614 NeuStar, Inc. 615 470 Conrad Dr 616 Mars, PA 16046 617 US 619 Email: br@brianrosen.net 620 Hannes Tschofenig 621 Nokia Siemens Networks 622 Linnoitustie 6 623 Espoo, 02600 624 Finland 626 Phone: +358 (50) 4871445 627 Email: Hannes.Tschofenig@gmx.net 628 URI: http://www.tschofenig.priv.at 630 Randall Gellens 631 QUALCOMM Incorporated 632 5775 Morehouse Drive 633 San Diego, 92651 634 US 636 Email: rg+ietf@qualcomm.com