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

From: [email-masked]
Date: Fri, 1 Mar 2002 08:04:15 -0500

From:  Tom Gray@MITEL on 03/01/2002 08:04 AM

911 and like calls cannot be placed on hold. This includes both hard hold which
is the customary type of hold and soft hold which is used as part of a transfer
service. This effectively bars the custom services mentioned below. I would be
very surpised in DMS did not obey this standard since it is a common example
used int eh feautre interaction literature and Nortel is an active participant
in this community.

It can cause problems as when someone goes into 3 way call mode to make an
emergency 911 call for someone he is conversing with. After calling 911 he
cannot swap back to his distressed correspondent or conference him into the 911
call since this would place the 911 service on hold. However I suppose the
general benefit of this service outweighs these handicaps.

Tehre are other serivices whcih also require that there be callee control of
disconnect. This includes calls to operator services. Call trap services to foil
abusive callers  and more that I don't recall off hand.

SIP if it is to be a practical way of creating public services must be able to
handle 911  and other services requiring callee control of disconnect  properly.

Henning Schulzrinne <[email-masked]> on 02/28/2002 07:30:31 PM

To:   "Farahmand, Fardad" <[email-masked]>
cc:   "'Dean Willis'" <[email-masked]>, [email-masked] (bcc: Tom
      Gray/Kan/Mitel)

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

I should point out that I had a discussion on this topic with some folks
in the (U.S.) 911 community. Opinions diverged - some claimed that
switches restricted services, while other disagreed, saying (e.g.,) that
this might have been done in the past, but was no longer feasible with
modern switches. It appears that this may well be dependent on the LEC
and maybe the particulars of the local CO. Apparently, you get some
really strange results when three-way calling gets involved, with two
911 operators on the line.

As long as the PSAP has a reliable call-back address, even midcall
disconnects are not that big a deal. As Dean hints at, that's about the
best you can do for mobiles in any event. Here are some quotes:

"I can't speak for Call Transfer however Call Waiting and Three Way
Calling are still available to the 9-1-1 caller.  At least it is here
in a DMS environment."

"From my experience, most switches (5ESS, DMX-100, and GTD5EAX) disable
custom calling features for the entire call when calling to N11 services
in a manner similar to when they are establishing a call to another
number.  In other words, the switch deals with the 911 call like when
you are listening to a ringing signal (i.e.  no call waiting, no call
transfer, no 3-way calling, etc.).

ANSI T1S1 is the standards group that is responsible for the PSTN
signaling
standards for the US and Canada. T1S1.7 is specifcally tasked with the
architecture, services and signaling. ANSI T1.628-2000 and ANSI
T1.628a-2001
seem to be the governing ANSI documents relating to ECS (Emergency
Calling
Services). You might look there."

I don't have access to the documents.

_______________________________________________
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: [email-masked]
Date: Fri, 1 Mar 2002 13:53:29 -0500

From:  Tom Gray@MITEL on 03/01/2002 01:53 PM

.It should be no problem keeping a 911 or other emergency connection up even
across multiple switches. The local office has routed the 911 call.  It can
simply be programmed to ignore the disconnect signal from the station set. It
already does similar things to prohibit custom calling services which would
interfere with 911 service.

Indeed this is really a way that a SIP user agent could be set up to handle the
911 case. If it originates a call to a pre-set emergency  number, it should
ignore any disconnect signal coming from its user interface. This would result
in the called party disconnect control which is a requirement of 911 services.

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

To:   Tom Gray/Kan/Mitel@Mitel, "'Henning Schulzrinne'" <[email-masked]>
cc:   "'Farahmand, Fardad'" <[email-masked]>, "'Dean Willis'"
      <[email-masked]>, "[email-masked]'" <[email-masked]>

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

