Chaney, Charles (SNL US) wrote:
> 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.
3261 says (or implies) that the proxy (would apply to UAC too) may treat
the responses as additional candidates in addition to those already
being considered. (With the limitation that if the 3xx returns a
candidate already tried then it must not be tried again.)
3261 also implies that the q-values of the new candidates be used to
sort the new ones into the ordering of the ones already present. That is
a questionable practice. It came up when working on callerprefs (RFC
3841). There we noticed the q-values are only intended to be ordinals,
and thus comparing values from different sources won't give reasonable
results. Instead, we suggested that the ordering of values in a 3xx be
considered to be subordinate to the ordinal position of the contact that
resulted in the 3xx. Doing that will also give more consistent results
to the case where the target itself forks rather than returning the 3xx.
> Shall the behavior be as documented in RFC3267 section 16.7, 6. Choosing
> the best response or something different?
>
> - Immediately act upon the 3xx, retargeting the request for the
> responding UAS dialog and let the others continue.
This is consistent with what I just said above.
> - 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.
>
> - 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.
If you don't want to recurse locally, it would make sense to wait,
accumulate all the candidates you have received, and then return them
all in a 3xx. But you are free to discard any that you don't like for
some reason.
> - 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.
There is something to be said for that, but AFAIK there is no active
work on that idea.
> - Have the proxy ignore the 3xx as a matter of policy.
The proxy has a lot of discretion. It can always ignore any of the
candidates based on local policy.
> - Other possibilities?
>
> - Are proxies free to choose any of the above approaches?
Pretty much.
> 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.
I would think so. If you forked to multiple places I think you would
want to give them all a chance.
> 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.
This will work ok if proxies always return 3xx rather than fork.
But if a proxy chooses to fork, then it probably should recurse rather
than returning 3xx responses. If it doesn't recurse, then it will either
have to abandon attempts early, or else save the 3xx responses until the
outstanding attempts have given up. Neither is likely to give an ideal
result.
Paul
> Thanks in advance,
> Chuck
>
>
> _______________________________________________
> 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
