Subject: RE: [Sipping] sip-911, Preventing dialog termination

From: [email-masked]
Date: Tue, 5 Mar 2002 08:18:48 -0500

From:  Tom Gray@MITEL on 03/05/2002 08:18 AM
 Anti-disconnect has the value of preventing a perpetrator from using the
telephone for other purposes.  it also maintains a connection even if a confused
or panicked person accidentally or by coercion hangs up the telephone. In this
it is in the same vein as the prevention of custom calling services which
prevent the use of conference facilities to achieve the same thing.  Similar
questions could be raised about the 'call back' capability that is also being
proposed. it requires the cooperation of the end station just as the prevention
of disconnect operation does. if the end station does not honour some sort of
emergency override feature than all a perpetrator would have full access to any
of the phone capabilities. he would obviously have very little interest in a
call waiting beep.

The most compelling argument that I see though is that it is the common practice
now. it would need a very convincing argument to convince an operator to give up
functionality that it already has when inventing in a new system. As pointed
out, below anti-disconnect and custom calling barring are easily achievable in
an end device and they require either no or minimal changes to SIP
specifications. Why not leave them in and maintain the operation of E911 systems
as they are now. it really is a question that puzzles me.

To the objection that ripping the phone out of the wall renders anti-disconnect
futile, a reply could be made that this will render the phone unusable by a
perpetrator as well which seems to be one of the purposes of anti-disconnect.
Another argument is that anti-disconnect is just a part of the 911 capability in
this area. No one portion of this capability solves all problems or can expected
to be. Ripping the phone off the wall renders the call back capability useless
as well in any event and I have heard no comment that this should be removed
even though it seems to require more cooperation between the end station and the
network than the other 911 capabilities.

"Ben Campbell" <[email-masked]> on 03/04/2002 07:07:34 PM

To:   "David R. Oran" <[email-masked]>, "'Farahmand, Fardad'"
      <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>,
      "'Kozdon, Peter'" <[email-masked]>, "'Tom Gray'"
      <[email-masked]>
cc:   [email-masked] (bcc: Tom Gray/Kan/Mitel)

Subject:  RE: [Sipping] sip-911, Preventing dialog termination

Actually, I am tempted to take one step further back, and aski what does
anti-disconnect accomplish? Is it _in_itself_ a requirement for an emergency
service? Or is it simply something existing PSTN services do to assist
tracing?