In the early days there was 911 - this service simply delivered a call to a
PSAP - with NO location information, etc.. Even this basic service is not
ubiquitous in the US today with a few areas still having to dial a local
number to reach emergency services.  In those cases it is highly beneficial
to keep the call up so that the PSAP can find out from the caller where
he/she is located, etc.. This basic 911 service is typically associated with
a single CO switch, where in the worst case they could do a wire trace to
find out where the call was originated (I suspect that this is why there is
a need to keep the connection up - in many of these CO's - if either of the
2 parties in call does not "hang up" - then the connection would is kept up
- no disconnect supervision from the PSAP.

Today, many areas in the US have E-911 service - this provides information
related to the location of the caller, enables the use of tandem CO
switches, etc.. I would be very surprised if a connection could be reliably
kept up in all cases after a disconnect at the callers device, however, as
the PSAP has location information (via ANI (automatic number identification)
and ALI (automatic location information)) this should be much less of a
concern.

In the UK the 999 service  has had location identification for over 20
years, in some countries a common number for emergency services is only just
being introduced and in many others it is way off.

We must enable a reliable delivery service to what ever emergency number is
required depending on deployment, IMHO this may require additional localized
intelligence in the GSTN gateway through which the call is delivered. I
support the concept of the "sos.*@local-domain" alias proposed, this would
enable the "local proxy" and/or "local gateway" to be customized to support
local variations. The problem will, however, be to determine the
"local-domain" associated with the "local gateway" -- this will not always
be the same as the domain where the user is register.

Peter Kozdon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 01, 2002 5:04 AM
To: Henning Schulzrinne
Cc: Farahmand, Fardad; 'Dean Willis'; [email-masked]
Subject: Re: [Sipping] sip-911, Preventing dialog termination

911 and like calls cannot be placed on hold. This includes both hard hold
which is the customary type of hold and soft hold which is used as part of a
transfer service. This effectively bars the custom services mentioned below.
I would be very surpised in DMS did not obey this standard since it is a
common example used int eh feautre interaction literature and Nortel is an
active participant in this community.

It can cause problems as when someone goes into 3 way call mode to make an
emergency 911 call for someone he is conversing with. After calling 911 he
cannot swap back to his distressed correspondent or conference him into the
911 call since this would place the 911 service on hold. However I suppose
the general benefit of this service outweighs these handicaps.

Tehre are other serivices whcih also require that there be callee control of
disconnect. This includes calls to operator services. Call trap services to
foil abusive callers  and more that I don't recall off hand.

SIP if it is to be a practical way of creating public services must be able
to handle 911  and other services requiring callee control of disconnect
properly.

To:   "Farahmand, Fardad" <[email-masked]>
cc:   "'Dean Willis'" <[email-masked]>, [email-masked] (bcc:
Tom
      Gray/Kan/Mitel)

I should point out that I had a discussion on this topic with some folks in
the (U.S.) 911 community. Opinions diverged - some claimed that switches
restricted services, while other disagreed, saying (e.g.,) that this might
have been done in the past, but was no longer feasible with modern switches.
It appears that this may well be dependent on the LEC and maybe the
particulars of the local CO. Apparently, you get some really strange results
when three-way calling gets involved, with two 911 operators on the line.

As long as the PSAP has a reliable call-back address, even midcall
disconnects are not that big a deal. As Dean hints at, that's about the best
you can do for mobiles in any event. Here are some quotes:

"I can't speak for Call Transfer however Call Waiting and Three Way Calling
are still available to the 9-1-1 caller.  At least it is here in a DMS
environment."

"From my experience, most switches (5ESS, DMX-100, and GTD5EAX) disable
custom calling features for the entire call when calling to N11 services in
a manner similar to when they are establishing a call to another number.  In
other words, the switch deals with the 911 call like when you are listening
to a ringing signal (i.e.  no call waiting, no call transfer, no 3-way
calling, etc.).

ANSI T1S1 is the standards group that is responsible for the PSTN signaling
standards for the US and Canada. T1S1.7 is specifcally tasked with the
architecture, services and signaling. ANSI T1.628-2000 and ANSI T1.628a-2001
seem to be the governing ANSI documents relating to ECS (Emergency Calling
Services). You might look there."

_______________________________________________
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: "Kozdon, Peter" <[email-masked]>
Date: Fri, 1 Mar 2002 11:18:32 -0800

Because of the way the call could be extended over the best effort internet
- I would suggest that it may be better for the "local gateway" to
re-establish the connection to the caller rather than relying on the
originating UA keeping the connection open if the call is terminated by the
caller, there are many other cases why the call could be terminated within
the network - re-establishment seems to make more sense.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 01, 2002 10:53 AM
To: Kozdon, Peter
Cc: 'Henning Schulzrinne'; 'Farahmand, Fardad'; 'Dean Willis';
[email-masked]'

.It should be no problem keeping a 911 or other emergency connection up even
across multiple switches. The local office has routed the 911 call.  It can
simply be programmed to ignore the disconnect signal from the station set.
It already does similar things to prohibit custom calling services which
would interfere with 911 service.

Indeed this is really a way that a SIP user agent could be set up to handle
the 911 case. If it originates a call to a pre-set emergency  number, it
should ignore any disconnect signal coming from its user interface. This
would result in the called party disconnect control which is a requirement
of 911 services.

To:   Tom Gray/Kan/Mitel@Mitel, "'Henning Schulzrinne'"
<[email-masked]>
cc:   "'Farahmand, Fardad'" <[email-masked]>, "'Dean Willis'"
      <[email-masked]>, "[email-masked]'" <[email-masked]>

Peter Kozdon

---

From: [email-masked]
Date: Fri, 1 Mar 2002 14:38:42 -0500

From:  Tom Gray@MITEL on 03/01/2002 02:38 PM
I do not see this as an either-or situation, multiple techniques can co-exist.

One challenge with the re-establishment technique is that it requires that the
incoming 911 call have the capacity to override any subsequent connection that
has been set up. This is of course not insoluble but appears to be more
difficult than just having the UA refuse to drop the call.

"Kozdon, Peter" <[email-masked]> on 03/01/2002 02:18:32 PM

To:   Tom Gray/Kan/Mitel@Mitel
cc:   "'Henning Schulzrinne'" <[email-masked]>, "'Farahmand, Fardad'"
      <[email-masked]>, "'Dean Willis'" <[email-masked]>,
      "[email-masked]'" <[email-masked]>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 01, 2002 10:53 AM
To: Kozdon, Peter
Cc: 'Henning Schulzrinne'; 'Farahmand, Fardad'; 'Dean Willis';
[email-masked]'

Peter Kozdon

---

From: [email-masked]
Date: Fri, 1 Mar 2002 15:31:37 -0500

From:  Tom Gray@MITEL on 03/01/2002 03:31 PM

AN exclusive call-back system is not compatible with what is now offered in the
PSTN in which disconnection is prohibited.  Both disconnect prohibition and
call-back with special indications are used. This is  a legal requirement. It
also has such obvious benefits in emergency situations  that the requirement
will not be going away soon.

A no disconnect requirement would have an effect on the protocol in that it
would indicate a required behaviour on the part of the UA.

Adam Roach <[email-masked]> on 03/01/2002 02:48:24 PM

To:   Tom Gray/Kan/Mitel@Mitel, "Kozdon, Peter" <[email-masked]>
cc:   "'Henning Schulzrinne'" <[email-masked]>, "'Farahmand, Fardad'"
      <[email-masked]>, "'Dean Willis'" <[email-masked]>,
      "[email-masked]'" <[email-masked]>

> difficult than just having the UA refuse to drop the call.

Even if the caller goes out of range?

The callback feature is going to be necessary. So, ask:
is it also sufficient? If the answer is yes, everything
else is wasted effort.

/a

---

From: "Kozdon, Peter" <[email-masked]>
Date: Fri, 1 Mar 2002 13:26:32 -0800

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. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 01, 2002 12:32 PM
To: Adam Roach; [email-masked]
Cc: [email-masked]'
Subject: RE: [Sipping] sip-911, Preventing dialog termination

AN exclusive call-back system is not compatible with what is now offered in
the
PSTN in which disconnection is prohibited.  Both disconnect prohibition and
call-back with special indications are used. This is  a legal requirement.
It
also has such obvious benefits in emergency situations  that the requirement
will not be going away soon.

To:   Tom Gray/Kan/Mitel@Mitel, "Kozdon, Peter"
<[email-masked]>
cc:   "'Henning Schulzrinne'" <[email-masked]>, "'Farahmand, Fardad'"
      <[email-masked]>, "'Dean Willis'"
<[email-masked]>,
      "[email-masked]'" <[email-masked]>

/a

---

From: Tom Gray <[email-masked]>
Date: Fri, 1 Mar 2002 15:58:52 -0800 (PST)

timeout.

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

---

From: "Kozdon, Peter" <[email-masked]>
Date: Sun, 3 Mar 2002 13:33:50 -0800

> Do you have a reference or listing of where these types of location
identification services are available?

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, March 01, 2002 3:45 PM
To: Kozdon, Peter
Cc: [email-masked]'
Subject: Re: [Sipping] sip-911, Preventing dialog termination

> years, in some countries a common number for emergency services is 
> only just being introduced and in many others it is way off.

> Do you have a reference or listing of where these types of location
identification services are available?

Sorry - I have no details but I remember when school children made prank
calls the local constabulary arrived even if the  call was terminated
without leaving any information.

> 
> We must enable a reliable delivery service to what ever emergency 
> number is required depending on deployment, IMHO this may require 
> additional localized intelligence in the GSTN gateway through which 
> the call is delivered. I support the concept of the 
> "sos.*@local-domain" alias proposed, this would enable the "local 
> proxy" and/or "local gateway" to be customized to support local 
> variations. The problem will, however, be to determine the 
> "local-domain" associated with the "local gateway" -- this will not 
> always be the same as the domain where the user is register.
> 
>
> The idea was that the first proxy is more likely, statistically speaking, 
> to be closer to the caller and thus more likely to reach the right PSAP, 
> particularly in cases of international roaming. Clearly, this isn't 
> always the case, with VPNs and such, but it seems like the best heuristic 
> under the circumstances.

With nation wide IPS's or ASP's, e.g. Earthlink, AOL, MSN, Cable&Wireless,
etc.. They are unlikely to have a proxy at every POP on their network.

---

From: "Kozdon, Peter" <[email-masked]>
Date: Sun, 3 Mar 2002 16:08:23 -0800

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

timeout.

or SS7 support.

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball http://sports.yahoo.com

---

From: [email-masked]
Date: Mon, 4 Mar 2002 13:13:52 -0500

From:  Tom Gray@MITEL on 03/04/2002 01:13 PM

It is also a matter of recreating the service that is provided now. prevention
of disconnect is a standard feature along with prevention of use of custom
calling services. A customer is going to be very unimpressed if his new
ultramodern IP telephony product is incapable of recreating important services
that his current equipment provides. After all it is obviously undesirable to
have Call Waiting and Three Way Calling available so that media outlets or
accomplices could, with the cooperation of a perpetrator, conference themselves
into 911 calls.  Call disconnection and custom feature prevention can be done
locally. It could be mandated for UAs or it could be done by other devices local
in the network as indicated below.

"Farahmand, Fardad" <[email-masked]> on 03/04/2002 12:18:44 PM

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

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

> From: Kozdon, Peter [mailto:[email-masked]]
> Sent: Sunday, March 03, 2002 7:08 PM
> To: 'Tom Gray'; [email-masked]'

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 5 Mar 2002 08:03:32 -0500

Generally, I agree than a BCP for a UA is a good idea, which we
should take up immediately.  I do think that we need some other
items because I think your list of ERC connections mechanisms 
neglects the most interesting, which is SIP connected.  I have
no doubt that early systems will use digital trunks as they do now,
but I look forward to the point when the SIP world is a significant
source of emergency calls, and the additional capability of SIP
will cause ERCs to acquire the infrastructure to be able to provide
better service.

So, beyond a SIP UA BCP, I think we need:
	A proxy BCP that describes how emergency calls should be
		handled
	An RFC that describes how an outgoing proxy locates an ERC
	A BCP that describes how a UA/outgoing proxy interacts with
		an incoming proxy/UA at the ERC

Brian

> Sent: Monday, March 04, 2002 5:24 PM
> To: 'David R. Oran'
> Cc: [email-masked]
> 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 ....
> 
> 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]
> 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
> standardized in 
> > > this body. It is also the standard capability for modern switches.
> > > 
http://sports.yahoo.com
> > 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: Michael Hammer <[email-masked]>
Date: Tue, 05 Mar 2002 12:26:32 -0500

