Subject: RE: [Sipping] Loose Routing Proposal

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 10 Sep 2001 14:37:38 +0100

From the 3GPP perspective I guess we thought the existing route header with
a preloaded route did all we want it to do. It was IETF participants who
identified shortcomings in the mechanism. A loose route may do things
slightly better, providing it does not allow one outbound proxies to omit a
subsequent outbound proxy.

We do not seem to be addressing the main half of the problem from the 3gpp
perspective, which is learning the URLs of the outbound proxies in the first
place, so that we can use them in the INVITE.

This is what the path proposal is 100% about. It takes place solely in the
REGISTER method and is a means of the outbound proxy or proxies informing
the local proxy of their URLs for outgoing calls, and of informing the final
outbound proxy of their URLs for incoming calls.

I seen none of the discussion of loose source routeing as an alternative
solution for path - or have I missed the point somewhere?

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Rosen, Brian[SMTP:[email-masked]]
> Sent: 	07 September 2001 12:44
> To: 	'Cullen Jennings'; [email-masked]
> Subject: 	RE: [Sipping] Loose Routing Proposal
> 
> I think the proposal is a good one.  I would specifically like to hear
> from the 3GPP folks if this would solve their problem.
> 
> Brian
> 
> > -----Original Message-----
> > From: Cullen Jennings [mailto:[email-masked]]
> > Sent: Thursday, September 06, 2001 10:32 PM
> > To: [email-masked]
> > Cc: Cullen Jennings
> > Subject: [Sipping] Loose Routing Proposal
> > 
> > 
> > 
> > At the last IETF there was some discussion of Dave's idea of 
> > allowing both
> > strict and loose routes to be intermixed in a single route 
> > header. I think
> > this would address the "How to Get Outbound Services from A 
> > Non-Local Proxy"
> > discussion and end up being more flexible and general than 
> > the path header.
> > 
> > The basic ideas would be to add a route-type tag that can be 
> > set to loose or
> > strict on with each name-addr in the route header. This would 
> > be taken as a
> > hint by the proxy on how it could route the message. Strict 
> > routing would
> > happen like normal, loose routing would have the proxy 
> > attempt to loosely
> > route to the to the specified location in the same way it 
> > would attempt to
> > route a message with this URI to this location. A key item on 
> > loose routing
> > is that the sending proxy can not pop a loose route, the 
> > receiving proxy
> > must do this when the message finally reaches the correct proxy.
> > 
> > To make this a little more concrete, Imagine the case where a 
> > UA knows it
> > must first go to an edge proxy called edge.visitor.com then 
> > it is going to
> > get outbound services from a proxy called vamp1.visitor.com 
> > then another
> > called vamp2.home.com. It has no idea of the proxies in 
> > between edge, vamp1,
> > and vamp2. Just to pretend, lets say that vamp1 knows that to get to
> > vamp2.home.com it must send a message to the proxy 
> > nat.home.com. The initial
> > UA could specify a route header like
> > 
> > Route: edge.visitor.com vamp1.visitor.com;route-type=loose
> > vamp2.home.com;route-type=loose
> > 
> > Edge would receive this, do the normal thing and send a 
> > message to vamp1
> > with the Route changed to
> > 
> > Route: vamp1.visitor.com;route-type=loose 
> > vamp2.home.com;route-type=loose
> > 
> > vamp1 would notice it was the first thing on the route header 
> > and pop this.
> > It would than look at the next thing on the route list and 
> > see that it was a
> > loose route to vamp2. vamp1 knows it needs to send to 
> > nat.home.com and would
> > send a message to nat with the header of
> > 
> > Route: vamp2.home.com;route-type=loose
> > 
> > nat would notice this is a loose route and that it was not 
> > vamp2. It would
> > send this message to vamp2 with a header of
> > 
> > Route: vamp2.home.com;route-type=loose
> > 
> > vamp2 would pop this item and the route header would be empty 
> > and normal
> > processing would continue.
> > 
> > Specifically I am proposing the following changes to the ABNF
> > 
> > rr-tag = ( rr-type-tag | generic-tag ) rr-type-tag = 
> > "route-type" "=" (
> > "loose" | "strict" | token )
> > 
> > And adding some test to the behavior of proxies along the lines of
> > 
> > The route-type is a hint that the proxy may honor. If a proxy 
> > receives a
> > message and finds itself as the top most item on the route 
> > header, it must
> > pop this item. If the top item in the route header specifies 
> > a route-type of
> > loose, the proxy should look at the URI in the top name-addr 
> > on the route
> > header and route the message in the same way it would route a 
> > message that
> > had this URI and no route header. Furthermore, it should not 
> > pop the top
> > most item off of the route list. If no route-type is 
> > specified, the default
> > is strict.
> > 
> > I did try and think about this idea from the point of view of 
> > backwards
> > compatibility and I don't think there is any situation where 
> > it will make
> > the situation worse. If a proxy that does not do loose 
> > routing attempts to
> > route a hop that is supposed to be loose, it will try a 
> > strict route. If
> > this works great, things carry on. If it does not work, the 
> > call will fail.
> > The mechanism does not require that every proxy must support 
> > loose routing,
> > only those that are going to be asked to do a loose route or 
> > receive a loose
> > routed item need to do it.
> > 
> > Thoughts? Thanks, Cullen
> > 
> > 
> > 
> > 

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

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 11 Sep 2001 13:02:09 -0400

The mobile has to know its SIP identity, presumably via a some kind of
smartcard. This provides the domain, which in turn leads to a server
(via DNS). Whether this is _sip._tcp or _siphome._udp, if we want to
separate inbound calls from call routing. Minimal complexity. What does
this not address?

The HTTP idea has the problem that HTTP is far harder to scale. Plus,
the DHCP would be in the visited network. How would it know the home
network's server?

Dean Willis wrote:
> 
> The question is "how to discover the path", IE find the home serving CSCF.
> 
> I believe I recently proposed a couple of alternatives that provide dynamic
> discovery solutions:
> 
> 1) Another DHCP field.
> 2) Another protocol operation, such as an HTTP get.
> 
> One might posit that that the visited proxy might return a "configuration
> server" address in the DHCP (or Proxy Discovery Protocol, whatever). The
> mobile could then do an HTTP get, retrieve the "path", and populate
> loose-routes appropriately.
> 
> Or the visited proxy could execute the HTTP GET on behalf of the user, and
> use it in constructing a loose-route that it would prepend to loose-routes
> originating from the mobile.
> 
> Or, we could simply ignore the visited network at this phase (after all,
> we've already discovered the visited proxy) and just do an HTTP GET from the
> mobile to discover what home platform addresses shoudl be included in
> loose-route.
> 
> Each model decouples the loose-routing from the REGISTER operation and
> solves the requirements as I understand them.
> 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 11 Sep 2001 11:40:25 -0500

1) Another DHCP field.

--
Dean
----- Original Message -----
From: "Drage, Keith (Keith)" <[email-masked]>
To: "'Cullen Jennings'" <[email-masked]>; <[email-masked]>; "'Rosen,
Brian'" <[email-masked]>
Sent: Monday, September 10, 2001 8:37 AM
Subject: RE: [Sipping] Loose Routing Proposal