AW: [enum-wg] COCOM & ENUM ...

>>>>> "Richard" == Richard Shockey <richard at shockey.us> writes:

    Richard> HUH are you kidding ... its is because of the basic and
    Richard> orthogonal conflict between what carriers need and want
    Richard> and what end users need and want.

I'm not convinced that really is (or will be) the case. Alice is an
end user with SIP applications that lookup E.164 numbers in public
e164.arpa tree to find SIP gateways. Fast-forward a few years. Bob's a
telco doing VoIP and SIP and using DNS lookups of E.164 numbers to
route calls in his net and to other operators. What's the difference?
The applications are both using the DNS to figure out how to find the
right SIP server for some VoIP session (or whatever). Carol sells SIP
server and client software. Will she want to develop, sell and support
different versions of the same thing to Alice and Bob? Meantime, what
if Bob wants to dump calls from his network to Alice on Alice's
internet SIP server so that he doesn't have to pay termination charges
to Alice's telco?

    Richard> Either bifurcate the tree at Tier one into two non
    Richard> terminal NAPTR records (public & carrier)..which BTW will
    Richard> break SIP applications since there is no standards any
    Richard> where on how to deal with this.

Maybe there should be a standard on this? :-) Though the bifurcation
could also be realised with split DNS.

    Richard> Two merge T1 and T2 into the national registry which
    Richard> makes the registry operator the central repository for
    Richard> ALL SIP routing data for both the carriers and end
    Richard> users...which at least preserves the existing model of
    Richard> the DNS responds with an "answer" ..the carriers can
    Richard> still use non terminal records but normal SIP CUA's would
    Richard> simply ignore them.

This is too awful for words. I think there's general consensus that
end users should not see core telco routing data.

    Richard> Three have two entirely separate trees ..e164.arpa for
    Richard> number holders e164.int for carriers.  The .int tree
    Richard> could be designed to look into apra for answers it is not
    Richard> authoritative for.  Problem solved.

This gets very ugly very quickly IMO. Operationally such setups would
be very brittle and near-impossible to debug.

    Richard> oh no we're not going down that rat hole of split DNS

It's no more of a rat hole than having yet another domain name with
funky forwarding/fallback on failure modes between the 2 (or more?)
domain names that you seem to favour. I suspect these could be much,
much worse to administer and operate than a split DNS solution. It
would be good to get hard data on the pros and cons of both
approaches. And any others for that matter. Even better would be to
get that data before a lasting decision is made. :-)

    Richard> you forget the basic consumer or PBX edge ENUM resolver
    Richard> has no need to see the carrier data.

I've not forgotten that at all. I think you have misunderstood
me. Well, I have an accent.... :-)

Suppose some company is writing ENUM-aware telephony software that
needs to figure out which SIP server to use when terminating a call
for some E.164 number. [Note the deliberate hand-waving about where
that software lives or which net the device is on.] How many DNS
lookups and domain names is it going to need to do that? From a
developer's perspective, how will the software know which net it's in
so it knows which domain names to try (and in what order)?

    >> A centralised database could well mean telcos expose their
    >> customer and call routing data to each other. Which is unlikely
    >> to get much acceptance.

    Richard> Well then you have argued that LNP databases dont work
    Richard> and I have it on good authority that they do :-)

You would say that, wouldn't you? :-)

Does a number portability database disclose to TelcoA how TelcoB
routes calls around its networK?