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

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

Rene

9-1-1 is a valid number (or service invocation) in many dialing plans.
In fact, the delegation of 1.9.e164.arpa would be to India, since it
owns the +91 country code.

A phone with a numeric pad only would dial the "local" emergency number.
That would be translated by a routing proxy to the universal emergency
URI (sos@localdomain).  The draft discusses this.

A LOC entry is a single point.  You need a boundary.  In fact, you need
a list of polygons.  The "nearest" ERC is not correct.  ERCs have defined
service boundaries.  You must intersect the location (a point) with the
boundary to determine which ERC service area the point is located.
I'll expand this later, but there are circumstances where there might be
more than one ERC serving a given location.  This is even more obvious
with levels above the ERC; the boundary for the U.S. and Canada for example,
cannot be reduced to a point where you can determine which side of the
border you are on by comparing distance from a single point to the
target location.

Your outline of walking the tree differs in detail from my proposal,
but it is similar.  I start at sos.arpa.  You start at 1.1.9.e164.arpa.
I use 2 character ISO country codes.  You use e.164 numeric country codes.
You don't identify the form of "whatever you want".  I use political
subdivisions that actually do delegation for lower levels.  You suffix
all entries with 1.1.9, I'm working on a couple different ways of
identifying
ERC entries.  Otherwise, the BASIC idea is the same, the details are
quite different.

Brian

-----Original Message-----
From: Rene Bartsch [mailto:[email-masked]]
Sent: Tuesday, January 13, 2004 5:36 PM
To: Rosen, Brian; [email-masked]
Subject: Re: [Sip] Suggestion to locate nearest ERC-center by ENUM

Rosen, Brian schrieb:
> 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,

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

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

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

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

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!

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

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

_______________________________________________
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: Wed, 14 Jan 2004 00:39:17 +0100

> owns the +91 country code.

Ok, we just cut off India ;-)
(Should have checked the dialing plans ...)

So we'll have to find another, world wide ERC-number or use national 
ones with country prefix. But looking at internationalization and people 
crossing the world by plane I'd prefer one world-wide ERC-number. And 
the ITU has the possibilites to realize that.

> URI (sos@localdomain).  The draft discusses this.

And what if the phone cannot reach a proxy? There should be a 
Peer2Peer-fallback in such a case. In that situation the translation of 
numerics to alphanumerics can only be done by ENUM.

Our national regulator (Germany) will never allow ERC-systems dependent 
on one proxy without redundancy!

> a list of polygons.

And how do you define a polygon? If I do remind well from my 
math-lessons by several points ...

> The "nearest" ERC is not correct.  ERCs have defined

A polygon of LOCs ...

> I use 2 character ISO country codes.  You use e.164 numeric country codes.

To be discussed. But I'd prefer ENUM as starting-point to avoid problems 
with dialing by numeric pads.

> ERC entries.  Otherwise, the BASIC idea is the same, the details are

It's my goal to set up a flexible, common layer based system independent 
from political issues - you never know how long political/national 
borders are kept (no Sowjet Union anymore, Germany, France, Great 
Britain, ... may become EU and maybe Iraq the 53rd federal state of the 
US ;-)

My suggestion allows to use any domains below the top-layer domain.

Rene