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

From: Rohan Mahy <[email-masked]>
Date: Fri, 02 Mar 2001 12:59:48 -0800

Hi,

SIP is a peer-to-peer cooperative protocol.  The only way to get the 
functionality you describe in SIP is with the cooperation of the user agents.

What I would suggest is that the Emergency Call Center  (the term PSAP only 
applies in North America) return a signed header or body in the 200 OK that 
conveys that the call is an emergency call. Cooperating user agents would 
not hangup (BYE), transfer (REFER), or put these calls on hold (reINVITE).

Alternatively if the user agent knows that it is inviting an Emergency Call 
Center by matching the correct URL (tel:911, tel:112, tel:000, 
sip:[email-masked], etc.) then it provide 
identical functionality without any SIP extensions.

thanks,
-rohan

At 12:24 PM 3/2/01, Mo Zonoun wrote:

>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.
>
>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.
>
>Mo Zonoun

---

From: "Don Stanwyck" <[email-masked]>
Date: Fri, 2 Mar 2001 15:58:33 -0700

Unfortunately this solution will not be acceptable to the governing
authorities since there is no way to trust user agents to act on behalf of
the network or the police authorities.  If we want SIP to be accepted as a
real protocol for telephony (and we do!), then this is an issue that has to
receive more thought and consideration than the simple, but honest brush-off
it gets here.  Otherwise we will find that the public utility commisions in
the US, at least, will require that local service companies use a different
solution.

Don Stanwyck
  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Rohan Mahy
  Sent: Friday, March 02, 2001 2:00 PM
  To: Mo Zonoun
  Cc: 'Henning G. Schulzrinne'; [email-masked]
  Subject: Re: [SIP] Holding Calls UP for Emergency Service

  Hi,

  SIP is a peer-to-peer cooperative protocol.  The only way to get the
functionality you describe in SIP is with the cooperation of the user
agents.

  What I would suggest is that the Emergency Call Center  (the term PSAP
only applies in North America) return a signed header or body in the 200 OK
that conveys that the call is an emergency call. Cooperating user agents
would not hangup (BYE), transfer (REFER), or put these calls on hold
(reINVITE).

  Alternatively if the user agent knows that it is inviting an Emergency
Call Center by matching the correct URL (tel:911, tel:112, tel:000,
sip:[email-masked], etc.) then it provide identical
functionality without any SIP extensions.

  thanks,
  -rohan

    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.

    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.

    Mo Zonoun

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 02 Mar 2001 18:02:53 -0500

> Unfortunately this solution will not be acceptable to the governing authorities since there is no way to trust
> user agents to act on behalf of the network or the police authorities.  If we want SIP to be accepted as a real
> protocol for telephony (and we do!), then this is an issue that has to receive more thought and consideration
> than the simple, but honest brush-off it gets here.  Otherwise we will find that the public utility commisions in
> the US, at least, will require that local service companies use a different solution.

For 911 services, presumably the end system has an interest in doing
whatever is appropriate for the end user. We do need to define, say,
appropriate addresses so that the end system can recognize that this is
an emergency call. This is a draft I'm working on; unfortunately, I
missed the I-D deadline.

I could well imagine that some kind of FCC or equivalent requirement,
similar to requirements for hearing-aid compatibility, will happen at
some point.

Good luck restricting IP telephony to the "local service companies".

Also, instead of vague threats, maybe some technical input as to why the
answer is technically incorrect would be more productive in this forum.

_______________________________________________
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: Ovidiu Sas <[email-masked]>
Date: Tue, 6 Mar 2001 16:54:59 -0500 (EST)

Basic 911 Service require:

Called Party Hold
=================
Enables the PSAP attendant to retain control of the call connection
and to hold the line up for manual tracing even if the calling party
goes on-hook. This is a useful feature to locate people who did not
communicate all of the data needed for response by the PSAP and to
trace nuisance calls. Called party hold can only be provided with
direct dedicated trunk facilities.

