Subject: Re: [Ecrit] Problem statement for Premature Disconnect

From: Randall Gellens <[email-masked]>
Date: Sat, 1 Aug 2009 07:23:43 -0700

At 5:31 AM -0400 7/29/09, Brian Rosen wrote:

>  I was asked to reword a problem statement on premature disconnect that
>  might be acceptable to begin work on, probably a design team on
>  requirements.

Hi Brian,

I think this problem statement is much better.  I made a few small 
suggested changes:

>  In emergency calls, people are stressed.  They sometimes try to
>  disconnect a call where communication between the caller and the call
>  taker has begun, but before the call taker has acquired enough
>  information to direct appropriate response.  That circumstance is known
>  as "premature disconnect".

>  In those circumstances the device should
>  behave differently.

I suggest replacing this sentence with "Special behavior by the 
device during emergency calls can help avoid premature disconnect."

>    For example, the device may alert rather than
>  disconnect.

I suggest changing this sentence to "For example, the device may 
respond to a disconnection request by first alerting rather than 
immediately disconnecting."

>  The behavior of the device would be UI driven, and thus not
>  specifiable by the IETF, although advice might be given. 
>
>  Special behavior is not always desirable.  For example, in high call
>  volume circumstances, the call may be answered by the PSAP at an IVR, in
>  which case no special behavior is desired.  The device may not implement
>  the specification, or for some reason, it may not be available for a
>  particular emergency call.  For this reason, some form of signaling at
>  the beginning of the call is needed to negotiate enabling the special
>  behavior.

>  It is desirable that the PSAP be aware that the user has attempted to
>  disconnect/reconnect, and it may be useful for the PSAP to be able to
>  influence the behavior of the device.  Some form of signaling for this
>  purpose is desirable, but need not be reliable, since it is advisory.

Perhaps we can change this to: "An additional desire expressed by 
some PSAPs is to be aware that the user has attempted to disconnect 
or reconnect, and in such cases it may be useful for the PSAP to be 
able to influence the behavior of the device. Some form of signaling 
for this purpose is desirable, but need not be reliable, since it is 
advisory."

>  In all circumstances the user must maintain control of his device, and
>  it must be possible for the user to take some action to complete a
>  disconnect.

Can we add "The device must opt-in to any such special handling (as 
an example, based on a user preference or setting)."

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The most savage controversies are those about matters as to which there
is no good evidence either way.
    --Bertrand Russell

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 2 Aug 2009 12:26:02 +0300

A few minor changes: 

--------

In emergency calls, people are stressed.  They sometimes try to disconnect a
call where communication between the caller and the call taker has begun,
but before the call taker has acquired enough information to direct
appropriate response.  That circumstance is known as "premature disconnect".

Special behavior by the device during emergency calls can help avoid
premature disconnect. For example, the device may respond to a disconnection
request by first alerting rather than immediately disconnecting.
Unfortunately, the device of the emergency caller does not by itself know at
what point in time enough information has been obtained by the call taker so
that it would be safe to disconnect. As such, it appears desirable to let
the call taker disconnect the call rather than the emergency caller. The
behavior of the device in case of a premature disconnect would be user
interface (UI) driven, and thus not specifiable by the IETF, although advice
might be given.  

Note that this special behavior may not always be desirable.  For example,
in high call volume circumstances, the call may be answered by the PSAP at
an Interactive Voice Response (IVR), in which case no special behavior is
desired.  The device may not implement the specification, or for some
reason, it may not be available for a particular emergency call.  For this
reason, some form of signaling at the beginning of the call is needed to
negotiate enabling the special behavior.  

An additional desire expressed by some PSAPs is to be aware that the user
has attempted to disconnect or reconnect, and in such cases it may be useful
for the PSAP to be able to influence the behavior of the device. Some form
of signaling for this purpose is desirable, but need not be reliable, since
it is advisory.

The device must opt-in to any such special handling (as an example, based on
a user preference or setting).

--------

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Randall Gellens
>Sent: 01 August, 2009 17:24
>To: Rosen, Brian; [email-masked]
>Subject: Re: [Ecrit] Problem statement for Premature Disconnect
>
>>  I was asked to reword a problem statement on premature disconnect 
>> that  might be acceptable to begin work on, probably a 
>design team on  
>> requirements.
>
>Hi Brian,
>
>I think this problem statement is much better.  I made a few 
>small suggested changes:
>
>> information to direct appropriate response.  That circumstance is 
>> known  as "premature disconnect".
>
>
>>  In those circumstances the device should  behave differently.
>
>I suggest replacing this sentence with "Special behavior by 
>the device during emergency calls can help avoid premature disconnect."
>
>>    For example, the device may alert rather than  disconnect.
>
>I suggest changing this sentence to "For example, the device 
>may respond to a disconnection request by first alerting 
>rather than immediately disconnecting."
>
>> volume circumstances, the call may be answered by the PSAP 
>at an IVR, 
>> in  which case no special behavior is desired.  The device may not 
>> implement  the specification, or for some reason, it may not be 
>> available for a  particular emergency call.  For this reason, some 
>> form of signaling at  the beginning of the call is needed to 
>negotiate 
>> enabling the special  behavior.
>
>
>
>Perhaps we can change this to: "An additional desire expressed 
>by some PSAPs is to be aware that the user has attempted to 
>disconnect or reconnect, and in such cases it may be useful 
>for the PSAP to be able to influence the behavior of the 
>device. Some form of signaling for this purpose is desirable, 
>but need not be reliable, since it is advisory."
>
>>  In all circumstances the user must maintain control of his device, 
>> and  it must be possible for the user to take some action to 
>complete 
>> a  disconnect.
>
>Can we add "The device must opt-in to any such special 
>handling (as an example, based on a user preference or setting)."
>
>--
>Randall Gellens
>-------------- Randomly selected tag: --------------- The most 
>savage controversies are those about matters as to which there 
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>