For number 5 below, is it also clear that these locations should be 
geographic as well as topological or logical?

Mike

At 02:23 PM 3/4/2002 -0800, Kozdon, Peter wrote:
>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
>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
>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
>Focusing on desired functionality for such a service offering. We should
>include:
>
>3) Automatic dial back from the local gateway in case of loss of connection
>6) Callback initiated by the Emergency Response Center (direct or to the
>general proximity)
>the domain of the physical laws of this universe (prevent the phone from
>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
> > > 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

---

From: "Kozdon, Peter" <[email-masked]>
Date: Tue, 5 Mar 2002 09:46:31 -0800

The location service needs to be geographical - the physical location of the
emergency situation is needed to allow for response. Topological or logical
is useful for system troubleshooters but not to the emergency services - it
could be argued that this information should be captured somewhere for post
call resolution, i.e. in case of crank calls to 911, but the emergency
service does not need this kind of information once they know the physical
location of the caller.

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Tuesday, March 05, 2002 9:27 AM
To: Kozdon, Peter
Cc: 'David R. Oran'; [email-masked]
Subject: RE: [Sipping] sip-911, Preventing dialog termination

Mike

---

From: "Kozdon, Peter" <[email-masked]>
Date: Tue, 5 Mar 2002 10:13:01 -0800

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)

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]

