No subject

   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