One document matched: draft-rosen-ecrit-premature-disconnect-rqmts-00.txt
ecrit B. Rosen
Internet-Draft NeuStar
Intended status: Standards Track July 28, 2008
Expires: January 29, 2009
Requirements for handling abandoned calls and premature disconnects in
emergency calls on the Internet
draft-rosen-ecrit-premature-disconnect-rqmts-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 29, 2009.
Abstract
The -phonebcp draft currently requires endpoints to disable sending a
BYE on an emergency call. Insufficient justification and lack of
attention to the entire problem has caused comment on that section of
the document. This document attempts to define the problem and the
requirements to controlling disconnect on emergency calls.
Rosen Expires January 29, 2009 [Page 1]
Internet-Draft Abandoned Call/PrematureDisconnect July 2008
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Premature disconnect . . . . . . . . . . . . . . . . . . . 3
1.2. Abandoned Call . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements for Premature Disconnect . . . . . . . . . . . . . 4
3. Requirements for Abandoned Call . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Informative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Rosen Expires January 29, 2009 [Page 2]
Internet-Draft Abandoned Call/PrematureDisconnect July 2008
1. Problem Statement
[I-D.ietf-ecrit-phonebcp] currently disallows sending of BYE by the
calling UA. This requirement has generated a request for additional
capability, and has also caused some to question why it is needed,
and how the mechanisms interact with current and future emergency
call systems. There are two aspects of handing emergency calls that
give rise to the discussion.
1.1. Premature disconnect
Occasionally, when on an emergency call, a caller hangs up the call
before the call taker is finished acquiring enough information.
Emergency calls are stressful, and mistakes are easily made. A
mechanism is needed to re-establish communication between the caller
and the call taker when this happens. The PSTN has a feature
available, "Called Party Hold" which is used in some jurisdictions to
meet this requirement. When CPH is engaged, if the user hangs up,
the call is not torn down, but instead is maintained despite the "on
hook" condition. The call taker has a mechanism (called "Ringback"
which is different than call-back) to ring the user's telephone. If
the handset is picked up, since the call is still active and
resources maintained, the caller and the call taker are readily
reconnected. Called Party Hold is a feature that has long been
available in wireline networks, but is not currently implemented in
wireless networks. Some jurisdictions are desirous of maintaining
the current PSAP call disconnect control capability, while other
jurisdictions would like to gain access to those capabilities.
Still, in other jurisdictions, the function may not be needed or
desired.
1.2. Abandoned Call
It is not uncommon for an emergency call to be cancelled before it
reaches a call taker. Abandoned, in this context, means that the
call is terminated before the call taker answers it. While it can be
that the user is fully aware that the call is being cancelled, and
considers the cancellation the most appropriate solution, abandoned
calls are problematic to PSAPs because they don't know why the call
was abandoned. Unfortunately, what looks like an abandoned call can
be a more serious circumstance such as a hostage situation. In some
jurisdictions, the PSAP dispatches a police unit to all logged
abandoned calls. In such jurisdictions, dispatch could be avoided
for true inadvertent calling if the call went through, and the call
taker was able to assess the actual situation. Other jurisdictions
do not have the resources and may not respond to abandoned calls at
all. Sometimes, application of the function depends on conditions.
For example, in a mass calling event, an Interactive Media Response
Rosen Expires January 29, 2009 [Page 3]
Internet-Draft Abandoned Call/PrematureDisconnect July 2008
unit may be used to answer calls. Abandoning a call answered by a
machine may be appropriate. Even if jurisdictions respond to
abandoned calls by dispatching emergency personnel in normal
situations, they may not in this situation.
Retaining the connection is extremely important when there is no
callback information (e.g., uninitialized phone) or the caller has
call termination features active (such as call forwarding, do not
disturb) and the PSAP is unable to callback.
2. Requirements for Premature Disconnect
PD-1 It must be possible to have the PSAP rapidly re-establish
communications with a caller that attempts to prematurely
disconnect from the call.
Rationale: Time is paramount when handling emergency calls.
Keeping resources active and available until the call taker
determines the call can be terminated saves valuable time.
PD-2 It must be possible for the PSAP to know when the user has
attempted to prematurely disconnect
Rationale: Knowledge of the device state (and caller action) gives
valuable information to the call taker which may influence how the
call will be managed going forward.
PD-3 Reconnecting the caller must work reasonably reliably under
congestion conditions.
Rationale: PSAPs require robust mechanisms to perform their tasks.
PD-4 When PD-1 is enforced, the PSAP must be able to cause alerting
at an endpoint which has attempted to prematurely disconnect from
the emergency call
Rationale: The user believes they have disconnected. The ability
to alert is needed to encourage the user to reconnect.
PD-5 When PD-1 is enforced,the caller must not be able to place
another call until the PSAP allows the call to be released.
Rationale: Priority must be given to the PSAP until such time the
call taker determines the call can be terminated.
PD-6 All Media and signaling streams flowing between the caller and
call taker must be maintained to the extent needed for rapid
reconnection.
Rationale: Media and signaling resources must be available as soon
as the user re-answers.
PD-7 Control of premature disconnect is not needed in all
jurisdictions. It must be possible to not invoke the function and
allow premature disconnect to terminate the call as if no special
features were present.
Rosen Expires January 29, 2009 [Page 4]
Internet-Draft Abandoned Call/PrematureDisconnect July 2008
Rationale: This reflects the current situation.
3. Requirements for Abandoned Call
AC-1 It must be possible for the PSAP, or the network that serves
it, to have abandoned calls complete and stay connected.
Rationale: PSAPs cannot distinguish between calls which are
appropriately abandoned and calls that need response but were cut
short. Controls to limit abandonment are needed for those PSAPs
who would otherwise respond to all abandoned calls.
AC-2 AC-1 shall be applied at the earliest possible time in the call
establishment process.
Rationale: Disallowing call abandonment early minimizes the
chances of abandoned calls.
AC-3 Control of abandoned call is not needed in all jurisdictions.
It must be possible to not invoke the function and allow calls to
be abandoned as if no special features were present. Enabling or
disabling must be dynamic, so that it can be enforced or not
depending on requirements at the PSAP.
Rationale: This reflects the current situation.
4. IANA Considerations
There are no IANA Considerations for this document
5. Security Considerations
If these features can be enabled by entities other than PSAPs, the
entity may gain more control over the end device. Failures of
various kinds may prohibit callers from being able to disconnect.
6. Acknowledgments
Thanks to Guy Caron, Theresa Reese, John Hearty and other members of
the NENA i2.5 working group for their comments and suggestions on
this draft.
7. Informative References
[I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-05 (work in progress),
Rosen Expires January 29, 2009 [Page 5]
Internet-Draft Abandoned Call/PrematureDisconnect July 2008
July 2008.
Author's Address
Brian Rosen
NeuStar
470 Conrad Dr.
Mars, PA 16046
US
Phone: +1 724 382 1051
Email: br@brianrosen.net
Rosen Expires January 29, 2009 [Page 6]
Internet-Draft Abandoned Call/PrematureDisconnect July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Rosen Expires January 29, 2009 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-20 17:21:09 |