[OpenSIPS-Users] Conflicting info for q-value order
bogdan at voice-system.ro
Thu Apr 1 13:53:05 CEST 2010
Based on the RFC quotes, I would say the serialize function is
considering 0.0 as higest priority and RFC suggest the other way around.....
Could you try the attached patch to see if it fixes the problem ?
Brett Nemeroff wrote:
> 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?
> Users mailing list
> Users at lists.opensips.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Users