One document matched: draft-rosen-ecrit-premature-disconnect-rqmts-01.txt

Differences from draft-rosen-ecrit-premature-disconnect-rqmts-00.txt

ecrit                                                           B. Rosen
Internet-Draft                                                   NeuStar
Intended status: Standards Track                        November 3, 2008
Expires: May 7, 2009


 Requirements for handling abandoned calls and premature disconnects in
                    emergency calls on the Internet
            draft-rosen-ecrit-premature-disconnect-rqmts-01

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 May 7, 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 May 7, 2009                  [Page 1]

Internet-Draft     Abandoned Call/PrematureDisconnect      November 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 . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Informative References  . . . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8






































Rosen                      Expires May 7, 2009                  [Page 2]

Internet-Draft     Abandoned Call/PrematureDisconnect      November 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 inevitablely 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" (CPH) which is used in some
   jurisdictions to meet this requirement.  If the user hangs up When
   CPH is engaged, the call is not torn down, but instead is maintained
   despite the "on hook" condition.  The call taker may also have 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 their current PSAP call disconnect control
   capability, while other jurisdictions would like to regain 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 a 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, dispatching resources 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



Rosen                      Expires May 7, 2009                  [Page 3]

Internet-Draft     Abandoned Call/PrematureDisconnect      November 2008


   Interactive Media Response 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.

   There is always a period of time after a call is initiated by a
   caller before there is any reasonable possibility to determine that a
   call is abandoned.  Since the appication of special handling for
   abandoned call is dependent on conditions, there is an implication
   that some form of negotiating is needed between the UAS and the UAC
   to invoke any kind of abandoned call processing.  This in turn
   implies that if the call is abandoned before the signaling
   negotiation completes, no special handling should be provided.
   Accordingly, an abandoned call is defined as a call which is
   attempted to be disconnected prior to the UAS answering, but after
   any signaling that would enable the feature is completed.

   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 reconnect via callback.


2.  Requirements for Premature Disconnect

   In the following discussion "caller" is the human, "UAC" is the
   device the caller uses, "Call Taker" is the human, "UAS" is the
   device in the PSAP.
   PD-1  It must be possible to have the call taker 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 call taker to know when the caller
      has attempted to prematurely disconnect.
     Rationale:  Knowledge of the 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, especially those where call admission
      control is implemented.
     Rationale:  PSAPs require robust mechanisms to perform their tasks.
      When congestion gets severe, it may not be possible to perform any
      signaling, and media may be disrupted.  This requirement does not
      imply QoS nor does it imply any priority mechanisms.  It biases
      towards solutions that leave calls up over solutions that let call
      signaling or media sessions terminate and attempts to re-establish



Rosen                      Expires May 7, 2009                  [Page 4]

Internet-Draft     Abandoned Call/PrematureDisconnect      November 2008


      them.
   PD-4  When PD-1 is enforced, the call taker must be able to cause
      alerting at the UAC which has attempted to prematurely disconnect
      from the emergency call.
     Rationale:  The caller believes they have disconnected.  The
      ability to alert is needed to encourage the caller 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.  This
      requirement is not intended to imply a user inteface with multiple
      lines accessible independently is locked to the single line that
      placed the emergency call.  As mistakes can be made, an override
      mechanism invoked by the caller must be be feasible.  The
      implementation must fail safely such that the phone cannot be
      locked and unable to call for help.
     Rationale:  Priority must be given to the call taker until such
      time she/he determines the call can be terminated.
   PD-6  All Media and signaling streams flowing between the UAC and UAS
      must be maintained to the extent needed for rapid reconnection.
      This specifically does not imply that the call taker be able to
      recieve live media from the UAC while the user believes the call
      is disconnected.  "Rapidly" is in human terms: the time from when
      the caller reacts to the mechanism, initialting reconnect, and the
      time the call taker can resume conversing, and is perhaps a
      second.
     Rationale:  Media and signaling resources must be available as soon
      as the caller 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.
     Rationale:  This reflects the current situation.


3.  Requirements for Abandoned Call

   In the following discussion "caller" is the human, "UAC" is the
   device the caller uses, "Call Taker" is the human, "UAS" is the
   device in the PSAP.  "PSAP" is management action in the jurisdiction.
   AC-1  It must be possible for the PSAP or the network that serves it
      to cause abandoned calls to complete and stay connected.
     Rationale:  Call takers 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
      jurisdictions who would otherwise respond to all abandoned calls.







Rosen                      Expires May 7, 2009                  [Page 5]

Internet-Draft     Abandoned Call/PrematureDisconnect      November 2008


   AC-2  AC-1 shall be applied at the earliest possible time in the call
      establishment process.  Abandoned calls are defined as those where
      roundtrip signaling messages are completed between the UAS and the
      UAC necessary to invoke the mechanism.  Calls disconnected before
      that time are not considered abandoned.
     Rationale:  Disallowing call abandonment early minimizes the
      chances of abandoned calls, but since the conditions at the call
      taker have to be considered before the mechanism can be invoked,
      some negotiation via signaling is needed.
   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 conditions at the UAS.
     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, Ric Atkins, Anand
   Akundi 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),
              July 2008.








Rosen                      Expires May 7, 2009                  [Page 6]

Internet-Draft     Abandoned Call/PrematureDisconnect      November 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 May 7, 2009                  [Page 7]

Internet-Draft     Abandoned Call/PrematureDisconnect      November 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 May 7, 2009                  [Page 8]