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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 14 Jan 2004 09:14:55 -0500

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

> 
> > 
> > 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.
> 
> 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.
You are dreaming, I think.  Very few phones will know how to do
an ENUM lookup.  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.

> 
> Our national regulator (Germany) will never allow ERC-systems 
> dependent 
> on one proxy without redundancy!
Redundancy will be required, I agree

> 
> > 
> > A LOC entry is a single point.  You need a boundary.  In 
> fact, you need
> > a list of polygons.
> 
> And how do you define a polygon? If I do remind well from my 
> math-lessons by several points ...
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.

> 
> > 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.
> 
> A polygon of LOCs ...
A list of a list of LOCS (or something equivalent)

> 
> > 
> > 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.
> 
> To be discussed. But I'd prefer ENUM as starting-point to 
> avoid problems 
> with dialing by numeric pads.
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.

> 
> > 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.
> 
> 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 ;-)
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.
> 
> My suggestion allows to use any domains below the top-layer domain.
> 
Which I agree with.

_______________________________________________
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 17:31:25 +0100

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

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

And without dreaming and visions we'd still live in trees ... ;-)

> It is not practical for a phone to do the

This would mean a phone must be capable to handle several proxies.

> but it will need new DNS machinery.

Just a firmware-/software update on the DNS machinery, if really necessary.

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.

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

> a county.  Its just a level in the DNS tree, where there are levels above

In my example, "alleghny" is just a unspecified level, too.

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

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!

I've learned to use simple solutions as complex solutions are quite fragile.

Rene