Forced Disconnect
=================
Allows the PSAP attendant to disconnect any call on a 9-1-1
trunk. This feature prevents intentional jamming of the PSAP lines by
persons dialing all of the 9-1-1 trunks and refusing to hang up. This
feature is useful during situations where the system is inundated with
calls about a single emergency. The PSAP operator can quickly
ascertain if this is a new emergency, if not, quickly state that
emergency services are responding and clear the line with the forced
disconnect feature.

Idle Circuit Tone Application
=============================
Provides a means of determining upon answering a call whether the
calling party has already disconnected the call or is still on the
line, but unable to speak. If the caller abandoned the line just
before the PSAP attendant answered, a distinct tone is heard by the
PSAP. If the caller is unable to verbally respond but is still on the
line, no tone will be heard.

Ringback
========
This feature is used in conjunction with called party hold to reach a
caller who has hung-up before the PSAP has obtained all of the
necessary emergency data. Single party service and direct dedicated
trunks are required.

  All this services are _not_ required in E911 (Enhanced 911).

        Ovidiu

____________________

-- 
Ovidiu Sas                              Email: [email-masked]
SOMA Networks, Inc.                     Phone: 416-348-1560
312 Adelaide Street West 700            Fax:   416-977-1505
Toronto, ON M5V 1R2
Canada

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 06 Mar 2001 23:27:12 +0100

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

>   Basic 911 Service require:

As the Internet is packet-switched there is no line to hold.
Your PSAP end-device may remember SIP and IP addresses of callers.

> Forced Disconnect

Disconnecting SIP emergency calls is as easy as disconnecting any
other calls -- you just send a BYE. Then, co-operating end-devices 
will stop sending packets. No lines, no need to disconnect them.

You may have non-cooperating devices which continue sending packet 
or even send unsolicited packets. However this is a broader denial 
of service issue which is not necessarily specific to 911.

> Idle Circuit Tone Application

Finding out of a call was terminated is easy and can be implemented
in various ways as product UI feature. PSAP attendent's phone may flash
red if a phone is active and flesh green otherwise.

I'm not really sure there is reliable way of finding out a caller
is unable to speak, left phone without haning up, etc.

> Ringback

Ringback is easy. The PSAP attendant or better his device just needs
to remember from where it was called. Absolutely no change to SIP
required.

Jiri

---

From: Ovidiu Sas <[email-masked]>
Date: Tue, 6 Mar 2001 18:10:47 -0500 (EST)

Oh...
  I wanted to point out that Basic 911 Service is different than
Enhanced 911 Service and not all the Basic 911 requirements applies to
E911 Service. There is no need to provide "Called Party Hold", "Forced
Disconnect", "Idle Circuit Tone Application" and "Ringback" in E911.
In most of the cases 911 calls are going to be routed in to the PSTN
and Basic 911 is "deprecated" by E911.

      Ovidiu
___________________

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 Mar 2001 14:50:53 -0600

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?

>to remember from where it was called. Absolutely no change to SIP

*************************************
"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

---

From: "Mart Nurmet" <[email-masked]>
Date: Mon, 19 Mar 2001 15:52:09 -0600

James et all:

The functionality has been required by legislation in the North
American environment.  Not just as a nice to have feature.  In other
parts of the world such requirements may not exist and/or folks are
not aware of that.  There are other features that exist in the PSTN
world that don't translate well into the IP world as well.

Location requirements have been required in the wireline world for
decades but are now being required for wireless users as well.  Not
just geographic, but also altitude.

Legal intercepts for voice traffic is in the final stages of
requirements definitions between the FCC and the courts.

There is also an emergency services prioritization feature, not
preemption, that is being requested.  It has been presented to ITU-T
Study Groups and the different TI Working Groups.  That emergency
services functionality exists in various forms, in many countries, and
as IP communications becomes more ubiquitous those national
administrations will very likely mandate such functionality for us as
well.

So this question is not only for Emergency 911 Service but other
additional functions as well.  They will be laid on us as we handle
calls for people.

