Subject: RE: [Sipping] Re: Comments on revised 'sos' draft

From: "Mills, Duncan, D, CND Tech Dev, VF UK" <[email-masked]>
Date: Mon, 16 Dec 2002 13:32:24 -0000

Henning,

Just a quick comment/question, relating to what Keith just said:

In section 5 of the draft - 'Request Routing':

You talk about the need for a UA to be able to provide information about its location.  You mention providing exact information such as longitude, latitude and altitude.  You also mention possibilities of providing 'Agent-Circuit-ID' and 'Remote-ID', as per RFC 3046.

Have you considered also mentioning the use of the p-access-network-info header for this purpose?  (see draft-garcia-sipping-3gpp-p-headers-02 which is in the RFC editors queue).

The p-access-network-info header enables you to specify an access-type and an access-info field in cases where the UA is aware of the access network.

In 3GPP circles this helps (as Keith said) the outbound proxy to try and figure out if the 'dialled digits' are that of a local emergency centre or not...

Best Regards,

Duncan

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]]
Sent: 16 December 2002 13:05
To: 'Henning Schulzrinne'; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Re: Comments on revised 'sos' draft

See below

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: 13 December 2002 20:53
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sipping] Re: Comments on revised 'sos' draft
> 
> 
> Indeed; I don't want to go there since that's the wrong 
> solution. From 
> what I've heard, 112 is built into GSM devices and works everywhere, 
> even in the US. Is there any country where 911 or 112 means something 
> other than emergency (or nothing)?
> 
It may work fine for US related numbers, but do we want this document to reflect a US centric view.

The normal example quoted of difficulties in 3GPP circles is "192" which is an emergency number in some South American companies, and is (currently) directory enquiries in the UK. I understand that there are other local service number conflicts.

It is worth pointing out that 3GPP has addressed this issue for SIP, and discovered that it CANNOT rely on local configuration of the phone due to just such conflicts. In addition to local configuration of the phone and the SIM, it therefore also relies on two mechanisms:

1)	downloading information to the phone when it registers (to the local cellular network - information provided by the SGSN or local MSC)

2)	analysing calls made at the outbound proxy against a database and making decisions based on the roamed-to network (Mobile Country Code + Mobile Network Code) which are sent with each call, as to whether the call is an emergency call in that network or not.

I agree that neither of these two mechanisms can be generally applicable in SIP, as they both rely on some intermediate entity support.

Keith
_______________________________________________
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: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 18 Dec 2002 10:30:20 -0000

See below

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> From: Michael Hammer [mailto:[email-masked]]
> Sent: 17 December 2002 20:06
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sipping] Re: Comments on revised 'sos' draft
> 
> 
> Mike,
> 
> In all cases, one must "dial" or input something.  On some 
> phones it is 
> possible to simply push a button and that translates to a 
> dialed number.
> 
> I think the experience of the PSTN showed that having a well 
> known service 
> indicator was better than every place doing its own thing.  
> But, I don't 
> expect that the various PSTN administrative domains will 
> converge on either 
> 911 or 112.  At least in the case of the Internet, because of 
> the early 
> nature of VoIP there is at this time the possibility of 
> converging on one 
> thing.
> 
While you may converge on a small set of consistent SIP URLs, you will still need to cater for people who go to an unfamiliar device that happens to look like a phone, and enter the PSTN local service number they associate with emergency dialling. I believe supporting such emergency calls is a requirement, and the regulators will insist that it is so. Thus we continue to have the same problem in SIP space.

> The fact that this is a service indicator as opposed to a 
> routable address 
> means that each locality can translate that into the local 
> address of the 
> emergency number, e.g. PSAP.  I think this helps the mobile 
> user who may 
> not know the local peculiar number.
> 
As I say, you still need to cater for the person who hits the key sequence "911" or whatever, as well as someone who enters the sos SIP URL.

