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; 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). If these 3xx response contain only retargets of the same request (e.g., different host like a 305) 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. It can't make these type of retargeting decisions without the UAC involvement, so the decision must be made downstream. 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. > > - 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? > > - 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. 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? > > - 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. > > 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. > > 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. > > Dale > _______________________________________________ > 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
