Next-Generation Pan-European eCall
Extracted elements (30)
SIP INFO was chosen over MESSAGE, OPTIONS, re-INVITE, SUBSCRIBE/NOTIFY, and media-plane mechanisms for mid-call eCall data transport. MESSAGE is not bound to a dialog; OPTIONS and re-INVITE are less semantically clean; SUBSCRIBE/NOTIFY provides one-way notification semantics ill-suited to bidirectional data exchange; media-plane setup (e.g., MSRP) would be disproportionately heavy for the very low message volume expected.
The MSD uses ASN.1 PER binary encoding (Annex A of EN 15722) rather than the XML encoding (Annex C) to maintain consistency with legacy circuit-switched eCall and to comply with 3GPP requirements. This choice means the MSD cannot be represented as text in protocol examples.
If the IVS receives a SIP final response to the INVITE without a metadata/control block, this indicates the dialog is not being handled as NG-eCall (e.g., a legacy gateway has intervened). The 'handling=optional' Content-Disposition value is the mechanism enabling legacy elements to process or forward the INVITE without failing on unknown body parts.
An IVS initiating an NG-eCall MUST include the MSD body part with Content-Disposition header value 'By-Reference; handling=optional' in the initial INVITE. The 'handling=optional' directive prevents rejection by legacy intermediaries that do not understand the MSD.
An MSD or metadata/control block MUST always be enclosed in a multipart body part, even if it would otherwise be the only body part in the SIP message. The SIP message MUST also include a Call-Info header field with a CID URL and 'purpose' parameter identifying the data type.
New MIME subtypes added to the 'EmergencyCallData' media subtree MUST be registered by a standards-related organization responsible for some aspect of emergency communications, per Section 3.1 of RFC 6838.
The only <request> action that MUST be supported by an IVS is 'send-data' with 'datatype' set to 'eCall.MSD'. All other actions defined in the Emergency Call Actions registry are optional.
The PSAP MUST send an <ack> element acknowledging receipt of every unsolicited MSD sent by the IVS (e.g., in the initial INVITE). The <ack> element MUST include a 'received' boolean indicating whether the PSAP considers the MSD successfully received.
When the IVS is unable to fulfill a PSAP request (e.g., to send an MSD), it MUST send a metadata/control object containing an <actionResult> element with 'success' set to 'false' and a 'reason' attribute indicating why the request could not be accomplished.
The MSD carries personal and identifying information including vehicle VIN, location, direction, and number of occupants. It must be protected against unauthorized disclosure and eavesdropping. Local regulations may impose additional privacy protection requirements beyond those in RFC 7852.
The <ack> element references a specific Content-ID ('ref' attribute, type anyURI) and carries a 'received' boolean. It is used by the PSAP to confirm successful or unsuccessful receipt of an IVS-sent data object. An <actionResult> child element reports the outcome of non-'send-data' actions.
The <capabilities> element is sent by the IVS to the PSAP (e.g., in the initial INVITE) to advertise supported actions. It contains one <request> child per supported action. If absent, the PSAP assumes the IVS supports only 'send-data' with 'datatype=eCall.MSD'.
The metadata/control block is an XML structure (application/EmergencyCallData.Control+xml) used for PSAP-IVS signaling during an eCall. It contains three top-level elements: <ack> (acknowledgment), <capabilities> (IVS capability advertisement), and <request> (PSAP action requests).
The Minimum Set of Data (MSD) is a standardized set of vehicle-related data (VIN, vehicle type, propulsion type, current and optionally previous location, number of occupants) specified by CEN in EN 15722. It is carried using the MIME type application/EmergencyCallData.eCall.MSD.
The <request> element allows the PSAP to request IVS actions. Its mandatory 'action' attribute references the Emergency Call Actions IANA registry. For 'send-data', the 'datatype' attribute (also mandatory outside <capabilities>) specifies the requested data block using Emergency Call Data Types registry identifiers.
Two service URNs differentiate NG-eCall trigger modes: urn:service:sos.ecall.automatic (crash/incident-triggered) and urn:service:sos.ecall.manual (occupant-triggered). A test URN urn:service:test.sos.ecall is also defined for non-emergency test calls.
IANA registered three service URNs under the 'sos' subservice: urn:service:sos.ecall (parent), urn:service:sos.ecall.automatic, and urn:service:sos.ecall.manual. Also registered: urn:service:test.sos.ecall under the 'test' sub-services for non-emergency test calls.
INFO package 'EmergencyCallData.eCall.MSD' registered in the Info Packages Registry per RFC 6086. Both IVS and PSAP include it in Recv-Info headers to indicate ability to receive eCall-related INFO requests. Body must be multipart containing zero or one MSD part and zero or more Control+xml parts.
MIME type application/EmergencyCallData.Control+xml registered for the metadata/control XML block. Encoding uses XML (8-bit characters per charset parameter). Intended for LIMITED USE. Change controller is IETF ECRIT WG.
MIME type application/EmergencyCallData.eCall.MSD registered for carrying the ASN.1 PER-encoded MSD in SIP. Encoding is binary. Intended for LIMITED USE. Change controller is CEN. Security considerations note the presence of personal data (VIN, location, direction).
New IANA registry 'Emergency Call Action Failure Reasons' created for the 'reason' attribute of <actionResult>. Operates under Expert Review. Initial values: damaged, data-unsupported, security-failure, unable, unsupported.
New IANA registry 'Emergency Call Actions' created under 'Emergency Call Metadata/Control Data'. Operates under Expert Review. Initial value: 'send-data'. Expert must verify the proposed action is within vehicle purview, distinguishable from others, and clearly described.
This document establishes the 'EmergencyCallData' MIME media subtype tree (application/EmergencyCallData.*). New subtypes require registration by organizations responsible for emergency communications. Initial subtypes include EmergencyCallData.eCall.MSD and EmergencyCallData.Control+xml (defined here) plus types from RFC 7852.
Two entries added to the 'Emergency Call Data Types' registry (originally established by RFC 7852): 'eCall.MSD' and 'Control', both with Data About value 'The Call'. These registry entries allow SIP intermediaries to identify data blocks by the 'purpose' parameter in Call-Info header fields.
An attacker able to intercept and spoof the PSAP response to the initial INVITE could send a 600/486/603 rejection with a metadata/control object setting 'received=true', causing the IVS to believe the PSAP received the MSD and refrain from re-initiating the call. Mitigation requires integrity protection of the SIP signaling path.
Control information (PSAP requests to the vehicle) must originate only from a PSAP or authorized emergency services provider and must not be modified in transit. PSAP callback calls present additional verification challenges since current mechanisms are not ideal for confirming a callback is genuinely from the responding PSAP.
Data received from external sources (MSD and metadata/control objects) may be malformed, contain unexpected characters, or have excessively long attribute values. Implementations must apply defense-in-depth including fuzz testing, component isolation, and avoidance of unsafe coding techniques to mitigate risks such as buffer overflows and XML parsing vulnerabilities.
NG-eCall call flow: (1) IVS sends INVITE with MSD; (2) PSAP responds 200 OK with <ack> metadata/control block; (3) media streams start; (4) PSAP may send INFO with <request> for updated MSD; (5) IVS responds 200 OK; (6) IVS sends INFO with updated MSD; (7) BYE terminates. Absence of metadata/control in the final response indicates a non-NG-eCall leg.
Each MSD or metadata/control body part is identified by a Content-ID header field. The enclosing SIP message references it via a Call-Info header field containing a CID URL and a 'purpose' parameter whose value matches an entry in the Emergency Call Data Types registry (e.g., 'EmergencyCallData.eCall.MSD').
The MSD is encoded using ASN.1 Packed Encoding Rules (PER) as specified in Annex A of CEN EN 15722. This is a binary encoding; when transported in SIP it uses binary content transfer encoding. The XML encoding (Annex C of EN 15722) is explicitly not used, per 3GPP requirements.