> In arguing against this, you have not reduced the 
> infrastructure workload 
> one bit, but you have pushed the problem to the end-user to 
> configure, with 
> attendant Murphy's Law consequences.
> 
> Mike H.
> 
> 
> At 02:25 PM 12/17/2002 -0500, [email-masked] wrote:
> >In a message dated 12/13/2002 3:52:32 PM Eastern Standard Time,
> >[email-masked] writes:
> >
> >
> >[HS] Thus, I'm somewhat at a loss what 'appropriate 
> processing' the UA should
> >do and, more importantly, how it should know what the local emergency
> >number is. I don't think manual configuration is a reasonable option.
> >The whole idea of a universal identifier is to push this 
> knowledge into
> >fewer devices (proxies, gateways) that tend to stay put rather than
> >billions of devices that tend to move around. Thus, I'm fundamentally
> >opposed to recreating the current local configuration mess in SIP.
> >
> >
> >[MAP] And that's the idea in the PSTN - the millions of 
> phones don't have to
> >know the dialing plan, only the fewer fixed switches have to 
> deal with it,
> >which often happens at 2 AM. I don't know what the solution 
> to this is in the
> >Internet model, unless one accepts the concept of an 
> "intermediate entity
> >support" that Keith mentioned. No, I don't know what 
> "appropriate processing"
> >would be either, but that is what the current draft says the 
> device should be
> >"allowed" to do (based on "SOS". The point is that if there is any
> >"appropriate processing" that the device does when one 
> enters "SOS", or
> >pushes a button labeled that, then it MUST do the same thing 
> if someone dials
> >911 (or whatever the local emergency number is.)
> >
> >
> > >
> > > The 4th paragraph should be reworded as:
> > >
> > > In addition, user agents and proxies MUST also recognize 
> the appropriate
> > > local emergency number, expressed as ...
> >
> >[HS] This is not a useful requirement for user agents. 
> That's exactly what
> >we're trying to get away from.
> >
> >[MAP] I agree, but then any suggestion that it do something 
> special for
> >SOS@anydomain should be removed, too.
> >
> >
> > >
> > > If the approach in the 6h paragraph of defining 
> subaddresses is used
> > > (e.g., fire, rescue, police), it would be necessary to be 
> able to define
> > > many other types, as well as to deal with language 
> differences. Note
> > > that "SOS" itself was chosen due it its international 
> recognition and
> > > not being dependent on a particular language. There would 
> need to be, at
> > > a minimum, an IANA Considerations for assignment of other 
> subaddresses.
> >
> >I agree that an IANA section is needed. These are protocol 
> identifiers,
> >so there is no need for 'sos.feuer' and 'sos.polizei' or 
> 'sos.gendarme'.
> >The notion is that 'sos' (without qualifier) would get you normal
> >emergency service and the rest is for special situations only. All
> >countries that worry about this are moving to a single 
> emergency number.
> >Thus, being memorable and universal only matters for 'sos', not the
> >remainder.
> >
> >[MAP] Again, we need to decide whether these are just 
> "protocol identifiers"
> >or they are intended for human readibility. If they are only protocol
> >identifiers as you've said, then we could define a set (how 
> would we know it
> >was complete?) and just label them "1", "2", "3", etc. But I 
> believe it has
> >been clearly stated that the intention is for the URI to be 
> "human readible",
> >so one could expect the local langauge to be used.
> >
> > >
> > > The seventh paragraph states that the "sos" user name and 
> user names
> > > starting with "sos." MUST NOT be assigned to any user. Such a
> > > restriction can not possibly be enforced due to possible existing
> > > conflicts (as noted in Section 6). While this restriction may be
> > > "recommended", just as it might be recommended that a PBX 
> not use an
> > > extension number of 911, this can not be the basis for 
> any processing on
> > > the URL in a proxy. Depending on a URL of the form 
> "sos@any_domain" to
> > > call the emergency center is not sufficient. This could 
> result in many
> > > unwanted calls to emergency centers.
> >
> >[HS] I would appreciate alternate suggestions. Local dialing 
> plans are not an
> >option. Since losing one of billions of possible user names is not
> >exactly a big deal, I don't see this as a major problem. The 
> first time
> >somebody accidentally reaches an emergency number, they'll fix that.
> >
> >[MAP] I don't have an alternative if the intention is to 
> make it look like a
> >normal address. It's partly why I'm against the idea of 
> defining an "SOS"
> >url. The alternate is to just put the number dialed into a 
> tel:uri (e.g., 911
> >for certain local areas) and let either the user agent or an 
> "intermediate
> >entity" figure out how to handle it, just as it does for any 
> other dialed
> >number. Same solution for "service numbers" and other things 
> allowed in local
> >dialing plans like #77, 311, 0, 011, etc.
> >
> >Mike Pierce
> >Artel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 18 Dec 2002 12:41:28 -0500

