{"draft":"draft-ietf-ecrit-psap-callback-13","doc_id":"RFC7090","title":"Public Safety Answering Point (PSAP) Callback","authors":["H. Schulzrinne","H. Tschofenig","C. Holmberg","M. Patel"],"format":["ASCII","HTML"],"page_count":"18","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Emergency Context Resolution with Internet Technologies RAI","abstract":"After an emergency call is completed (terminated either prematurely\r\nby the emergency caller or normally by the call taker), the call\r\ntaker may feel the need for further communication.  For example, the\r\ncall may have been dropped by accident without the call taker having\r\nsufficient information about the current state of an accident victim.\r\nA call taker may trigger a callback to the emergency caller using the\r\ncontact information provided with the initial emergency call.  This\r\ncallback could, under certain circumstances, be treated like any\r\nother call and, as a consequence, it may get blocked by authorization\r\npolicies or may get forwarded to an answering machine.\r\n\r\nThe IETF emergency services architecture specification already offers\r\na solution approach for allowing Public Safety Answering Point (PSAP)\r\ncallbacks to bypass authorization policies in order to reach the\r\ncaller without unnecessary delays.  Unfortunately, the specified\r\nmechanism only supports limited scenarios.  This document discusses\r\nshortcomings of the current mechanisms and illustrates additional\r\nscenarios where better-than-normal call treatment behavior would be\r\ndesirable.  We describe a solution based on a new header field value\r\nfor the SIP Priority header field, called \"psap-callback\", to mark\r\nPSAP callbacks.","pub_date":"April 2014","keywords":["PSAP","callback","SIP","emergency","VoIP"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC7090","errata_url":null}