Paul, Not sure if you read draft-rosenberg-sip-ua-loose-route or not. I think it talks about the preservation of orig-RURI for service identification.
FYI Regards, -Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Tuesday, September 09, 2008 1:02 AM To: Robert Sparks Cc: [EMAIL PROTECTED]; [email protected] Implementors Subject: Re: [Sip-implementors] Question on proxy routing Robert, This wasn't my question, but I have wondered the same thing. Robert Sparks wrote: > Hrmm - I'm not sure I see the confusion yet, but let me describe one > concept that drove the text in that section to see if it helps. If, > after you read this, you think there's still a lack of clarity, we'll > start walking through the text and see if we can make it better (will > you be at SIPit? We can do this in person if you will be). IMO its not that the text is confusing or ambiguous, but rather that it is illogical. Until the Route headers are exhausted, there is no guarantee that the request will be going to the R-URI at all. It could be aborted or redirected for a variety of reasons, including reasons that are based on the value in the R-URI. By replacing the R-URI "early", the hops based on the Route headers are deprived of the opportunity to examine the R-URI as it was. If the R-URI is left alone until the Route headers are exhausted, and the request hasn't yet failed, it will eventually get back to this proxy based on the domain name in the R-URI. Then the proxy will have the opportunity to replace the R-URI as it sees fit. Lets consider another contrived example: Alice and Bob both have example.net as their SP, including the same home proxy. Alice also has subscribed to some services. These are provided by a proxy service.example.net. Her UA gets: Service-Route: sip:example.net, sip:services.example.net One of the tasks of the services proxy is to screen outgoing calls, blocking calls to destinations on a black list. In this case, Bob is a boyfriend that her parents consider unacceptable, so they have added his address to the blacklist, in an attempt to prevent her from calling him. (Presumably there is also a blacklist on incoming calls, but that isn't important to this example.) Then Alice attempts to call Bob: INVITE sip:[EMAIL PROTECTED] Route: sip:example.net, sip:services.example.net This is delivered to example.net. According to 3261 as it is written, the proxy should note that it is responsible for [EMAIL PROTECTED], and so possibly translate it to the address of Bob's registered phone: sip:some-phone.com. Then the call is routed to services.example.net. It doesn't find the R-URI on its blacklist, so it just routes it on to bob. Not what was desired (by policy, not Alice.) The alternative would be that the example.net proxy would route to services.example.net without changing the R-URI. If the proxy finds the R-URI on its blacklist it can reject the call, or redirect it elsewhere. If Bob were *not* on the blacklist, it would simply route based on the R-URI, back to example.net. In that case it would then note there are no Route headers, and that it was responsible for the R-URI. So then it would translate the R-URI to the address of Bob's phone and route based on that. I realize that even if my view makes more sense its probably too late to change. But I'm still interested in the logic behind why things are the way they are. Thanks, Paul > 3261 introduced loose-routing at proxies. Under the loose-routing > rules, a proxy is able to retarget a request (that is, change its > Request-URI) with much more independence of how it routes the request > than 2543 proxies had. > > In the case you describe, a proxy can change the RURI in the requests > it forwards. It can choose to push the request through several other > proxies (the motivation was invoking services) by pushing additional > Route URIs in front of whatever Route stack exists. (What it's not > allowed to do is remove elements other than itself from that list of > Route URIs). > > Here's a contrived example: > > Suppose a proxy that's responsible for example.com receives a request > with a RURI of <sip:[EMAIL PROTECTED]> and a Route header field with > this list > "<sip:[EMAIL PROTECTED]>,<sip:[EMAIL PROTECTED] net>. > > > It will pop the [EMAIL PROTECTED] uri off the stack. If it has > no other local policy to do work, it will forward the request to > downstream.example.net. It has, however, the option of doing other > work by local policy. In this contrived example, it is responsible for > the RURI, and is going to retarget that request. Using whatever local > information it has, it decides that this request should be retargeted > to <sip:[EMAIL PROTECTED]> and routed through a service proxy > at <sip:[EMAIL PROTECTED]> before it goes on to > downstream.example.net. So the request it forwards will have a request > URI of <sip:[EMAIL PROTECTED]> and a Route header field of > <sip:[EMAIL PROTECTED]>,<sip:[EMAIL PROTECTED] m.example.net>. > > > Now the interesting thing (and this is where I think you might be > running into confusion reading 16.5), is that the proxy could also > decide to fork this request and retarget it to > <sip:[EMAIL PROTECTED]> and route it through that same > (or some different) service proxy. The only constraint is that it's > got to go through downstream.example.net before its done. > > Rereading your original question, I'll point out that nothing changes > if the original request showed up without the > <sip:[EMAIL PROTECTED]> in the topmost route other than the topmost route not getting popped. > This proxy is still responsible for the RURI and will make sure the > request goes through the routeset the request showed up with. > > Hope this helps, > > RjS > > > > > On Sep 8, 2008, at 12:07 AM, Franz Edler wrote: > >> Hello experts! >> >> Reading chapter 16.5 of RFC 3261 a question came up and maybe anyone >> can answer. >> >> When a proxy server receives a request where it recognises that it is >> responsible for (based on the domain part of the request URI) but the >> Route header field is not empty how does it proceed? >> >> According to chapter 16.5 of RFC 3261 it ignores the Route header and >> determines the new targets with the help of the location service. >> >> In my view (until recently) the proxy forwards the request to the >> next hop based on the next Route header field and only checks if it >> is responsible for the request when the Route header is empty. But >> maybe I have to correct my view. >> >> Any clarification appreciated. >> >> Regards >> Franz >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
