Public Safety Answering Point (PSAP) Callback
Extracted elements (18)
The callback may use a different calling party identity than the PSAP answered the emergency call from (e.g., due to multi-stage routing), so UA state does not need to store calling party identity—only a timer is required for the callback recognition window.
The existing RFC 6443 mechanism for PSAP callback detection—comparing the PSAP domain from the outbound call to the domain of an incoming callback—fails in scenarios like routing asymmetry, multi-stage routing, call forwarding, and network-based URN resolution, motivating the new explicit 'psap-callback' header value.
The same media requirement for callbacks is motivated by two concerns: the emergency caller may have disabilities requiring a specific medium, and a caller seeking help covertly (e.g., via IM to avoid noise) could be endangered if the callback switches to a voice call with a ringtone.
In multi-stage routing, the PSAP URI domain (e.g., [email protected]) may differ from the next-hop domain stored during emergency call setup (e.g., [email protected]), causing the VoIP provider to treat a legitimate PSAP callback as a normal call.
In routing-asymmetry deployments where inbound and outbound SIP proxies are different entities, the domain-comparison approach from RFC 6443 fails because callback state is stored only at the outbound proxy while the callback arrives at the inbound proxy.
PSTN interworking scenarios (Figure 5), where the emergency call enters the PSTN and the callback may use a different gateway or endpoint identifier, are explicitly out of scope for this specification and are not supported by the defined solution.
When emergency calls are forwarded to a different emergency services network (e.g., from state.example to example.net/org/com), the callback originates from the forwarded domain while the UA has stored state for the original domain, breaking domain-comparison callback detection.
A PSAP callback MUST use the same media as the original emergency call (e.g., if the initial call used real-time text, the callback must also use real-time text), to accommodate disabilities and intentional media choices of the emergency caller.
A UA that has made an emergency call MUST keep state information so that it can recognize and accept a callback from the PSAP if it occurs within a reasonable time after the emergency call was placed.
SIP UAs MUST maintain a timer started at the time of the original emergency call, which expires within a reasonable amount of time (e.g., 30 minutes per RFC 6881), to limit the window during which PSAP callback preferential treatment applies.
VoIP providers MUST only give PSAP callbacks preferential treatment when the calling party identity of the PSAP was successfully matched against entries in a white list. If not verified, the provider MUST remove the PSAP callback marking so the call reverts to normal treatment.
A new SIP Priority header field value 'psap-callback' is defined to mark SIP requests associated with a PSAP callback session, allowing SIP entities to apply callback-specific procedures such as bypassing call barring or forwarding.
During emergency call setup, two identifiers are conveyed to the PSAP: the caller's Address-of-Record (AOR) and, if available, the Globally Routable User Agent URI (GRUU), both used as contact information to enable PSAP callbacks.
This document adds the 'psap-callback' value to the IANA SIP 'Priority Header Field Values' registry, originally allocated by RFC 6878. The semantic is defined in Section 4.
Identity assurance for PSAP callbacks can use SIP Identity (RFC 4474, cryptographic) or P-Asserted-Identity (RFC 3325, chain of trust), as well as TLS between neighboring SIP entities. The STIR working group was revising these mechanisms at time of writing to better handle legacy interworking.
If the 'psap-callback' extension is not recognized, not verified, or not obeyed by SIP intermediaries or endpoints, the call must be treated as a normal call without any preferential marking, preventing failures in call handling procedures.
The 'psap-callback' Priority header value can be inserted by any SIP entity, including attackers, enabling bypass of blacklists, call-forwarding, and UI settings such as vibrate-only mode. Preferential treatment must only be granted when the PSAP identity is verified against a trusted white list.
The ABNF extension for the SIP Priority header field adds 'psap-callback' as a new priority-value: `priority-value =/ "psap-callback"`. This value is inserted in the SIP Priority header of INVITE requests to signal PSAP callback status.