[OpenSIPS-Users] Conflicting info for q-value order

[Brett Nemeroff]

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
<bogdan at 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 at 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 at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>