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

At 03:48 PM 12/14/2004, Jim Reid wrote:

> >>>>> "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?

a great deal .. network operators do not generally or historically expose 
internal network architectures or border ingress elements into something as 
public as the DNS.

the general requirement I have been constantly told is that the result of 
the carrier TN2URI translation must not be publicly exposed or amenable to 
MiM attack and is generally hidden behind some  AA  which is why all the 
discussion on non terminal NAPTR records.

>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?

Of course not that is why the carrier record would be non terminal and 
require out AA in fact most of the architectures I see nearly have only 1 
URI for the entire network.  A huge wall of SBC's surrounding the VoIP network.

>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.

I do not agree on either point. SIP CUA's would all have to be redesigned 
to accept the new DNS structure ..I dont think that is acceptable.


>     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.

not if the URI is non terminal it only increases the requirements on the 
registry. The Tier 1 Tier 2 constructs were artificial in the first place 
to more balance the loads on the DNS and give end user more flexible 
options on controlling their NAPTR records.


>     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.

what are you talking about ..it would work perfectly well. End user CUA's 
do not need to see carrier data so they would never look into carrier.foo

but John is entirely right here the chances of carrier.foo getting off the 
ground are problematic though .MOBI did get through ICANN for some reason.


>     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?

only one ..if the software is edge based in the case of IP-PBX's or end 
user devices,  two if the proxy is licensed carrier based ( aka they issue 
phone numbers )

the definition of a carrier here is do you or do you not issue phone 
numbers..if you do not you will not have access to the carrier data and BTW 
that will not guarantee that the network provider will even give you access 
to the network .. the two carriers will have presumed to have a bi-lateral 
agreement in place covering inter network transactions.

> 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?

no only the destination endpoint or LRN in the case of the US and Canada. 
The carrier TN2URI scheme would not expose internal network archichecture 
either under the current designs I've seen ..only the location of the 
network Session Border Element or Controller. The terminating carrier 
network would still need to look up into its own routing tables ..and this 
is where I see SIP redirect all over the place..to find the actual end 
point routing data.

There is no doubt in my mind BTW that SIP redirect servers are being used 
to replicate the functionality of Service Control Points (SCP's) in the IN 
and that SIP is becoming the new NGN equivalent of TCAP.

But even exposing the LRN does permit the originating carrier to deduce a 
great deal about the called party network provider...in the first case you 
know the number has been ported and from the LRN tables you can find out 
who that carrier is.  In the US and Canada LIDB will give you everything 
else you want to know about the customer.



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<