[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00)
Here is an example of the authoritative data we're trying to get at, copied
from ITU Bulletin 901:
Rwanda (country code +250)
Communication of 9.I.2008:
The Agence Rwandaise de Régulation des Services d'Utilité Publique, Kigali,
announces the current National Numbering Plan (NNP) of Rwanda. A new
numbering plan is under preparation and will be communicated as soon as it
is available.
Country code +250
International prefix 00
Overview:
Minimum number length (excluding the country code): six (6) digits
Maximum number length (excluding the country code): eight (8) digits
Details of numbering scheme:
(1) (2) (3) (4) (5)
N(S)N (National (Significant) Number) N(S)N
number length Usage of E.164 Number Operator Additional
information
Maximum
length Minimum length
5YXXXX
5YZXXX or
5YZXXXXX 8 digits 6 digits Geographic number for fixed
telephony services Rwandatel Digit ?5? identifies the Rwandatel
company: Y and Z identify the regional base used in giving telephone
numbers. Y, Z and X form the Subscriber Number (SN).
05XXXXXX 8 digits 8 digits Non-geographic number for
digital mobile telephony services
(e.g. CDMA) Rwandatel ?05? digits identify the Rwandatel company
and then X forms the Subscriber Number (SN).
06YZXXXX 8 digits 8 digits Geographic number for fixed
telephony services Artel ?06? digits identify the Artel company; Y
and Z identify the regional base used in giving telephone numbers. Y, Z and
X form the Subscriber Number (SN).
08XXXXXX 8 digits 8 digits Non-geographic number for
digital mobile telephony services
(e.g. GSM) MTN Rwanda cell ?08? digits identify the MTN Rwanda cell and
then X forms the Subscriber Number (SN).
03XXXXXX 8 digits 8 digits Non-geographic number for
digital mobile telephony services
(e.g. GSM) MTN Rwanda cell ?03? digits identify the MTN Rwanda cell and
then X identifies the Subscriber Number (SN).
It's possible to reflect that in an enum tree, but it's certainly not the
only way.
This is all the information you need to get a call routed to the correct
domain in country code +250. There isn't, but if there was a block that was
6-8 digits, with the last 1 or 2 digits determined by the end domain, the
information needed to route the call to the end domain would be in this
table.
The problem I have with doing this in enum is that we need the data for all
countries to run any form of routing: public, infrastructure or private
ENUM, TRIP or any other way. If there is no user enum deployed for any
country, we need this data anyway. We need a way to encode the above data
and distribute it for every country instead of the ITU bulletin that the
table is copied from. That is the problem. The shape of a non existent
public enum tree has nothing to do with that.
Another little tidbit. Often, the number plan administer announces a change
before the change is in effect. They include an effectivity date. Some
times, they communicate that there is a period of time where old and new
versions of the number plan will work. Whatever we do has to communicate
that data.
One way to look at the disagreement we are having is that I'm interested in
providing a way for some entity building an ENUM T1 to know what the shape
of the T1 is. You are interested in communicating to a user of this T1 how
to use it. You have to solve my problem before you solve yours.
I think once you solve my problem, everyone can use that solution pretty
effectively, and they won't need you to solve it. That may not be the case,
but I think we have to solve my problem first. Then we can see if it works
for everyone.
Brian
-----Original Message-----
From: Jay Daley [mailto:jay at nominet.org.uk]
Sent: Wednesday, April 09, 2008 6:14 PM
To: Brian Rosen
Cc: enum at ietf.org
Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New
draft - draft-bellis-enum-send-n-00)
Brian
> You are missing the point.
>
> The number of digits need to route the call to the correct domain is
> determined by a more static database which is not subject to public enum
> implementations.
No I'm not missing the point - it the incorrect assumption in what you are
saying above that I am disagreeing with. The number of digits needed to
route a call is not determined by an independent static database, it is
determined by the numbers provisioned in the ENUM trees, which in turn
creates the structure of that tree. This draft is a way of describing
that structure.
> Once you get to the domain, there is more routing to do. I would prefer
> that the domain handle that directly. That is, after all, how SIP
works.
> We route to the domain using one set of mechanisms. Then the domain
uses
> another set of mechanisms to route to the device.
>
> Right now, route to the device with variable length TNs is .001% of the
> problem. The other 99.999% is route to the domain. I think a simple
> solution to that would be great. I don't think that is an ENUM
solution.
I have no objection to anyone working on that further routing. But nobody
in their right mind who runs a user ENUM tree (or other ENUM tree) would
run a SIP server that just deals with that further routing and then add a
NAPTR for that SIP server at every non-terminal point in their ENUM tree,
if they could use send-n instead.
Jay
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum