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

From: [email-masked]
Date: Tue, 5 Mar 2002 14:31:55 -0500

From:  Tom Gray@MITEL on 03/05/2002 02:31 PM
I don't know why this is controversial. It will be reliable over any type of
connection. The end station just will not issue a BYE message  since it will
ignore any disconnect message from its interface. It will have determined that
the call was routed to an emergency number and can set its state to activate
this behaviour., The network (any type of network)  will be completely unaware
and indifferent to this operation.. That is all. It is just a requirement on how
UA should be specified. The creation of a pre-emption service will be more
difficult than this. If n end station is capable of understanding a pre-emption
value it must surely be capable of understanding that a call has been sent to a
emergency or other number requiring calling party control of disconnect
(operator calls and others that I don't recall).

"Kozdon, Peter" <[email-masked]> on 03/05/2002 01:13:01 PM

To:   Tom Gray/Kan/Mitel@Mitel, Ben Campbell <[email-masked]>
cc:   "David R. Oran" <[email-masked]>, "'Farahmand, Fardad'"
      <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>,
      "'Tom Gray'" <[email-masked]>, [email-masked]

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

I do not think that anyone is proposing that we do not attempt to maintain a
connection - that is certainly one of the services that we should enable,
however, the whole concept of this type of call hold is only reliable over a
local CO analog connection - which is true today for most residential
customers. (for instance in California when ISDN was being introduced - a
customer also had to have an analog connection for emergency access -
because of the local power requirements for a ISDN set)

For IP communication to work reliably - the customer will need to have UPS
to support all the local infrastructure between the entry point and the UA,
unless this is provided a momentary power glitch will result in a restart of
all the equipment (Cable Modem, DSL Modem, HUB, Switch, etc..). In a similar
fashion a cordless phones (if sold without battery support) carry a caution
that they will not allow access to Emergency Services in the case of a power
outage. The fall back for a DSL connection to Analog is obvious, however,
once we get to Cable, Fiber, etc.. local power backup is required.

The most important thing in dealing with the Emergency Calls is:

1) Complete the call (pre-emption, QoS, etc..)- keep it up is practical
2) Imediatelly provide the location information to the Emergency Service
3) Anything beyond the above increases the value of the communication and
allows for more effective response, but without the first 2 - there can be
no response

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 05, 2002 5:19 AM
To: Ben Campbell
Cc: David R. Oran; 'Farahmand, Fardad'; 'Henning Schulzrinne'; Kozdon,
Peter; 'Tom Gray'; [email-masked]
Subject: RE: [Sipping] sip-911, Preventing dialog termination

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: "Don Stanwyck" <[email-masked]>
Date: Tue, 5 Mar 2002 13:26:34 -0700

There is one piece of this technology that does require some extension
to the protocol.

In the US TDM network, when the emergency call is placed it behaves as
previously described.  There is one feature, however, that is also
present and is necessary.

When the phone user places the phone back on hook the operator receives
and indication that it has been placed on hook.  The operator can then
cause the phone to ring.

So, to provide this service, there needs to be new methods to a) notify
on-hook conditions to the other side that are not a BYE, and b) to cause
an endpoint that is in a session to notify the caller again through
whatever alerting mechanism it has.

> On Behalf Of [email-masked]
> Sent: Tuesday, March 05, 2002 12:32 PM
> To: Kozdon, Peter; [email-masked]
> Cc: Ben Campbell; David R. Oran; 'Farahmand, Fardad'; 
> 'Henning Schulzrinne'; 'Tom Gray'; [email-masked]
> I don't know why this is controversial. It will be reliable 
> over any type of connection. The end station just will not 
> issue a BYE message  since it will ignore any disconnect 
> message from its interface. It will have determined that the 
> call was routed to an emergency number and can set its state 
> to activate this behaviour., The network (any type of 
> network)  will be completely unaware and indifferent to this 
> operation.. That is all. It is just a requirement on how UA 
> should be specified. The creation of a pre-emption service 
> will be more difficult than this. If n end station is capable 
> of understanding a pre-emption value it must surely be 
> capable of understanding that a call has been sent to a 
> emergency or other number requiring calling party control of 
> disconnect (operator calls and others that I don't recall).
> 
> 
> 
> 
> 
> 
> I do not think that anyone is proposing that we do not 
> attempt to maintain a connection - that is certainly one of 
> the services that we should enable, however, the whole 
> concept of this type of call hold is only reliable over a 
> local CO analog connection - which is true today for most 
> residential customers. (for instance in California when ISDN 
> was being introduced - a customer also had to have an analog 
> connection for emergency access - because of the local power 
> requirements for a ISDN set)
> 
> For IP communication to work reliably - the customer will 
> need to have UPS to support all the local infrastructure 
> between the entry point and the UA, unless this is provided a 
> momentary power glitch will result in a restart of all the 
> equipment (Cable Modem, DSL Modem, HUB, Switch, etc..). In a 
> similar fashion a cordless phones (if sold without battery 
> support) carry a caution that they will not allow access to 
> Emergency Services in the case of a power outage. The fall 
> back for a DSL connection to Analog is obvious, however, once 
> we get to Cable, Fiber, etc.. local power backup is required.
> 
> 3) Anything beyond the above increases the value of the 
> communication and allows for more effective response, but 
> without the first 2 - there can be no response
> 
> 
> 
> Cc: David R. Oran; 'Farahmand, Fardad'; 'Henning 
> Schulzrinne'; Kozdon, Peter; 'Tom Gray'; [email-masked]
>  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.
> 
> 
> 
> 
> 
> 
> 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?
> 
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf 
> > Of David R. Oran
> > 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 
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Farahmand, Fardad
> 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).
> > > 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
> > >
> > >
> > > > supported by today's modern COs and Networks be a legal 
> > > > requirement.
> > > >
> > > >
> > > > disconnecting an active call. When call hold is applied to ECS 
> > > > calls originating from an ISDN user-network
> > > > E9-1-1 Call hold is an optional network feature 
> provided to a PSAP 
> > > > which prevents a caller from disconnecting an ESC.
> > > >
> described 
> > > > in Clauses 4 and 5. However, there is no DSS1 or SS7 
> support for 
> > > > this capability at
> > > > this time.
> > > > 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.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 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
> > > > Sipping mailing list  
> > > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > Sipping mailing list  
> > > > https://www1.ietf.org/mailman/listinfo/sipping
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list 
> is for NEW development of the application of SIP Use

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 5 Mar 2002 16:39:52 -0500

