About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

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

  • To: "Stastny Richard" < >
    "Jim Reid" < >
    "Richard Shockey" < >
  • From: "Marco bernardi" < >
  • Date: Wed, 15 Dec 2004 11:06:52 -0000
  • Cc: "Andrzej Bartosiewicz" < >
    "Carsten Schiefner" < >
    < >

Richard,

Very, very unlikely  we have a single tree for operator ENUM. Operators will
never be able to agree. And perhaps it  is right - different trees may serve
different applications, different operators' communities with different
policies.

Not sure how we can enforce across different communities/trees  the rule
that  an operator can only insert his numbers - A job for ITU-T?

marco
----- Original Message ----- 
From: "Stastny Richard" <Richard.Stastny@localhost
To: "Jim Reid" jim@localhost; "Richard Shockey" richard@localhost
Cc: "Marco bernardi" <marco.bernardi@localhost; "Andrzej Bartosiewicz"
andrzejb@localhost; "Carsten Schiefner" <enumvoipsip.cs@localhost;
enum-wg@localhost
Sent: Wednesday, December 15, 2004 9:19 AM
Subject: RE:: [enum-wg] COCOM & ENUM ...


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





<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community