Subject: Re: [Sipping] Other concerns within sos ID

From: [email-masked]
Date: Wed, 11 Feb 2004 21:32:12 EST

In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, 
[email-masked] writes:

The fundamental idea that this draft proposes is that emergency calls 
get special attention.  The special attention is that location is included 
on the call.  There are also routing implications, but the inclusion of 
location is the key issue.

[MAP] The point I'm trying to make is that the requirement to provide 
location for emergency calls has nothing to do with this draft (SOS URI). It must be 
accepted as a requirement and solved even if this SOS URI disappeared today. 
It can not be the SOS URI which enables the location to be provided.

In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, 
[email-masked] writes:

The issue you raise with local emergency numbers is complicated by VPN 
tunnels.  My usual example is the patron of a cafe in Chicago seeing an 
accident while connected via a hotspot through a VPN tunnel to an employer's
VoIP system in Sierra Leone.  In this example, dialing the Sierra Leone 
emergency number would not be an emergency call, but 9-1-1 would be.  

[MAP] If the proxy at the emplyees home office wants to try to handle an 
emergency call and contact the emergency bureau at the location where it thinks 
the person is located, and has all the data to define such things, then let it. 
But I doubt that any regulatory agency would touch this, and any requirement 
they try to place on it would be a mess, since it's so dependent on lots of 
things out of anyone's control. I would say it's not a case we're trying to solve.

In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, 
[email-masked] writes:

Again, generally I agree.  It's a very unfortunate situation, because if you
are a visitor, your awareness of the local emergency number is not very good,
while you clearly know your home emergency number.  

[MAP] True, but that doesn't mean one should use their  home emergency 
number, just because they know it better. I know how to drive on the right better, 
but if I'm in England, I still have to drive on the left.

In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, 
[email-masked] writes:

>[MAP] The final sentence should state: "User agents conforming to the SIP 
>specification [RFC3261], but unaware of this document, must be able to place 
>emergency calls without any restriction using entry of normal emergency 
>numbers, although they will not generate the SOS URI." 
I think this is incorrect.  First of all, a proxy can redirect to sos.
Secondly, you can't get "without restriction" because you don't get
location. 

[MAP] I think what I wrote above is a regulatory requirement. The UA must be 
able to place an emergency call "without restriction". Of course the proxy can 
generate an SOS URI. I didn't say it couldn't. As noted above, "location" is 
another issue not dependent on the SOS URI and not made possible by this 
document.

In a message dated 2/11/2004 1:50:25 PM Eastern Standard Time, 
[email-masked] writes:

>[MAP] Case 4 is used when the terminal does not know the local dial plan. It 
depends 
>on a proxy to interpret the number, just as for any other dialed number. 
Disagree, as above

[MAP] I'm not sure why you said "disagreed", since your other comments seem 
to agree with the point I'm making in case 4 (terminal doesn't understand dial 
plan so it depends on a proxy to "recognize the call as an emergcncy call"). 
I'm just trying to be explicit by enumerating the case which this document does 
not cover.

Mike Pierce

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Feb 2004 22:38:26 -0500

> location for emergency calls has nothing to do with this draft (SOS 
> URI). It must be accepted as a requirement and solved even if this SOS 
> URI disappeared today. It can not be the SOS URI which enables the 
> location to be provided.

No, but the sos URI allows a downstream proxy to provide the location to 
the calling user via a redirect response (The caller then re-initiates a 
location-equipped emergency call as if it had the location itself).

Whether the SOS URI is the *only* mechanism for the calling UA to 
request location information is another question.

> emergency call and contact the emergency bureau at the location where it 
> thinks the person is located, and has all the data to define such 
> things, then let it. But I doubt that any regulatory agency would touch 
> this, and any requirement they try to place on it would be a mess, since 
> it's so dependent on lots of things out of anyone's control. I would say 
> it's not a case we're trying to solve.

In our architecture, this just works and is no more difficult than 
solving any other problem. If you have a concrete concern, please share 
it, but general regulation fear mongering isn't going to help much.

> number, just because they know it better. I know how to drive on the 
> right better, but if I'm in England, I still have to drive on the left.

The problem is that driving on the wrong side gets you killed, while 
being able to dial a number that you remember while in panic quickly 
saves your life. Thus, the analogy is a rather poor one, in my opinion.

The only drawback is that, in rather rare circumstances, your back-home 
emergency number is a valid service number at your current location. 
This seems, at worst, a minor nuisance. Since you're familiar with your 
home emergency number, if you find that the Easter Island use 911 for 
their directory service, there could be a user interface override 
('escape').

One solution is to make this behavior configurable. If you'd rather use 
a device that does not remember your home dial plan, be my guest. Given 
that this is new and improved behavior compared to today's system, 
making this optional is not a big deal.

> [MAP] I think what I wrote above is a regulatory requirement. The UA 
> must be able to place an emergency call "without restriction". Of course 
> the proxy can generate an SOS URI. I didn't say it couldn't. As noted 
> above, "location" is another issue not dependent on the SOS URI and not 
> made possible by this document.

There are two cases:

(1) Your UA recognizes the digits you dial as an emergency number and 
translates the digits into sos@something.

(2) It doesn't.

In the former case, the call will be placed correctly, assuming that 
(crude) location information is available. We should make sure that case 
(1) is the high-probability event. With the mechanisms described in the 
emergency-arch document, finding the local emergency number is not hard. 
That document suggests two different approaches (DNS and XCAP).

In case (2), two things can happen: the call gets placed as a tel:XXX 
call and your local outbound proxy routes it to a gateway that does the 
right thing. This should be the common scenario, leaving odd VPN cases 
aside. (A well-maintained VPN will always get you to case (1).)

Thus, I don't see the problem.

> an emergcncy call"). I'm just trying to be explicit by enumerating the 
> case which this document does not cover.

Which I still don't understand. Getting the geographically local dial 
plan is beyond the scope of this document, but is part of the 
emergency-arch document.

> Mike Pierce

_______________________________________________
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