If we have other methods of delivering location info, do we still need
anti-disconnect?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> David R. Oran
> Sent: Monday, March 04, 2002 3:56 PM
> To: 'Farahmand, Fardad'; 'Henning Schulzrinne'; 'Kozdon, Peter'; 'Tom
> Gray'
> Cc: [email-masked]
> Subject: RE: [Sipping] sip-911, Preventing dialog termination
>
>
> Whatever the legal requirements, I would like to understand what
> conceivable "anti-disconnect" requirement involves more than:
>
> A) some way to convey in the protocol that the call is an emergency
> call.
> B) conventions in the UA when an emergency call is in progress to
>    - ignore local hangup operations
>    - reject conflicting incoming calls
>    - reject local UI operations for transfer
>    - etc.
>
> We already have (A) in SIP via Henning's SOS draft, and (B) is a
> requirement on a UA/device, and not on the "network" or the protocol.
>
> Many of the other so-called requirements are either not achievable in
> the domain of the physical laws of this universe (prevent the phone from
> being ripped out of the wall), or not implementable on an IP network
> (retain call state in edge routers).
>
> So, could someone package up the requirements in a way that makes sense
> to an IP-head?
>
> Dave.
>
> P.S. we get the same kind of "do 'x' even if it makes no sense on an IP
> network" from the LEAs for wiretapping requirements, so I'm not
> surprised there's the same kind of disconnect here.
>
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > On Behalf Of Farahmand, Fardad
> > Sent: Monday, March 04, 2002 12:19 PM
> > To: 'Henning Schulzrinne'; 'Kozdon, Peter'; 'Tom Gray'
> > Cc: [email-masked]'
> > Subject: RE: [Sipping] sip-911, Preventing dialog termination
> >
> >
> >
> > Based on valuable comments from folks, there is clearly a
> > level of uncertainty about the legal requirements for
> > operator control of disconnect in emergency and tracing call
> > scenarios.  But it still seems useful to have some standard
> > recommendations in SIP for such a feature.  IMHO the fact
> > that some PSTN switches can not do this does not eliminate
> > the need for a SIP recommendation.
> >
> > My other observation is that we keep thinking about specific
> > network topologies when considering such features.  But
> > perhaps this type of protocol recommendation should be
> > independent of specific network designs.
> >
> > It would be useful to have some guidelines about the ability
> > to prevent call termination up to the (logically) closest UA
> > or Proxy to the calling party which is capable of detecting
> > and entering an operator-call state.  An operator-call aware
> > entity can then implement the necessary device call back
> > feature (open to implementations).
> >
> > Granted, such recommendation maybe more useful for some cases
> > than others:
> >
> > - The UA is in the network (for example a SoftSwitch
> > controlling MGCP IAD).
> >
> > - There is a B2BUA in the network in front of the device UA
> > (for example the B2BUA products from several access feature
> > server companies).
> > - The UA is on a GW on the edge of the PSTN network.
> >
> > Also, we should consider the cases where the operator herself
> > is using a smart SIP UA which is the more likely scenario in
> > the long run.
> >
> > Thanks,
> > Fardad Farahmand
> >
> >
> > > -----Original Message-----
> > > From: Kozdon, Peter [mailto:[email-masked]]
> > > Sent: Sunday, March 03, 2002 7:08 PM
> > > To: 'Tom Gray'; [email-masked]'
> > > Subject: RE: [Sipping] sip-911, Preventing dialog termination
> > >
> > >
> > > I continue to question how a service that is not universally
> > > supported by
> > > today's modern COs and Networks be a legal requirement.
> > >
> > >
> > > Quoting verbatim from the ANSI Document (ANSI T1.628a-2001)
> > addendum
> > > referred to:
> > >
> > > -------------------------------
> > > The use of connection hold is restricted when the caller
> > has an ISDN
> > > user-network interface. Due to existing provisions of the DSS1
> > > protocol it is not possible to prevent an ISDN caller from
> > > disconnecting an active call.
> > > When call hold is applied to ECS calls originating from an
> > > ISDN user-network
> > > interface and the caller disconnects, the network will
> > > attempt to reconnect
> > > to the user's terminal in cases when the network has
> > information that
> > > permits it to identify the end user's terminal.
> > > -------------------------------
> > >
> > >
> > > The full document (ANSI T1.628-2001) states:
> > >
> > > -------------------------------
> > > 4.1.4    E9-1-1 Call Hold
> > >
> > > E9-1-1 Call hold is an optional network feature provided to a
> > > PSAP which
> > > prevents a caller from disconnecting an ESC.
> > >
> > > Capabilities needed for supporting E9-1-1 Call Hold are
> > > described in Clauses
> > > 4 and 5. However, there is no DSS1 or SS7 support for this
> > > capability at
> > > this time.
> > > -------------------------------
> > >
> > >
> > > Both documents clearly state that CALL HOLD can not be universally
> > > supported, in fact it is clearly stated that a network reconnect -
> > > i.e. call back will be attempted only - this is because the network
> > > may not have the
> > > actual callers station ID, but some other number,
> > reflecting maybe the
> > > billing number or a location based "equivalent number" in the
> > > case of larger
> > > organizations.  The fact that SS7 does not support this
> > provision will
> > > effect the ability of call hold via Tandem Offices as is the
> > > case with most
> > > E911 offerings.
> > >
> > >
> > > I restate that there is a need to provide "intelligent call
> > > back" capability
> > > via the "local-gateway" through which the call to the local
> > emergency
> > > service was initiated.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Tom Gray [mailto:[email-masked]]
> > > Sent: Friday, March 01, 2002 3:59 PM
> > > To: [email-masked]
> > > Subject: RE: [Sipping] sip-911, Preventing dialog termination
> > >
> > >
> > > >I am not sure how with today's modern CO switches
> > > such a legal requirement
> > > >could be satisfied. An ISDN call will always be
> > > disconnected after a
> > > timeout.
> > >
> > > >Looking into the T1S1 ECS document (T1.628-2000)
> > >
> > > >Section - 4.1.4 Call Hold - it specifies this as an
> > > optional feature no DSS1
> > > or SS7 support.
> > >
> > >
> > > I don't understnad this comment the abstract at
> > >
> > > http://www-comm.itsi.disa.mil/t1/628.html
> > >
> > > clearly indicates that disconnect control is being standardized in
> > > this body. It is also the standard capability for modern switches.
> > >
> > > It is standard practice to have a forced disconnect
> > > service in operation. A called party may go on hook
> > > and force a disconnect after a time out to prevent
> > > abusive callers from seizing his line and never
> > > releasing - calling party control with forced
> > > disconnect ifI recall my terms rightly.
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! Sports - sign up for Fantasy Baseball http://sports.yahoo.com
> > >
> > > _______________________________________________
> > > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use
> > > [email-masked] for questions on current sip Use
> > > [email-masked] for new developments of core SIP
> > >
> > > _______________________________________________
> > > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use
> > > [email-masked] for questions on current sip Use
> > > [email-masked] for new developments of core SIP
> > >
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current
> > sip Use [email-masked] for new developments of core SIP
> >
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Robert Sparks <[email-masked]>
Date: 05 Mar 2002 14:34:28 -0600

