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

["Stastny Richard" <]

Jim writes:
> I think there's general 
> consensus that end users should not see core telco routing data.

Here we are at the point: why should they?

The basic question discussed here is VoIP (aka SIP) on the public
Internet
and VoIP (aka NGN - or NWOS - new wine in ols skins - Lawrence) in
walled gardens.

If you implement VoIP on the Internet you basically need SIP URIs (AoRs)
and proxies
(SVR records in the DNS) to reach this SIP AoRs. If you do not have
these ENUM in e164.arpa
Is completely useless. If you have these, you basically do not need
telcos for routing
E.164 numbers.

If you implement VoIP in NGN walled gardens you basically have two
choices:
a - they use an extranet (e.g. GRX from GSM-A) to interconnect between
the walled gardens
the choice of the routing mechanism (ENUM or something else)
in this case is purely a decision of the extranet provider (e.g. GSM-A) 
and also limited to the club. End-user will not have access to these
data.
What you need here is a mapping E.164 number to operator.

b - they use the public Internet to interconnect, so they need some kind
of
public AoRs (URIs) (e.g. +xxx@localhost )to address the ingress border
elements 
(these finally have public IP-adresses). So they may use some kind of
ENUM in a
commonly agreed upon tree, which could be any root e.g.
e164.stastny.com)
Subscribers may may be able to query the tree or not, but it will be
useless
because they cannot access the border elements directly.

The bsaic question here is: do the carriers agree on ONE tree or will
there be a wood
of trees? But this is not a big issue if all con-federations have a
basic rule: any
participating carrier is obliged to enter only E.164 numbers he is
serving. Then
automatically not overlaps exist between the trees (expect carriers
participating 
in more then one tree) and therefor the trees could be merged easily
later.

Back to the original question:
> I think there's general 
> consensus that end users should not see core telco routing data.

Normal end-users give a s**t anyway about technical details if making
a call, so why should the be prevented to see core telco routing 
data. They real problem of telcos is to prevent OTHER TELCOS to see
their data, primarily to see how many subscribers they really have ;-)

They funny thing here is that competitors know these facts anyway, but
it's nice to pretend to have secrets.

Now we are at the basic problem: 
Is there a way to feed data into a database
used by competitors to find out which numbers a given telco hosts
without
disclosing to the competitors which numbers this telco hosts?

A cretan says: all cretans are liars. True or false?

This is the problem we have to solve ;-)

-richard



> -----Original Message-----
> From: Jim Reid [
	    
	    
] 
> Sent: Tuesday, December 14, 2004 9:48 PM
> To: Richard Shockey
> Cc: Stastny Richard; Marco bernardi; Andrzej Bartosiewicz; 
> Carsten Schiefner; enum-wg@localhost
> Subject: Re: AW: [enum-wg] COCOM & ENUM ... 
> 
> >>>>> "Richard" == Richard Shockey richard@localhost 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?
>