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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 6 Dec 2005 13:10:43 -0500

Klaus,

It has to do with the difference between re-targeting and routing.  Is
the point of interconnect the real target of the request or just a
waypoint in the route to get to the target?  In the User ENUM case, it
seems as though the addresses are all about the target users and their
devices.  But, here it seemed a bit different.  It is a route through an
intermediate point.  It seems like the semantic and syntactical element
would be more coherent and no more complicated.  Thus, I posed the
question.

Mike

> -----Original Message-----
> From: Klaus Darilion [mailto:[email-masked]] 
> Sent: Tuesday, December 06, 2005 11:48 AM
> To: Stastny Richard
> Cc: Michael Hammer (mhammer); [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Sip] SIP AoR, tel and ENUM
> 
> Stastny Richard wrote:
> > 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
> > ...
> > 
> 
> 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
> 
> 
> 
> > 
> >>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
> > 
> > 
> 

_______________________________________________
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: Wed, 07 Dec 2005 09:33:02 +0100

Hi Michael!

As there are some concerns about the terminology. Thus I will use AD 
(adminsitrative domain, from the SPEERMINT charter) as synonym for ITSP, 
carrier, telco, VoIP enabled enterprise .....

> would be more coherent and no more complicated.  Thus, I posed the

I can not really see a difference to user ENUM. There is only one 
Infrastructure ENUM tree. Thus, all ADs which query this tree will get 
the same URI back from ENUM. Thus, the ingress point announced by the 
receiving AD is the same for all outgoing ADs.

Further, if the outgoing AD does not send the request directly to the 
announced ingress point (maybe no peering relationship), but to an 
intermediate point (transit provider, clearinghouse, ....), this routing 
is different for each AD. Thus, such kind of routing information can not 
be in ENUM.

Once the request reaches the ingress point of the receiving AD, there 
will be further routing inside the receiving AD. Maybe the route is for 
example:
  1. ingresspoint1.ad
  2. accountingbox.ad
  3. mainproxy.ad
  4. .....

Publishing such a route in ENUM makes no sense, as the route is the same 
for all incoming requests. Thus, the route should be applied by the 
previous hop. That means, ingresspoint1.ad knows that it should formward 
to accountingbox.ad, and so on.

IMO, ENUM is a simple routing and re-targeting in one step. If complex 
re-routing and re-targeting is required it should be done by the 
receiving AD. The outoing AD is not interested in the internal routing 
of the receiving AD.

Maybe you can give me an example of a scenario were my model does not fit.

regards
klaus