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

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 03 Jan 2003 22:14:41 -0500

I agree with Mike. I don't want to require that a SIP UA has to use a 
specific "local" outbound proxy, for example, but it may do so as a 
performance optimization. The local outbound proxy can and should 
recognize the local emergency number (in addition to 'sos') - that's 
fairly trivial. There isn't really anything much the terminal (UA) needs 
to do special in that case. (Possible exception: if the terminal 
normally ignores the outbound proxy, it might decide not to in an 
emergency. That seems a stretch since ignoring the outbound proxy is 
likely to have you run smack into the firewall.)

The draft already says

Outbound proxy servers {\MUST} be
configurable to recognize additional local emergency numbers.

What other special actions does the *terminal* need to perform in case 
of emergency?

Michael Hammer wrote:
> Mike,
> 
> Before a "terminal" can handle the local dial plan, it must first 
> determine what "local" is.  It is still not clear to me how that is 
> going to occur.
> 
> The terminal may be able to handle a number input by the end-user and 
> formulate a request, but then it may need to rely on a nearby proxy 
> which is more fixed and knowledgeable of what local is and route 
> accordingly.  But, this may depend on the topology of the network and 
> its relationship to geography and jurisdictional boundaries.
> 
> Mike
> 
> 
> At 03:11 PM 12/23/2002 -0500, [email-masked] wrote:
> 
>> In a message dated 12/21/2002 12:06:10 AM Eastern Standard Time, 
>> [email-masked] writes:
>>
>>
>>> That's why I argued that incorporating all local numbers is not feasible
>>> nor desirable. I'm still undecided whether favoring 112 or 911 is a good
>>> idea (I suspect it may not be since it's hard to draw the line).
>>
>>
>>
>>
>> [MAP] I think there is still confusion here. Of course, a device can 
>> not "incorporate" all local numbers. My comment was that it must 
>> "handle" all local numbers (where the primary discussion at the moment 
>> is regarding emergency numbers). If this is claiming to lead to an 
>> "international standard", then it can not "favor" 112 or 911. While 
>> "SOS" itself could be a good idea, perhaps the discussion and draft 
>> should be separated from the more general, complex issue of 
>> recognition by a terminal of the local dial plan. Maybe just a 
>> statement to the effect that "besides handling the "SOS" as defined in 
>> this note, a terminal must correctly handle the local dial plan, 
>> including the appropriate emergency number(s), which is not described 
>> here".
>>
>> Mike Pierce
>> Artel
> 
> 
> _______________________________________________
> 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: Henning Schulzrinne <[email-masked]>
Date: Sat, 04 Jan 2003 11:06:09 -0500

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

We've been playing around with a simple mechanism that includes the 
location information, both civil and geographic, in a SIP header only 
for 'sos' calls. This is simple to implement and avoids having to set up 
a large infrastructure. It also greatly simplifies the trust 
relationships. If you deliver this information out-of-band *e.g., as 
part of a presence mechanism via UPDATE), the PSAP has to convince the 
entity holding the location information that it is indeed a PSAP and, 
more over, preferably the one the user just called. (See the related 
discussion on the difficulties of authenticating users.)

The location information can be added by the UA or the proxy; it is 
somewhat similar in spirit to the NAI problem.

The reason for suggesting a SIP header field instead of a body is that 
proxies aren't supposed to be adding body parts to requests.

However, a header like this should be standardized outside the emergency 
call context since it is more generic.

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

My take is that we should not *require* that a proxy between the caller 
and the home domain know that the call is special, but allow this. The 
Draft describes two such actions:
- the obp may recognize a local emergency number and route it to a local 
gateway or PSAP
- the obp may recognize 'sos' and do the same.

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

We have implemented a system that does exactly that, based on the 
location information I mentioned above, using a commercially-available 
database. Unfortunately, the protocol that maps location information to 
jurisdiction is proprietary and it is very difficult to gain access to 
the database. (You need to set a strange VPN, establish contracts and 
the like. This makes this arrangement suitable for large telecom 
carriers, but not for a small or mid-sized business with its own proxy 
servers.)

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

I agree. My current hunch is that my draft or something improved is 
probably heading for BCP or Informational. It really doesn't describe 
any new SIP protocol elements.

At this point, there is an opportunity to ensure somewhat SIP-friendly 
non-jurisdiction-specific solutions in this space, rather than mandating 
replicating the existing system with all its warts.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 04 Jan 2003 11:48:36 -0500

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

