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 mo
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 properl
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_br
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
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 i
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 t
