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

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY draft-ietf-ecrit-phonebcp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-phonebcp.xml">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact='yes'?>
<rfc category="std" ipr="full3978" docName="draft-rosen-ecrit-premature-disconnect-rqmts-01">
<front>
    <title abbrev="Abandoned Call/PrematureDisconnect">
       Requirements for handling abandoned calls and premature disconnects in emergency calls on the Internet
    </title>
    <author fullname="Brian Rosen" initials="B.R" surname="Rosen">
      <organization>NeuStar</organization>

      <address>
        <postal>
          <street>470 Conrad Dr.</street>
          <city>Mars</city>
          <region>PA</region>
          <code>16046</code>
          <country>US</country>
        </postal>
        <phone>+1 724 382 1051</phone>
        <email>br@brianrosen.net</email>
      </address>
    </author>
    <date month="November" day="3" year="2008" />
    <area>RAI</area>
    <workgroup>ecrit</workgroup>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>geopriv</keyword>
    <keyword>location</keyword>
    <abstract>
      <t>
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.
      </t>
    </abstract>
</front>
<middle>
 
<section title="Problem Statement">
<t><xref target="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.</t>
<section title="Premature disconnect">
<t>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.</t> 
</section>
<section title="Abandoned Call">
<t>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 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.</t>
<t>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.</t>
<t>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.</t> 
</section>
</section>
<section title="Requirements for Premature Disconnect">
<t>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.
<list style="hanging">
<t hangText="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.</t>
<t hangText="  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.</t>
<t hangText="PD-2"> It must be possible for the call taker to know when the caller has attempted to prematurely disconnect.</t>
<t hangText="  Rationale:"> Knowledge of the caller action gives valuable information to the call 
taker which may influence how the call will be managed going forward.</t>
<t hangText="PD-3"> Reconnecting the caller must work reasonably reliably under congestion conditions, especially those where call admission control is implemented.</t>  
<t hangText="  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 them.  </t>
<t hangText="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.</t>
<t hangText="  Rationale:"> The caller believes they have disconnected.  The ability to alert is needed to 
encourage the caller to reconnect.</t>
<t hangText="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.</t>
<t hangText="  Rationale:"> Priority must be given to the call taker until such time she/he determines the call can be terminated.</t>
<t hangText="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.</t> 
<t hangText="  Rationale:"> Media and signaling resources must be available as soon as the caller re-answers.</t>
<t hangText="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.</t>
<t hangText="  Rationale:"> This reflects the current situation.</t>
</list></t>
</section>
    
<section title="Requirements for Abandoned Call">
<t>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.
<list style="hanging">
<t hangText="AC-1"> It must be possible for the PSAP or the network that serves it to cause abandoned calls to complete and stay connected.</t>
<t hangText="  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.</t> 
<t hangText="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.</t>
<t hangText="  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.</t>
<t hangText="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.</t>
<t hangText="  Rationale:"> This reflects the current situation.</t></list></t>  
</section>
    

<section title="IANA Considerations">
<t>There are no IANA Considerations for this document</t>
</section>

<section title="Security Considerations">
<t>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.</t>
</section>

<section title="Acknowledgments">
<t>
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.
</t>
</section>
  </middle>

  <back>
    <references title="Informative References">
      &draft-ietf-ecrit-phonebcp;
    </references>
  </back>
</rfc>