As suggested for 3G, it would be helpful, but not necessary, to have 
some geographically local entity provide this information to the UA. 
(After all, a telephone doesn't need to know that the digits 911 are 
special in some way.)

There are, I believe, only two plausible solutions:

(1) DHCP or possibly SLP. Given that it's in the same broadcast domain 
as the caller, most likely to be local, at least at the country level. 
(Even traveling dial-in users will rarely dial an out-of-country number.)

SLP would seem most appropriate, but it is yet another specialized 
service that would be used only for a very narrow purpose. (Unless, of 
course, our suggestion of using SLP [draft-zhao-iptel-gwloc-slp] for 
local gateway location catches on...) The only extension needed would be 
  the list of locally valid emergency numbers.

(2) Outbound proxy. Given the separation of data carriage and SIP 
services, may be at corporate headquarters or at some centralized SIP 
service provider POP.

Thus, (1) seems better. However, for DHCP, since it's the outbound proxy 
server that needs to route the calls, it may be better to have it 
indicate what the numbers it can handle.

A slightly different approach would be to have DHCP identify a local 
gateway that can handle local emergency calls, rather than just the 
numbers.

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

Fortunately, for this problem, either entity only needs to know the 
country (or, in Western Europe and North America, a good chunk of a 
continent) rather than more precise location. This may make it more 
manageable. In general, since there are likely going to be far fewer 
outbound proxies than UAs, I tend to prefer a 'UA does a best guess at 
location, outbound proxy knows local dialing plans'. For devices that 
are unlikely to move beyond national borders, such as the SIP phone on 
your desk, a local dialing plan will work pretty well.

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

That's the intent of the draft.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 04 Jan 2003 12:48:50 -0500

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

Hopefully, the devices can then have a red button marked 'SOS' which 
should deal with some of the user interface issues. See the other 
discussion on means to find the local emergency number. In practice, 
this may not be a big issue. After all, in the worst case that the call 
goes back 'home' across several timezones, the list of such numbers is 
no larger than the list of 200+ countries, so a simple SOAP service that 
retrieves the current list is pretty straightforward. (I'm restricting 
myself to countries with national emergency numbers.) The harder part is 
then routing the call to a place that can dial the number and reach 
somebody useful. In practice, I don't see anything except an obp local 
to the caller (at least within the same country) that can do this.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 04 Jan 2003 13:12:08 -0500

Mills, Duncan, D, CND Tech Dev, VF UK wrote:
> 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.

This seems potentially useful, but somewhat in the wrong direction and 
at the wrong layer. At least currently, the information appears to be a 
list of physical layers, as in

"IEEE-802.11a" / "IEEE-802.11b" /
"3GPP-GERAN" / "3GPP-UTRAN-FDD" /
"3GPP-UTRAN-TDD" /
"3GPP-CDMA2000"

and is provided by the UA. This type of information doesn't seem to help 
much in determining the local emergency number, a local suitable gateway 
or other emergency information. How would you envision extending this 
information and how would the UA find out this information?

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 04 Jan 2003 13:33:08 -0500

Thanks for your comments. Skipping things discussed already, some 
remarks inline.

[email-masked] wrote:

> This capability to support a special universal identifier does not 
> replace any requirements that a user must be able to dial local 
> emergency numbers and have the UA correctly handle the call, including 
> any appropriate processing..

I noted that this is an additional capability.

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

Has been added.

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

Do you have any suggestions that work better? The section 'Alternative 
Identifiers Considered' describes why I believe that none of the obvious 
alternatives is workable if you want

- gradual deployability (this rules out special tel: URIs)

- ability for non-modified UAs to dial this number (this rules out a new 
header field or URI parameter)

We have a long-standing precedent for this, namely the 'postmaster' 
convention in RFC 2821, Section 4.5.1:

  Any system that includes an SMTP server supporting mail relaying or
    delivery MUST support the reserved mailbox "postmaster" as a case-
    insensitive local name.

> 
> 4. Request handling
> 
> The 4th paragraph talks about "testing" by use of OPTIONS. Since the 
> testing is only "recommended", there should be no reason that the random 
> intervals be a "MUST".

This does not follow logically. It simply states that "if you do X, you 
MUST do it in a certain way." I don't want to say that "if you do X, you 
SHOULD do it that way, but may do it differently if you need to".

> 
> The next paragraph states that "any proxy ... that receives such a 
> request MUST forward the request to the appropriate local emergency 
> number". Since this certainly does not refer to the test call in the 
> preceding paragraph, this paragraph should be moved.