---

From: "Kozdon, Peter" <[email-masked]>
Date: Tue, 5 Mar 2002 09:49:50 -0800

I agree that native IP connectivity will be possible in the future, and so
may be a nation wide network - it should be considered and what ever can be
provided via PSTN gateway - the same info will be needed over IP.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Monday, March 04, 2002 4:55 PM
To: Kozdon, Peter
Cc: 'David R. Oran'; [email-masked]
Subject: Re: [Sipping] sip-911, Preventing dialog termination

> (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.

---

From: [email-masked]
Date: Tue, 5 Mar 2002 15:33:24 -0500

From:  Tom Gray@MITEL on 03/05/2002 03:33 PM

This could be a use for an INFO method or an implied Subscription.

"Don Stanwyck" <[email-masked]> on 03/05/2002 03:26:34 PM

To:   [email-masked]
cc:    (bcc: Tom Gray/Kan/Mitel)

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]
> 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'"
>       "'Tom Gray'" <[email-masked]>, [email-masked]
>
> 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.
> >
> 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.
> > >
> > > 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:
> > >
> > > - 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
> > >
> > >
> > > > I continue to question how a service that is not universally
> > > > 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.
> > > >
> > > > 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.
> > > > 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: "Kozdon, Peter" <[email-masked]>
Date: Wed, 6 Mar 2002 01:45:16 -0800

