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

[Ted Hardie <[e-mail]>]

At 7:15 AM -0700 10/7/08, Brian Rosen wrote:
>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.

Is my memory correct that this mechanism is currently in place
in Canada, desired by some operators in the U.S., but not a universal
practice?  One of my concerns here is that we do not impose this
model onto systems which do not work this way now by encoding
it into the signalling protocols.  If, for example, it is the presumption
of certain types of emergency services (spousal abuse crisis centers,
to take an example), that the caller must always be able to
terminate a call as swiftly and silently as possible, anything that
keeps the call up so that an abusive spouse can hear that a call
is present may be counter-productive.  [This is not meant to reflect
any real-world experience with these centers, as I have none.  This
is simply a way of getting at the idea that the desire to allow
user termination may also occur because of a specific emergency
setting; kidnap and home invasion have been used as examples
in the past.]


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

I think that is a remarkable presumption.  They may not be the same
thing at all.  In jurisdictions which have multiple response numbers,
for example, an abandoned call might reflect a realization from the
caller that they need to call a different emergency number (I called
the police when the fight started, but before they answered, I realized
we urgently need medical response.  Or, I called for medical help then
saw the bottle that tells me I need a poison-specific response.).

Systems which do not acknowledge that the people making these calls
may have knowledge that causes them to change their response to
an emergency should not be encoded in the signalling in my view.
I am also seriously worried about the interaction of this with the
no-SIM test call problem.  If PSAPs MUST respond to these calls
and handle abandoned calls, abandoned test calls take on an
even more problematic aspect.  At least now, those callers can
hang up when they hear a ring.


>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

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