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

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

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