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

Brian,

What was your comment about amateurs?

:^)

-Marc-

On 10/8/08 7:35 PM, "Brian Rosen" <br@brianrosen.net> wrote:

> 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:mlinsner@cisco.com]
> 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" <br@brianrosen.net> 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:hardie@qualcomm.com]
>> 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
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit