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

From: "Kozdon, Peter" <[email-masked]>
Date: Mon, 4 Mar 2002 14:23:39 -0800

If there is general consensus that there is no Legal requirement, or at
least despite any such requirement,  then we should focus on scenarios and
develop a BCP for Emergency Service. But, we must consider "global"
connectivity and not just local trunk circuits to a CO in the US. 

The connectivity will depend on the type of gateway or IAD that is used to
establish a connection to an Emergency Response Center (I am deliberately
not using the term PSAP - because that is very specific to 911/E911 only).
The connectivity may be via the PSTN by Analog Circuits, Digital Circuits
providing Analog Equivalence (T1-CAS, CEPT 30+2, etc..), Digital Circuits
(ISDN or SS7), etc.. The Gateway may be self contained or controlled by an
MGC - there will be many flavours and no fit all solution, each of the
interfaces and locations will have their own quirks.

Henning's proposal has the concept of sos@.... this is a good approach and
does permit the consistent behavior at the originating UA - it is easier to
recommend behavior for a UA in response to sos@... rather than deal with
every conceivable number that may be applicable in a particular geographic
location.  (note: nothing prevents the user from re-configuring his UA to
deal with a specific number over his user interface, however, this should be
mapped to sos@... by the UA)

Focusing on desired functionality for such a service offering. We should
include:

1) Prevention of originator disconnect
2) Pre-emption in call backs from sos@...
3) Automatic dial back from the local gateway in case of loss of connection
4) Blocking of secondary features if a connection to sos@... exists
5) Delivery of caller location information (actual or approximate)
6) Callback initiated by the Emergency Response Center (direct or to the
general proximity)
7) other suggestions ....

-----Original Message-----
From: David R. Oran [mailto:[email-masked]]
Sent: Monday, March 04, 2002 1: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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 04 Mar 2002 19:54:46 -0500

> (ISDN or SS7), etc.. 

Or, it may be via IP, end-to-end. Not next month, but we'd presumably
want to plan ahead a bit.

> Focusing on desired functionality for such a service offering. We should

While I'd still think that finding out why the behavior existed first,
if this is to be provided as a guideline, the recent end system
guideline document by Sinnreich et al would probably be the right place.

The only real advantages compared to call-back might be that 

- there is no guarantee that resource reservation will succeed the
second time around

- it is probably useful to limit the chance for caller error or
inadvertent end system behavior ("hi, would you like aluminum siding
today?" "no, sorry, I'm having a heartattack right now").

I don't think the goal can be to prevent all such disconnects (among
other things, that's clearly impossible), but to reduce the number of
inadvertent disconnects.