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 RFC3267 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. - 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. - 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. - 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. 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. 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. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
