Subject: Re: [Sip] SIP AoR, tel and ENUM

From: "Stastny Richard" <[email-masked]>
Date: Tue, 6 Dec 2005 16:47:29 +0100

Mike wrote:

>Before going down this path too far, can we ask where the results of the
>ENUM queries will go in the SIP message to control routing?
>Hypothetically, the egress and ingress gateways could be identified in
>Route headers rather than in the Request-URI.  An external ENUM dip and
>an internal ENUM dip might lead to something along the lines of:
 
Correct,
 
Jonathan proposed this some time ago, but this thread somewhere stranded
 
So basically an interneal ENUM entry of

sip:[email-masked];user=phone
 
would result in

INVITE tel:+17775551111 SIP/2.0
...
Route: <sip:egress11.provider3.com;lr>
 
an the external ENUM entry would be
sip:[email-masked]
 
result in
Route: <sip:ingress39.provider17.com;lr>
 
This is basically what I am after
...

>I am also suggesting that the ENUM result be an AoR, since one might
>want some reliability in choosing which server in the gateway cluster to
>go to based on further DNS queries, load balancing, etc.
 
Now this is in contradiction to the above
 
Richard

>Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stastny Richard
> Sent: Tuesday, December 06, 2005 4:54 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Sip] SIP AoR, tel and ENUM
>
> 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:[email-masked], this is definetely an AoR. Because
> of privacy reasons, more and more people start using SIP URI
> such as sip:[email-masked] or (an AoR)
> sip:[email-masked];user=phone (IMHO not an AoR) or
> even sip:[email-masked]
>
> 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:[email-masked], 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:[email-masked];user=phone or better
> SIP:[email-masked]; 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
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Klaus Darilion <[email-masked]>
Date: Tue, 06 Dec 2005 17:48:26 +0100

> This is basically what I am after

Hi folks.

What is the benefit of splitting the ENUM result (the SIP URI) into a 
Route header and into a request URI?

IMO there should be no semantic for the internal routing (the routing 
from the main proxy to the egress proxy). This should be out of scope of 
all WGs. Also the internal routing of the ingress provider should be out 
of scope. The ingress provider should have SIP URI which can be used to 
address its customers.

If this URI is sip:[email-masked] or 
[email-masked], or sip:[email-masked] is the 
ingress provider's choice. Maybe the ingress provider also allows all of 
the previous SIP URIs to reach a certain user. The incoming provider 
just has to make sure that these SIP URIs map to the corresponding user 
(to the user's AoR). If this user also has an E.164 number which is in 
I-ENUM, then it's again the ingress provider's choice which URI to put 
into the NAPTR.

IMO there should not not be any semantics how to create a request URI 
and a pre-loaded route set of the SIP URI received from ENUM. The egress 
proxy sends the request to the ingress proxy in the format choosen by 
the ingress provider (e.g. publish via ENUM or an business cards).

We should not complicate things. I do not see any problems with this 
simple approach. If there are some problems, please correct me.

regards
klaus

---

From: Thilo Salmon <[email-masked]>
Date: Tue, 06 Dec 2005 20:05:35 +0100

Richard, Klaus, et al.

Apparently, I have missed an important developlement lately. 

> Route header and into a request URI?
[...]
> of scope. The ingress provider should have SIP URI which can be used to 

I absolutely second that statement. If for any reason (we all have
enough a vivid enough phantasy to imagine a good reason, I suppose) an
ingress provider wishes to feed a different set of SIP URIs to each and
every of his egress partners, he should not be stripped of this option.
The scenario I have in mind is one in which an ingress provider chooses
to encrypt the user part of all his SIP URIs with a key uniquely assigns
to his egress partner.

Just as Klaus I feel this complicates things and takes authority over
internal adressing away from the ingress provider for no reason apparent
(to me).

Thilo