after reading the documentation it didn't become clear to me if openser tm enhancement "proper serial forking" includes serial forking based on q values, i.e., can i just make one t_relay() call and tm tries the contacts in proper q value order.
-- juha
Juha,
the fix is not q-value related. It's more about proper branch selection during serial forking - the final branch is selected only from the last set of serial forked branches. Maybe an example will be more conclusive:
1) initial fork in parallel to two destination; 486 and 301 are received -> picked branch will be 301 (based only on branch 1 and 2) 2) serial fork from failure_route to another two destinations; 408 and 407 -> SER will pick 301 again (from all 4 branches); OpenSER will pick 408 (from only the last serial forked replies - 3 and 4).
This approach will allow to build correct logics based on multiple serial forking steps.
hope the example helped, bogdan
Juha Heinanen wrote:
after reading the documentation it didn't become clear to me if openser tm enhancement "proper serial forking" includes serial forking based on q values, i.e., can i just make one t_relay() call and tm tries the contacts in proper q value order.
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
the fix is not q-value related.
why is it then that you didn't include lcr module to openser 0.9.4 release, which supports serial forking based on q value?
openser 0.9.4 is started from ser 0.9.3 which doesn't contains lcr module. It will be in the next release - the way to go is "release early, release often", so lcr will be soon included in a stable release. Also related to q value, I'm looking for a way to have serial q-based forking for user location also. I thing it will require some merging (as ideas) with the lcr.
bogdan
-
Bogdan-Andrei Iancu -
Juha Heinanen