Next-Generation Vehicle-Initiated Emergency Calls
Extracted elements (30)
The 'msg-static' registry uses consecutive integer IDs so that a vehicle can indicate support for all messages up to a given value by sending a single integer in its <capabilities> element, minimizing signaling overhead while ensuring compliant vehicles support all messages translated into their supported languages.
The SIP INFO method was chosen for mid-call data transport over alternatives (MESSAGE, OPTIONS, re-INVITE, SUBSCRIBE/NOTIFY, media-plane) because it is bound to the SIP dialog, semantics fit two-way data exchange, and the overhead of user-plane setup (e.g., MSRP) would be disproportionately large given that most dialogs carry zero or very few data messages.
VEDS and metadata/control body parts use Content-Disposition 'by-reference;handling=optional' in the initial INVITE to prevent rejection by legacy elements (e.g., gateways between SIP and circuit-switched environments) that do not understand these objects.
The same service URNs ('urn:service:sos.ecall.automatic' and 'urn:service:sos.ecall.manual') are used for both NG-ACN and NG-eCall since only one system is supported in any given region, and PSAP equipment may support multiple data formats allowing handling of vehicles that erroneously send the wrong data object.
When an NG-ACN call is routed to a PSAP that is not NG-ACN capable, the PSAP ignores or does not receive vehicle data; this is detectable by the IVS or TSP when the 200 OK response lacks a metadata/control structure acknowledging receipt, after which the IVS proceeds as for a CS-ACN call (e.g., oral data conveyance).
An IVS initiating an NG-ACN call MUST support sending the VEDS data object and MUST include at minimum a <request> child element with action set to 'send-data' and supported-values containing 'VEDS' in its <capabilities> element.
For each metadata/control block received containing one or more <request> elements (except for successfully executed send-data requests), the IVS sends a metadata/control object containing an <ack> element acknowledging the received block with an <actionResult> per <request> element.
If the IVS is aware that VEDS data it sent previously has changed, it MAY send an unsolicited VEDS in any convenient SIP message, including a SIP INFO request during the call.
Multiple requests with the same 'action' value MUST be sent in separate metadata/control body parts to avoid any ambiguity in the acknowledgment.
Support for the eCall MSD data set is OPTIONAL and support for VEDS is REQUIRED in NG-ACN calls; this document extends RFC 8147 by making MSD optional and VEDS mandatory.
The IVS and the PSAP MUST support the mandatory action of transmitting a VEDS data object; all other actions (msg-static, msg-dynamic, honk, lamp, enable-camera, door-lock) are optional and MAY be supported.
Vehicles MAY decline to carry out any requested action (e.g., if the vehicle requires but is unable to verify the certificate used to sign the request), and vehicle policy MAY decline higher-risk requests such as unlocking doors in certain circumstances.
Access to vehicle camera streams enabled by this document must be carefully restricted to within the context of an emergency call or to verified emergency services providers (e.g., by verifying that a camera access request is signed by a certificate issued by an emergency services registrar).
The VEDS data structure contains optional elements carrying identifying and personal information about the vehicle and owner as well as location data; it must be protected against unauthorized disclosure per RFC 7852, and local regulations may impose additional requirements.
The <ack> element is sent by the PSAP to acknowledge unsolicited IVS data, or by the IVS to acknowledge a PSAP <request> other than a successfully performed send-data request; it references the unique ID of the acknowledged metadata/control block and contains <actionResult> elements indicating success or failure with optional reason and details.
The <capabilities> element is transmitted by the IVS in the initial INVITE to inform the PSAP of vehicle capabilities; it contains one <request> child element per supported action including data types, lamp IDs, and camera IDs.
The <request> element within metadata/control blocks contains a mandatory 'action' attribute specifying the requested action, optional 'element-id', 'requested-state', 'persistence', and 'supported-values' attributes, and an optional <text> child element for dynamic messages.
The VEDS (Vehicle Emergency Data Set) is an XML structure defined by APCO and NENA, transported in SIP using the application/EmergencyCallData.VEDS+xml MIME media type, and carries crash-related vehicle data such as airbag deployment, location, spatial orientation, crash pulse, seat belt status, and injury indicators.
A new 'Emergency Call Static Messages' sub-registry is created under 'Emergency Call Metadata/Control Data', operating under Specification Required rules; it maps integer IDs to pre-defined vehicle-displayable messages (initial value: ID 1 = 'Emergency services has received your information...').
A new 'Emergency Call Vehicle Camera IDs' sub-registry is created under Expert Review rules with 11 initial camera identifiers (backup, left-rear, right-rear, forward, rear-wide, lane, interior, night-front, night-rear, night-left, night-right) used in the 'element-id' attribute of <request> elements.
A new 'Emergency Call Vehicle Lamp IDs' sub-registry is created under Expert Review rules with 11 initial lamp identifiers (head, interior, fog-front, fog-rear, brake, brake-center, position-front, position-rear, turn-left, turn-right, hazard) used in the 'element-id' attribute of <request> elements.
IANA added 'VEDS' to the 'Emergency Call Data Types' registry (established by RFC 7852) with 'Data About' value of 'The Call', enabling PSAPs to identify VEDS blocks by the purpose parameter 'EmergencyCallData.VEDS'.
IANA registered the MIME media type application/EmergencyCallData.VEDS+xml for carrying Vehicle Emergency Data Set XML structures in emergency calls; it has no mandatory parameters and carries personal vehicle data requiring protection against unauthorized disclosure.
RFC 8148 adds six new values to the 'Emergency Call Action' registry created by RFC 8147: msg-static, msg-dynamic, honk, lamp, enable-camera, and door-lock.
The EmergencyCallData.VEDS INFO package is registered in the Info Packages Registry; it enables mid-call transport of VEDS data blocks, metadata/control objects, and optionally MSD objects in SIP INFO requests within an established NG-ACN emergency call dialog.
Because some vehicle actions carry more potential risk than others (e.g., unlocking doors versus flashing lights), vehicle policy MAY differentiate between requests received in vehicle-initiated versus vehicle-terminated calls, potentially declining higher-risk actions in the latter case.
Location data supplied or determined with the assistance of an end host may be incorrect, either intentionally (e.g., in a denial-of-service attack against emergency services infrastructure) or due to a malfunctioning device; RFC 7378 is referenced for discussion of these vulnerabilities.
A VEDS or metadata/control body part is identified by its MIME type in the Content-Type header, assigned a unique identifier in Content-ID, and referenced by a Call-Info header field at the top level of the SIP message with a CID URL and a 'purpose' parameter (e.g., 'EmergencyCallData.VEDS' or 'EmergencyCallData.Control').
The SIP INVITE for an NG-ACN call uses 'urn:service:sos.ecall.automatic' or 'urn:service:sos.ecall.manual' in the Request-URI, includes Call-Info header fields referencing the VEDS and metadata/control blocks, and carries PIDF-LO, VEDS, and capabilities data as multipart body parts with Content-Disposition 'by-reference;handling=optional'.
VEDS and metadata/control body parts MUST carry a Content-Disposition header field with value 'By-Reference' and MUST always be enclosed in a multipart body part, even if they would otherwise be the only body part in the SIP message.