Chaney, Charles (SNL US) wrote:
> Thanks Paul and Dale.
>
> I think there is a need for more clarification and the need to ask a few
> more questions below.
>
> My original question was primarily handling by a forking proxy when a
> UAS sends a 3xx response to perform CF. From the discussion this seems
> to be a general RFC3261 section 16.7 interpretation issue when a forking
> proxy receives one or more 3xx response(s) due to a forked INVITE.
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]
>> Sent: Friday, April 06, 2007 10:10 PM
>> To: [email protected]
>> Subject: Re: [Sip-implementors] forking and 3xx responses
>>
>> From: "Chaney, Charles \(SNL US\)" <[EMAIL PROTECTED]>
>>
>> I am trying to determine how a forking proxy (and UAC for
>> that matter)
>> should handle a UAS 1xx response and another UAS
>> responding with a 3xx.
>> I'm unable to find a definitive answer in RFC3261. While
>> 3xx responses
>> are typically sent by servers performing a location
>> service, there are
>> SIP-UA (UE) that do this for some types of call
>> forwarding/deflection.
>>
>> Shall the behavior be as documented in RFC3261 section
>> 16.7, 6. Choosing
>> the best response or something different?
>>
>> There's quite a bit of flexibility. Leaving out the possibility that
>> the proxy can discard some contacts provided by 3xx as a matter of
>> local policy, once you've chosen an overall strategy, the proxy is
>> fairly tightly constrained in what it can do and still provide a good
>> "user experience".
>>
>> - Immediately act upon the 3xx, retargeting the request for the
>> responding UAS dialog and let the others continue.
>>
>> This is the "forking proxy" strategy. As Paul says, there was some
>> question as to how to prioritize various contacts, but the only scheme
>> that produces consistent results is to consider the q values of the
>> contacts of one 3xx as a sort key that is secondary to the q values of
>> the top-level set of contacts the proxy is forking to.
>>
>> And if one of the secondary contacts returns a 3xx, the contacts from
>> the 3xx must be considered a set whose q values are a tertiary sort
>> key. Etc.
>
> I'm having trouble coming to the same conclusion. The above seems to be
> in conflict with RFC3261 section 16.7;
What sort of conflict are you seeing?
> so are the above statements
> really applicable to a forkig proxy or do they really only pertain to a
> UAC as covered in 8.1.3, Processing 3xx Responses? The statements imply
> the proxy has a special policy and routing knowledge (and is alowed to
> use it).
Well, some proxies do, and some may not.
A "home" proxy - responsible for an AOR and routing based on
registrations and the like, often will have policies of its own -
perhaps the result of configuration on behalf of the owner of the AOR.
As the responsible server for the AOR is has the right to have such
policies for how to translate the R-URI from the AOR to something else.
> If these 3xx response contain only retargets of the same
> request (e.g., different host like a 305)
Be careful of 305. It is vastly underspecified in 3261 - to the point of
being unusable. Its been the subject of some proposed clarification but
that hasn't gotten traction yet.
> within the same routing domain
> of the proxy, then it may be able to add these and continue, but if the
> 3xx rsponding UAS has inserted a new user target or a host target that
> is outside the routing domain of the proxy, then the forking proxy
> should not honor the 3xx.
Why is that?
> It can't make these type of retargeting
> decisions without the UAC involvement, so the decision must be made
> downstream.
Well, some argue that *all* 3xxs should be left to the UAC to deal with.
But setting that aside for the moment, why do you think the proxy
cannot make the decision in this particular case?
IMO the decision about what the proxy is permitted to do is itself a
policy decision. You may decide, for your AOR, that you don't want your
home proxy making these decisions. But I may decide otherwise.
> At the saem time, due to the final response forwarding rules
> the 3xx response cannot be forwarded until the proxy determines that
> this the best final response of all non-2xx final responses received.
Yes, and this is the dilemma. If the proxy has chosen to fork, then it
also need to recurse on 3xx responses in order to give a reasonable user
experience. If it didn't fork, then passing the 3xx upstream can work.
>> - Treat the 3xx as the best final response upon reception,
>> send it to
>> the UAC, cancel all existing dialogs, and expect the UAC
>> to handle the
>> 3xx.
>>
>> That doesn't produce good results if one of the other forks is
>> currently ringing on a UA.
>
> Agreed, but the UAS sending the 3xx response is representing the user's
> intent in the forking case, so maybe this should be cause for immediate
> response fowarding action to the UAC by the forking proxy?
Its only reflecting the intent of the user that sent it. In the case of
forking there may be several users involved.
For instance Alice may have called Bob. Bob's home proxy may parallel
fork to Bob's home phone and to his vacation home. The vacation phone
may be set to redirect to the caretaker Charlie. Should that redirect
cancel the ringing at Bob's home?
>> - Hold the 3xx response until all UAS's have responded
>> with a either a
>> 200 OK or 3xx-6xx final response and then pick the most appropriate
>> final response.
>>
>> This is completely legitimate, but if one fork returns 401/407
>> (authentication requires) and another returns 3xx, it's a little dicey
>> to decide which is the best response, as you either lose the
>> information in the contact list or the information that authentication
>> could be helpful.
>
> This seems to be what's implied by section 16.7 point 5 and 6. If
> there's more than this someone should clarify in RFC3261.
There has been a lot of discussion of these points over the years.
(Search for HERFP.)
> It basically
> defeats the intent of the UAS (and possibly the user) sending the 3xx
> response since it may not be processed until some time later when all
> other UAS's have sent a final response (less than the 3xx), if at all.
>
> You bring up an interesting point with the 401. If the request is
> forked, as long as one UAS is responding favorably to the INVITE, the
> 401 will not be forwarded to the UAC to respond? Did I miss something?
No.
>> - Implement something new like sending a 199 response for the early
>> dialogs, canceling these dialogs downstream, and having
>> the proxy send
>> the 3xx response or retarget itself based on the 3xx contact.
>>
>> Isn't this a version of the second previous alternative?
>>
>> - Have the proxy ignore the 3xx as a matter of policy.
>>
>> - Other possibilities?
>>
>> - Are proxies free to choose any of the above approaches?
>>
>> Generally, if a proxy forks a request, it needs to accept and fork 3xx
>> responses, so that it can consolidate all responses well. But if a
>> proxy does not fork the request, it can easily just pass 3xx responses
>> back upstream.
>
> For a forking proxy, this seems to go against the statements in RFC3261
> section 16.7 points 5 and 6.
Which ones?
>> I'd like to also consider the other possibility where the
>> initial UAS
>> response is the 3xx, followed by 1xx response(s).
>> Hopefully it's the
>> same rule.
>>
>> Well, the 1xx's must come from different forks than the 3xx, as after
>> sending a 3xx, a UAS may not send a 1xx. And 1xx's have to be passed
>> upstream independently of the machinery for processing final
>> responses.
>
> This too seems to be conflicting. A new UAS as a result of the
> retargeting the UAS may send send response as for any UAS. The same
> rules should apply if this was the handling, but now I have my doubts
> that the retargeting due to the 3xx response would even be attempted.
I don't understand what you are saying here.
>> In general it seems more appropriate to inform the UAC if
>> retargeting is
>> going to proceed since the UAC's perspective of the dialog may be
>> changing even though it has an already established early
>> dialog with
>> another UAS. If retargeting should not immediately
>> proceed, then the 3xx
>> effectively becomes a NO-OP or is delayed until all other
>> UAS's respond
>> with a 4xx-5xx.
>>
>> OTOH, in many systems, *all* calls are retargeted with 3xx as part of
>> the location service, so you don't want to stop and request the UAC
>> user's permission for every 3xx.
> I think this is specific to the 3xx contact-uri and what's allowed.
> There are cases where the UAC must be consulted since it may not chose
> or be allowed to continue based on the 3xx response.
I don't follow your point. You seem to have some specific ideas about
who is allowed to do what. They may make sense in some deployment, but
AFAIK not in general.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
