Subject: [Sip] Suggestion to locate nearest ERC-center by ENUM

From: Rene Bartsch <[email-masked]>
Date: Mon, 12 Jan 2004 23:01:09 +0100

Hi,

for emergency calls we have the problem to locate the nearest ERC-center.

As most SIP-phones will have a numeric pad only, we'll have to use ENUM 
anyway. This brought me to the idea to use ENUM for allocating the SIP 
or WhatEverProtocol address of the nearest ERC-center.

The idea is simply:

Just using NAPTR-RR and LOC-RR.

The ITU would run the top-layer ERC-ENUM-domain 1.1.9.e164.arpa. The 
Zone-file would have a LOC-RR and a NAPTR-RR pointing to each national 
ERC-domain (e.g. 1.1.9.1.e164.arpa for the US, 1.1.9.9.4.e164.arpa for 
Germany, 1.1.9.4.4.e164.arpa for UK, 1.1.9.3.3.e164.arpa for France, 
1.1.9.3.4.e164.arpa for Austria, etc.)

Every national regulator would run the national ERC-ENUM-domain in the 
same shape, either pointing directly to the adresses of the ERC-centers 
or having additional sub-layers of ERC-ENUM-domains for e.g. federal 
states, districts, etc.

This would be quite flexible and could also be used for any other 
ERC-service/communication protocol.

The SIP-phones would just use their geographic coordinates (either 
manually stored in fixed phones or e.g. evaluated by GPS for cell 
phones, ...) and do a DNS-lookup when 911 is dialed to find the nearest 
LOC-RR and the corresponding NAPTR-RR for the ERC-center.

Comments?

Rene Bartsch

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 14 Jan 2004 12:27:53 -0500

> > This is WAY beyond anything the IETF can do, and I think is not
> > practical at this time.  If you want to take such an effort 
> on, please 
> > go ahead and let us know if you suceed.  In the mean time, 
> we will have
> > to deal with current reality, which is that there is no 
> universal number.
> > 
> 
> What if they set up a RFC for a inernational ERC-number? I think 
> regulators will adapt it, even if it will last years.
Because the world numbering plan is "owned" by the ITU, and any attempt
to define anything in the e.164 area is going to be impossibly hard.
I don't think the IETF would even try to do this, and I don't think
we have to.

Actually, I think that there is no 3 digit number that would not
be in use in some country for a purpose other than emergency calls.

> 
> > You are dreaming, I think.  Very few phones will know how to do
> > an ENUM lookup.
> 
> The ENUM-drafts delegate the DNS-lookup to the phones. This is 
> reasonable as it will decrease load for the proxies and increase 
> redundancy as DNS is spread over the world. And it's just 
> some lines of 
> code in the firmware. Simon Morlat has just implemented ENUM into 
> Linphone within a few days.
I don't think the drafts talk about who does the lookup.
Most of the systems I know do not have ENUM In the phones, it is
in routing proxies.  I don't see that changing because there isn't
any benefit.  We will have to change the way phones work to
provide emergency calls, so in theory we could do it, but I
don't think it's reasonable, or necessary.

I also don't think that numbers are the right way forward for
any kind of address, but of course it will be aa LONG time
before numeric-only dialing will be obsolete.