-Mart

"James M. Polk" wrote:

> JiriYou 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>>Ovidiu Sas
> wrote:>>>>   Basic 911 Service require:>>>> Called Party Hold>>
> =================>> Enables the PSAP attendant to retain control of
> the call connection>> and to hold the line up for manual tracing
> even if the calling party>> goes on-hook. This is a useful feature
> to locate people who did not>> communicate all of the data needed
> for response by the PSAP and to>> trace nuisance calls. Called party
> hold can only be provided with>> direct dedicated trunk
> facilities.>>As the Internet is packet-switched there is no line to
> hold.>Your PSAP end-device may remember SIP and IP addresses of
> callers.>>>> Forced Disconnect>> =================>> Allows the PSAP
> attendant to disconnect any call on a 9-1-1>> trunk. This feature
> prevents intentional jamming of the PSAP lines by>> persons dialing
> all of the 9-1-1 trunks and refusing to hang up. This>> feature is
> useful during situations where the system is inundated with>> calls
> about a single emergency. The PSAP operator can quickly>> ascertain
> if this is a new emergency, if not, quickly state that>> emergency
> services are responding and clear the line with the forced>>
> disconnect feature.>>Disconnecting SIP emergency calls is as easy as
> disconnecting any>other calls -- you just send a BYE. Then,
> co-operating end-devices>will stop sending packets. No lines, no
> need to disconnect them.>>You may have non-cooperating devices which
> continue sending packet>or even send unsolicited packets. However
> this is a broader denial>of service issue which is not necessarily
> specific to 911.>>>> Idle Circuit Tone Application>>
> =============================>> Provides a means of determining upon
> answering a call whether the>> calling party has already
> disconnected the call or is still on the>> line, but unable to
> speak. If the caller abandoned the line just>> before the PSAP
> attendant answered, a distinct tone is heard by the>> PSAP. If the
> caller is unable to verbally respond but is still on the>> line, no
> tone will be heard.>>Finding out of a call was terminated is easy
> and can be implemented>in various ways as product UI feature. PSAP
> attendent's phone may flash>red if a phone is active and flesh green
> otherwise.>>I'm not really sure there is reliable way of finding out
> a caller>is unable to speak, left phone without haning up, etc.>>>>
> Ringback>> ========>>Ringback is easy. The PSAP attendant or better
> his device just needs>to remember from where it was called.
> Absolutely no change to
> SIP>required.>>Jiri>>_______________________________________________>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.
> "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

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 19 Mar 2001 14:04:04 -0800

Comments below...

At 01:52 PM 3/19/2001, Mart Nurmet wrote:
>James et all:
>
>The functionality has been required by legislation in the North American 
>environment.  Not just as a nice to have feature.  In other parts of the 
>world such requirements may not exist and/or folks are not aware of 
>that.  There are other features that exist in the PSTN world that don't 
>translate well into the IP world as well.

Yes the U.S. has their requirements, but some of the requirements outside 
of the U.S. may be even stronger. So the IETF shouldn't limit their 
requirements to that of the U.S.

>Legal intercepts for voice traffic is in the final stages of requirements 
>definitions between the FCC and the courts.

Let's not set the expectation that legal intercept for packet networks will 
be resolved any time soon in the U.S. or elsewhere. We are smack in the 
middle of the process and nowhere near the true end IMHO. As I said above, 
requirements outside the U.S. may be stronger than those in the U.S. Wait, 
I'll change "may" to "very likely".

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 20 Mar 2001 07:13:52 -0500

The IESG and IAB has spoken on this issue quite strongly in RFC 2804.

Legal intercept has been punted to the International SoftSwitch Consortium
(ISC) <http://www.softswitch.org>.  That's not ideal, as the ISC is a member
(not open) organization.  However, the membership is pretty open :-)

My suggestion is that things that are driven by legal, as opposed to
technical, requirements get worked on outside of the IETF.  If the work
product of such groups result in BCP, architecture, or deployment documents,
then it should be taken to SIPPING.  If there are needs to modify the SIP
protocol itself, then it should be taken to the SIP work group.

