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 > <[email protected]> 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 >>> <[email protected]> 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 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