On Tue, 2002-03-05 at 07:18, [email-masked] wrote:
> telephone for other purposes.

Anti-disconnect by itself will _not_ achieve that goal.
Without regulation on all endpoints requiring them to have internally
battery-backed state and no external reset button, all your perpetrator
would need to do is reboot the endpoint (simple as unplugging and
plugging back in). If you did manage to impose non-rebootable phones
on the world, you introduce some really interesting failure cases when
the network fails to convince the endpoint that it can actually free up
its resources.

Life gets even worse if you allow that "phone" to be an integrated
device. If my endpoint is capable of web-browsing, are you going to
deny access to the browser during that call? If my endpoint is capable
of running a notepad like text-editor, are you going to prevent me from
using it to take notes from an EMT talking me through handling my
medical emergency?

> it also maintains a connection even if a confused
> or panicked person accidentally or by coercion hangs up the telephone.

Keeping the media resources allocated when dealing with a confused
person is compelling. I would rather see a solution here that caused
the phone-device to switch motifs for "hanging up" based on the hint
rather than put it in a state where something had to come from the
network to allow it to release resources. Instead of honoring something
like a hookswitch, terminating during this state might require
navigating a menu, or chording on a 12-key pad, or some other thing that
a confused person is not likely to have programmed into their
neuro-muscular auto-pilot. Without something like this (or the ability
to hit reset), a few lost packets could turn your phone into a
boat-anchor.

As above, prevention of access to other types of calls in the coercion
case is not achievable, and its lack of utility goes beyond just the
ease of defeat by rebooting the endpoint. What is it really that you are
trying to keep your perp from doing and why? If you succeed in locking
up the particular device the emergency call was placed on, but the perp
can just plug in his own pocket-sized SIP device (or go to your PC and
use IM to achieve the things you are trying to prevent (or just use a
non-SIP wireless phone)), what have you gained?

> In this

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2002 09:46:06 -0500

> non-SIP wireless phone)), what have you gained?

I have been amused watching this discussion, without having any specific relevant knowledge other than common sense. This seems to be yet another case of government
attempting to regulate the "how" rather than the "what". They almost always get this wrong. (E.g. building codes - you MUST use copper pipe.)

For every case where prevention of access to other calls is a good thing, there is probably an equally compelling case where that is a bad thing. For instance, consider the
case (often seen in dramas) where an intruder is in the house, and a victim is present but unknown to the intruder. The victim quietly makes a 911 call while remaining
hidden.

A common scenario in this case is that the intruder notices the line is active and realizes there is someone in the house.

One might assert that in this case the proper thing to do is hide the existence of the call from all other "extensions", present them all with dial tones, and permit
outbound calls, even if it means dropping the 911 call.

With IP calls and smart endpoints the possibilities are so much different than in the typical black phone scenarios that the existing regulations are pretty much nonsense.
Of course getting a bunch of idiot legislators to understand that is probably impossible.

	Paul

---

From: Jay Batson <[email-masked]>
Date: Wed, 20 Mar 2002 18:46:55 -0500

At 09:46 AM 3/6/2002, Paul Kyzivat wrote:
>A common scenario in this case is that the intruder notices the line is 
>active and realizes there is someone in the house.
>
>One might assert that in this case the proper thing to do is hide the 
>existence of the call from all other "extensions", present them all with 
>dial tones, and permit

Of course, the opposite is true too....  One might argue that "single line 
extension" type behavior is desirable in an emergency call.  The emergency 
services operator may be accustomed to saying (in appropriate 
circumstances) "Hang up the phone, walk to another phone, and pick up the 
phone.  I'll be on the line when you get there."....

So this flies in the face of "hiding the existence of the call from all 
other 'extensions.'"

Interesting "requirements" exercise, eh?

-jb