ECRIT B. Rosen Internet-Draft NeuStar, Inc. Intended status: Informational H. Tschofenig Expires: January 16, 2013 Nokia Siemens Networks July 15, 2012 Internet Protocol-based In-Vehicle Emergency Call draft-rosen-ecrit-ecall-06.txt Abstract This document describes how to use a subset of the IETF-based emergency call framework for accomplishing emergency calling support in vehicles. Simplifications are possible due to the nature of the functionality that is going to be provided in vehicles with the usage of GPS. Additionally, further profiling needs to be done regarding the encoding of location information. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 16, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Rosen & Tschofenig Expires January 16, 2013 [Page 1] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Profile . . . . . . . . . . . . . . . . . . . . . . . 5 4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative references . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Rosen & Tschofenig Expires January 16, 2013 [Page 2] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 1. Introduction Emergency calls made from vehicles can assist with the objective of significantly reducing road deaths and injuries. Unfortunately, drivers often have a poor location-awareness, especially on urban roads (also during night) and abroad. In the most crucial cases, the victim(s) may not be able to call because they have been injured or trapped. In Europe the European Commission has launched the eCall initiative that may best be described as a user initiated or automatically triggered system to provide notifications to Public Safety Answering Point's (PSAP), by means of cellular communications, that a vehicle has crashed, and to provide geodetic location information and where possible a voice channel to the PSAP. At the time of writing the suppor for eCall are focused on legacy technology. This document details how emergency calls triggered by vehicles can be accomplished in an Internet Protocol-based environment. This document is organized as follows: Section 2 defines the terminology, Section 3 illustrates the required protocol functionality, Section 4 indicates the required data that has to be transmitted within a PIDF-LO and Section 5 shows an example message exchange. This document concludes with the security considerations in Section 6 and IANA considerations in Section 7. Rosen & Tschofenig Expires January 16, 2013 [Page 3] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. This document re-uses a lot of the terminology defined in Section 3 of [9]. Rosen & Tschofenig Expires January 16, 2013 [Page 4] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 3. Protocol Profile The usage of in-vehicular emergency calls does not require the usage of a Location Configuration Protocol since GPS is used. Furthermore, since the GPS receiver is permanently turned on it can even provide useful information in cases where the car entered a tunnel. Consequently, there is no need to discover any Location Information Server (LIS). Since the emergency call within the car is either triggered by a button or, in most cases, automatically thanks to sensors mounted in the car there is no need to learn a dial string. This document registers a separate Service URN, namely 'urn:service:ecall', used specifically for emergency calls that are triggered by vehicles. This URN comes with two sub-services to indicate how the emergency call was triggered, namely 'automatic' for cases when the emergency call was triggered due to a crash automatically without any user involvement and 'manual' for cases where a driver or a passenger triggered the emergency call. If the device initiating the emergency call does not allow to differentiate these two cases then the Service URN 'urn:service:ecall' is used. The following list provides information about the sections and requires of [2] that are relevant to this specification: Identifying an emergency call: Emergency calls are detected at the end point, i.e., by the vehicle, and the Service URN 'urn:service:ecall' MUST be implemented by the end point and recognized by the VSP. The requirements listed in Section 5 of [2] are therefore irrelevant to this specification, as they deal with identifying an emergency call based on dial strings. Location: The encoding of the PIDF-LO [3] is described in Section 4. In an emergency, the end point adds the available location information to the initial SIP INVITE emergency call message. In special cases a location update may be provided, using the procedure described in requirement ED-38 of Section 6.8 of [2]; all other aspects of Section 6.8 from that document are not applicable to this specification. Section 6.2.1, 6.2.2, 6.2.4, 6.4, 6.5 and 6.6 of [2] are not applicable to this document. For location conveyance in SIP [4] MUST be used. Further aspects that are not relevant for this document are multiple locations (Section 6.9 of [2]), location validation (Section 6.10 of [2]), default location (Section 6.11 of [2]) Rosen & Tschofenig Expires January 16, 2013 [Page 5] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 LoST: Emergency call routing support, for example utilizing LoST, is provided by VSP. As such, the description in Section 8 of [2] is applicable to this document, except for requirement SP-25 and SP-26 regarding legacy devices. Signaling of emergency calls: Section 9 of [2] is applicable to this document with the following exception: ED-60/AN-25 is not applicable as HELD is not used. Video and real-time text may be supported by end device in the future, although currently not envisioned. The corresponding text paragraphs are relevant from Section 9 of [2] when support is being provided. Additionally, ED-62 dealing with "SIP signaling requirements for User Agents" is simplified as follows. The initial SIP signaling method is an INVITE request with the following setting: 1. The Request URI MUST be the service URN 'urn:service:ecall' or one of the sub-services. 2. The To header MUST be a service URN 'urn:service:ecall.automatic' or one of the sub-services. 3. The From header MUST be present and SHOULD be the AoR of the caller. 4. A Via header MUST be present. 5. A Contact header MUST be present which MUST be globally routable to permit an immediate call-back to the specific device which placed the emergency call. 6. Other headers MAY be included as per normal SIP behavior. 7. A Supported header MUST be included with the 'geolocation' option tag [4]. 8. The device MUST include location by-value into the call. 9. A normal SDP offer SHOULD be included in the INVITE. If voice is supported the offer SHOULD include the G.711 codec, if a voice channel can be established based on the equipment in the car. 10. If the device includes location-by-value, the UA MUST support multipart message bodies, since SDP will likely be also in the INVITE. 11. The UAC MUST include a "inserted-by=endpoint" header parameter on all Geolocation headers. This informs Rosen & Tschofenig Expires January 16, 2013 [Page 6] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 downstream elements which device entered the location at this URI (either cid-URL or location-by-reference URI). 12. SIP Caller Preferences [5] MAY be used to signal how the PSAP should handle the call. For example, a language preference expressed in an Accept-Language header may be used as a hint to cause the PSAP to route the call to a call taker who speaks the requested language. SIP Caller Preferences may also be used to indicate a need to invoke a relay service for communication with people with disabilities in the call. Call backs: The description in Section 10 of [2] is relevant for this document. Mid-call behavior: The description in Section 11 of [2] is fully applicable to this document. Call termination: The description in Section 12 of [2] is fully applicable to this document. Disabling of features: The description in Section 13 of [2] is fully applicable to this document. Media: If hardware and software for real-time text, voice, and video is available in the end device then the requirements regarding multi-media support described in [2] are applicable. Testing: The description in Section 15 of [2] is fully applicable to this document. Rosen & Tschofenig Expires January 16, 2013 [Page 7] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 4. Data Profile Due to the requirement for a built-in GPS receiver only geodetic location information will be sent within an emergency call. Furthermore, the number of location shapes is is restricted. Hence, the following location shapes of [6] MUST be implemented: 2d and 3d Point (see Section 5.2.1 of [6]), Circle (see Section 5.2.3 of [6]), and Ellipsoid (see Section 5.2.7 of [6]). The coordinate reference systems (CRS) specified in [6] are also mandatory for this document. Furthermore, the direction of travel of the vehicle is important for dispatch and hence it MUST be included in the PIDF-LO. The element specified in [7] MUST be supported. Rosen & Tschofenig Expires January 16, 2013 [Page 8] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 5. Example Figure 1 shows an emergency call placed from a vehicle whereby location information information is directly attached to the SIP INVITE message itself. The call is marked as an emergency call using the 'urn:service:ecall.automatic' service URN and the PSAP of the VoIP provider determines which PSAP to contact based on the provided location information. As shown in the figure, this route determination may be based on LoST. Then, the emergency call continues towards the PSAP and in this example it hits the ESRP, as the entry point to the PSAP operators emergency services network. Finally, the emergency call will be received by a call taker and first reponders will be dispatched. +--------+ | LoST | | Servers| +--------+ ^ +-------+ | | PSAP2 | | +-------+ v +-------+ +------+ +-------+ Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker +-------+ +------+ +-------+ +-------+ | PSAP3 | +-------+ Figure 1: Example of In-Vehicular Emergency Call Message Flow The following example, in Figure 2, shows the SIP INVITE and location information encoded in a PIDF-LO that is being conveyed in such an emergency call. INVITE urn:service:ecall.automatic SIP/2.0 To: From: ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: Geolocation-Routing: no Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... Rosen & Tschofenig Expires January 16, 2013 [Page 9] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 --boundary1 Content-Type: application/sdp ...Session Description Protocol (SDP) goes here --boundary1 Content-Type: application/pidf+xml Content-ID: -34.407 150.883 278 gps 2012-04-5T10:18:29Z vehicle-number --boundary1-- Figure 2: SIP INVITE indicating an In-Vehicular Emergency Call Rosen & Tschofenig Expires January 16, 2013 [Page 10] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 6. Security Considerations This document does not raise security considerations beyond those described in [10]. As with emergency service systems with end host provided location information there is the possibility that that location is incorrect, either intentially (in case of an a denial of service attack against the emergency services infrastructure) or due to a malfunctioning devices. The reader is referred to [11] for a discussion of some of these vulnerabilities. Rosen & Tschofenig Expires January 16, 2013 [Page 11] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 7. IANA Considerations IANA is requested to register the URN 'urn:service:ecall' under the sub-services 'sos' registry defined in Section 4.2 of [8]. This service identifier reaches a public safety answering point (PSAP), which in turn dispatches aid appropriate to the emergency related to accidents of vehicles. Two sub-services are registered as well, namely urn:service:ecall.manual This service URN indicates that an eCall had been triggered based on the manual interaction of the driver or a passenger. urn:service:ecall.automatic This service URN indicates that an eCall had been triggered automatically, for example, due to a crash. No human involvement was detected. Rosen & Tschofenig Expires January 16, 2013 [Page 12] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 8. Contributors We would like to thank Ulrich Dietz for his help with earlier versions of the document. Rosen & Tschofenig Expires January 16, 2013 [Page 13] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 9. Acknowledgements We would like to thank Michael Montag, Arnoud van Wijk, and Gunnar Hellstroem for their feedback. Rosen & Tschofenig Expires January 16, 2013 [Page 14] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", draft-ietf-ecrit-phonebcp-20 (work in progress), September 2011. [3] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [4] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011. [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009. [7] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)", RFC 5962, September 2010. [8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008. 10.2. Informative references [9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008. [10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008. [11] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy Location Information", draft-ietf-ecrit-trustworthy-location-03 (work in progress), April 2012. Rosen & Tschofenig Expires January 16, 2013 [Page 15] Internet-Draft IP-based In-Vehicle Emergency Call July 2012 Authors' Addresses Brian Rosen NeuStar, Inc. 470 Conrad Dr Mars, PA 16046 US Phone: Email: br@brianrosen.net Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Rosen & Tschofenig Expires January 16, 2013 [Page 16]