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]>.
>
>
> 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]>.
>
>
> 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
