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

["James M. Polk" <[e-mail]>]

in-line

At 09:15 AM 10/7/2008, Brian Rosen wrote:
>It's manual, not automatic.

I'm wondering if it can/should be automated, that once the receiver 
fills all the fields it needs to fill, the caller can now disconnect 
whenever they wish (because sufficient location has been conveyed, 
and the callback number/URI has been captured - both by the PSAP UAS)....


>When the PSAP call taker decides the call is over, then call termination
>occurs.

This means the UAC cannot send a BYE (you can spin it any other way, 
this is the results of what you are looking for)

>  They release the call (with a button).  In the proposed mechanisms,
>the caller cannot terminate until then.

This seems like the no one can terminate the call until the call 
taker does (which means the caller doesn't have the ability to send a BYE)


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

that would be bad!


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

The latter of these appears to me to be a prevention of sending a 
CANCEL request, in addition to a BYE... this "feature" is expanding 
(or creeping)

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

i.e., sending a CANCEL, regardless of Reason header, is also prevented

I have to think about that one before I agree it's a good idea in all cases.

There's easily one good case for it (robber hangs up the call), one 
annoying case (prank call), and one honest mistaken case (unintended call)


>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