Subject: [Ecrit] Premature Disconnect

From: Marc Linsner <[email-masked]>
Date: Fri, 07 Aug 2009 13:47:06 -0400

At the Stockholm meeting Brian Rosen presented Premature Disconnect
(http://www.ietf.org/proceedings/75/slides/ecrit-2.ppt) based on
draft-rosen-ecrit-premature-disconnect-rqmts-02
(http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts-02)
.  After some amount of discussion, we told Brian to Œgo away¹ and bring
back a problem statement vs. a set of requirements so we could evaluate
whether this is something we wanted to work on.  I had hoped we would have
time during the meeting for Brian to present the problem statement, but we
ran out of time. Brian sent it to the list on 7/29/09
(http://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html).

Now for the obvious questions.

Do you have feedback regarding the problem statement?

Do you think that this is a problem worth solving in ECRIT?

Your feedback will determine whether we ask for AD approval to add this work
to our charter.  Please respond by COB Friday August 14, 2009.

Thanks,

Marc & Hannes

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 7 Aug 2009 12:15:13 -0700

The essence of the problem is described in Section 1.1
draft-rosen-ecrit-premature-disconnect-rqmts:

   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 inevitably made.  A

   mechanism is needed to re-establish communication between the caller

   and the call taker when this happens. 

As was pointed out during the meeting, the question is exactly what it means
to "re-establish communication", and in particular, the role of the caller
vs. the PSAP.   

For me, Section 1.1 of the original document did not provide the
justification for the requirements that subsequently followed in Sections 2
and 3. 

The problem statement posted to the list on July 29 is a step in the right
direction, in that it goes into more detail on the types of behavior that
might be desirable in different circumstances (e.g. answering of the
emergency call by IVR versus a dispatcher).  

However, it still seems to me that the problem statement (not requirements)
deserves an expanded treatment which in particular goes into the issues that
can be encountered in "re-establishing communication" with existing
implementations, as well as those conforming to phone-bcp.  

So if the question is whether the problem is well-specified enough to modify
the charter so as to enable work on solutions, my answer is "no". 

If the question is whether I think ECRIT WG should add a problem statement
work item to its charter, my answer is "yes". 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marc Linsner
Sent: Friday, August 07, 2009 10:47 AM
To: 'ecrit'
Subject: [Ecrit] Premature Disconnect

.  After some amount of discussion, we told Brian to 'go away' and bring

Thanks,

Marc & Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 17 Aug 2009 21:09:33 +0300

FYI: We have not received a lot of feedback (maybe because of the holidays,
maybe because of lack of interest, maybe because of the other discussions).
So, help us to make a decision...

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marc Linsner
Sent: 07 August, 2009 20:47
To: 'ecrit'
Subject: [Ecrit] Premature Disconnect

Thanks,

Marc & Hannes

---

From: "Reese, Theresa E" <[email-masked]>
Date: Mon, 17 Aug 2009 14:34:45 -0400

I think that it is appropriate that this problem be addressed in ECRIT, and that Brian's proposed Problem Statement is a good first step in the process.

Terry Reese

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, August 17, 2009 2:10 PM
To: 'Marc Linsner'; 'ecrit'
Subject: [Ecrit] Please respond to the Premature Disconnect HUM

FYI: We have not received a lot of feedback (maybe because of the holidays, maybe because of lack of interest, maybe because of the other discussions). So, help us to make a decision...

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Linsner
Sent: 07 August, 2009 20:47
To: 'ecrit'
Subject: [Ecrit] Premature Disconnect
At the Stockholm meeting Brian Rosen presented Premature Disconnect (http://www.ietf.org/proceedings/75/slides/ecrit-2.ppt) based on draft-rosen-ecrit-premature-disconnect-rqmts-02 (http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts-02).  After some amount of discussion, we told Brian to 'go away' and bring back a problem statement vs. a set of requirements so we could evaluate whether this is something we wanted to work on.  I had hoped we would have time during the meeting for Brian to present the problem statement, but we ran out of time. Brian sent it to the list on 7/29/09 (http://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html).

Your feedback will determine whether we ask for AD approval to add this work to our charter.  Please respond by COB Friday August 14, 2009.

Thanks,

Marc & Hannes

---

From: Ted Hardie <[email-masked]>
Date: Mon, 17 Aug 2009 21:52:00 -0700

>FYI: We have not received a lot of feedback (maybe because of the holidays, maybe because of lack of interest, maybe because of the other discussions). So, help us to make a decision...

I'm not sure whether you're counting the discussion in Stockholm as part
of this feedback, but my basic take remains the same.  The PSAP can
*ask* for this capability during a negotiation, but they have to take
no for an answer and it must default off.  As feedback on Brian's
recent statement, I think this:

>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.

doesn't really jibe with where we've been going.  We've been
talking about a case in which the user is given a cue that
the disconnect may be premature and is given a mechanism
to continue to disconnect.  The "double press end" view of
things, if  you will.  Waiting for the PSAP to get signalling
on this is a non-starter for me personally, so I see this as
potentially complicating the code paths for very little gain.

				Ted

PS.  (I'm on vacation until I start my new job, and I'm at the beach
for much of the next 10 days; please expect slow responses).

>At the Stockholm meeting Brian Rosen presented Premature Disconnect (<http://www.ietf.org/proceedings/75/slides/ecrit-2.ppt>http://www.ietf.org/proceedings/75/slides/ecrit-2.ppt) based on draft-rosen-ecrit-premature-disconnect-rqmts-02 (<http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts-02>http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts-02).  After some amount of discussion, we told Brian to 'go away' and bring back a problem statement vs. a set of requirements so we could evaluate whether this is something we wanted to work on.  I had hoped we would have time during the meeting for Brian to present the problem statement, but we ran out of time. Brian sent it to the list on 7/29/09 (<http://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html>http://www.ietf.org/mail-archive/web/ecrit/current/msg06500.html).
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

---

From: [email-masked]
Date: Tue, 18 Aug 2009 07:49:12 +0200

> Waiting for the PSAP to get signalling

As I understand it [*] several lives are saved annually and prosecutions 
succeed because of this functionality in the PSTN.

In the latter case it's because the PSAP operator has been able to monitor 
and record evidence of a crime still in progress.

Ray

[*] admittedly hearsay, but I know a man who'd know for sure, but like me 
and you he's on vacation at the moment.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Aug 2009 12:57:17 -0700

At 7:49 AM +0200 8/18/09, [email-masked] wrote:
>As I understand it [*] several lives are saved annually and prosecutions succeed because of this functionality in the PSTN.
>
>In the latter case it's because the PSAP operator has been able to monitor and record evidence of a crime still in progress.

Maybe I've misunderstood the course of discussion so far, but it
was my understanding the Brian, at least, was not after functionality
that allowed the PSAP to continue to monitor a UE after an initial
attempt to disconnect was made.  The functionality was closer to
a fast-reconnect than retaining an open channel.  I'd also like
to re-point out that using PSTN models for this is not likely to
be perfect. 

If the proposed flow is:

User initiates call to PSAP
PSAP asks for special treatment of disconnect
User agent agrees
(Call begins)
User initiates disconnect
User confirms disconnect using special treatment
Call tears down

I think we have met what is currently on the table.

if it runs

User initiates call to PSAP
PSAP asks for special treatment of disconnect
User agent agrees
(Call begins)
User initiates disconnect
PSAP is informed prior to disconnect
(PSAP either controls the disconnect or confirmation must wait)
User confirms disconnect
Call tears down

I think we're back in the realm that requires a lot
more thought.  If you want a message the goes when
the User initiates disconnect but has no effect,
I strongly suspect that the confirmation will complete
prior to the PSAP operator being able to do or say anything
useful, except in cases where the User already recognized
that it was a mistake. 

regards,

Ted

>Ray
>
>[*] admittedly hearsay, but I know a man who'd know for sure, but like me and you he's on vacation at the moment.

---

From: Marc Linsner <[email-masked]>
Date: Tue, 18 Aug 2009 17:13:04 -0400

Ray,

On 8/18/09 1:49 AM, "[email-masked]" <[email-masked]>
wrote:

> In the latter case it's because the PSAP operator has been able to monitor and
> record evidence of a crime still in progress.
> 
[ML]  I don¹t understand how this is accomplished if the caller placed the
handset on the hookswitch.   Obviously, if the caller and call-taker have
agreed to allow the PSAP to monitor the situation,  that could work for any
technology, the caller simply lays the handset down without ending the call.

-Marc-

---

From: Randall Gellens <[email-masked]>
Date: Tue, 18 Aug 2009 22:00:36 -0700

Do you have feedback regarding the
problem statement?

Yes.  I've sent some proposed revisions.  I intended
to, but didn't actually send, comments on your proposed revision, to
the effect that the text about PSAP's being signalled in the middle
defeated the intent of the earlier statements about special handling
by the client.

Do you think that this is a problem worth solving in
ECRIT?

Depends on the problem statement :-)

I think it's useful for ecrit to work on this, provided we're
working on a problem that doesn't predetermine the solution, and that
the solution is helpful.

At 9:52 PM -0700 8/17/09, Ted Hardie wrote:

The PSAP can

*ask* for this capability during a
negotiation, but they have to take

no for an answer and it must default off.  As feedback on
Brian's

> purpose is desirable, but need not be reliable, since it is
advisory.

doesn't really jibe with where we've been
going.  We've been

to continue to disconnect.  The "double press end" view
of

things, if  you will.  Waiting for the PSAP to get
signalling

potentially complicating the code paths for very little
gain.

This is the basic disagreement that we've been struggling
with.

I think that ecrit can agree to work on a solution along the
lines of what Ted suggests, and that this solution would be useful in
solving the problem that Biran and Guy describe, and that this
solution would still allow for further revisions in the future to give
the PSAP more information about disconnection attempts.  In other
words, optional signalling at call set-up seems a useful way to get a
lot of the problem fixed, even if it doesn't go as far as some would
prefer.  In still other words, a compromise.

> potentially complicating the code paths for very little
gain.

As I understand it [*] several lives
are saved annually and prosecutions succeed because of this
functionality in the PSTN.

In the latter case it's because the PSAP operator has been able to
monitor and record evidence of a crime still in
progress.

As I understand it, this has been explicitly ruled out by almost
everyone who has spoken on the subject.  very explicitly and many
times.

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

The whole problem with the world is that fools and fanatics are always

so certain of themselves, but wiser people so full of doubts.

--Bertrand Russell

---

From: <[email-masked]>
Date: Mon, 31 Aug 2009 16:09:47 -0400

Hi,

YES. Those features are an integral part of some emergency services and should have an evolution path within the IP domain. In my view, ECRIT is the most appropriate place to initiate such engineering process and possibly improve the features over their PSTN ancestors.

Thanks,

Guy
________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Hannes Tschofenig
Envoyé : 17 août 2009 14:10
À : 'Marc Linsner'; 'ecrit'
Objet : [Ecrit] Please respond to the Premature Disconnect HUM

Thanks,

Marc & Hannes