I hate sounding like a broken record but there are 2 points that are being
overlooked:

1) Withholding of a local disconnect works, however, without the response
center knowing that the call has attempted to hang up and being able to
invoke ringing back the benefit is somewhat limited. Yes - by withholding a
disconnect - if the caller again picks the phone up - he will still be
connected to the PSAP and the caller can not initiate another call or
service. We can use INFO - to send a message to the Gateway which connects
to the PSTN/PSAP - to be able to signal the PSAP that a disconnect attempt
has occurred - the Gateway will need to itself attempt to HANG UP - but not
release the connection back to the caller. So far so good - the PSAP can
request a "RING BACK" - this will send apply RING Voltage to the Gateway -
the Gateway - now send and INFO to the caller to start alerting. This only
works over Analog circuits because DSS1 (ISDN) (or SS7) do not support this
service (see below)  I would propose that most gateways to the PSTN will be
either ISDN or SS7 connected  - we should also remember that ISDN/ANI is the
only way to deliver ANI (station ID) or location ID to the PSAP. (Yes for
small systems analog trunk may be used, but then there is no way to
communicate user ANI - unless there is a 1/1 mapping - 1 trunk per user)
There is another alternative for connection to the PSAP - that relies on
special purpose analog trunks (CAMA trunks) - but these are dedicated as
connections to the PSAP and can not be used for other traffic.

2) The solution is very specific to the US, other localities may not want
this type of service

Again - I do not like the concept of mandating behavior which is not
globally applicable. I have been investigating the "US legal requirement
statement" and to date have not been able to confirm that this is valid -
the only requirement is to keep the call up long enough to deliver "ANI".  

