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
> <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
>>
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
--
Bogdan-Andrei Iancu
www.voice-system.ro