Moved.

---

From: William Marshall <[email-masked]>
Date: Mon, 6 Jan 2003 08:08:42 -0500 (EST)

Henning,

Very good questions, and I really wish I had something citable as
evidence of the current situation.

I've been told that Bell South has written their own specifications
for 9-1-1 service, and don't use the Bellcore ones. (but no citation).

And I certainly agree that these "basic-9-1-1 features" won't work in
an E911 system when the caller is not connected to the same class 5
switch as the PSAP.  I believe all the NENA and Bellcore documents on
E911 are consistent on this.

The most solid piece of evidence that I have is that the packetcable
signaling draft specification was rejected by the cable operators because
it did not support PSAP-initiated constant-ring on an attempted hangup.
At least one cable operator (unknown which one) insisted this was an
absolute requirement in their service area.  But since it was an
anonymous veto, there is again no citation available.  So we just deal
with it (and a few lines of text added to the next rev of the proxy-
proxy I-D defining an additional token to the P-DCS-OSPS header).

I really do wish that I had a better answer for this one.

> Given the many ways that the caller can terminate a call, this seems 
> like a second-order problem. Can ISUP refuse a teardown request? What 
> happens in that case?

I agree that the technical situation borders on ludicrous, but the fact
remains that CLEC-certification is essential and is not a technical issue.

> Do cell phones support any of the features you describe?

Keith can answer this one more completely, but I believe emergency calls
on cell phones are not supported yet in IMS - that the cell phones are
required to use the circuit-switch modes for 9-1-1 calls.  As for non-3G
phones, nothing prevents them being turned off, and (fortunately) nobody 
considers that a problem.

Bill Marshall
[email-masked]

-----original message-----
Date: Fri, 03 Jan 2003 23:10:47 -0500
From: Henning Schulzrinne <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Sipping] Re: Comments on revised 'sos' draft

William Marshall wrote:
> 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).

Since this comes up again and again, I've asked this question (a while 
ago) on the NENA mailing and nobody (that answered) was able to provide 
any indication that this is still true for E911 today. (It was true for 
the early 911 service where the PSAP was connected directly to the local 
switch.) It was claimed that modern ISDN switches don't provide this 
functionality, either. Maybe you're talking about non-North American 
jurisdictions? Do you have citable evidence on this requirement? Since 
the PSAP tandem and the caller switch may be several 'hops' apart, this 
capability would have to be part of ISUP.

I looked at one of the Telcordia/Bellcore specs for 911 service and it 
doesn't mandate it, either. Since CLECs generally don't (like to) write 
their own switch software, I'd imagine that this would at least be a 
Bellcore requirement.

I got the following two contradictory quotes, among others:

"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.)."

This only requires the originating switch to recognize N11, so that 
seems fairly easy in PSTN land. I suppose one could say that UAs should 
not use REFER.

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

This probably argues again for a global identifier. Some behavior, like 
call waiting, doesn't really apply in UAs. REFER issued by the UA to the 
PSAP is harmless.

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

Given the many ways that the caller can terminate a call, this seems 
like a second-order problem. Can ISUP refuse a teardown request? What 
happens in that case?

This may be a simple UI issue. Since this is primarily a prevention of 
accidental disconnects, a UA might want to treat the 403 as a "Callee 
doesn't want to hang up. Do you really want to terminate the call?" (The 
rough equivalent of the corresponding Windows Ctrl-Alt-Del behavior...)

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

You mean for PSAP initiated call-back? This would be the same situation 
as if I had sent a BYE and an INVITE crossed on the wire. It would 
probably yield an invalid call-ID error.

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

Since these are corner-cases, it seems a bad idea to rely on specific UA 
behavior. Do cell phones support any of the features you describe?
_______________________________________________
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, 8 Jan 2003 10:31:38 -0000

see below (original snipped)

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 
> 
> 
> I've added a reference to this. I suppose for an 802.11 wireless base 
> station, the basestation MAC address would be the equivalent. Any 
> interest in defining this, given that the draft already lists 
> IEEE-802.11a and IEEE-802.11b as access-types?
> 
There is work going on in 3GPP release 6 on using wireless LAN as an access mechanism to 3GPP. This has not yet addressed the issue of SIP users on the wireless LAN accssing the IM CN subsystem within 3GPP. There are still more fundamental architectural issues being addressed. I would expect some specification of the requirement here to eventually fall out of this, but it is too early to say yet which specification it will end up in (whether it be 3GPP or IEEE).