[asterisk-users] Please some enlightment on ENUM !!

[Norbert Zawodsky]

SIP schrieb:
>
> By the time telephone operators began to be replaced by mechanical
> switches, open numbering plans became impossible to design for. Once
>   
Sorry, but there was definitely a time between retired human operators
and software switches.
And during that period, "our" open numbering plan worked perfectly well.
(And it still does)
> software switches came about and massive modifications to numbering
> plans became as easy as coding new exceptions and pushing them out to
> the millions of switches on the network, numbering plans had, largely,
> been codified to make for logical and understandable patterns.
>
>   
> ENUM has no issues with variable length numbering plans in its design.
> However, you have to stop calling it ENUM if it gets above 15 digits,
>   
AFAIR, there was no call for extending ENUM above 15 digits.
> since it's no longer a valid E164 numbering scheme as per the design
> there. ENUM is even applicable to local-only dialing plans, in which
> you'd run your own server, point your phones to that server as their
> primary ENUM server, and off you go.
>
> It's a very flexible idea as far as mapping E164 numbers to services go.
> However, once you get into the realm of registering with the IANA
> approved servers and trying to place your own ENUM DNS server into the
> mix, you can't start mixing local-only and public numbering schemes or
> things break.
>   
No one starts *mixing* local and public numbering scemes! It is very simple.

If you rent 1 line from, you'll get a number assigned. For example
+4311234567
You can place only 1 concurrent casl over that line (or 2, if it's an ISDN)
*Below* that number you can do what ever you want as long as the length
is <15: +4311234567[xxxxx]
If that is too less for your needs, you can rent a trunk of 10 lines
Then you'll probably get a number assigned like +431123456 and you can
use +431123456[xxxxxx] for your own neeeds.

And so on ....
> Austria is somewhat of a special case in which their numbering schemes
> are such that they allow the ad-hoc creation of additional virtual DIDs
> by simply tacking on digits to a valid DID. It's an open numbering plan,
> but from what I gather, it's a variation of the traditional open
> numbering plan in that each DID owner or designate gets to create his
> own additions instead of the telco approving all variable-length DIDs.
> This doesn't break any ENUM rules (unless the number exceeds 15 digits),
> but it does create a scenario in which it may become difficult to apply
> traditional ENUM tools to the scenario at hand with an attempt to get
> the results you're after.
>   
Sorry, but why? I don't understand your point. Why would it be difficult
for ENUM tools?
> For instance, if user X owns the number +4311234567, and he decides he
> wants to create a slew of virtual DIDs after that (+4311234567[01-99]),
> it doesn't violate the ENUM standard because all those numbers are fewer
> than 15 digits, and therefore all valid E164 numbers.  But the question
> was how to register them and if user X should create his own DNS server
> to handle the ENUM mappings. User X is free to do this, but then how is
> that server reached to map those numbers? There are certain 'accepted'
> ENUM registrars that have been IANA approved. User X could attempt to
> get his own approved, but even then, most existing ENUM tools would
> still not know of its existence, since it would be new.
>   
No! It's just like with any other name-to-IP resolution.
If you operate your own server, you just have to tell your ISP to route
DNS requests regarding *.YOURDOMAIN.TLD to your server.
Any ISP should do this if you want. (At least, here in Austria every ISP
does it)

It's the same with e164.arpa requests.

BTW, meantime I have alread implemented all that. My DNS server is up &
running.
I've chosen one of the existing registrars and payed him for registering
7.6.5.4.3.2.1.1.3.4.e164.arpa as "my" number at nic.at.
The registrar vaildated that this really is my number, and when this was
confirmed, did the registration.
Then I registerd my DNS server as the authorative master for the domain
*.7.6.5.4.3.2.1.1.3.4.e164.arpa
That's it. It works!
When ever anyone anywhere in the world does a ENUMLOOKUP(mynumber), my
server receives a request and (hopefully) sends the correct answer.

> Options are (as were provided) to register each of those numbers with an
> approved registrar (bulk registrations are often available), or in some
> way to convince a registrar to forward any and all requests to
> +4311234567[XX] to User X's DNS server. THAT might be tricky, but it
> creates a logical scenario in which there are 2 extra digits of a
> variable nature to pass off to the DNS server of the registrar and then
> forward to User X's DNS server. 
>
> However, when you get into the idea of creating additional digits, it
> may become tricky simply because of the way DNS handles requests.  No
> longer do you have a simple *.*.7.6.5.4.3.2.1.1.3.4.e164.arpa mapping
> zone, but you essentially need to create
> *.*.*.7.6.5.4.3.2.1.1.3.4.e164.arpa, and
> *.*.*.*.7.6.5.4.3.2.1.1.3.4.e164.arpa, etc, etc. just to handle all
> cases. And I'm not even sure that would work other than in theory (I've
> personally not tested such a scenario), so you're back to the fact that,
> while useful for a country full of people, a dynamic numbering scheme
> that does not correspond to standards cannot easily be handled by tools
> which are designed to comply with standards.
>
> And Austria's open numbering scheme is not standards. There are other
> open numbering schemes in a handful of countries, but they behave
> differently -- each with its own ideas on how they should be
> implemented. If you want to 'fix' ENUM to handle that, you end up
> creating a standard full of exceptions to handle the whims of random
> telecoms throughout the world, and it no longer becomes a useful concept.
>   
No, there's no need to 'fix' ENUM. Just the opposite! ENUM works
perfectly well just as it is.
Every country has to handle it's own e164.arpa subtree according to it's
numbering plan.
> Again. This is my opinion. Feel free to have a different one. :)
>
>   
I fully accept this as your private opinion. I just wanted to answer
some of your arguments...

Norbert