Search RFCs

RFC Editor

File formats:

Status:

PROPOSED STANDARD

Authors:

H. Schulzrinne
H. Tschofenig
C. Holmberg
M. Patel

Stream:

IETF

Source:

ecrit (rai)

Cite this RFC:TXT  | XML  |  BibTeX

DOI:  https://doi.org/10.17487/RFC7090

Discuss this RFC: Send questions or comments to the mailing listecrit@ietf.org

Other actions:Submit Errata  | Find IPR Disclosures from the IETF  | View History of RFC 7090

Abstract

After an emergency call is completed (terminated either prematurelyby the emergency caller or normally by the call taker), the calltaker may feel the need for further communication. For example, thecall may have been dropped by accident without the call taker havingsufficient information about the current state of an accident victim.A call taker may trigger a callback to the emergency caller using thecontact information provided with the initial emergency call. Thiscallback could, under certain circumstances, be treated like anyother call and, as a consequence, it may get blocked by authorizationpolicies or may get forwarded to an answering machine.

The IETF emergency services architecture specification already offersa solution approach for allowing Public Safety Answering Point (PSAP)callbacks to bypass authorization policies in order to reach thecaller without unnecessary delays. Unfortunately, the specifiedmechanism only supports limited scenarios. This document discussesshortcomings of the current mechanisms and illustrates additionalscenarios where better-than-normal call treatment behavior would bedesirable. We describe a solution based on a new header field valuefor the SIP Priority header field, called "psap-callback", to markPSAP callbacks.

For the definition ofStatus,seeRFC 2026.

For the definition ofStream, seeRFC 8729.