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

[Henning Schulzrinne <[e-mail]>]

Brian,

as I've tried to explain to you, this mechanism doesn't work and  
redefines existing SIP behavior by using the Require mechanism, which  
is a no-no. It's essentially a kludge. ECRIT shouldn't be redefining  
SIP, but having NENA do it seems even less appropriate. These end-runs  
don't exactly induce confidence. NENA has to trust IETF  
"representatives" to know their SIP stuff, but that relies on those  
representatives not riding off on their own.

I'm sorry, but this smells, badly.

Henning

On Oct 8, 2008, at 6:13 PM, Brian Rosen 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