Bogdan, Hey, I was working on this problem some more and this is what I found...
Serialize branches does in fact order the branches, but lowest to highest.. if you just do a: 1. serialize_branches 2. t_relay 3. next_branches 4. t_relay 5. next_branches 6. t_relay 7. next_branches 8. t_relay and you have q-values of .01 .02 .03 .04 Calls would be sent like: 1. call to q-value .01 2. call to q-value .04 3. call to q-value .03 4. call to q-value .02 next_branches appears to POP in the right order. Serialize branches has the affect of ordering them wrong (no POP). So if you just call next_branches first, then it appears to work properly. In other words like: 1. serialize_branches 2. next_branches 3. t_relay 4. next_branches 5. t_relay 6. next_branches 7. t_relay 8. next_branches 9. t_relay Does this logic make sense? It's probably still worth fixing serialize_branches just because this behavior is a bit confusing. I'll try to get this tested today for you and let you know how it goes. Thanks! -Brett On Thu, Apr 1, 2010 at 6:53 AM, Bogdan-Andrei Iancu <[email protected]> wrote: > Hi Brett, > > 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 ? > > Regards, > Bogdan > > 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? >> Thanks, >> Brett >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > > -- > Bogdan-Andrei Iancu > www.voice-system.ro > > > Index: serialize.c > =================================================================== > --- serialize.c (revision 6739) > +++ serialize.c (working copy) > @@ -184,7 +184,7 @@ > contacts[n].q = q; > > /* insert based on q */ > - for (i = first; i != -1 && contacts[i].q < q; i = > contacts[i].next); > + for (i = first; i != -1 && contacts[i].q >= q; i = > contacts[i].next); > > if (i == -1) { > /* append */ > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
