[Enum] SIP AoR, tel and ENUM

["Stastny Richard" <Richard.Stastny at oefeg.at>]

Folks,

This post is primarily to SPEER, but since it also concerns ENUM and SIP
I cross-post it.

I need (urgently) some guidance on the question what SIP URIs to
use in Infrastructure ENUM.

User ENUM as defined in RFC 3761 provides a mapping from E.164 numbers
to SIP URIs for primarily for end-users. So what you get back is the
AoR pointing to the destination SIP server.

If you get something back on the ENUM query such as
sip:Richard at stastny.com,
this is definetely an AoR. Because of privacy reasons, more and more
people
start using SIP URI such as
sip:4319793321 at provider.net or (an AoR)
sip:+4319793321 at provider.net;user=phone (IMHO not an AoR) or even
sip:+4319793321 at provider.net

IMHO the last one should not be used, and some guidance
is also needed here. but it only concerns the destination
server and if the destination servers can deal with it, fine.

Now with Infrastructure ENUM (and especially in combination
with private ENUMs) the situation is different.

The purpose of Infrastructure ENUM is according to the
re-chartered ENUM WG "to discover points of interconnection necessary to
terminate communications sessions identified by a E164 number,
in addition to identifying end point protocols and services."

This translates to: Infrastructure ENUM does not necessarily contain
end-point information (AoR), but routing information. Routing, in my
definition here, is basically to provide you with the information what
the next hop is.

A very common scenario is the following one: a walled garden network
is using private ENUM to detect the border element for a given number,
Some border element may lead to another private (extranet), using
a federated ENUM for this number, another may be connected to the 
Internet using public Infrastructure ENUM for another number.
Public Infrastructure ENUM is giving back the ingress border
element, which in turn uses private ENUM again to find the
SIP server hosting the user with this number.

In addition, again for privacy reasons, in most cases the above
mentioned SIP URIs containing E.164 numbers are used.

This raises two issues, an architectural one and a BCP one:

To principally different scenarios are possible

Scenario A

ENUM is providing ONLY the mapping from the E.164 number
to an AoR. (= name to address mapping)
The above described routing between the networks
to find the destination network is done via the AoR. How this
is done is completely within the scope of SPEER.

Note: this is the only future proof way, because a user may
use the AoR in the first place and then the routing MUST work
anyway. So any additional routing information in ENUM would
be duplicated and therefore error-prone.

I propose in addition to use in this case a SIP in the format
sip:4319793321 at provider.net, to clearly indicate that this
has no relationship to an E.164 number.

Scenario B:

This is the scenario proposed in most current implementations
and also in the RFI on ENUM popping up everywhere. The reason
is that most scenarios currently concentrate solely on
the peering with E.164 numbers and completely forget the
peering with SIP URIs

The ENUM entry is giving you the next hop: This is in case
of the walled garden originating network either the server
hosting the end-user or the egress border element (e.g. IBCF,
THIG, or whatchamacallit). This element is again querying another
kind of ENUM, getting back the ingress border element of the
destination network (or even of a "transit" L5 network), and so
on. The ingress border element is the again calling its private ENUM
to finally find the hosting server.

Note: I have a sub-question here: Some implementations are
even proposing here to skip the SRV query and directly pointing
to the SIP server(s) in ENUM. Does this make sense?

If this scenario is used, I propose to use only SIP URIs
in the format
sip:+4319793321 at provider.net;user=phone or better
SIP:+4319793321 at sbc.prov.net; user=phone

to clearly indicate that this is still basically a 
tel: URI combined with a routing info and that it may 
be used in another ENUM query.

My questions to the crowd are the following:

1. is this proposed use of SIP URIs within the context
of ENUM ok?

2. What should be the preferred scenario for
VoIP peering? 
Is some kind of combination between the scenarios
feasible? 
And what are the arguments pro and con?

I consider the outcome of this discussion as
substantial input to the deliverables of SPEER,
but some first guidance is urgently required now,
because many entities are making basic decisions
in this direction NOW.

Please also excuse and correct incorrect use of terminology.

Regards
Richard Stastny









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