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

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

Right now, it's in a NENA doc, because we thought we were supposed to finish
the requirements before starting on the mechanisms.

We'll bring it into ecrit as soon as its needed.

Brian

-----Original Message-----
From: Marc Linsner [mailto:[e-mail]] 
Sent: Wednesday, October 08, 2008 7:10 PM
To: Brian Rosen
Cc: 'ECRIT'
Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

Brian,

What document contains your proposed mechanisms?

-Marc-


On 10/8/08 6:13 PM, "Brian Rosen" <[e-mail]> wrote:

> Ted
> 
> Lots of systems get used even when they don't meet the user's
requirements.
> That's what happened.  I don't mean to imply that the whole thing won't
work
> without this feature.  On the other hand, as you know, sometimes
> implementers ignore requirements for financial or other reasons.  I don't
> think that applies here in ecrit, but it may.  I just don't see how you
take
> a situation where carriers flat out refused to meet the requirement as
> justification for not considering the requirement, or negating its
> importance.  The 9-1-1 system "worked" without any location.  When
wireless
> first started, it didn't provide ANY location at all.  Are you suggesting
> that the location reporting requirement be dropped because millions of
9-1-1
> calls were completed without it?
> 
> Then, I think you drop immediately into mechanism issues.  You, for
example,
> get worried about some new negotiation phase.  No one has suggested that.
> The proposals that are at the front of the table use the existing
> Supported/Required option negotiation mechanism.  The UA indicates that it
> can support the option in Supported.  The PSAP indicates that it can
> implement the option, and desires to employ it on the specific call, by
> including it in Required.  If the UA sees it in Required, and it sent it
in
> Supported, it enables the function.  If it doesn't understand it, or
doesn't
> see it in Required, it's not enabled.  In some folk's preferred
> implementation, you use the existing Hold signaling (SDP
sendrecv=inactive)
> to indicate "hook state", and rather than sending BYE from the UA.  The
PSAP
> terminates the call.  The UA can terminate if it doesn't complete the
> ReINVITE that signals a hook state change.  I think that avoids the
"brick"
> problem.  There is NO added latency.  It doesn't use any resources that
> weren't already allocated for the call.  You do something similar with
> CANCEL.
> 
> Brian (who is still listening)
> 
> -----Original Message-----
> From: Ted Hardie [mailto:[e-mail]]
> Sent: Wednesday, October 08, 2008 5:41 PM
> To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Henning Schulzrinne'; 'Marc
> Linsner'
> Cc: 'ECRIT'
> Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination
> 
> At 1:42 PM -0700 10/8/08, Brian Rosen wrote:
>> I do not accept that the telecommunications industry can override a
>> reasonable requirement like this making an argument that "the operator
may
>> need resources for other purposes".  This is an individual call, and
we're
>> talking about disconnect under control of one of two humans.  There
aren't
>> many 'resources' that are available for 'other purposes'.  PSAPs aren't
>> dictators, nor do they have veto rights, but this is a pretty reasonable
>> requirement I believe.
> 
> I continue to believe we're talking past each other here, and my
experience
> has been that folks talking past each other tend to get louder and listen
> less.   I'm trying to avoid that by trying to go back to the basics here,
> and I hope you'll take that in the spirit meant--trying to avoid this
> turning
> into a situation where anyone stops listening.
> 
>  At the base line, I think one of the issues is your use of the term
> "requirement".  A group of PSAP operators would like the system
> that replaces the current system to have specific characteristics.  One
> of the desired characteristics is that only a PSAP call-taker can
terminate
> a call which has reached the PSAP.
> 
> If Marc is correct, the Canadian jurisdiction PSAPs live without this
> characteristic
> for about two-thirds of their calls.  The system clearly works when this
> characteristic is not present.  It may be a very strong desire, but there
is
> no overall system failure when it is not present.  U.S. PSAPs had this
> characteristic and it was dropped, over their objections.  The 911 system
> continues to work here, even without this.  Call-backs and other methods
> are used instead.   The PSAP operators feel that this is not as good, and
> they
> are the experts on what works for them here; no one is denying this.
> 
> But some of us have serious concerns about adding protocol mechanisms
> to the ECRIT system to support this characteristic, especially if they
> necessitate
> the introduction of a negotiation phase that is not currently present.
The
> risks here are quite real, and they are obvious enough that even amateurs
> can
> see them.  If a negotiation phase adds significant latency, rates of
> call abandonment *will* go up.   To take a ridiculous number, if it
> takes 20 seconds to do this negotiation, supporting this is out of the
> question.  Way too many people will give up completely or be in
> seriously worse straits to make that sensible.  That number is clearly
> not probable, but it indicates the need to balance.  That same need
> for balance is needed in other arenas:  the need to maintain the
> privacy of the user may be mandated or desired in some jurisdictions;
> the need to maintain the security of the communication channel; the
> need for the caller to make other calls; and, yes, the need to free
> resources so that *other* callers can make their own calls
> (which in disaster situations may also be to emergency services).
> 
> I know I would feel more like I'm being heard if you acknowledged
> that there are other needs to balance here, and I hope you hear that
> I understand that PSAP operators have experience with this system
> that I do not.
> regards,
> Ted Hardie
> 
> 
> 
> 
> 


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