Keith,

You might as well be trying to solve the "problem" of a person randomly 
dialing any number and expecting it to go to who they want to talk to.

The problem with your reply is that the scope of those emergency 
regulations is limited to their geographic domain.  If I go to some domain 
where 911 is not used and dial 911, I won't get an emergency operator.  And 
if I complain to anyone, they will tell me I am not in the USA anymore, and 
to get with the local program.

Yes, I do expect that the local "switch" will have to still direct calls to 
the local PSTN emergency number to the correct location.  But, I don't see 
why a single designator cannot be agreed on in the domain called the Internet.

Mike

At 10:30 AM 12/18/2002 +0000, Drage, Keith (Keith) wrote:
>While you may converge on a small set of consistent SIP URLs, you will 
>still need to cater for people who go to an unfamiliar device that happens 
>to look like a phone, and enter the PSTN local service number they 
>associate with emergency dialling. I believe supporting such emergency 
>calls is a requirement, and the regulators will insist that it is so. Thus 
>we continue to have the same problem in SIP space.
>
>As I say, you still need to cater for the person who hits the key sequence 
>"911" or whatever, as well as someone who enters the sos SIP URL.
>

---

From: [email-masked]
Date: Wed, 18 Dec 2002 12:57:59 EST

In a message dated 12/17/2002 4:08:06 PM Eastern Standard Time, 
[email-masked] writes:

> In all cases, one must "dial" or input something.  On some phones it is 
> possible to simply push a button and that translates to a dialed number.

[MAP] There is nothing wrong with building a phone with a special button that 
translates into a dialed number, e.g., 911, but my point is that the user 
must still be able to dial 911 and have the exact same thing happen. Which 
means if the phone does something special when you push that button, then it 
must do the same special thing when you dial 911.

> 
> I think the experience of the PSTN showed that having a well known service 
> indicator was better than every place doing its own thing.  But, I don't 
> expect that the various PSTN administrative domains will converge on either 
> 911 or 112.  At least in the case of the Internet, because of the early 
> nature of VoIP there is at this time the possibility of converging on one 
> thing.
> 
> The fact that this is a service indicator as opposed to a routable address 
> means that each locality can translate that into the local address of the 
> emergency number, e.g. PSAP.  I think this helps the mobile user who may 

[MAP] But I think the question is, what is the "locality" that does the 
translating? And how? If it is the user agent (phone), it needs to know the 
local dialing plan. If it is some "network" element, it needs to know the 
location of the originating user. I don't see an easy solution to either.

> In arguing against this, you have not reduced the infrastructure workload 
> one bit, but you have pushed the problem to the end-user to configure, with 
[MAP] Yes, I understand the end-user configuration problem. And I think the 
rules would say that calls to 911 must work without any end-user 
configuration.

Mike Pierce
Artel

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Dec 2002 13:59:49 -0500

The draft describes a universal identifier.  I take it no one
objects to the basic idea.

This thread is based on the notion that it's not enough; the
device may have to pass a "dialed" number.  Let's examine what
we have to standardize:

1. If it's only stuff in the UA, then we don't need any standards.
We could write a BCP or Informational.

2. If it requires that a proxy actively know that an emergency
number is dialed, and take some distinguished action based on that
knowledge, then we don't need any standards.  We could write
a BCP or Informational.

3. If it requires that a UA be able to reliably communicate with
a gateway, and the gateway is required to actively know that an
emergency number is dialed, and take some distinguished action based
on that knowledge, then we don't need any standards.  We could write
a BCP or Informational.

4. If it requires that the UA tell the proxy server, the UA tell
the gateway, or the proxy server tell the gateway something not
already in the SIP messages, then we have some work to do.