This should fit within the guidelines of RFC 2804.  It is highly likely base
protocol requirements to implement legal intercept, emergency services, etc.
will be similar across jurisdictions, even if the high-level laws may be
different.  Moreover, the IETF, as an international organization, is in a
position to comment on implementations that, although would work locally,
would break the Internet architecture as a whole.

Can we put this topic into the FAQ and put it to bed?

> [mailto:[email-masked]]On Behalf Of Matt Holdrege
> Sent: Monday, March 19, 2001 5:04 PM
> To: Mart Nurmet; James M. Polk
> Cc: [email-masked]
> requirements

---

From: "Mart Nurmet" <[email-masked]>
Date: Tue, 20 Mar 2001 08:27:58 -0600

Eric et all:

Thank you, your point is well taken and a FAQ is quite appropriate.  -Mart

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 20 Mar 2001 03:06:59 +0100

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Mar 2001 09:32:31 -0600

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:
>> 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?
>> 

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

---

From: Chip Sharp <[email-masked]>
Date: Tue, 20 Mar 2001 11:14:06 -0500

>(not open) organization.  However, the membership is pretty open :-)

In addition, for the US, there has not been a legal or regulatory decision 
that CALEA (a US LI law) applies to VoIP. Other countries, of course, have 
their own laws and regulations.

> > I'll change "may" to "very likely".

-------------------------------------------------------------------
Chip Sharp                       Consulting Engineering
Cisco Systems
-------------------------------------------------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 20 Mar 2001 11:46:29 -0800

In any IP network, you have to rely on the cooperation of the end
system, whether this involves the end system not hanging up when dialing
911 or some magic "remote control" protocol that "keeps" it from doing
so. Nothing can keep software from hanging up if it (or, rather, its
designer, by mistake or design) wants to. Since it's a lot easier to
sell a device with a sticker that says "911-compliant" than one without,
I suspect that end systems will do the right thing, particularly since
it's pretty easy in this particular case. (Roughly, three lines of code,
as in

if (destination == 911 && user presses bye) {
  popup("sorry, can't do this in an emergency call"); return;
}

"James M. Polk" wrote:
> 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?
> 
> saves

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Mar 2001 11:22:51 -0600

Henning

Interestingly... in a conversation last night, the number of lines of code was
brought up as a negative for this functionality..... thank you for submitting a
solution that has even less than I proposed, which I considered a positive in
its simplicity to write in that conversation.....

BTW -- I wholeheartedly agree that a "911-Compliant" (or whatever is
appropriate for others local jurisdiction) device will be a selling feature.

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

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 20 Mar 2001 22:29:19 +0100

James,

it seems to me that we are running into *mechanism* discussion again
and again before agreeing on what the *problem* is. Could someone help
me and explain what *problem* are we facing here and why is
it desired to prevent emergency calls from being BYE-ed
by caller? 

Once we document the problem we can discuss mechanisms. I do not think
that adding more state to a SIP proxy or introducing a new
"prevent-from-hanging-up" protocol/SIP-extension would help
to deal with emergency situations better. Co-operative end-devices
sound much better to me in the IP context. They may also go beyond 
imagination of today's emergency device designers. For example, 
a NG implementation of a public emergency-enabled SIP phone may 
lock its door until PSAP hangs up so that a nervous caller will be 
not be able to leave the phone after saying "Please come, there is 
emergency here". 

Jiri

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 22 Mar 2001 12:15:23 -0500

I may be badly misunderstanding the issue here, but it seems to me that
this is 95% a SIP UAC problem. As long as the UAC knows it is talking
911 it can do all the appropriate stuff, like not sending BYEs when the
user goes on-hook.
 
