Yes, if you in the db store aors (which I presume), replacing the ruri with a new aor requires you to do a "recursion" on your INVITE logic. I use a true recursion inside the script, i.e. the same INVITE logic is called for the new ruri (handling forwarding etc), but for hunts you need to decide whether you want to also follow forwarding or just continue on your huntlist... g-)
Steve Blair wrote:
OK. A little trial and error and I think I found the problem. I changed the failure_route to include the command lookup("location"). I'm not clear why this makes a difference but it does. The new failure route is:
# Iterate through extension list for subscribers with call hunting enabled failure_route[6] { if (avp_pushto("$ruri/username", "s:huntlist")) { lookup("location"); append_branch(); avp_delete("s:huntlist"); t_on_failure("6"); t_relay(); }; }
Thanks,Steve
Steve Blair wrote:
Greger:
This technique almost works. Two things are happening which I cannot fully explain. Perhaps you can help. First, does the avp_db_load load the values in a specific, predictable order? Second, I cannot seem to hunt to a third number. I believe this is because the call to the second number causes SER to exit failure_route[6] effectively stopping the hunt. Do you or anyone else on this list have any thoughts on why I can only hunt trough the second number?
Thanks,Steve
Steve Blair wrote:
Greger:
So something like the following:
# hunting (serial forking) if (avp_db_load("$ruri/username", "s:allow_hunt")) { if (avp_check("s:allow_hunt", "eq/y/i")) { avp_delete("s:allow_hunt"); avp_db_load("$ruri/username", "s:huntlist/sam"); t_on_failure("6"); t_relay(); break; }; };
# Iterate through extension list for subscribers with call hunting enabled failure_route[6] { if (avp_pushto("$ruri/username", "s:huntlist")) { append_branch(); avp_delete("s:huntlist"); t_on_failure("6"); t_relay(); }; }