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

[Brett Nemeroff]

Why not just permanently change the sort order? What's the purpose of
sorting them if you don't intend to sequentially execute them?

What I'm wondering is what is more confusing to users troubleshooting
q-value issues. Have serialize branches sort branches backwards, or
having it sort them properly, but not prepare the branches? If you
change the order, it may have the affect of people doing what I did:
serialize branches without next_branches and it "looks" like it'll
work (ie: can't tell with 2 branches) but in reality , it wasn't
working right.

Maybe the best thing to do is to just add a note in the docs about
serialize_branches. I have a feeling that if you change
serialize_branches, next_branches would likely need to get changed
too, right? Because of the pop order.

Thanks,
Brett


On Fri, Apr 2, 2010 at 4:29 AM, Bogdan-Andrei Iancu
<bogdan at voice-system.ro> wrote:
> 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
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>