Sounds like a job for...
	...superma...
Uh, sorry...
	....sip-events!

> On Behalf Of Don Stanwyck
> Sent: Tuesday, March 05, 2002 3:27 PM
> To: [email-masked]
> There is one piece of this technology that does require some 
> extension to the protocol.
> 
> In the US TDM network, when the emergency call is placed it 
> behaves as previously described.  There is one feature, 
> however, that is also present and is necessary.
> 
> When the phone user places the phone back on hook the 
> operator receives and indication that it has been placed on 
> hook.  The operator can then cause the phone to ring.
> 
> So, to provide this service, there needs to be new methods to 
> a) notify on-hook conditions to the other side that are not a 
> BYE, and b) to cause an endpoint that is in a session to 
> notify the caller again through whatever alerting mechanism it has.
> 
>

---

From: "Bert Culpepper" <[email-masked]>
Date: Tue, 5 Mar 2002 17:16:10 -0500

And there's two approaches in the works...
http://www.ietf.org/internet-drafts/draft-mahy-sipping-signaled-digits-00.tx
t and
http://www.ietf.org/internet-drafts/draft-culpepper-sip-key-events-00.txt
(with -01 soon to appear in the archives).

Regards,
Bert

> [mailto:[email-masked]]On Behalf Of
> David R. Oran
> Sent: Tuesday, March 05, 2002 4:40 PM
> To: 'Don Stanwyck'; [email-masked]
> [mailto:[email-masked]] On
> controlling
> service in

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 06 Mar 2002 13:17:21 -0600

> 	...superma...

There have been several proposals trying to make SIP emulate all the
PSTN functions and more. 
A sure road to failure IMHO.
Thanks, Henry

> On Behalf Of David R. Oran
> Sent: Tuesday, March 05, 2002 3:40 PM
> > > Behalf Of [email-masked]
> > > I don't know why this is controversial. It will be 
> reliable over any 
> > > type of connection. The end station just will not issue a BYE 
> > > message  since it will ignore any disconnect message from its 
> > > interface. It will have determined that the call was routed to an 
> > > emergency number and can set its state to activate this 
> behaviour., 
> > > The network (any type of
> > > I do not think that anyone is proposing that we do not attempt to 
> > > maintain a connection - that is certainly one of the 
> services that 
> > > we should enable, however, the whole concept of this type of call 
> > > hold is only reliable over a local CO analog connection - 
> which is 
> > > true today for most residential customers. (for instance in 
> > > California when ISDN was being introduced - a customer 
> also had to 
> > > have an analog connection for emergency access - because of the 
> > > local power requirements for a ISDN set)
> > > 
> > > For IP communication to work reliably - the customer will need to 
> > > have UPS to support all the local infrastructure between 
> the entry 
> > > point and the UA, unless this is provided a momentary 
> power glitch 
> > > will result in a restart of all the equipment (Cable Modem, DSL 
> > > Modem, HUB, Switch, etc..). In a similar fashion a 
> cordless phones 
> > > (if sold without battery
> > > Cc: David R. Oran; 'Farahmand, Fardad'; 'Henning Schulzrinne'; 
> > > Kozdon, Peter; 'Tom Gray'; [email-masked]
> > > 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.
> > > 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 
> > > 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.
> > > 
> > > 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
> https://www1.ietf.org/mailman/listin> fo/sipping
> > > This list 
> https://www1.ietf.org/mailman/listin> fo/sipping
> > > This list

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 6 Mar 2002 16:53:50 -0500

I have to agree with Henry here.  There have been over 20 messages on this
subject, most starting out with, "I think this is how emergency services
works..."

I was tempted to load my old BOC Notes on the LEC Network for a definitive
answer.  However, that would miss the point.  "What does the PSTN do today?"
is *not* the important question.  The important question is "What do we need
to do to offer equivalent OR BETTER service in the packet network?"

An example of this is the thought of using pre-emptive QoS on call-back
instead of "holding open the line".  [What does "holding open the line" mean
in a packet network, anyway?]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Henry Sinnreich
Sent: Wednesday, March 06, 2002 2:17 PM
To: 'David R. Oran'; 'Don Stanwyck'; [email-masked]
Subject: RE: [Sipping] sip-911, Preventing dialog termination

[snip]