There seem to be only two issues that might affect the protocol:
1. Having a way for the UAS to tell the UAC that it's an emergency
center, so the UAS kows to invoke the appropriate local mechanisms.
Seems that this could be done a lot of ways, none of which require
actual protocol extensions, such as with a supported: header.
2. Having a way to tell the calling UAC to ring the phone if on hook.
Again, there are lots of ways I could think of to do this without
protocol extensions, such as ringing the phone if any mid-call INVITE
comes in when on-hook.
 
No matter what we do with #1, we either need strong mutual
authentication or a way for the UAC to over-ride this behavior, else
some unfriendly callee could claim to be a emergency center and put the
calling UAC into this wierd state. Doing this with naming conventions
seems wrong, so I would not be in favor of just depending on how 911
centers are named in the urls.
 
Dave.
 
P.S. I kow there are lots of 911-related issues, like geolocation and
call routing, but those most likely won't affect the protocol either.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of James M. Polk
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?

saves 

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: "Robert T. Bell" <[email-masked]>
Date: Thu, 22 Mar 2001 11:53:40 -0700

MessageDave -

I agree with you. The one issue I think that effects the protocol is that we
need to carry the location blob someway. This is primarily for the use of
gateway devices interfacing to the existing PSTN. I know that eventually,
there will exist IP PSAPs, but for the next period of time, we will have to
deal with the existing arrangement. In talking with Dean the other day, he
mentioned the possibility of carrying this blob in a SIMPLE package. I don't
know enough about SIMPLE yet to know if that will work, but if it does,
perhaps this will do it for this transport. Leaving the call up is largely
an end point requirement with the strong authentication requirements you
identified. One implication to the network (not within the scope of SIP but
of the total network architecture) is that within a resource constrained
network, emergency calls need to be given priority access to resources for
transmission. That represents interesting QoS and RSVP issues.

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of David R. Oran
Sent: Thursday, 22 March, 2001 10:15 AM
To: 'James M. Polk'; [email-masked]
Subject: RE: [SIP] Holding Calls UP for Emergency Service

  I may be badly misunderstanding the issue here, but it seems to me that
this is 95% a SIP UAC problem. As long as the UAC knows it is talking 911 it
can do all the appropriate stuff, like not sending BYEs when the user goes
on-hook.

  There seem to be only two issues that might affect the protocol:
  1. Having a way for the UAS to tell the UAC that it's an emergency center,
so the UAS kows to invoke the appropriate local mechanisms. Seems that this
could be done a lot of ways, none of which require actual protocol
extensions, such as with a supported: header.
  2. Having a way to tell the calling UAC to ring the phone if on hook.
Again, there are lots of ways I could think of to do this without protocol
extensions, such as ringing the phone if any mid-call INVITE comes in when
on-hook.

  No matter what we do with #1, we either need strong mutual authentication
or a way for the UAC to over-ride this behavior, else some unfriendly callee
could claim to be a emergency center and put the calling UAC into this wierd
state. Doing this with naming conventions seems wrong, so I would not be in
favor of just depending on how 911 centers are named in the urls.

  Dave.

  P.S. I kow there are lots of 911-related issues, like geolocation and call
routing, but those most likely won't affect the protocol either.

    -----Original Message-----

    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?

saves

    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

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 22 Mar 2001 14:22:09 -0500

-----Original Message-----
From: Robert T. Bell [mailto:[email-masked]] 
Sent: Thursday, March 22, 2001 1:54 PM
To: 'David R. Oran'; 'James M. Polk'; [email-masked]
Subject: RE: [SIP] Holding Calls UP for Emergency Service

Dave - 
 
I agree with you.  
 
Good :-)
 
 The one issue I think that effects the protocol is that we need to
carry the location blob someway.  
 
Perhaps. There obviously needs to be someway for the PSAP to find out
where the calling UAC is, but that does not necessarily translate into
carrying it in the call establishment, or even necessarily in SIP at
all. There are also privacy considerations to be balanced against most
(but not all) emergency services needing to know where the user is.
There is also the generic problem of the caller;'s location not being
relevant  (e.g. user two miles away from crime/disaster with
surveillance camera).
 
 This is primarily for the use of gateway devices interfacing to the
