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

[Bogdan-Andrei Iancu]

Hi Brett,

Brett Nemeroff wrote:
> Why not just permanently change the sort order? What's the purpose of
> sorting them if you don't intend to sequentially execute them?
>   
more or less no. So, using serialized_branches() without next_branches() 
makes no sense.
> 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?
how the serialize function sends data (branches) to the next_branches() 
is completely transparent for the user, so the user should not care of 
that. The serialize function does sorting and prepare the data for usage 
- the data is stored in AVPs and to be later consumed by next_branches() 
function.
>  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.
>   
serialize without next_branches is bogus - as said, serialize take all 
branches (remove them), sort them and push them into AVPs to be used by 
next_branches(). So, after running serialize function, you do not have 
the branch set present (as it was moved into AVPs)
> 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.
>   
Probably a better documentation (and probably a short tutorial) will 
solve the issue.

Regards,
Bogdan
> 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
>>>>>           

-- 
Bogdan-Andrei Iancu
www.voice-system.ro