Hi All,
I'm trying to figure out an issue with q-values on 302 redirects. I'm
being told that I'm following q-values wrong on a 302. OpenSIPs is
delivering to a URI with a q-value of 0.25 before a q-value of 0.5.
>From the RFC:
As the target set grows, the client MAY generate new requests to the
URIs in any order. A common mechanism is to order the set by the "q"
parameter value from the Contact header field value. Requests to the
URIs MAY be generated serially or in parallel. One approach is to
process groups of **decreasing** q-values serially and process the URIs
in each q-value group in parallel. Another is to perform only serial
processing in decreasing q-value order, arbitrarily choosing between
contacts of equal q-value.
However, I see serialize_branches setting branches in ascending order
(0.25 is picked before 0.5) which works according to the online docs;
which state:
Takes all the branches added for parallel forking (with
append_branch() and including the current RURI)
and prepare them for serial forking. The ordering is done in
**increasing** "q" order. The serialized branches
are internally stored in AVPs - you will be able to fetch and use
via the "next_branches()" function.
I've looked for a simple function to reverse the order as well, but
that doesn't seem like the right fix and I can't find a simple way to
do it without looping thru the branches and rebuilding the array.
Am I missing something here?
Thanks,
Brett
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
