Subject: RE: [SIP] Holding Calls UP for Emergency Service

From: "Sean Olson (EUS)" <[email-masked]>
Date: Fri, 2 Mar 2001 15:01:53 -0600

SIP group should consider to define a protocol support for holding a connection up, and not allowing the call to be dropped by the caller, for emergency calls. This capability should only be available for emergency calls (E911) made to the Public Safety Access Point (PSAP). The call should be maintained until the PSAP initiates the disconnection procedure. Also the PSAP should be able to upgrade the emergency call path to ensure availability of resources and the reliability of the call, as well as having the capability to receive location information automatically without the caller's consent.  
[Sean Olson] 

This is not a protocol issue. This is an architectural issue. Possible protocol impacts include:

1) The addition of a Priority: header to indicate an emergency call

2) The need for an authenticated originator field (perhaps Remote-Party-ID)

3) The need for location information (possibly not through SIP at all)

The ability to block a connection attempt while an emergency call is in progress does not need to be

directly addressed by the protocol. This is something that should either be addressed in the UA or

a proxy of some sort.

During an emergency call, the call may be dropped (intentionally or otherwise) and the PSAP can not call back the caller due to congestion or other problems. This capability which is already supported by analog emergency calls on CAMA trunks, ensures that the connection is maintained until resolved. A similar capability is being developed for ISDN. I believe the same will be required for IP telephony. My question is what is the way for SIP to do this.
[Sean Olson] 

Again you need an architecture that can support this. I don't think SIP as a protocol will address this. The solution in this

case is going to be tied to your access network and possibly to your outbound proxy.

Mo Zonoun

---

From: Scott Bradner <[email-masked]>
Date: Mon, 19 Mar 2001 16:57:12 -0500 (EST)

> The functionality has been required by legislation in the North
> American environment.  Not just as a nice to have feature. 

background reading:

"IETF Policy on Wiretapping" - RFC 2804

Scott

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 20 Mar 2001 10:57:05 -0500

PLEASE folks, we need to frame this discussion in terms that will allow us
to address requirements
users will have for making sure that their emergency calls will work the way
they want them to
and not get into a protracted argument about which national authorities
require what 
behavior.  The former is a proper discussion to have on the list.  The
latter is inappropriate.
 
Before we have discussions of solutions, we need to have discussions on
requirements.
There is a subgroup formed to look at these.  Please join it by signing up
to it's mail list.
 <http://lists.cs.columbia.edu/mailman/listinfo/911>
http://lists.cs.columbia.edu/mailman/listinfo/911.
 
Until there are some sensible requirements, I would like to stop discussion
of
changes to SIP for this subject.
 
Brian
 -----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: Tuesday, March 20, 2001 10:33 AM
To: [email-masked]
Subject: Re: [SIP] Holding Calls UP for Emergency Service

Jiri

I know there is no *line* to hold up, but either the device making the
emergency call has code to make it possible to keep that device from acting
normally when it sends a BYE (ie - goes *on-hook*) to that PSAP (or the like
in non-North American jurisdictions) or the like (in other jurisdictions
that have those stricter rules in this area), or somehow (and this is
somewhat to very ugly): that call to the PSAP must be made in a stateful
scenario where some Proxy (and I don't know where) must control (or have the
ability to control) potentially both ends (devices) of this session.

The first referenced (weak) solution would involve something like the PSAP
(or the like in other localities/jurisdictions) having the control when the
UA (I think) makes that recognizable emergency call -- preventing certain
actions to be taken by that calling device (that it could normally do) until
that called PSAP/location/emergency service determines to their satisfaction
that whatever they require from that call/caller/calling device/whatever.

If SIP doesn't embrace this conceptual type of solution or something very
similar to this functionality (but better thought out than it is here),
there will be (if there isn't already) legislation from one, some of and/or
most localities that have this functionality now, or in the planned future.
I'd hate to force a retrofit to incorporate this semantic.

Clear as mud, right?

At 03:06 AM 3/20/2001 +0100, Jiri Kuthan wrote:
>James,
>
>I don't think I said what you are writing bellow. My point has been that 
>regardless of how useful some *functionality* is, Internet *mechanisms* 
>for implementing it may substantially differ from those known in PSTN. 
>For example, saving lives in the Internet by holding a line makes limited 
>sense as there is no such line.
>
>There was an Internet Draft trying to identify the issues and non-issues,
>which is expired now (draft-schulzrinne-sip-911-00.txt). Unfortunately,
>there was little discussion on it.
>
>Jiri
>
>
>"James M. Polk" wrote:
>> 
>> Jiri
>> 
>> You aren't saying that just because something is based from the PSTN 
>world, it doesn't apply to the IP world -- that somehow the IP world needs 
>to self determine what is and isn't really important -- and that just 
>because something is hard, to not make it any part of a requirement on the 
>IP world's version of a thing, are you?
>> 
>> Some things do translate and are common sense, even if they have been so 
>far overlooked.  What Ovidiu brings up is not required in e911, but saves 
>lives... which do you support?
>> 
>> At 11:27 PM 3/6/2001 +0100, Jiri Kuthan wrote:
>> >I think you are looking at PSTN mechanisms. I think needed
>> >functionality needs to be discussed first before mechanisms.
>> >Please note that many PSTN mechanisms do not translate
>> >to IP by simple replication. In particular, there is no notion
>> >of trunks in IP telephony. Also note that most of needed
>> >functionality may be implemented as product features
>> >without having to change SIP at all.
>> >
>> >Details follow.
>> >
>> >Jiri
>
>
>

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
18581 N. Dallas Parkway
Dallas, Texas 75287
w) 972.813.5208
f)  972.813.5280
www.cisco.com <http://www.cisco.com/>

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 20 Mar 2001 15:59:42 -0000

James,
 
Let's make a distinction between the case where the SIP UAC is a terminal
device owned and managed by the user, and connected to the network at the IP
layer, and the case where the UAC is owned and managed by a Service
Provider, with a different (perhaps analogue) connection to the user's
terminal.
 
In the former case, the UAC is untrusted. No matter what extensions we add
to SIP for 'holding up' the connection we cannot force the UA to obey them.
The user is always at liberty to buy/write/hack new software which does not
have this facility.
 
It is the same with Mobile phones, there is absolutely nothing which can be
done to stop the user turning the phone off, after which 'holding up' the
'line' is not possible.
 
Even regulators cannot make you do the impossible :-)
 
However, in the latter case, the UA is owned and managed by a Service
Provider, and the service presented to the user looks a lot like PSTN
service. In this case I would imagine the same regulations as for the PSTN
would apply.
 
Now, since the UA is under our control, we can instruct it to change the
clearing program, so that off-hook no longer results in a BYE. Some kind of
backwards option tag or header to trigger this behaviour in the UAC would be
the obvious solution.

Regards,
 
Mark Watson
Nortel Networks

-----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: 20 March 2001 15:33
To: [email-masked]
Subject: Re: [SIP] Holding Calls UP for Emergency Service

Jiri

Clear as mud, right?

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
18581 N. Dallas Parkway
Dallas, Texas 75287
w) 972.813.5208
f)  972.813.5280