Hi Brett, Brett Nemeroff wrote: > 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. > actually it does make sense, as the serialize_branches is not intended to be used alone (without next_branches function).
So, they complete one each other. Maybe to make usage of the serialize funtion for q sorting only (without doing the serial / parallel forking), we could have: 1) serialize_branch("sort") -> the function will simply sort them, without preparing the branches for "next_branches" 2) serialize_branch(); next_branches("all") -> we change the next branches to extract them all, disregarding the q levels. Regards, Bogdan > Thanks! > -Brett > > On Thu, Apr 1, 2010 at 6:53 AM, Bogdan-Andrei Iancu > <bog...@voice-system.ro> 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 >>> Users@lists.opensips.org >>> 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 >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Bogdan-Andrei Iancu www.voice-system.ro _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users