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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 13 Jan 2004 16:20:58 -0500

I'm working on a proposal to use the DNS somewhat like this.
This is a little premature, but Rene brought it up, so....

The fundamental difference between what I will propose, and your
proposal is that the phone number mapping to geographic area
breaks down after the country code (for example, in North America,
there is no relationship between the "area code" (first 3 digits
in a phone number) and ERC service boundaries.  Also, there is
no agreement on the "number" for emergency calls, and in fact,
there is an active draft that should be ready for WGLC soon
that proposes that the SIP URI for an emergency call is
sos@<localdomain>.  Therefore, using ENUM like structure isn't
very usefull.  

As you point out, in most countries, there are one or more levels of 
"delegation" on ERC organization that match political subdivisions.  
For example, in the U.S., ERCs are organized by the states, and 
in some cases, there is further delegation to counties.
This varies by country.

In my immediate area, the ERC is called "NEWCOM" and is in Allegheny
County, in Pennsylvania.  I propose that the service boundary of
this ERC be found in the DNS at something like
newcom.allegheny.pa.us.sos.arpa
There are some details to be worked out.

My proposal will be more complex than this, because I would include
much more information in the DNS.  For example, the boundary of
Room 235 on the 5th floor of the Wigit suite at 123 Main Street in 
Pittsburgh PA might be found in the DNS at 
235.5.wigit.123.main.pittsburgh.allegheny.pa.us.sos.arpa 

In this proposal, there is a VERY BIG ASSUMPTION.  The assumption 
is that the DNS is used for PUBLISHING the data, and is not 
actually used in the processing of an emergency call.  Rather, 
I envision that spiders will periodically walk the DNS tree and 
extract the boundary information, storing it in a local database 
organized to make the operations more efficient.

Boundary information would be available at intermediate nodes in 
this proposal (that is, the boundary of Allegheny County could 
be found at allegheny.pa.us.sos.arpa).  It is probably the case 
that the boundary information below the street address level 
would be encrypted if the building owner did not want to make 
interior layout information public.

The data in the DNS would then allow a conversion between civil
(room/floor/building/street address) and geo (lat/lon/altitide).
It would also replace what in the U.S. is called the "Master
Street Address Guide". 

In operation, phones will learn their location, either civil
or geo.  They pass that information on a call to sos@<localdomain>.
A proxy routing an emergency call converts a civil to a geo using
the (previously spidered) DNS sos.arpa data if necessary, and 
intersects the geo with the ERC service boundaries to find the 
serving ERC.  The entry in the DNS contains a URI for the ERC, 
and the proxy routes the call to that ERC.  The ERC gets
location in civil or geo form.  It validates a civil by verifying
that the address exists in the sos.arpa domain, or converts a geo 
to a (valid) civil for dispatch.

You could also imagine a link between sos.arpa and e164.arpa, 
whereby for a fixed phone, there was a "domain name" in sos.arpa 
stored in the terminal e164.arpa entry that mapped a phone number 
to a civil location.  This too might be encrypted.  You could
use such a mechanism to replace existing "ALI" databases that
convert a caller phone number to a location for legacy phone
systems.

Note that the delegation mechanism in the DNS is very appropriate
for this purpose:
	An international organization (possibly ITU) delegates the
		iso country code in sos.arpa to a national agency
	The national agency delegates to lower layer political entities
		(states in my example)
	The (say) state agency, delegates to any lower level agencies
		which in turn delegate to lower level agencies.  In my
		example, PA delegates to Allegheny County, which would
		delegate newcom.allegheny.pa.us.sos.arpa to NEWCOM.  It
		would delegate pittsburgh.allegheny.pa.us to the City of
		Pittsburgh.  The City would create entries for all of
		its streets, and for all of the buildings on those
		streets.
	The City (township, village,...) would delegate to building
		owners
	Building owners would (if appropriate) delegate to tenants
	Tenants would enter floor/room data

An entity at some level might decide that it would not actually
delegate lower levels, but create an administrative mechanism to
populate the lower levels. 

More later.

Brian

-----Original Message-----
From: Rene Bartsch [mailto:[email-masked]]
Sent: Monday, January 12, 2004 5:01 PM
To: [email-masked]
Subject: [Sip] Suggestion to locate nearest ERC-center by ENUM

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

_______________________________________________
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: Rene Bartsch <[email-masked]>
Date: Tue, 13 Jan 2004 23:35:56 +0100

Rosen, Brian schrieb:
> no agreement on the "number" for emergency calls,

The ITU should just delegate ENUM-911 for ERCs world-wide.

  and in fact,
> sos@<localdomain>.  Therefore, using ENUM like structure isn't

But there is a problem:

Most SIP-phones will habe numeric pads, but no alpanumeric 80-key pads.
So we cannot use an addressing out of the decimal range - no letters, no 
"@"!

And there's no problem with the number mapping to the geographic area as 
the geographic is not determined by the area prefixes but by the 
LOC-records.

I think my explanation was a bit misunderstandable.

When you do an ERC,

1.) you dial 911 at your phone
2.) the phone looks up the ENUM 1.1.9.e164.arpa
3.) the phone checks it's geographic data against the LOC-records listed 
in the 1.1.9.e164.arpa-zone and finds the nearest LOC-entry (in your 
case it would be a NAPTR-RR pointing to the ERC-ENUM of the US - 
1.1.9.1.e164.arpa)
4.) the phone looks up the ENUM 1.1.9.1.e164.arpa
5.) the phone checks it's geographic data against the LOC-records listed 
in the 1.1.9.1.e164.arpa-zone and finds the nearest LOC-entry (in your 
case it would be a NAPTR-RR pointing to the ERC-ENUM-domain of 
Pennsylvania - 1.1.9.[WhatEverYouWantLevel1].1.e164.arpa)
6.) the phone looks up the ENUM 1.1.9.[WhatEverYouWantLevel1].1.e164.arpa
7.) the phone checks it's geographic data against the LOC-records listed 
in the 1.1.9.[WhatEverYouWantLevel1].1.e164.arpa-zone and finds the 
nearest LOC-entry (in your case it would be a NAPTR-RR pointing to the 
ERC-ENUM of Allegheny County 1.1.9.[WhatEverYouWantLevel2].1.e164.arpa)
.
.
.
n.) the phone looks up the ENUM 1.1.9.[LastLayer].1.e164.arpa
n+1.) the phone checks it's geographic data against the LOC-records 
listed in the 1.1.9.[LastLayer].1.e164.arpa-zone and finds the nearest 
LOC-entry (in your case it would be a NAPTR-RR pointing to the 
SIP-address of NEWCOM)
n+2.) the phone connects to the ERC transmitting it geographical data 
(longitude, latitude, altitude).
n+3.) the ERC looks up the Address/Room, etc. based on the received 
geographical data and static land office data
n+4.) ambulance, police or whatever is send

It's a quite easy, reliable, flexible and user-friendly solution. Only 
the top-level ENUM 1.1.9.e164.arpa has to be fix, in the lower levels 
you can use ANY domain-name (but I'd suggest to use ENUMs with local 
prefixes to allow users to directly dial their local area ERC-ENUM in 
case upper DNS-brances break down by a nuclear war ;-) ).

> to a (valid) civil for dispatch.

what about privacy? If you put the address data of a person into DNS 
anyone can look it up - No chance to get european countries into the boat!

> populate the lower levels. 

And such a complex system will never work reliable. If you register all 
that phones and flats the data will never be up-to-date. Do you really 
think users will update DNS here and something else here all the time?

Rene Bartsch