Public Safety Answering Point (PSAP) Callbacks
draft-schulzrinne-ecrit-psap-callback-03
| Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Henning Schulzrinne , Hannes Tschofenig , Milan Patel | ||
| Last updated | 2010-03-08 | ||
| Replaced by | draft-ietf-ecrit-psap-callback | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-ecrit-psap-callback | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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 or for a clarification. 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, then 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 addresses callbacks in a limited fashion and thereby covers a couple of scenarios. This document discusses some shortcomings and raises the question whether additional solution techniques are needed.
Authors
Henning Schulzrinne
Hannes Tschofenig
Milan Patel
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)