Subject: [Enum] User ENUM vs Operator ENUM

From: "Stastny Richard" <[email-masked]>
Date: Sat, 12 Jun 2004 05:49:48 -0400

Steve wrote:

>As to your proposed agenda item 1, I believe that the direct should be:

>1a: What are the issues/problems that need to be addressed?
>1b: What are the reasons that "Public" ENUM can't solve them?

>I've never gotten any answers on those questions from my European colleagues that seem to be more involved in the >"Carrier" ENUM activities on that side of the pond.

You are correct insofar that your  "European colleagues" are more involved in "Carrier" (infrastructure, operator)
ENUM activities, because ETSI is trying to write a TS on this issue.
 
Sorry for answering a bit late, but I was yesterday at a meeting on this issue hosted by a Telco operator,
which implies that one is incommunicado Internet-wise ;-)
 
A short recap of  the status:
 
On one side you have User ENUM, which means this is End-user to End-user on the 
Internet. This implies that the calling user has direct access to the data in the DNS and 
also can do something with the retrieved data. It also implies that the called user
has direct or indirect managing access to the data in the DNS, especially he is provided
by his VoIP SP with a public accessible URI. It also means that you may use the information
provided in DNS for establishing communication, but if you know the URI you also
be able to establish the communication without using ENUM. ENUM is only necessary
to establish communication form the PSTN because you cannot enter a URI. It also
implies that there is zero termination charge to reach the called party. User ENUM
should be implemented in e164.arpa, but could also be implemented in other trees.
If in all trees the rule is obeyed that only the entity having the right to use
the E.164 number in the first place is the domain name holder, a later 
merging of the trees is not a problem.

On the other side you have operator ENUM: Operator ENUM is used to route
calls between operators - as the name implies, and NOT end-user. So operator
ENUM is all about linking controlled VoIP islands together. Other buzzword coming into my
mind is walled-garden, termination charges, hiding of end-user
information, session border controllers, NGN, cable-networks, IMS, 3GPP, MMS routing
etc..
 
User ENUM and operator ENUM are orthogonal to each other regarding opt-in
numbers, because operator ENUM can really be considered as part ot the PSTN.
For opt-in ENUM entries, one looks first in User ENUM, and if no entry is
found, he looks in a (or more) Operator ENUM trees, and finally as a last resort
he dumps the call to the "real" PSTN.  Done correctly, he should find the information
in operator ENUM finally always, especially if no conventional PSTN exists in 5-10 years.
 
On hack in this is the now created ENUM-enabled number ranges which can only
be resolved in User ENUM.
 
For operator ENUM the same applies as for User ENUM: 
If in all trees the rule is obeyed that only the entity having the right to use
the E.164 number in the first place is the domain name holder, a later 
merging of the trees is not a problem (but see high-jacking below). 
The only difference here is that
the domain name holder in this case is the operator, because there
is nor opt-in from the user, which also implies that either the information
is not in a public DNS, not in a public accessible DNS, or if in a public
accessible DNS, the information does not disclose any "privacy" information.
 
This means you may find in a domain related to a number e.g. 
+4319793321 only NAPTRs in the form e.g. 
sip:+4319793321 at provider.net,  which is in essencey
all what operator ENUM is about:
finding the operator or service provider hosting the number.
 
One word about high-jacking of numbers: in User ENUM high-jacking
is an issue because the number exists on the PSTN and on the Internet,
at least for opt-in numbers (not for ENUM-enabled numbers).
 
In operator ENUM high-jacking of numbers would not be a problem,
if zero-termination would apply and also if calls would only be routed 
to the destination network (no transit function).
 
This means, if everybody would put in operater ENUM only the numbers
he is hosting (and why should he put in other numbers, because he cannot
terminate it), as said above, the whole could start out with 10 differnt trees,
but merging trees would not be a problem, because there would be
no "domain name disputes".
 
There is only one problem with this: operator ENUM created by con-federations
will also be used for transit routing:
 
Take the following (virtual) example: US-cable operators aggree to use
a common "private" database to route calls between numbers hosted by
these cable operators directly between also privatly agreed upon IP-based
Point of interconnect. All other calls will be routed to the "PSTN".
 
