Yes, I'm aware of loose-route. I like the idea, but its more or less
been decided that we can't get there from here.
Thanks,
Paul
Rockson Li (zhengyli) wrote:
> 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
