Subject: RE: [Sipping] Loose Routing Proposal

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Sep 2001 10:33:56 -0400

I really don't want to redesign 3GPP myself, but...

I really don't like the idea that we need a new SIP header
to pass a piece of information that does not affect the operation
of any element on the transaction.  You want a way to pass the
home proxy from the registrar to the outbound proxy, and to
pass the inbound visited proxy to the home proxy.  But the word is
"pass" - it doesn't affect the current transaction - it's just 
opaque information to most elements, and is only used on
subsequent transactions.  

If there is need to pass opaque information between elements, 
just put it in a body; a new MIME type seems harmless.

Also, we explicitly do NOT define how the registration server
passes information to the location server.  If there is a need to
do this, we should come up with a generalized mechanism to do so,
but I'm not convinced it's a good idea.  That's the inbound side
(how does the home proxy know what the inbound visited proxy is).
You can, if you like, turn this into a local-to-the-visited-network
problem by having the body as above from the reply to the
register, have the outbound visited proxy record route, 
pick up the body, and pass it to the inbound visited proxy.
I have to go look at how the current 3G specs do registration, but
I would have both the visited and home networks in the path of
registration and both keeping the information about the other.
Any transit networks could do the same.

The outbound side is really easy - Juha pointed out that if the
UA wants his home services, it should put the loose route in.
If you want the outbound proxy server to be statefull and force
this, record route, pick up the body and use it.

Next, 

> -----Original Message-----
> From: Miguel A. Garcia [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 9:29 AM
> To: Rosen, Brian
> Cc: 'Cullen Jennings'; [email-masked]
> Subject: Re: [Sipping] Loose Routing Proposal
> 
> 
> Hi Brian:
> 
> In the current flows in 3GPP, there is a path header for REGISTER
> and 200 OK. The path header is used to transport the route to 
> preload in INVITES 
> 
> Preloading of the routes is done at the outbound local proxy for
> outgoing calls, or at the home proxy for incoming calls.
> 
> I see that the proposal of the loose routing solves the problem
> of having several proxies in the middle between a local and a
> home proxy. In addition, it does not create a strict route 
> between them, and this is excellent. But, like I said, this is
> just one problem to solve.
> 
> The other problem that is not solved is how the local proxy might
> get the knowledge of the route to apply for outbound calls in 
> order to get to the home proxy. And vice versa, how does the home
> proxy learn about the local proxy (this will be the route for
> terminating calls, that is, home proxy, visited proxy, UA).
> 
> This is what the path header, although some of us don't like it,
> it is solving.
> 
> Regards,
>        
>       Miguel
> 
> "Rosen, Brian" wrote:
> > 
> > But I want to get rid of the Path header, so if this doesn't
> > do it, we need to work harder.
> > 
> > I don't understand how you "learn" the route; all the cases
> > I know about, you know about the route, either because of
> > service selection or policy.  In either case, there could be
> > a problem of state saving (where do you keep the info),
> > but that is what cookies/state does.
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Miguel A. Garcia [mailto:[email-masked]]
> > > Sent: Friday, September 07, 2001 8:21 AM
> > > To: Rosen, Brian
> > > Cc: 'Cullen Jennings'; [email-masked]
> > > Subject: Re: [Sipping] Loose Routing Proposal
> > >
> > >
> > > Hi:
> > >
> > > Although I haven't gone through all the details in the 3GPP case,
> > > my first thought is that this will solve the problem of having a
> > > strict route. Actually, I like Cullen's idea and the proposed
> > > wording for the the bis draft.
> > >
> > > However, this proposal does not deprecate the proposed 
> path header,
> > > as proxies (or even the UA) need to learn how to preload 
> the Route...
> > > but that is another problem.
> > >
> > > /Miguel
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > 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
> > >
> > > --
> > > Miguel-Angel Garcia                     Oy LM Ericsson AB
> > >                                         Jorvas, Finland
> > > mailto:[email-masked]     Phone:  +358 9 299 3553
> > > mailto:[email-masked]        Mobile: +358 40 5140002
> > >
> > > _______________________________________________
> > > 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
> > >
> 
> -- 
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                         Jorvas, Finland
> mailto:[email-masked]     Phone:  +358 9 299 3553
> mailto:[email-masked]        Mobile: +358 40 5140002
> 

_______________________________________________
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: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 07 Sep 2001 17:56:56 +0300

> opaque information to most elements, and is only used on

This is how other headers work today in SIP. Record-Route does not
affect the current transaction, but subsquent transactions.

> just put it in a body; a new MIME type seems harmless.

Agree.

> (how does the home proxy know what the inbound visited proxy is).

Agree with you, we should not define procedures outside the SIP 
scope, and I believe the location server is.

> pick up the body, and pass it to the inbound visited proxy.

To my knowledge, the inbound and outbound visited proxy is the same
entity in 3GPP. So it is easier than that.

> this, record route, pick up the body and use it.

Sound fine. In addition, in 3GPP the UA always want to go to the 
home network. One non-requested service that the home network 
offers is to charge for the service, so the UA always needs "to
request" that service.

/Miguel