In simple systems, none of the above is necessary.  The scenario
where it might be necessary to do some work is a situation in
which you have:
	A number of UAs in different geographic locations
	A set of proxy servers where the UAs served by one
		proxy server do not respect geographic locations
	A set of gateways in different geographic locations
	A set of users who can roam from UA to UA

In this case, if the user dialed the "local" emergency number,
the some entity must know which gateway to route the call to.
It isn't dependent on the user, it's dependent on the UA, or more
precisely, the geographic location of the UA when the call is made.
The distinction is what happens if the UA is moved.
If a user whose home registrar is in New York visits a site in
Chicago and calls 911, you need the call to route to a gateway
in Chicago. The proxy server for Chicago might be in St. Louis.  
Somehow, the proxy server needs to know that a call from the UA 
in Chicago, regardless of who is registered, needs to be routed 
to the gateway in Chicago.

Generally, most real systems have dialing plans, where dialing
strings are interpreted by some element to determine how to
route a call.  Most systems I know of use a proxy server to
implement the dialing plan.  It's a local matter for the proxy
server to determine how to route a call to the emergency number
BUT, it has to know the geographic location of the UA.
So, we might have some work to do in order to pass that
kind of information from UA to proxy server.  There is some work
on this underway (thanks again Henning).  I'm not sure there is
anything else we need do.

If there is, please be specific.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, December 18, 2002 12:58 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft

[MAP] There is nothing wrong with building a phone with a special button
that translates into a dialed number, e.g., 911, but my point is that the
user must still be able to dial 911 and have the exact same thing happen.
Which means if the phone does something special when you push that button,
then it must do the same special thing when you dial 911. 

Mike Pierce 
Artel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 18 Dec 2002 15:27:30 -0500

Brian,

I think you summed this up nicely.  The one element that is missing is the 
ability to report the geographic location of the UA.

This is the same issue that TIA TR45.2 had to address when dealing with 
cell phones and determining how to route to the correct PSAP.  An example 
given was that a caller in Georgia will be directed to a 911 center in 
Atlanta, but the connection to the police/fire/medical personnel had to be 
local to the caller.  And often the caller did not know where he was.  A 
number of solutions were proposed, which included various angle of arrival 
(AOA), time of arrival (TOA), and GPS-assisted triangulation methods where 
either the phone or the radio station determined and reported this type of 
information.

I don't know if we want to repeat that whole history here.  But, it might 
be useful to provide the ability to add that information to the INVITE.  Is 
there any current technique for doing that?

Mike

---

From: William Marshall <[email-masked]>
Date: Thu, 19 Dec 2002 10:00:51 -0500 (EST)

One aspect of 'sos' calls that is rather annoying is that there
is no agreed standard for some details of the service.  While
organizations such as NENA and ANSI write various documents, local
justidictions actually set the requirements as part of CLEC-
certification (important if you want to get blocks of phone numbers
from the NANP so PSTN subscribers can call your subscribers).

Some jurisdictions require "called-party control" on 9-1-1 calls.  Some 
jurisdictions require PSAP-initiated constant-ring on an attempted hangup.
(I realize that SIP phones, like cell phones, are under the user's
control and can be disconnected or powered off and the real usefulness
of these requirements is dubious; but CLEC-certification is still useful).

There is a basic design decision of whether it is all in the UA, and if 
not, potentially a standardization issue.

If the decision is that the UA doesn't really know when it calls an
emergence service (possibly due to the numerous ways to dial such a 
service), then there are several areas that would need some agreement.

1) what is the effect of a BYE request generated by a UAC that is
rejected by the UAS with a 4xx (e.g. 403-Forbidden)?  Does the UA
need to wait for the response to the BYE before tossing call state?
Likewise, call-stateful proxies on the path?  There is, of course,
a denial-of-service threat here when a non-PSAP rejects a BYE.

2) what is the effect of a mid-call INVITE when the instrument is
in an on-hook state?  Is 180-Ringing an allowable response?

I believe both case are "under-specified" in rfc3261, so the needed
behavior is allowed but not mandated.  I think this is more than a BCP.

Bill Marshall
[email-masked]