RFC 7090: Public Safety Answering Point (PSAP) Callback
In plain English — editorial summary, not part of the RFC
After an emergency call is completed (terminated either prematurely by the emergency caller or normally by the call taker), the call taker may feel the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current state of an accident victim. A call taker may trigger a callback to the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and, as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture specification already offers a solution approach for allowing Public Safety Answering Point (PSAP) callbacks to bypass authorization policies in order to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than-normal call treatment behavior would be desirable. We describe a solution based on a new header field value for the SIP Priority header field, called "psap-callback", to mark PSAP callbacks.
Document record
- Document ID
- RFC7090
- Published
- April 2014
- Authors
- H. Schulzrinne; H. Tschofenig; C. Holmberg; M. Patel
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- art
- Pages
- 18
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 7163URN for Country-Specific Emergency ServicesCurrent
March 2014
- RFC 6881Best Current Practice for Communications Services in Support of Emergency CallingUpdated
March 2013
- RFC 8866SDP: Session Description ProtocolCurrent
January 2021
- RFC 6404Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested CountermeasuresCurrent
November 2011
- RFC 6035Session Initiation Protocol Event Package for Voice Quality ReportingCurrent
November 2010
- RFC 5866Diameter Quality-of-Service ApplicationCurrent
May 2010
- RFC 7092A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User AgentsCurrent
December 2013
- RFC 7118The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)Current
January 2014
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?