> 
> And without dreaming and visions we'd still live in trees ... ;-)
> 
> > It is not practical for a phone to do the
> > calculations involved in determining the correct psap.
> > Therefore, you will depend on a proxy to do it.  There could
> > be more than one (actually, I personally think that EVERY proxy
> > server should be capable of handling an emergency call, even
> > if normally they are short-circuit routed to a proxy that is
> > designated for emergency calls.
> > 
> 
> This would mean a phone must be capable to handle several proxies.
Which is a heck of a lot easier than intersecting a point in a series
of polygons - in code, execution time, and probability of getting it
right in corner cases.

> 
> > 
> > Yes, of course.  There are many details.  We need a new RR to be
> > able to have a list of polygons.  We need to have the argument about
> > the format chosen for LOC.  I don't think this is a big problem,
> > but it will need new DNS machinery.
> > 
> 
> Just a firmware-/software update on the DNS machinery, if 
> really necessary.
Yes, I think this is relatively easy, although difficult to get 
agreement on.

> 
> But maybe we can define a geographical area based on one point and a 
> exponential function. That function could just be added to the 
> text-field with coordinates of the standard LOC-entry.
No, the ERC service area is not defined by any function, it is defined
by a political process and described by an irregular physical boundary.
There is no way to use any simple function to choose the ERC.  You need
to know the service boundary polygons of each ERC and intersect your
location with them until you find the one that you are inside of.

There are circumstances in which you will find that you are in more than
one service area, but I'll leave that problem for a little later.
> 
> > 
> > I agree that a phone with a numeric pad only has to be able 
> to reliably
> > place an emergency call.  I don't think we can use ENUM to do that.
> > 
> 
> Why not? DNS has proven being the most reliable addressing system in 
> world for 15 years. And setting up a zone-file is quite simple.
I'm happy to use the DNS.  I don't think you can use e164.arpa as the
root.

Would you agree that the only difference between your proposal and 
mine comes down to two things:
1. The root of the tree you want to see is <dialing prefix>.e164.arpa
and the root I propose is <iso country code>.sos.arpa?
2. The terminal nodes in the tree you propose is something like 1.1.9.
while the terminal node I propose is something like newcom (or any name
for the psap).  I'm still discussing my proposal with some DNS folks.
It may be that the DNS entry is newcom.psap.allegheny.pa.us.sos.arpa,
or it may be that the newcom.allegheny.pa.us.arpa is somehow marked
as a psap entry.

I think that you can't really take advantage of the fact that the
terminal part of your proposal is the emergency calling number,
because the middle of the tree is not ENUM.  If you branch off
the real ENUM tree, then it doesn't matter, much, what the
terminal part of the entry looks like - it's a new definition
of a part of the DNS.  The name doesn't matter to the phone;
it has to find all of the service boundaries in the tree, and
find the intersection of the point in the polygon.

A complication we have to deal with is that in some areas,
the psap is located at different depths of the tree. So, for
example, you might have a statewide ERC center, but a city
ERC for the largest few cities.  This means either that
the service boundary has holes in it, or that you need a
"most specific" kind of search of the tree (and maybe both).

I don't think that your proposal is any simpler than mine.
I think I have merely thought out exactly how the data in the
DNS gets populated, and how you deal with geo as well as civil
location.

Take, for example, the interior layout information.
Right now, in most places I know about, the way that is kept is
that the fire marshall carries a big box of paper in his truck.
The way that location to a building or a room is communicated between
an enterprise and the psap involves a bunch of forms, two or three
intermediaries and, sometimes, a fax, that maps a phony phone number
to a room/floor/building string.  

I'm proposing a mechanism that we know will scale well to delegate
and populate a database that contains the information needed to 
respond.  Consider, for example, that EVERY CALL needs both a 
geo and a civil location:

You need a geo to find the ERC service boundary, as I have explained.
You need a civil to dispatch a responder.

Therefore, we need a good source of civil to geo translation.
We need that to match what is called a "Master Street Address Guide".
We need that to work down to a room on a floor in a building.

Not every phone will have geo, not every phone will have civil, but
every phone will, we propose, have one or the other.  That means
we need a universal, reliable conversion database between civil
and geo.
> 
> > 
> > Yes, but you have to deal with the fact that emergency response is a
> > government function, and is organized by different 
> governments in different
> > ways.  My proposal will be acceptable only if the civil 
> format is acceptable
> > to every government.  There has been work on this by 
> Henning Schultzrinne.
> > I do think that we can have a multiple level system where the exact
> > meaning of each level is not standardized, but the process 
> for delegation
> > and populating is.  That would allow any country to 
> organize its civil
> > location formats as it prefers, and still allow a phone 
> manufactured by any
> > vendor work anywhere, and be able to reliably make 
> emergency calls anywhere.
> > 
> > I think that is what you propose, and we are just having a 
> minor semantic
> > difficulty.  In my example, you don't need to know that 
> "allegheny" is
> > a county.  Its just a level in the DNS tree, where there 
> are levels above
> > and below it.
> 
> In my example, "alleghny" is just a unspecified level, too.
> 
> > 
> >>My suggestion allows to use any domains below the top-layer domain.
> >>
> > 
> > Which I agree with.
> 
> The difference between your ideas and mine is just the way of 
> addressing. I want to use ENUM only for reasons of reliability and 
> redundancy and combine the caller's data only in the ERC-center for 
> reasons of privacy, while you want to use proxies which need 
> excessive 
> encryption to ensure privacy and a more complex SIP-protocol, which 
> really isn't "Simple" anymore. And all data of each human 
> being will be 
> published in DNS - a SPAM-friendly world I don't want to live in!
As above, I think we have the same mechanism to address, up to the
ERC boundary location.  I propose to go beyond that to solve another
real problem.

The proxies don't need to decrypt any data to route a call.  The
ERC would have to decrypt data below building level in order to
dispatch to a specific place in a building.  I think that is 
quite reasonable (and the decrypting can be done in advance).  I
propose to use the DNS to publish the data because the delegation
mechanism matches what we need so well.  Having the civil to geo
translation database to street address level will be usefull for
many other purposes as well.  

I think the SIP part of the problem is in the eye of the beholder.
I don't think UAs will implement ENUM, and I think proxies will
route emergency calls.  You think phones will implement ENUM
and phones will be able to directly route calls.  The SIP messaging
is the same, right?  Its only where routing decisions are made.

I don't think there is any more data on individual humans in my
proposal than yours.  There is a more boundary information
for the interior of buildings.  In some jurisdictions, this
is public data already.  In most it is not, which is why it needs
to be protected.  I think the mechanism to do that is simple,
and is only between the publisher (building owner or tenant
for example) and the emergency response providers.
> 
> I've learned to use simple solutions as complex solutions are 
> quite fragile.
Agree

But you have to solve the whole problem, not just a part of it.

In emergency calls, there are 4 basic things you have to do:
1. Recognize a call as an emergency call
2. Route the call to the correct ERC
3. Deliver location of the caller
4. Provide a useable call-back identifier for the call

The ERCs would also like to be able to prevent the UA from hanging
up the call, but I don't think we can give that to them.

Brian