%% You should probably cite rfc7090 instead of this I-D. @techreport{ietf-ecrit-psap-callback-10, number = {draft-ietf-ecrit-psap-callback-10}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/10/}, author = {Henning Schulzrinne and Hannes Tschofenig and Christer Holmberg and Milan Patel}, title = {{Public Safety Answering Point (PSAP) Callback}}, pagetotal = 15, year = 2013, month = jul, day = 13, abstract = {After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call taker) it is possible that the call taker feels 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 situation of a wounded person. A call taker may trigger a callback towards 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 PSAP callbacks to bypass authorization policies 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. A solution based on a new header field value, called "psap-callback", for the SIP Priority header field is specified to accomplish the PSAP callback marking.}, }