Robert,
Thank you. I was hoping to get that sort of explanation - that the
alternatives had been considered and the one in 3261 explicitly picked.
I knew that my example was contrived, and that it is equally possible to
contrive one for the documented behavior.
And no, I wasn't in Las Vegas. That had to be before I started following
sip. My knowledge of the history has holes like that.
Thanks,
Paul
Robert Sparks wrote:
>
> On Sep 8, 2008, at 12:01 PM, Paul Kyzivat wrote:
>
>> 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.
>
> No - there was some logic there. I think the disconnect is in
> recognizing where services can place service logic (and when they would
> choose to have it happen, as you said, late or early).
>
>>
>>
>> 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.
>
> Which can be a _goal_ of some applications (possibly even the primary
> goal).
>
> I don't remember if you were at the Interim meeting we had in Las Vegas
> many years ago. I described a feature there where I might want to be
> able to dial folks I know by the name I remember them by, but don't
> necessarily want them to know what that alias was. (Don't dwell on
> realizing this kind of application too hard).
>
>>
>>
>> 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.
>
> We discussed this kind of thing at the time and came to consensus on
> retargeting while things were moving along. While bouncing through this
> service cloud, I might have feature A decide that stuff downstream
> really should be operating on my assistant's (hah) communication
> devices, not mine. Allowing what you describe as "early" retargeting
> lets that be realized. You could engineer things differently, so that
> the entire service chain got invoked and there were enough bits around
> to invoke the service chain _again_ (and nothing prevents you from
> building things this way now if you want to), but there were
> participants that had a more streamlined approach in mind.
>
>>
>>
>> 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
>
> possibly was an important word here.
>
> 3261 _allows_ it to retarget at this time. It doesn't _require_ it.
> The service provider built a broken service by combining these features
> in this way (feature-interaction is always fun).
>
>
>> 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