existing PSTN. I know that eventually, there will exist IP PSAPs, but
for the next period of time, we will have to deal with the existing
arrangement. In talking with Dean the other day, he mentioned the
possibility of carrying this blob in a SIMPLE package.  
 
That's one attractive solution, and may make the privacy problem a bit
easier.
 
 I don't know enough about SIMPLE yet to know if that will work, but if
it does, perhaps this will do it for this transport. Leaving the call up
is largely an end point requirement with the strong authentication
requirements you identified. One implication to the network (not within
the scope of SIP but of the total network architecture) is that within a
resource constrained network, emergency calls need to be given priority
access to resources for transmission. That represents interesting QoS
and RSVP issues. 
 
In my view, at least from the protocol/design standpoint, the last is a
solved problem. The RSVP/COPS priority/preemption objects deal with this
nicely for both the end-to-end RSVP case and the edge-policed
COPS-PR+Diffserv case.
Dave.
 
Bob

-----Original Message-----
[mailto:[email-masked]]On Behalf Of David R. Oran

 
 
Dave.

-----Original Message-----

Jiri

Clear as mud, right?

saves 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Mar 2001 15:16:02 -0800

Carrying location information in the call establishment has the obvious
advantage that this puts the end system in control, alleviating privacy
concerns. Presumably, the end system knows when it is making an
emergency call, at least in some cases. Since there is no requirement
that the end system register its location with some server (particularly
if this information is needed only for emergency calls), the end system
may be the only device that knows this information.

This discussion should move to the 911 list, I believe.

---

From: Romeo Zwart <[email-masked]>
Date: Tue, 27 Mar 2001 11:11:36 +0200

At 01:16 AM 3/23/2001, Henning Schulzrinne wrote:
>concerns.

One argument against this, that I heard when discussing this in a slightly 
different context, was to do with the time that it may take to have the UAC 
establish its location. If you make the location info part of the call 
establishment phase you may end up delaying call set up considerably if the 
end system needs to go out and get its location first. This obviously 
depends on what mechanisms the system has to establish its own location.

Simply using the system's last known location info may lead to serious 
problems if this information is outdated.

A combined solution might possibly be to have the client include its last 
known (i.e. possibly stale) location information at call establishment and 
have it kick off a location resolution request in parallel. When it 
receives back the update on its exact location it can then provide this 
updated info back to the emergency center, for instance in a SIMPLE message 
as suggested earlier.

Romeo

>Presumably, the end system knows when it is making an

---

From: "Robert T. Bell" <[email-masked]>
Date: Tue, 27 Mar 2001 17:58:23 -0700

One thing to consider in this discussion is that while PDA type devices that
are extremely portable may indeed be making SIP emergency calls, the vast
majority of the time, the endpoint will be relatively non-moving. For PDA or
other ultra portable devices, the SIP invite sequence may need to include
some form of notification while the location is determined. However, the
more static devices should have long ago determined their positions. Another
thing to consider, since the PSATs have jurisdictional residence, the call
cannot be completed until the location of the call originator is determined
so that the appropriate PSAT can be contacted. The hypothetical existence of
an IP-PSAP which would redirect calls after they are established is an
interesting concept for the future but is not applicable at this time and
will not be for several years (most probably. IMHO anyway).

This would tend to require that the actual call completion be delayed until
the appropriate PSAT can be located.

Bob Bell

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Romeo Zwart
Sent: Tuesday, 27 March, 2001 2:12 AM
To: Henning Schulzrinne; David R. Oran
Cc: [email-masked]; 'James M. Polk'; [email-masked];
[email-masked]
Subject: [911] Re: [SIP] Holding Calls UP for Emergency Service

Romeo

_______________________________________________
911 mailing list
[email-masked]
http://lists.cs.columbia.edu/mailman/listinfo/911

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 27 Mar 2001 20:05:47 -0500

> will not be for several years (most probably. IMHO anyway).