Now one  UK-cable operator joins the club. The easiest thing to do is to route
ALL calls to +44 to this cable operator via the PoI of this UK operator. So ENUM
is used to find the terminating network (for the numbers the UK operator is 
hosting himself, and as a transit (bypass) network for all other UK-numbers.
One could call this legal high-jacking ;-)
 
The problem only starts here of another UK operator is joining the club
or if two trees are merged.
 
To summarize: 
 
-User ENUM and operator ENUM are in principle
orthogonal and may co-exists. 
 
-Starting with more than one tree in both of them is not optimal, but
causes problems later when merging only if number or number-ranges 
are high-jacked (legally or illegally). So having a parking tree besides
e164.arpa for user ENUM is NOT a problem if some minum rules 
are obeyed
 
If  User ENUM or Operator ENUM finally survives is not decided
by ENUM, it will be decided in the battle between NGN vs Internet
(or Zero termination vs Termination charges)
 
best regards
Richard

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sat, 12 Jun 2004 11:10:13 -0400

Hi Folks,
 (recipients pruned - I suspect you're all on the ML :)
As someone who was also in Telco-purdah and so only with Internet 
access today,
I'm impressed with the level of discussion on the ML in the last couple 
of days.

I second//third the comments on the VON - it was hectic, and interest 
in ENUM or
ENUM-like systems is strong.

As James S. says, the issue for some of the ITCSPs (i.e. lots of 
people, now that
the bureaucracy has processed the EU Framework so that it's finally 
embodied in real
live forms one can fill in and send off) is that one can get PSTN 
number ranges, but
ENUM availability is at best erratic - bizarre but true.
Note - there are a LOT of small ITCSPs "out there", so ENUM for 
interconnect
is a "slam dunk" - it's about the only realistic way to do this stuff.

One of the issues that came up both at the VON and afterwards is the 
way that
sets of SPs can form into consortia/confederations/clubs. We discussed 
the concept
of a "three ring circus" to try to classify interoperation modes.

SP clubs in the "inner ring" allow "direct" SIP connections from one 
member's servers
to a customer of another member. One might expect an example of this to 
be a single Company
that provides service in more than one country (but judging from the 
way some such companies'
divisions interwork, maybe not :).

The next ring is a confederation of SPs who use an "IP Point of 
Interconnect" for sessions
between members of the club, and so expose the Contact/Gateway 
information for E.164 numbers
to members, but not to others (or to "the public"). Note - this differs 
in that the calls still
traverse defined gateways rather than going "direct", but ENUM is still 
a pretty obvious choice
to identify these IP POIs to other 'Club members'.

Finally, in the outermost ring, the SPs don't use ENUM so all sessions 
have to go via a standard
SCN/PSTN interconnect - the fact that a customer is "on VoIP" is no 
one's business. A degenerate
case is a single Operator that uses ENUM "in-house" to route their 
sessions, but doesn't expose
this to anyone else. From outside this barrier, it's a standard SCN 
provider.

Now... note that in the middle and outer ring, there's no full mesh to 
end customers, so sessions
traverse defined border elements. This is (I believe) tied in to 
Richard's comments that Infrastructure
ENUM identifies the destination network and so supports routeing the 
session rather than delivering
the session to the end user.

user ENUM, OTOH, is about selecting between different sessions and/or 
delivering an end user's choice
of URI  - this is not the same as iENUM.

Thus it's perfectly possible to have both user ENUM domain content and, 
in addition, Infrastructure
ENUM domain content, and they need not be the same, even when queried 
from the same place. For example,
I could have a user ENUM domain for +441794833000 with a NAPTR that 
points to tel:+441794511603.
The originating end user (or the system that acts as their agent) could 
decide to place a call to this
number, and make a request of "the Infrastructure" to set up the call.
Then, the SP might look up this destination number in Infrastructure 
ENUM to find out how to route it,
and could find that it's possible to send it to an IP POI, or even 
directly to a SIP URI (as this is a
"VoIP customer" and the SP is part of a close-knit club that allows 
such direct connection).
I'd expect the "CSP of record" for +441794511603 to have complete 
control over population of the content
for the Infrastructure ENUM domain. Conversely, it's perfectly possible 
for there to be a user ENUM
registration for this that might include content that the originating 
user doesn't want to use in this
case; nevertheless, it's still under the control of the customer who is 
provided service via this E.164
number - NOT their SP.

In short, whilst split horizon will almost certainly be useful in the 
three-ring circus of SP clubs,
it's very tricky to use one tree for both user *and* Infrastructure 
ENUM as there may be two sets of
data for the same ENUM domain (even from the same querying node's 
perspective).

One last joker in the pack:
It's possible/probable that the Infrastructure ENUM content includes 
Routing numbers. Not only are these
of no earthy use to an End user as they can't place a call using them, 
they may not be much use for every
SP either, even if they're exposed to all Operators.
For example, a RN is often not usable outside a particular country. 
Thus it's important that such entries
include the "phone context" as well, so that processing at an 
originating SP is easier - it must be given
enough information to know that it can't use this entry directly, but 
needs to find a transit that can.

... and with that, back to your normal service (and back to the BCP for 
me).

all the best,
  Lawrence
On 12 Jun 2004, at 10:45, Stastny Richard wrote:
A short recap of  the status:
On one side you have User ENUM, which means this is End-user to 
End-user on the
Internet. This implies that the calling user has direct access to the 
data in the DNS and
also can do something with the retrieved data. It also implies that 
the called user
has direct or indirect managing access to the data in the DNS, 
especially he is provided
by his VoIP SP with a public accessible URI. It also means that you 
may use the information
provided in DNS for establishing communication, but if you know the 
URI you also
be able to establish the communication without using ENUM. ENUM is 
only necessary
to establish communication form the PSTN because you cannot enter a 
URI. It also
implies that there is zero termination charge to reach the called 
party. User ENUM
should be implemented in e164.arpa, but could also be implemented in 
other trees.
If in all trees the rule is obeyed that only the entity having the 
right to use
the E.164 number in the first place is the domain name holder, a later
merging of the trees is not a problem.

On the other side you have operator ENUM: Operator ENUM is used to 
route
calls between operators - as the name implies, and NOT end-user. So 
operator
ENUM is all about linking controlled VoIP islands together. Other 
buzzword coming into my
mind is walled-garden, termination charges, hiding of end-user
information, session border controllers, NGN, cable-networks, IMS, 
3GPP, MMS routing
etc..

User ENUM and operator ENUM are orthogonal to each other regarding 
opt-in
numbers, because operator ENUM can really be considered as part ot the 
PSTN.
For opt-in ENUM entries, one looks first in User ENUM, and if no entry 
is
found, he looks in a (or more) Operator ENUM trees, and finally as a 
last resort
he dumps the call to the "real" PSTN.  Done correctly, he should find 
the information
in operator ENUM finally always, especially if no conventional PSTN 
exists in 5-10 years.

On hack in this is the now created ENUM-enabled number ranges which 
can only
be resolved in User ENUM.

For operator ENUM the same applies as for User ENUM:
If in all trees the rule is obeyed that only the entity having the 
right to use
the E.164 number in the first place is the domain name holder, a later
merging of the trees is not a problem (but see high-jacking below).
The only difference here is that
the domain name holder in this case is the operator, because there
is nor opt-in from the user, which also implies that either the 
information
is not in a public DNS, not in a public accessible DNS, or if in a 
public
accessible DNS, the information does not disclose any "privacy" 
information.

he is hosting (and why should he put in other numbers, because he 
cannot
terminate it), as said above, the whole could start out with 10 
differnt trees,

There is only one problem with this: operator ENUM created by 
con-federations
will also be used for transit routing:

Take the following (virtual) example: US-cable operators aggree to use
a common "private" database to route calls between numbers hosted by
these cable operators directly between also privatly agreed upon 
IP-based
Point of interconnect. All other calls will be routed to the "PSTN".

Now one  UK-cable operator joins the club. The easiest thing to do is 
to route
ALL calls to +44 to this cable operator via the PoI of this UK 
operator. So ENUM
is used to find the terminating network (for the numbers the UK 
operator is
hosting himself, and as a transit (bypass) network for all other 
UK-numbers.
One could call this legal high-jacking ;-)

are high-jacked (legally or illegally). So having a parking tree 
besides