Non-interactive Emergency Calls
Extracted elements (25)
Non-interactive emergency calls use SIP MESSAGE (not INVITE) because no two-way interactive media session is needed. The MESSAGE transaction does not create a session, distinguishing it from INVITE-based emergency calls that negotiate media streams such as voice, video, or real-time text.
Sensors may generate large data payloads, but including large amounts of data (tens of kilobytes) in a SIP MESSAGE is inadvisable because SIP entities are usually not equipped to handle very large messages. By-reference delivery via HTTPS avoids this limitation.
The CAP <area> element is limited to circle or polygon geometries. When converting from a PIDF-LO structure, points SHOULD be converted to a circle with radius equal to uncertainty, arc-bands and ellipses SHOULD be converted to polygons, and 3D locations SHOULD be converted to 2D forms.
AlertMsg-Error values sent in provisional responses MUST be sent using the RFC 3262 reliability mechanism, or if not negotiated, MUST be repeated in the final response. There MUST NOT be more than one AlertMsg-Error code in a SIP response.
An AlertMsg-Error header field MUST be included in any 425 response. A 425 response MUST NOT be sent when the request lacks CAP data, and a 425 response MUST NOT terminate an existing dialog.
For large data payloads, the sender SHOULD use the by-reference mechanism from RFC 7852, making data available via HTTPS, placing a URI in the Call-Info header field, so the recipient retrieves the data using HTTPS rather than embedding it in the SIP MESSAGE.
It is RECOMMENDED to omit the CAP <area> element when constructing a message. If location is present in the CAP alert, it SHOULD be copied into a PIDF-LO structure referenced by the SIP Geolocation header field.
The AlertMsg-Error header field MUST contain only one ErrorValue. The error code text string is OPTIONAL but RECOMMENDED for human readability; operators MUST NOT change the meaning of the error code.
The CAP <incidents> element MUST be present and the incident identifier MUST be chosen to be unique for a given <sender, expires, incidents> combination.
The server MUST return a list of acceptable formats using Accept, Accept-Encoding, or Accept-Language header fields when returning a 415 Unsupported Media Type error for an unrecognized CAP body format.
Usage of CAP MUST conform to the CAP specification. For the <sender> element: when a SIP-based originator creates the alert and author indication is irrelevant, the <sender> MUST be populated with the SIP URI of the user agent.
Privacy issues related to additional data (including location) are discussed in RFC 7852 and are applicable to non-interactive emergency calls. Confidentiality for emergency calls including non-interactive messages is subject to local regulations.
A CAP alert is included in a SIP message as an additional data block, conveyed via a Call-Info header field with purpose 'EmergencyCallData.cap'. The alert may be included by value (Content-ID URL with MIME body of type 'application/emergencyCallData.cap+xml') or by reference (a URI the recipient dereferences).
The 425 (Bad Alert Message) response code is a new SIP error indicating the request was malformed to the degree that no reasonable emergency response can be determined. It may be sent by a UAS or a SIP intermediary that detects a malformed alert.
IANA added the 425 (Bad Alert Message) response code to the SIP 'Response Codes' registry under Request Failure 4xx.
IANA added the AlertMsg-Error header field to the SIP 'Header Fields' subregistry, and added the 'code' parameter to the 'Header Field Parameters and Parameter Values' subregistry with no predefined values.
IANA created the 'SIP AlertMsg-Error Codes' registry with initial codes: 100 (Cannot process the alert payload), 101 (Alert payload was not present or could not be found), 102 (Not enough information to determine the purpose of the alert), 103 (Alert payload was corrupted). Registration procedure: Specification Required.
IANA registered a new 'cap' block type in the 'Emergency Call Data Types' subregistry of the 'Emergency Call Additional Data' registry (RFC 7852). The token is 'cap', Data About is 'The Call'.
IANA registered the 'application/EmergencyCallData.cap+xml' media type for carrying CAP payloads in SIP emergency calls. Optional parameter: charset (default UTF-8). Encoding: 7bit, 8bit, or binary.
For sensor-originated alerts, the identity of the sender plays an important role in deciding whether to accept or ignore incoming alert messages. SIP mechanisms such as P-Asserted-Identity (RFC 3325) and SIP Identity (RFC 8224) can be used, as can CAP's own signing mechanisms defined in CAP Section 3.3.4.1.
It is RECOMMENDED to use SIP security mechanisms such as SIP Identity PASSporT (RFC 8225) to tie the CAP alert to the SIP message, and TLS is RECOMMENDED to protect the entire SIP message exchange between neighboring SIP entities.
Recipients MUST take precautions when retrieving additional data blocks passed by reference (including the CAP alert via Call-Info URIs), as the URI may point to a malicious actor. No trust relationships can be assumed between the sending device domain, the CAP alert server domain, and additional data block domains.
There are no rate-limiting mechanisms in SIP; non-interactive emergency calls could be used by malicious actors or misbehaving automated devices to effect a denial-of-service attack on emergency services, potentially more easily than interactive calls since no human initiation is required.
To address replay attacks, a CAP document contains mandatory <identifier>, <sender>, and <sent> elements plus an optional <expires> element that together make each alert unique per sender with time restrictions. An entity that has already received a CAP alert within the indicated timeframe can detect replayed messages.
The AlertMsg-Error header field contains an ErrorValue composed of a 3-digit error-code followed by optional error-params. ABNF: AlertMsg-Error = 'AlertMsg-Error' HCOLON ErrorValue; ErrorValue = error-code *(SEMI error-params); error-code = 3DIGIT.