I see IP-PSAPs as being of more immediate interest for corporate or
university campus emergency response, not regular civil authorities.
Note also that this doesn't have to be run by the same people actually
providing emergency services. I would guess that Telcordia or Netnumber
or Neustar could run a service like this.

> the appropriate PSAT can be located.

Proxying would do this.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Romeo Zwart <[email-masked]>
Date: Wed, 28 Mar 2001 11:23:11 +0200

> At 02:58 AM 3/28/2001, Robert T. Bell wrote:
 > One thing to consider in this discussion is that while PDA type
 > devices that are extremely portable may indeed be making SIP emergency
 > calls, the vast majority of the time, the endpoint will be relatively
 > non-moving.

I couldn't deny a 'minor' bias on my part, but I'd expect non-static,
extremely portable, devices (PDA or other) to be a substantial part
of the population.

 > For PDA or other ultra portable devices, the SIP invite sequence
 > may need to include some form of notification while the location
 > is determined. However, the more static devices should have long
 > ago determined their positions.

Obviously, if a device is of a type where frequent changes of
location are impossible or not very unlikely, there would be no
need to have the device go off to re-establish its accurate
location.

There might be a way for the device to flag that it considers
the location information complete or incomplete. In the latter
case the Emergency center can expect to receive updated location
within a reasonable timeframe. Also it allows for the status
('informal' or 'incomplete') to be flagged to the operator
taking the call.

 > Another thing to consider, since
 > the PSATs have jurisdictional residence, the call cannot be
 > completed until the location of the call originator is determined
 > so that the appropriate PSAT can be contacted. The hypothetical
 > existence of an IP-PSAP which would redirect calls after they
 > are established is an interesting concept for the future but
 > is not applicable at this time and will not be for several
 > years (most probably. IMHO anyway).

I agree.

 > This would tend to require that the actual call completion
 > be delayed until the appropriate PSAT can be located.

Assuming the presence of a local proxy, the proxy would know the
jurisdiction it falls under, so the proxy could determine the right
Emergency Center.

Romeo

---

From: "Robert T. Bell" <[email-masked]>
Date: Wed, 28 Mar 2001 08:07:27 -0700

Henning -

I agree that for campus environments, the IP-PSAP would be of great
interest. However, these campus PSAPs would still need to dispatch to the
public PSAPs for emergency services such as paramedic response and fire (at
least normally. There are large enterprises with their own medical and fire
response teams but these are not the norm). I still think that the
implementation of an enterprise IP-PSAP is still 2-3 years off. I hope I am
hopelessly pessimistic in this estimate, but it would seem reasonable to me.

As to your second comment, even with a proxy function in the middle, the
completion would still require the location information. Otherwise, there is
no way to tell where the help is to be dispatched if the person is confused
or unable to respond to location queries.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Henning G.
Schulzrinne
Sent: Tuesday, 27 March, 2001 6:06 PM
To: [email-masked]
Cc: 'Romeo Zwart'; 'David R. Oran'; 'James M. Polk';
[email-masked]; [email-masked]
Subject: Re: [911] Re: [SIP] Holding Calls UP for Emergency Service

Proxying would do this.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 28 Mar 2001 10:15:06 -0500

> hopelessly pessimistic in this estimate, but it would seem reasonable to me.

2-3 years seems optimistic to me, but given that it took about five
years from first concept to today for developing SIP, we need to be
ready much earlier, before proprietary solutions start appearing.

> or unable to respond to location queries.

Agreed. Although initially, this is probably no different than today's
analog cell phones, which also have no location information.

I would suggest this discussion move to the 911 list.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Mart Nurmet" <[email-masked]>
Date: Wed, 28 Mar 2001 09:28:27 -0600

I agree Henning.

Furthermore, I also agree that this needs to be on the 911 mailing list.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 28 Mar 2001 08:58:08 -0800

Hey folks,

Can you please remove [email-masked] from the discussion!  (move 
this discussion exclusively to <[email-masked]> ).

Thanks,
-rohan