Re: Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00)
"Brian Rosen" <[email protected]>
| Newsgroups | gmane.ietf.enum |
|---|---|
| Message-ID | <[email protected]> |
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:[email protected]] Sent: Wednesday, April 09, 2008 6:14 PM To: Brian Rosen Cc: [email protected] 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