I do not object to providing this service (it does have value) as an
optional feature in the same way as it is defined in the ANSI T1.628-2000.
But we must also support dial back, etc.. if the withholding of a BYE is
mandatory - then dial back can not work - this is just as serious a problem.

The behavior along the lines could be acceptable:

User goes on Hook -  UA sends - INFO message "BYE attempted"
Gateway receives INFO - if it can deal with a "hold connections" sends back
an OK
UA receives OK - does not initiate a BYE
Later - Gateway recognizes request for "RING" and sends a INFO to the
originating UA 
UA send back OK (gateway keeps call up) - if it does not receive an OK -
Gateway terminates the call sends BYE and issues a CO disconnect ( the PSTN
deals with the disconnect in what ever way it wants - ie waits for Answer
supervision from CO, or terminates if ISDN/SS7, etc..)
UA must accept a BYE from the called end and terminate the call

Any other condition, i.e. no OK from Gateway within a "short time out" will
allow the UA to send a BYE. 

The key to the success is the correct handling in the Gateway - as
appropriate to the local requirements.

---------------------

from the ANSI standard T1.628a-2000 - call hold and ring back (applies to US
only):

The Connection Hold Network Capability disables a calling user's capability
to initiate release of a call. Connection hold also provides a mechanism to
indicate that the calling user has requested disconnect (or reconnect)
without initiating release procedures.

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

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]

-----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,

> > > supported by
> > > described in Clauses

---

From: [email-masked]
Date: Wed, 6 Mar 2002 14:45:20 -0500

From:  Tom Gray@MITEL on 03/06/2002 02:45 PM
I agree (but perhaps not in every detail) with what you are saying below. The
important aspect of a 911 discussion will be the creation of a gateway that can
interwork successfully with a 911 system. I do not agree that this requires the
use of analogue trunks to the PSAP office from the gateway. From what I have
seen the PSAP is served by analogue loop reverse battery trunks from what is
termed a 911 tandem. The local office (or gateway) will be connected to the
tandem. ANI signalling (hence the CAMA trunk) must be supplied from the local
office to the 911 tandem. This may be sent over either analogue or digital
trunks. With the ANI requirement comes the need to supply every UA, with 911
access, with a valid directory number.

911/E911 services do mandate these services:

called-party control
 selective transfer
,emergency ringback,
forced disconnect

 Selective transfer and forced disconnects are accomplished at the PSAP and are
of no concern to SIP in this discussion. As you point out called party control
(anti-disconnect) and emergency ringback will put special requirements on SIP
systems. Disconnect control appears to be something that has not been considered
in the previous discussions on SIP

"Kozdon, Peter" <[email-masked]> on 03/06/2002 04:45:16 AM

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

---------------------

---

From: [email-masked]
Date: Fri, 8 Mar 2002 09:55:55 -0500

From:  Tom Gray@MITEL on 03/08/2002 09:55 AM

 The issue of mass calling goes beyond emergencies. Mass callings for radio
station give aways are a problem, as one example. Emergency services served over
the same facilitities need to be able to maintain services during these events
as well.

"Rosen, Brian" <[email-masked]> on 03/08/2002 09:20:44 AM

To:   "'Ken Carlberg'" <[email-masked]>
cc:   Henry Sinnreich <[email-masked]>, [email-masked],
      [email-masked] (bcc: Tom Gray/Kan/Mitel)

We should keep the issues of call control and bearer control
separate.  The QoS discussion here is about bearer control.
Call Admission control is something that is probably not
subject to standardization as it applies to one component, and
not the interaction of multiple components, other than the priority
header that is being discussed.  If you want to implement preemption,
have one of your proxy servers do a presto-chango into a B2BUA and
send a BYE.

The bearer control problem is pretty hairy, Henry's belief in
the power of the Internet notwithstanding.  When a disaster occurs,
everyone's natural inclination is to immediately start
communicating far and wide.  Like it or not, some communication
in disasters has more than just priority - it has to go through.
Generally, when you want some reasonable assurance that it
will go through, then you, somehow, sequester resources so that you can
make it go through.

