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

[Ted Hardie <[e-mail]>]

At 10:48 AM -0700 10/7/08, Brian Rosen wrote:
>It is in use in some jurisdictions now.

To clarify, this system works now only with wireline deployments,
not with any cellular technology, right?  What happens in Canada
or other jurisdictions when cell phone callers abandon calls or
disconnect before the call taker would have?

				Ted




> Canada is an example.  It was
>deployed in the U.S., it got lost, and they mostly want it back.  It is not
>deployed in some areas.  The requirements state that if it's not needed, it
>doesn't stop termination, which implies some feature signaling with the
>appropriate defaults.
>
>In jurisdictions that have it deployed, I am not aware of the kind of
>problems you were imagining.  The current implementations put the call taker
>in charge of signaling alerts.
>
>Brian
>
>-----Original Message-----
>From: Ted Hardie [mailto:[e-mail]]
>Sent: Tuesday, October 07, 2008 1:15 PM
>To: Brian Rosen; 'James M. Polk'; 'Henning Schulzrinne'; 'Hannes Tschofenig'
>Cc: 'ECRIT'
>Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination
>
>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