Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

["Brian Rosen" <[e-mail]>]

It's manual, not automatic.

When the PSAP call taker decides the call is over, then call termination
occurs.  They release the call (with a button).  In the proposed mechanisms,
the caller cannot terminate until then.

The signaling is how the call taker keeps the call up, how the UA signals
its state (on hook/off hook or its logical equivalent) to the PSAP and how
the PSAP signals various alerts (ringing, howler, etc) to the UA.  The
concern that has to be addressed is making sure that in failure conditions,
we don't "brick" the UA.

Please remember there are two problems:
Premature Disconnect, which is what we are talking about, and "Abandoned
Call", which is where the caller attempts to abandon placing an emergency
call before it is answered by the PSAP.  These really are the same thing,
but the signaling problem is different.  In "Premature Disconnect", the call
completed, the call taker has answered, and conversation started. "Abandoned
Call" is an attempt to take the call down some time between when the
original call was placed and the beginning of that period.

Brian

-----Original Message-----
From: James M. Polk [mailto:[e-mail]] 
Sent: Monday, October 06, 2008 8:07 PM
To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig'
Cc: 'ECRIT'
Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

OK, fair, I'm glad we are going in the precise direction.  But I am 
curious about who determines "precise" within the PSAP (per your 
suggestion). Is it the call taker themselves, or is this somehow 
incorporated into a signaling protocol?

It seems like the IETF is concerned with how this can be done in 
signaling somehow.

I'm wonder aloud if this can be done in signaling either 
automatically (as a response or new transaction) to the calling party 
when some automaton determines it has received enough information 
(which is determined by a configurable API to know which fields or 
buckets get filled from the inbound signaling)?

Or if the call taker hits a button - indicating they have enough 
information to allow the caller to terminate the call -- knowing 
there is sufficient location and/or callback information for this call?

To me, these are completely different.  In fact, I could argue that 
the idea that a call taker make a mental decision that they have 
enough information about the caller is something that is a brand new 
type of requirement, and one that inherently doesn't have precedent 
in today's architectures anywhere.  This means we need to look at 
this as a fresh req that may or may not be necessary.

just thinking out loud...

At 04:21 PM 10/6/2008, Brian Rosen wrote:
>No, actually, it's pretty precise.  It's "premature" unless the PSAP says
>otherwise (that is, if the caller attempts to disconnect before the PSAP
>does, then it's a premature disconnect).
>
>Brian
>
>-----Original Message-----
>From: James M. Polk [mailto:[e-mail]]
>Sent: Monday, October 06, 2008 4:01 PM
>To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig'
>Cc: 'ECRIT'
>Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination
>
>This sounds a bit like a subjective thing, verses a quantifiable
>definitive thing.
>
>How exactly does a UAC know when it has achieved this status (i.e.,
>provided enough information)?
>
>I assume the goal is to have something in signaling that communicates
>this to the UAC, right?
>
>Or is this merely at the discretion of the called party (i.e., the
>call taker's personal satisfaction)?
>
>Where I'm going with this is that I'm beginning to wonder if, then
>how a signaling protocol document should address this, or should this
>not be dealt with in signaling (which is nearly 100% of what we are
>defining -- only!) IMO...
>
>James
>
>At 02:16 PM 10/6/2008, Brian Rosen wrote:
> >It was defined in draft-rosen-ecrit-abpd-reqs-00.  It was:
> >when on an emergency call, a caller hangs up the call before the call
taker
> >is finished acquiring enough information.
> >
> >Brian
> >
> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]] On Behalf Of
> >Henning Schulzrinne
> >Sent: Monday, October 06, 2008 2:27 PM
> >To: Hannes Tschofenig
> >Cc: 'ECRIT'
> >Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination
> >
> >I agree with Ted's concerns. In particular, "premature call
> >termination" has never been defined precisely and many of the fears
> >are based on the old single-line physical phone model which just don't
> >apply here. Carrying forward notions that apply to black phones with
> >rotary dials just seems unhelpful. In particular, the topic is
> >strongly connected to call-back and should not be treated in isolation.
> >
> >Henning
> >
> >On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote:
> >
> > > Hi all,
> > >
> > > we had a chat with Jon on how to make some progress on the subject
> > > of "Premature Call Termination" and here is the plan we came up with:
> > >
> > > * We delete the sentence that talks about the UAC not generating a
> > > BYE request in
> > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt
> > > We progress the document through the IETF process as "planned".
> > >
> > > * At the same time we create a design team in ECRIT to work on
> > > "Premature Call Termination".
> > >
> > > Depending on the progress of the design team we are able to
> > > incorporate the results of it into the document (even at a fairly
> > > late stage
> > > of the document process). If the design team does not produce
> > > results then anything that comes out of it can be seen as an
> > > extension to the
> > > Phone BCP document.
> > >
> > > We need members for the design team! We have already received the
> > > commitment of folks from NENA but we also need some guys from the
> > > ECRIT group. Who is interested in participating?
> > >
> > > Ciao
> > > Hannes & Marc
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/ecrit
> >
> >_______________________________________________
> >Ecrit mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >
> >_______________________________________________
> >Ecrit mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit

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