My usual speech on this subject goes something like "Sir, I'll give
it my BEST EFFORT to get to the fire.  In fact I'll give it my TOP PRIORITY"
vs. "Sir, I'll be at the fire in 30 seconds".

Henry does of course point out the quandary that the Internet does not
give you the tools to achieve what is required. However, a good deal
of the implementations of SIP will be on networks that are more
controlled than the big I Internet and there is some hope they
will actually perform adequately.

I'll agree that in the IETF we can't deal with one countries laws,
and preemption issue is one of those issues.  I suspect we
could not require a preemption capability.  On the other hand,
there are people walking around with special cell phones that,
when emergencies happen, will get through when ordinary ones won't,
and there are certain capabilities in all C5 switches that are
not talked about much (and which I have no actual direct knowledge).

Brian

> From: Ken Carlberg [mailto:[email-masked]]
> Sent: Friday, March 08, 2002 5:02 AM
> To: Henry Sinnreich
> Cc: 'Rosen, Brian'; [email-masked]; [email-masked]
> > And sorry to repeat, I'd rather get through without QoS and without
> > priority than not get through at all because some circuit-like
> > unavailability.
>
> in general I would agree with you.  but there are vendors that are
> and have been offering proprietary forms of call admission for VoIP
> (typically by counting number of VoIP flows, or signaled calls).
>
> as soon as one introduces call admission, then the chances exist for
> call blocking.  and if your going to have that as opposed to across
> the board degraded service, then some users will insist or require a
> means of distinguishing traffic to get around that in some form.
> whether that involves preemption is a regulatory/policy issue.
>
> automated preemption is not allowed on the US PSTN.  whether that
> extends to the VoIP world in pure end-to-end ISP VoIP flows, i have
> no clue and will let the lawyers battle that out.
>
> and speaking of regulations and laws.  I see folks bring that up on
> this list from time to time to make a point about whether a design
> or technology should be allowed.  everyone should keep in mind that
> laws/regulation are relative to where one is.  while automated
> preemption is not allowed in the states for the PSTN, it may
> be allowed
> elsewhere in other countries.  so please be careful when the word
> law is used in an arguement.
>
> cheers,
>
> -ken
>
>

---

From: Michael Hammer <[email-masked]>
Date: Fri, 08 Mar 2002 14:21:03 -0500

Much of how the emergency callers get through is part of an implementation 
design using special trunks, etc.  The design of software to handle the 
calls in some sort of priority order may also be based on some policy 
design.  The primary question may be how to signal to the proxies, 
gateways, or other servers that a particular call/session should get some 
special treatment.  In ITU SG11 they are looking to add a new parameter to 
indicate emergency calls.  While it is still too soon to draw any 
conclusions from that work, the question at hand is whether some protocol 
element is needed in SIP to signal that special treatment is in order, what 
is the nature of that element, and how can it be authenticated.

Mike Hammer

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 15 Mar 2002 19:29:28 -0000

This thread seems to have wandered a long way, and I am not sure whether it
came to any conclusions. I was also stuck as to which message to reply to,
so just replied to the last one, which happened to be Henry's. 

Henry's point about QoS is correct in another way. In the cellular world, if
a road accident occurs in a particular location, all the traffic in the cell
site covering that area are emergency calls, and therefore of equal priority
as far as any QoS designation goes. So a QoS designation does not help,
unless you can give signalling priority to sessions that are already in
existence over those that have not yet been established.

The points I would like to make are as follows:

1)	Even in the USA, I do not believe that current circuit switched PSTN
requirements for emergency calls will be applied indiscriminately to
equivalent communications made over an IP environment. As far as I
understand, the current rules do not apply, and action would need to be
taken to make them apply, jnust as much as would need to be taken to make
some other set of rules apply.

2)	In the GSM environment in the US, as far as I can see there is no
requirement to be able to retain circuits (e.g. the radio access bearer) or
to be able to offer callback. I assume that it has been decided that it is
acceptable to replace these with information as to:
-	who the caller is (based on SIM card if in phone being used)
-	where the caller is (extracted from LCS information or Cell
identity)

