[Asterisk-Dev] DUNDi (Was: A crazy idea... Skype channel
in Asterisk)
Kevin P. Fleming
kpfleming at starnetworks.us
Wed Oct 20 12:40:12 MST 2004
Wolfgang S. Rupprecht wrote:
> My gut reaction is that this seems like an awful lot of new code just
> to do something that an open ENUM-like DB would do. If the problem is
> that none of the current ENUM administrators will delegate, then
> *that* is the problem that needs fixing. Creating a new protocol
> simply to get around the delegations problems is a bit over the top.
But that is _not_ the entire problem, have you read the DUNDi whitepaper?
Here is a simple example where ENUM breaks: I am an ITSP, and I support
LNP. That means customers can bring numbers to my system. So, I get a
new customer, and they bring over +1-555-555-1212 to my service. Note
that I do not currently service _ANY_ other numbers in +1-555-555.
How, and who, would delegate to me the control I would need to manage
the NAPTR record for this number? How many levels of delegation would
there be, and who would be those "registrars"? What if the +1-555-555
number block was originally assigned to the ILEC in my area, and they
are also the registrar for all of +1-555-555 in e164.arpa? I then have
to convince them to let me manage this _ONE_ record in the zone that
they otherwise control?
Yes, this the same problem that exists for LNP on the PSTN in the United
States, but that is solved by having a single, government-authorized
authority to manage the database (although it's still a major amount of
work to port numbers, and it takes forever). What DUNDi wants to avoid
is that situation occurring again in E.164/VOIP space.
DNS does not lend itself to lots of little delegations (for individual
NAPTR records), and it doesn't have any reasonable way to be extended to
support that. It's a pain the in rear just to get a delegation to handle
the reverse DNS for a /27 (or smaller) IP address block, just imagine
what it would be like for a _single record_, and when the authority
controlling the upper level zone is a direct competitor of yours.
More information about the asterisk-dev
mailing list