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

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Folks, we need to get things going. Here is my suggestion:

1) Read through Brian's draft again
http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-00
.txt
2) Take a look at the previously received comments 
   - during the IETF meeting
   - after the meeting on the list
   Here are some links:  
http://www.ietf.org/mail-archive/web/ecrit/current/msg05450.html
http://www.ietf.org/mail-archive/web/ecrit/current/msg05447.html
3) Determine whether we can agree on some of the requirements. 

Ciao
Hannes

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of ext Marc Linsner
>Sent: 09 October, 2008 15:12
>To: Brian Rosen
>Cc: 'ECRIT'
>Subject: 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" <[e-mail]> 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:[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
>
_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit