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

From: "Farahmand, Fardad" <[email-masked]>
Date: Mon, 4 Mar 2002 12:18:44 -0500

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

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 4 Mar 2002 16:55:30 -0500

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.

> 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]'
> 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 
> - 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
> 
>  
> > 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.
> > 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
> > clearly indicates that disconnect control is being standardized in 
> > this body. It is also the standard capability for modern switches.
> > 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 4 Mar 2002 18:07:34 -0600

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
> Sent: Monday, March 04, 2002 3:56 PM
> To: 'Farahmand, Fardad'; 'Henning Schulzrinne'; 'Kozdon, Peter'; 'Tom
> Gray'
> Cc: [email-masked]