3)	The ability to prevent clearing a call in the circuit-switched
network disappeared with the usage of ISDN DSS1. While I am not familiar
with the US variant, in the ITU-T version, sending a DISCONNECT from the
terminal only has one option, the local access gets cleared. As far as I
know this propagates also through the ISUP portions of the call. There are
no ISDN phone requirements to be able to recognise emergency calls and not
send a DISCONNECT in those circumstances. Remember also that enterprise
networks are also connected to the public network using DSS1, and therefore
the connection with the user also gets lost at this point.

In summary, I see no reason to proceed with trying to describe SIP
mechanisms to prevent sending BYE from the User agent. I do not see it as
carrying any added value to an emergency calling capability. We should not
be blindly following what was a pragmatic solution for the PSTN, but work
out how we use the capabilities of SIP to assist the emergency centre in
what they need to know, i.e. who to send the aid to; where to send the aid
to; and how to filter out some of the prank calls. At the end of the day
however, they still need to give highest priority to the message that is
carried in the media, not what is carried in association with it in the
signalling.

Keith

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: 10 March 2002 18:26
To: 'Rosen, Brian'; 'Ken Carlberg'
Cc: [email-masked]; [email-masked]
Subject: RE: [Sipping] sip-911, Preventing dialog termination

>there are people walking around with special cell
> phones
and
> the power of the Internet notwithstanding.  When a disaster
> occurs, everyone's natural inclination is to immediately 
> start communicating far and wide.

Well, one could use IM and still get through on the Internet, while not
overloading the diminished resources - something one could probably not
do with SMS on a cell phone. Voila, the power of the Internet !

This has been experienced on 9/11. Non-prioritized voice SIP traffic
from Columbia University also worked.

My point is with straight wireless Internet access, emergency
communications are not what they are in circuit switched, walled garden
networks, and do not have to be for that matter either.

While classes of service may be a legitimate technology, best effort has
proven to work far beyond expectations in emergencies.

> The bearer control problem is pretty hairy

There is nothing hairy about classes of service, except few if any
public ISPs have found a business case for them as yet, tough I belive
they may eventually. 
What is used in private networks is hard to disucss on this list. 

Henry

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Friday, March 08, 2002 8:21 AM
> To: 'Ken Carlberg'
> Cc: Henry Sinnreich; [email-masked]; [email-masked]
> We should keep the issues of call control and bearer control separate.

> The QoS discussion here is about bearer control. Call Admission 
> control is something that is probably not subject to standardization 
> as it applies to one component, and not the interaction of multiple 
> components, other than the priority header that is being discussed.  
> If you want to implement preemption, have one of your proxy servers do

> a presto-chango into a B2BUA and send a BYE.
> 
> The bearer control problem is pretty hairy, Henry's belief in the 
> power of the Internet notwithstanding.  When a disaster occurs, 
> everyone's natural inclination is to immediately start communicating 
> far and wide.  Like it or not, some communication in disasters has 
> more than just priority - it has to go through. Generally, when you 
> want some reasonable assurance that it will go through, then you, 
> somehow, sequester resources so that you can make it go through.
> 
> My usual speech on this subject goes something like "Sir, I'll give it

> my BEST EFFORT to get to the fire.  In fact I'll give it my TOP 
> PRIORITY" vs. "Sir, I'll be at the fire in 30 seconds".
> 
> I'll agree that in the IETF we can't deal with one countries laws, and

> preemption issue is one of those issues.  I suspect we could not 
> require a preemption capability.  On the other hand, there are people 
> walking around with special cell phones that, when emergencies happen,

> will get through when ordinary ones won't, and there are certain 
> capabilities in all C5 switches that are not talked about much (and 
> which I have no actual direct knowledge).
> 
> Brian
> 
> > in general I would agree with you.  but there are vendors
> that are and
> > have been offering proprietary forms of call admission for VoIP 
> > extends to the VoIP world in pure end-to-end ISP VoIP
> flows, i have no
> > clue and will let the lawyers battle that out.
> > 
> > this list from time to time to make a point about whether a
> design or
> > technology should be allowed.  everyone should keep in mind that 
> > preemption is not allowed in the states for the PSTN, it may be 
> > allowed elsewhere in other countries.  so please be careful
> when the
> > word law is used in an arguement.
> > 
> > cheers,
> > 
> > -ken
> > 
> > 
>