Subject: RE: [Enum] ENUM Requirements

From: [email-masked] (Richard D G Cox)
Date: Thu, 2 Dec 1999 23:25 +0000 (Penarth Winter Time)

Larry Cox <[email-masked]> wrote:

> For numbers such as emergency call (typically 911 in North America) and
> toll free (800 or ..), the address may vary depending on the location
> where it is translated, the time of day, or other variables.

Most people would prefer to say the address associated with the number
does not vary; more commonly, the /routing/ or /translation/ will vary
according to several factors - such as include the location of the caller
(derived from the (network) A-number in the case of landlines, but also
from the radio site data in the case of mobile terminals). From a global,
rather than North American, standpoint, this is an important distinction.

I guess most people will be familiar with the proposals for more accurate
location of cellphones in the USA, but similar proposals are unlikely to
be replicated in other countries for a while, mainly due to the high cost.

> If the address associated with an E.164 number changes at 6 hour
> intervals (for toll free numbers this is not uncommon),

The situation is far more complex than that.  Globally, routings will be
changed on a dynamic basis according to the call loadings on individual
call centres.  A TV ad running in one time zone may create a sudden demand 
for answering resources from several call centres, while calls from other
locations may then be assigned different handling algorithms because their
otherwise-first-choice call centre is subject to a higher load than normal
at that time.

This can result in the routings changing on a minute-to-minute basis.

There is a need to define - unambiguously, but of necessity on an
address-by-address basis - how and where the routing decision-making
is to be implemented, and whether those routing decisions are to be
transmitted back down the line to be implemented at an earlier point.

> We should also not break the system that chooses a destination for
> the call based on the calling party number if this can be avoided.
> If I call an 800 number to order a pizza and due to the way the call
> is routed I find myself talking to someone in Los Angeles when I want
> my pizza delivered in Atlanta, the functionality of the system has
> been compromised.

While some services still see the location as a priority, in the majority
of cases the main requirement is speed of answer in a compatible language;
existing data networks can then transfer the order-taker's information to
the appropriate point of delivery.

Richard D G Cox

Mandarin Technology, Penarth, Wales: +44 29 2031 (voice) 1131 (fax) 1110.
Specialising in Telecommunications Interconnection and Numbering services.

_______________________________________________
enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Dec 1999 23:22:13 -0500

> transmitted back down the line to be implemented at an earlier point.

Remember, that the enum solution does not necessarily map a number to
the actual destination host. Rather, it maps it to a URL, which may be a
server that has the kind of logic you are talking about. For example, if
I dial 800-123-4567, this may get translated to
sip:[email-masked]. This turns out to be a large SIP
server that is programmed with time of day routing capabilities.

IMHO, what goes in enum is the most static piece of information
possible. It points you to the server that knows how to handle the
number further.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Albert Manfredi" <[email-masked]>
Date: Sun, 5 Dec 1999 18:42:16 -0500

It's interesting to me that enum has decided to go this way; i.e. to
combine the telephone number with the _name_ field of the DNS, and
to use the name part to implicitly identify the numbering _plan_
used for the telephone number.

One thing to worry about is that this could result in a lot of
different entries for any one telephone number, when only one E.164
would suffice? Is this not true? I mean, doesn't this potentially
list any globally unique E.164 number in the numbering plans of
150-odd countries?

For example, the local Rome number 3295887 would potentially be
listed as:

[email-masked]
[email-masked]
[email-masked]
[email-masked]

and a host of other options for each of the other numbering plans
extant.

Using the approach of a peer field for the E.164 number (a peer with
the name and the IP address), the onus of translating between
numbering plan and E.164 could be placed on the host. And the host
could, without too much difficulty, translate to its native
numbering plan based on the host's own address location?

(A mobile host could ultimately even use whatever local plan
applies, if it can be located in real time with something like GPS.
For example, it could have two options: use the local numbering plan
or use your "home" numbering plan.)

Bert
[email-masked]

P.S. For clarity, what I'm talking about is that the DNS would be
structured as follows (which it already is, I believe):

name field     IP address field    AESA field

A search on any one will return the other two. The AESA field can be
and encapsulated E.164 number, or other options exist. The name
field applies equally to AESA or IP addresses. At times, one or two
of the three fields might be blank.