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

From: <[email-masked]>
Date: Tue, 11 Aug 2009 22:32:36 +0100

Brian,

This looks to be very useful and I'd like to add an extra dimension to
requirements please.

One of main problems we have in answering emergency calls in UK PSAPs is
when a caller does not answer or is incoherent at the start of a call
and then clears.  The PSAP has not had time to establish whether or not
there's a genuine emergency or whether the call is accidental or is a
result of a child "playing" with the phone (a particular issue since we
have three digits the same with 999 as an emergency code!).  If the PSAP
is able to influence or affect the release/ending of the  emergency call
it provides an efficient way of establishing whether or not help is
required. 

This is currently achieved by setting of Last Party Release in C7
signalling, which means a caller cannot make another call until the PSAP
is satisfied that an emergency service is not required, usually by
caller confirming (adult finds child playing with phone or adult
realises they have misdialled) - it does not work on ISDN calls though.

Thanks 

John 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: 29 July 2009 14:22
To: [email-masked]
Subject: Re: [Ecrit] Problem statement for Premature Disconnect

There is a small typo in this.

The ECRIT work group would complete requirements for handling premature
disconnect.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf

> Of Rosen, Brian
> Sent: Wednesday, July 29, 2009 5:31 AM
> To: [email-masked]
> Subject: [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.  I propose:
> 
> 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.  For example, the device may alert rather 
> than disconnect.  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.
> 
> 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.
> 
> The geopriv work group would complete requirements for handling 
> premature disconnect.  Some of the resulting protocol work may need to

> be accomplished in other RAI work groups.
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Francois Menard <[email-masked]>
Date: Tue, 18 Aug 2009 07:13:29 -0400

I thought the consensus for many years is that when engaged into an  
emergency call, the PSAP would have to be the one sending a BYE and  
the end-user ATA would never initiate a BYE.

f.

>> be accomplished in other RAI work groups.

Francois Menard
[email-masked]