RFC 7090
Public Safety Answering Point (PSAP) Callback
🌸 RFC 7090: Public Safety Answering Point (PSAP) Callback 🌸
Okay bestie, this is the IETF spec from April 2014 about how a 911-style call taker can call the emergency caller back and actually get through. 📞✨ It's an IETF Standards Track document (ISSN 2070-1721), so it's the real deal, not a suggestion. 💅 The authors are H. Schulzrinne (Columbia University), H. Tschofenig, C. Holmberg (Ericsson), and M. Patel (Huawei Technologies (UK) Co., Ltd.). The title block doesn't list anything it obsoletes or updates, so it's a fresh start. 🦋
Abstract 🌸
Okay so, picture this: an emergency call ends, either because the caller hung up too early or because the call taker finished normally. 📱 The call taker might still need to talk to them, maybe the call dropped before they learned how the accident victim was doing. 😭 So the call taker can call back using the contact info from the first call. The problem is that a callback like this can be treated like any other call, which means it might get blocked by authorization policies or sent to voicemail. 💀
The IETF emergency services architecture already has a fix for this, letting PSAP callbacks skip authorization policies so they reach the caller quickly. ⚡ Unfortunately, that mechanism only covers a few scenarios. This document looks at what's broken and shows more situations where better-than-normal call treatment would be useful. 🧚 The solution is a new header field value for the SIP Priority header field, called psap-callback, which marks a call as a PSAP callback. Iconic. 👑
Status of This Memo 🍓
This is an Internet Standards Track document. 🎀
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741. 📚
For the current status of this document, any errata, and how to send feedback, look at http://www.rfc-editor.org/info/rfc7090. 🔗
Copyright Notice 💜
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License. 🫶
Table of Contents 🧚
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Callback Scenarios ..............................................5
3.1. Routing Asymmetry ..........................................5
3.2. Multi-Stage Routing ........................................7
3.3. Call Forwarding ............................................8
3.4. Network-Based Service URN Resolution ......................10
3.5. PSTN Interworking .........................................11
4. SIP PSAP Callback Indicator ....................................12
4.1. General ...................................................12
4.2. Usage .....................................................12
4.3. Syntax ....................................................12
4.3.1. General ............................................12
4.3.2. ABNF ...............................................12
5. Security Considerations ........................................12
5.1. Security Threat ...........................................12
5.2. Security Requirements .....................................13
5.3. Security Solution .........................................13
6. IANA Considerations ............................................15
7. Acknowledgements ...............................................16
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................171. Introduction ✨
Okay, so calling the police, the fire department, or an ambulance in an emergency is one of the most important things a phone does. 🚒 As phones move from old circuit-switched telephony to Internet telephony, users totally expect that this core function keeps working at least as well as it did before. 💖 Brand-new devices and services that aren't traditional phones are showing up, and people increasingly expect to use them for emergency calls too. 📱
An overview of how emergency calling works with the IETF emergency services architecture is in [RFC6443], and [RFC6881] gets into the technical details. 🤓 During emergency call setup, two key identifiers get passed to the PSAP call taker's user agent: the address-of-record (AOR), and, if it's available, the Globally Routable User Agent (UA) URIs (GRUUs). RFC 3261 [RFC3261] defines the AOR like this:
An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user.
Here's the thing: one user can have several user agents (handsets, softphones, voicemail accounts, and so on) that all share the same AOR. 🎧 Sometimes you want an identifier that points at one specific user agent instead of the whole group, and that's what the GRUU is for. It's a unique user-agent identifier, and it's also globally routable. ✨ [RFC5627] explains how to get and use GRUUs, and [RFC6881] uses GRUUs for emergency calls too. 🦋
Regulators require that the emergency call setup procedure itself gives the call taker enough info to call the emergency caller back. 📋 That matters when the call drops early or when more communication is needed. The AOR and the GRUU are what make that possible. 💅
The call taker's attempt to reach the emergency caller back is called a "PSAP callback". 📞
Here's the catch, though: a PSAP callback can still be blocked by user-configured authorization policies, or forwarded to an answering machine. 🙈 That's because SIP entities (SIP proxies and the SIP user equipment itself) can't tell a PSAP callback apart from any other SIP call. "Call barring", "do not disturb", and "call diversion" (also called call forwarding) are all features that stop a call from getting through. These features can be implemented by SIP intermediaries as well as by the user agent, so they can show up in more than one place. 💀
The emergency services community wants PSAP callbacks handled so the chances of reaching the emergency caller go up. 🌈 At the same time, any solution has to keep other calls from sneaking past call forwarding or other authorization policies. 🔒 Ideally, a PSAP callback should relate to an earlier emergency call that happened "not too long ago". 🕰️ Defining an exact time window in a global IETF standard is tricky because national regulations vary a lot, but [RFC6881] suggests 30 minutes. ⏱️
Still, to meet the emergency services community's needs, a basic way to give PSAP callbacks preferential treatment was defined in Section 13 of [RFC6443]. That spec says:
A UA may be able to determine a PSAP callback by examining the domain of incoming calls after placing an emergency call and comparing that to the domain of the answering PSAP from the emergency call. Any call from the same domain and directed to the supplied Contact header or AOR after an emergency call should be accepted as a callback from the PSAP if it occurs within a reasonable time after an emergency call was placed.
This approach works like a stateful packet-filtering firewall, and it really does help in plenty of cases. 🔥 It's also pretty simple to implement, even though user agents and SIP intermediaries both have to keep call state. The downside is that it doesn't work in every deployment scenario. 😭 Section 3 describes the cases where the currently standardized approach falls short. 🌸
2. Terminology 📚
Emergency-services terminology is borrowed from [RFC5012]. That includes terms like emergency caller, user equipment, call taker, Emergency Service Routing Proxy (ESRP), and Public Safety Answering Point (PSAP). 🧚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 💖
3. Callback Scenarios 🎀
This section shows a bunch of situations where the currently specified solution for preferential callback treatment, as described in [RFC6881], fails. 🙈 As Section 1 explained, a SIP entity checks an incoming PSAP callback by comparing the domain of the PSAP with the destination domain of the outbound emergency call that was placed earlier. 🔍
Part 1 done, bestie! 🌈💜
3.1. Routing Asymmetry ✨
okay so bestie, this one is giving "two different doors" energy 🚪💖. In some deployment environments it's super common for incoming and outgoing SIP messaging to get routed through different SIP entities. Figure 1 shows this, where a Voice over IP (VoIP) provider uses different SIP proxies for inbound and outbound call handling. Unless the two devices are synchronized, the callback that reaches the inbound proxy gets treated like any other call 😭, because the emergency call only stored its state information at the outbound proxy. Not fair, right? 🙈
,-------.
,' `.
,-------. / Emergency \
,' `. | Services |
/ VoIP \ I | Network |
| Provider | n | |
| | t | |
| | e | |
| +-------+ | r | |
+--+---|Inbound|<--+-----m | |
| | |Proxy | | e | +------+ |
| | +-------+ | d | |PSAP | |
| | | i | +--+---+ |
+----+ | | | a-+ | | |
| UA |<---+ | | t | | | |
| |----+ | | e | | | |
+----+ | | | | | | |
| | | P | | | |
| | | r | | | |
| | +--------+ | o | | | |
+--+-->|Outbound|--+---->v | | +--+---+ |
| |Proxy | | i | | +-+ESRP | |
| +--------+ | d | | | +------+ |
| | e | | | |
| | r +----+-+ |
\ / | |
`. ,' \ /
'-------' `. ,'
'-------'Figure 1: Example for Routing Asymmetry
3.2. Multi-Stage Routing 🌸
okay this one is a whole journey 🧚 routing towards the PSAP happens in several stages. We've got a SIP UA that uses the Location-to-Service Translation (LoST) Protocol [RFC5222] to learn the next-hop destination, which is esrp@example.net, to get the call closer to the PSAP. Then the call gets sent to the proxy of the user's VoIP provider (example.org). The provider receives the emergency call and creates a state based on the destination domain, example.net. Then it routes the call to the indicated ESRP. When the ESRP gets the call, it has to decide what the next hop is to reach the final PSAP. In our example, that next hop is the PSAP with the URI psap@example.com. Main character energy 👑
When a callback is sent from psap@example.com towards the emergency caller, it gets normal treatment by the proxy of the VoIP provider, since the PSAP's domain doesn't match the stored state information. Literally a plot twist 💀
,-----------.
+----+ ,' `.
| UA |--- esrp@example.net / Emergency \
+----+ \ | Services |
\ ,-------. | Network |
,' `. | |
/ VoIP \ | +------+ |
( Provider ) | | PSAP | |
\ example.org / | +--+---+ |
`. ,' | | |
'---+---' | | |
| | psap@example.com |
esrp@example.net | | |
| | | |
| | | |
| | +--+---+ |
+------------+-----+ ESRP | |
| +------+ |
| |
\ /
`. ,'
'----------'Figure 2: Example for Multi-Stage Routing
3.3. Call Forwarding 🦋
imagine this: an emergency call enters an emergency network (state.example) via an ESRP, but then it gets forwarded to a different emergency services network (in our example, example.net, example.org, or example.com). The same considerations apply when the police, fire and ambulance networks are part of the state.example subdomains (e.g., police.state.example).
Similar to the previous scenario, the wrong state information gets set up during the emergency call setup procedure. A callback would originate in the example.net, example.org, or example.com domains, whereas the emergency caller's SIP UA or the VoIP outbound proxy has stored state.example. Chaotic but make it make sense 😭🫶
,-------.
,' `.
/ Emergency \
| Services |
| Network |
|(state.example)|
| |
| |
| +------+ |
| |PSAP +--+ |
| +--+---+ | |
| | | |
| | | |
| | | |
| | | |
| | | |
| +--+---+ | |
------------------+---+ESRP | | |
esrp-a@state.org | +------+ | |
| | |
| Call Fwd | |
| +-+-+---+ |
\ | | | /
`. | | | ,'
'-|-|-|-' ,-------.
Police | | | Fire ,' `.
+------------+ | +----+ / Emergency \
,-------. | | | | Services |
,' `. | | | | Network |
/ Emergency \ | Ambulance | | (Fire) |
| Services | | | | | |
| Network | | +----+ | | +------+ |
| (Police) | | ,-------. | +----+---+PSAP | |
| | | ,' `. | | +------+ |
| +------+ | | / Emergency \ | | |
| |PSAP +----+--+ | Services | | | example.com ,
| +------+ | | Network | | `~~~~~~~~~~~~~~~
| | | (Ambulance) | |
| example.net , | | |
`~~~~~~~~~~~~~~~ | +------+ | |
| |PSAP +----+ +
| +------+ |
| |
| example.org ,
`~~~~~~~~~~~~~~~Figure 3: Example for Call Forwarding
3.4. Network-Based Service URN Resolution 🧚♀️
the IETF emergency services architecture also considers cases where resolving the Service URN to the PSAP URI doesn't only happen at the SIP UA itself, but also at intermediate SIP entities, like the user's VoIP provider. Cute, right? 🎀
Figure 4 shows this message exchange for the outgoing emergency call and the incoming PSAP graphically. While the state information stored at the VoIP provider is correct, the state allocated at the SIP UA is not. Oof 😭
,-------.
,' `.
/ Emergency \
| Services |
| Network |
| example.com |
| |
| +------+ | INVITE to police@example.com
| |PSAP +<---+------------------------+
| | +----+--------------------+ ^
| +------+ |INVITE from | |
| ,police@example.com | |
`~~~~~~~~~~~~~~~ | |
v |
+--------+ Query with location +--+---+-+
| | + urn:service:sos | VoIP |
| LoST |<-----------------------|Service |
| Server | police@example.com |Provider|
| |----------------------->| |
+--------+ +--------+
| ^
INVITE| | INVITE
from| | to
police@example.com| | urn:service:sos
V |
+-------+
| SIP |
| UA |
| Alice |
+-------+Figure 4: Example for Network-Based Service URN Resolution
3.5. PSTN Interworking 📞
okay so bestie, this one is a lil tricky 🥺 if an emergency call goes out through the PSTN (see Figure 5), there's no guarantee that the callback later goes through that same PSTN/VoIP gateway. The endpoint identifier might not even be the same going forward and backward, so it's genuinely hard to reliably spot PSAP callbacks. 😭
+-----------+
| PSTN |-------------+
| Calltaker | |
| Bob |<--------+ |
+-----------+ | v
-------------------
//// \\\\ +------------+
| | |PSTN / VoIP |
| PSTN |---->|Gateway |
\\\\ //// | |
------------------- +----+-------+
^ |
| |
+-------------+ | +--------+
| | | |VoIP |
| PSTN / VoIP | +->|Service |
| Gateway | |Provider|
| |<------INVITE----| Y |
+-------------+ +--------+
| ^
| |
INVITE INVITE
| |
V |
+-------+
| SIP |
| UA |
| Alice |
+-------+
Figure 5: Example for PSTN InterworkingNote: This scenario is considered outside the scope of this document. The specified solution does not support this use case. 🙈
4. SIP PSAP Callback Indicator 🎀
4.1. General
okay so this section adds a brand new header field value called "psap-callback" 💖 It goes into the SIP Priority header field, which is defined in [RFC3261]. Its whole job is to tell SIP entities that the request is tied to a PSAP callback SIP session. ✨
4.2. Usage
SIP entities that receive this header field value in an initial request for a SIP session can, depending on local policies, apply PSAP callback-specific procedures for the session or request. 🦋
The PSAP callback-specific procedures may be applied by SIP-based network entities and by the callee. What actually happens when a call is marked as a PSAP callback, like bypassing services and barring procedures, is outside the scope of this document. 💅
4.3. Syntax
4.3.1. General
This section defines the ABNF [RFC5234] for the new SIP Priority header field value "psap-callback". 🧚
4.3.2. ABNF
priority-value =/ "psap-callback"
Figure 6: ABNF5. Security Considerations 🔥
this part is SERIOUS bestie, read it carefully 💀
5.1. Security Threat
The PSAP callback functionality in this document lets marked calls bypass blacklists and ignore call-forwarding procedures and other similar features that are used to get an emergency caller's attention when someone is trying to reach them. 😤 And if the SIP UA supports the SIP Priority header value "psap-callback", it would override user-interface settings, like vibrate-only mode, to alert the caller of the incoming call. 📳
5.2. Security Requirements
The threat from Section 5.1 leads to a requirement: the mechanisms in this document cannot be used for malicious purposes, including telemarketing. 🚫📞
Also, if the newly defined extension is not recognized, not verified adequately, or not obeyed by SIP intermediaries or SIP endpoints, then it must not lead to a failure of the call handling procedure. Such a call must be treated like a call that does not have any marking attached. 🫶
The indicator described in Section 4 can be inserted by any SIP entity, including attackers. So it is critical that the indicator only leads to preferential call treatment in cases where the recipient has some trust in the caller, as described in the next section. 🚨
5.3. Security Solution
The approach for implementing the security requirements from Section 5.2 splits up depending on whether the behavior is applied by the UA or by SIP proxies. 🌈 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 an emergency call was placed, as described in Section 13 of [RFC6443]. Only a timer started at the time when the original emergency call has ended is required; information about the calling party identity is not needed, since the callback may use a different calling party identity, as described in Section 3. Because these SIP UA considerations are already described in [RFC6443] as well as in [RFC6881], the rest of this section focuses on the behavior of SIP proxies. 🧠
Figure 7 shows the architecture that uses the identity of the PSAP to decide whether preferential treatment of callbacks should be provided. To make this policy decision, the identity of the PSAP (i.e., calling party identity) is compared with a PSAPs white list. 👑
+----------+
| List of |+
| valid ||
| PSAPs ||
+----------+|
+----------+
*
* white list
*
V
Incoming +----------+ Normal
SIP Msg | SIP |+ Treatment
-------------->| Entity ||======================>
+ Identity | ||(if not in white list)
Info +----------+|
+----------+
||
||
|| Preferential
|| Treatment
++========================>
(if successfully verified)
Figure 7: Identity-Based AuthorizationThe identity assurance in SIP can come in different forms: via the SIP Identity [RFC4474] or the P-Asserted-Identity [RFC3325] mechanisms. The former relies on a cryptographic assurance and the latter on a chain of trust. Usage of Transport Layer Security (TLS) between neighboring SIP entities may also provide useful identity information. 🔐 At the time of writing, these identity technologies are being revised in the Secure Telephone Identity Revisited (stir) working group [STIR] to offer better support for legacy technologies interworking and for SIP intermediaries that modify the content of various SIP headers and the body. Once that work has been completed, these specifications will offer a stronger calling party identity mechanism that limits or prevents identity spoofing. 🦋
An important aspect from a security point of view is the relationship between the emergency services network (containing the PSAPs) and the VoIP provider, assuming the emergency call travels via the VoIP provider and not directly between the SIP UA and the PSAP. 💖
Setting up a white list with PSAP identities may be operationally complex and depends on the relationship between the emergency services operator and the VoIP provider. If there's a relationship between the VoIP provider and the PSAP operator, for example because they're both operating in the same geographical region, then populating the white list is fairly simple. That makes identifying a PSAP callback less problematic compared to when the two entities have never interacted before. In the end, the VoIP provider has to verify whether the marked callback message really came from a legitimate source. 🕵️♀️
VoIP providers MUST only give PSAP callbacks preferential treatment when the calling party identity of the PSAP was successfully matched against entries in the white list. If it cannot be verified (because there was no match), then the VoIP provider MUST remove the PSAP callback marking. That way, the callback reverts to a normal call. 🔄 As a second step, SIP UAs MUST maintain a timer that is started with the original emergency call, and this timer expires within a reasonable amount of time, such as 30 minutes per [RFC6881]. That timer also makes sure VoIP providers cannot misuse the PSAP callback mechanism, for example to get their support calls to reach their customers. ⏱️
Finally, a PSAP callback MUST use the same media as the original emergency call. For example, when an initial emergency call established a real-time text communication session, the PSAP callback must also attempt to establish a real-time communication interaction. There are two reasons for this, and they're both giving 🌸 First, the person seeking help may have disabilities that prevent them from using certain media, so using the same media for the callback avoids unpleasant surprises and delays. Second, the emergency caller may have intentionally chosen a certain media and not prefer to communicate in a different way. For example, it would be unfortunate if a hostage tries to seek help using instant messaging to avoid making any noise, only for the ringtone triggered by a PSAP voice-call callback to draw the attention of the hostage-taker. 😱 User-interface designs need to cater to such situations. 🎀
6. IANA Considerations 📋
This document adds the "psap-callback" value to the SIP "Priority Header Field Values" registry allocated by [RFC6878]. The meaning of the newly defined "psap-callback" value is defined in Section 4. ✅
7. Acknowledgements 🫶
huge thanks to these amazing people for their feedback: Bernard Aboba, Andrew Allen, John-Luc Bakker, Kenneth Carlberg, Martin Dolly, Keith Drage, Timothy Dwight, John Elwell, Janet Gunn, Cullen Jennings, Hadriel Kaplan, Paul Kyzivat, John Medland, Atle Monrad, James Polk, Dan Romascanu, Brian Rosen, Robert Sparks, Geoff Thompson, and Martin Thomson. 💜
Thank you also to the ECRIT working group chairs, Marc Linsner and Roger Marshall, for their support. Roger Marshall was the document shepherd for this document. Vijay Gurbani provided the general area review. ⭐
During IESG review, the document also got good feedback from Barry Leiba, Spencer Dawkins, Richard Barnes, Joel Jaeggli, Stephen Farrell, and Benoit Claise. 🌟
8. References 📚
Okay so this is the part where the paper trail lives, bestie 📚✨ these are all the RFCs and docs that 7090 leans on, and I'm keeping every single one exactly as written 🫶
8.1. Normative References 💜
Okay so these are the ones you need to read to actually get the spec, no cap 💅
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009.
[RFC6878] Roach, A., "IANA Registry for the Session Initiation
Protocol (SIP) "Priority" Header Field", RFC 6878, March
2013.8.2. Informative References 🌸
These ones are the extra background reading. Super helpful, not strictly required, but lowkey a must if you're curious about the backstory 🧚
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, December 2011.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling",
BCP 181, RFC 6881, March 2013.
[STIR] IETF, "Secure Telephone Identity Revisited (stir) Working
Group", http://datatracker.ietf.org/wg/stir/charter/,
October 2013.Authors' Addresses 🎀
Meet the crew who wrote this, bestie 🫶
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Hannes Tschofenig
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: christer.holmberg@ericsson.com
Milan Patel
Huawei Technologies (UK) Co., Ltd.
300 South Oak Way, Green Park
Reading, Berkshire RG2 6UF
U.K.
EMail: Milan.Patel@huawei.com📦 where this page comes from
- ietf: rfc7090 2014-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms