Additional Data Related to an Emergency Call
updates
Extracted elements (26)
Access network providers cannot add SIP Call-Info headers because they do not participate in application-layer signaling. The <provided-by> element in PIDF-LO was chosen as the mechanism for access network providers to supply additional data alongside location information they already deliver via protocols such as HELD.
Device/service-specific additional data can be carried either as a new registered block or via the DeviceSpecificData URI in DeviceInfo. The by-reference approach via DeviceInfo provides extra privacy protection (requester must supply a verified certificate) and prevents by-value transmission of very large payloads; a new block is preferred for small, widely applicable data that benefits from by-value delivery.
Only blocks registered in the Emergency Call Data Types registry (Section 11.1.9) are permitted to be conveyed using the mechanisms in this document. This document updates RFC 6443 and RFC 6881, extending their emergency call frameworks to carry the additional data defined here.
DataProviderString, ProviderID, and ProviderIDSeries are mandatory for all data providers except the originating device. TypeOfProvider and ContactURI are Required (MUST be present) for all providers without exception.
<DeviceSpecificType> MUST be provided whenever a <DeviceSpecificData> URI is present. The combination of ProviderIDSeries and ProviderID MUST be globally unique.
Every data block MUST include a <DataProviderReference> element, and all blocks added by a single entity at the same time MUST carry the same value. Any entity that provides any other block MUST also supply a Data Provider (ProviderInfo) block.
New blocks added to the Emergency Call Data Types registry MUST be categorized as data about the caller, about the call, or about a location, per the three categories described in Section 1.
ServiceEnvironment is Required in ServiceInfo unless ServiceType is 'wireless'; ServiceType and ServiceMobility are both unconditionally Required elements in ServiceInfo.
The device MUST provide at least one Call-Info header field with a 'purpose' value starting with 'EmergencyCallData' unless it knows a service provider is in the call path. Each service provider in the path of an emergency call MUST insert its own Call-Info.
The 'privacyRequested' boolean attribute MUST be provided if the SubscriberInfo block is not empty. If more than one <tel> property appears in a subscriber xCard, a parameter from the 'vCard Property Values' registry MUST be specified on each.
When additional data is provided by reference, an HTTPS URI MUST be used, ensuring TLS protection during retrieval. Data passed by value must be enclosed in SIP body MIME parts referenced via CID URLs.
The scope of these data structures is explicitly limited to emergency calls. Use in non-emergency calls is undefined and would unnecessarily expose confidential subscriber, device, and service information. The Call-Info 'EmergencyCallData' purpose value SHOULD NOT appear outside emergency call contexts.
The SubscriberInfo block's 'privacyRequested' boolean attribute expresses the subscriber's desire for privacy, mirroring a privacy flag in legacy emergency call systems. Interpretation is left to each jurisdiction per local regulatory requirements; the flag may affect display of data across any block.
A new 'main-number' value is added to the TYPE parameter of the xCard 'tel' property, enabling specification of a primary/main enterprise telephone number distinct from a direct-dial individual number. Usable in any xCard within an emergency call additional data block.
<DataProviderReference> is mandatory in every block. Its value has the same syntax as an RFC 5322 msg-id (world-unique) but without enclosing angle brackets, and it associates all blocks contributed by a single provider as a unit.
Five XML data blocks are defined: EmergencyCallData.ProviderInfo (provider identity/contact), EmergencyCallData.ServiceInfo (service characteristics), EmergencyCallData.DeviceInfo (device details), EmergencyCallData.SubscriberInfo (owner/subscriber), and EmergencyCallData.Comment (free-form human-readable text). Each block has a corresponding MIME media type.
<ServiceType> (Required) defines the type of service over which the call is placed. Initial registry values include: wireless, coin, one-way, temp, MLTS-hosted, MLTS-local, sensor-unattended, sensor-attended, POTS, OTT, digital, OPX, and relay. More than one value MAY be returned.
<SubcontractorPrincipal> and <SubcontractorPriority> are required when the data provider is a subcontractor. <SubcontractorPriority> MUST be 'sub' if the subcontractor is to be contacted first, or 'main' if the principal should be contacted first.
<TypeOfProvider> identifies the category of the data provider. Initial registry values include: Client, Access Network Provider, Telecom Provider, Telematics Provider, Language Translation Provider, Emergency Service Provider, Emergency Modality Translation, Relay Provider, and Other.
<UniqueDeviceID> with attribute <TypeOfDeviceID> identifies the specific device or SIM. Registered type tokens include MEID, ESN, MAC, WiMAX, IMEI, IMSI, UDI, RFID, and SN. Multiple instances may be present to supply more than one identifier.
Five MIME content-types are registered: application/EmergencyCallData.ProviderInfo+xml, application/EmergencyCallData.ServiceInfo+xml, application/EmergencyCallData.DeviceInfo+xml, application/EmergencyCallData.SubscriberInfo+xml, and application/EmergencyCallData.Comment+xml.
The Provider ID Series registry initially contains three entries: NENA (National Emergency Number Association), EENA (European Emergency Number Association), and 'domain' (fully qualified domain name as identifier). This registry governs how ProviderID values are interpreted.
This document creates the 'Emergency Call Additional Data' registry group containing nine sub-registries: Provider ID Series, Service Environment, Service Type, Service Mobility, Type of Provider, Device Classification, Device ID Type, Device/Service Data Type, and Emergency Call Data Types.
Additional call data is highly sensitive and private. By-reference transmission requires HTTPS/TLS. Unauthorized access must be prevented; the document notes that service providers typically protect this data carefully and disclosing it in an emergency call is a trade-off to protect the caller's greater interest.
Additional data is carried in SIP Call-Info header fields with a 'purpose' parameter of the form 'EmergencyCallData.<SubtypeRoot>' (e.g., 'EmergencyCallData.ProviderInfo'). The URI is either an HTTPS URL (by reference) or a CID URL (by value, referencing a MIME body part with matching Content-ID).
When conveyed via PIDF-LO, additional data blocks are placed in the <provided-by> element using the urn:ietf:params:xml:ns:EmergencyCallData namespace. Each block may be embedded by value or referenced by HTTPS URL; retrieval is via HTTPS GET returning an XML object.