[Serusers] revert_uri in failure_route

I think I am missing something very simple here, but I cannot figure out what it is. I have DID aliases set up for SER usernames, so when a call comes in as 2125551234, I do a lookup("aliases") which results in something like username1(a)sip.mydomain.com. Username1 is the registered SER user. the numbers are all aliases. I also have a secondary aliases table called "hunt" which I use to store call hunt sequences. The problem is that if a user does not pick up the phone and SER calls failure_route[1], I get a hunt for both 2125551234 and username1. Shouldn't my revert_uri() in failure_route cause the hunt lookup to be done on 2125551234 only? route[7] is called from failure_route only, so there isn't any other logic that might put me into these route blocks. Included below the call routing blocks are some syslogs. If anyone could offer a suggestion or has seen anything like this and could let me know what they did to solve it I would be eternally grateful. Thank you. Dan ### # Hunt (8), but only on 404/408/486 route[7] { if (t_check_status("408") | # Timeout t_check_status("404") | # Not found t_check_status("486")) # Busy { route(8); } else { xlog("L_NOTICE", "%ci: r7: hunt but not 404/408/486\n"); }; } ### # Hunt to the next number in sequence route[8] { # See if we're in a hunt if(search("P-hint: pt-hunt")) { xlog("L_NOTICE", "wanted to hunt, but hunt already in progress\n"); break; }; # Assumes URI has been revert and prefixed with "h#-" # Also assumes t_on_failure (#+1) has been set. xlog("L_NOTICE", "%ci: r8: hunt on %ru\n"); if(lookup("hunt")) { xlog("L_NOTICE", "%ci: r8: hunt changed URI to %ru, relaying\n"); append_branch(); append_hf("P-hint: pt-hunt\r\n"); setflag(9); t_relay(); break; } else { xlog("L_NOTICE", "%ci: r8: no further hunts, giving up\n"); }; } failure_route[1] { revert_uri(); prefix("h1-"); t_on_failure("2"); route(7); } failure_route[2] { revert_uri(); prefix("h2-"); t_on_failure("3"); route(7); } failure_route[3] { revert_uri(); prefix("h3-"); t_on_failure("4"); route(7); } failure_route[4] { revert_uri(); prefix("h4-"); t_on_failure("5"); route(7); } failure_route[5] { revert_uri(); prefix("h5-"); t_on_failure("6"); route(7); } failure_route[6] { revert_uri(); prefix("h6-"); t_on_failure("7"); route(7); } failure_route[7] { revert_uri(); prefix("h7-"); t_on_failure("8"); route(7); } failure_route[8] { revert_uri(); prefix("h8-"); t_on_failure("9"); route(7); } failure_route[9] { xlog("L_ERR", "too many hunts!\n"); } Jul 18 11:17:23 sip /usr/sbin/ser[18279]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: [192.168.32.18<http://192.168.32.18>] INVITE sip:2125551234@192.168.32.30:5060 Jul 18 11:17:23 sip /usr/sbin/ser[18279]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: alias lookup changed uri to sip:username1@sip.mydomain.com Jul 18 11:17:23 sip /usr/sbin/ser[18279]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: [192.168.32.30<http://192.168.32.30>] INVITE sip:username1@sip.mydomain.com Jul 18 11:17:53 sip /usr/sbin/ser[18301]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: r8: hunt on sip:h1-username1@sip.mydomain.com Jul 18 11:17:53 sip /usr/sbin/ser[18301]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: r8: hunt changed URI to sip:2125551234@vm.packetalk.net, relaying Jul 18 11:17:53 sip /usr/sbin/ser[18301]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: r8: hunt on sip:h1-2125551234@192.168.32.30:5060 Jul 18 11:17:53 sip /usr/sbin/ser[18301]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: r8: hunt changed URI to sip:2125551234@vm.packetalk.net, relaying Jul 18 11:17:53 sip /usr/sbin/ser[18281]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: [192.168.32.30<http://192.168.32.30>] CANCEL sip:username1@sip.mydomain.com Jul 18 11:17:55 sip /usr/sbin/ser[18295]: ERROR: t_should_relay_response: status rewrite by UAS: stored: 408, received: 200 Jul 18 11:17:56 sip /usr/sbin/ser[18285]: ERROR: t_should_relay_response: status rewrite by UAS: stored: 408, received: 200 Jul 18 11:17:57 sip /usr/sbin/ser[18295]: ERROR: t_should_relay_response: status rewrite by UAS: stored: 408, received: 200 Jul 18 11:17:58 sip /usr/sbin/ser[18289]: ERROR: t_should_relay_response: status rewrite by UAS: stored: 408, received: 200 Jul 18 11:17:59 sip /usr/sbin/ser[18298]: ERROR: t_should_relay_response: status rewrite by UAS: stored: 408, received: 200 Jul 18 11:18:00 sip /usr/sbin/ser[18281]: ERROR: t_should_relay_response: status rewrite by UAS: stored: 408, received: 200 Jul 18 11:18:08 sip /usr/sbin/ser[18280]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: [192.168.32.18<http://192.168.32.18>] CANCEL sip:2125551234@192.168.32.30:5060 Jul 18 11:18:08 sip /usr/sbin/ser[18280]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: alias lookup changed uri to sip:username1@sip.mydomain.com Jul 18 11:18:08 sip /usr/sbin/ser[18289]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: [192.168.32.30<http://192.168.32.30>] ACK sip:username1@sip.mydomain.com Jul 18 11:18:09 sip /usr/sbin/ser[18285]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: [192.168.32.30<http://192.168.32.30>] ACK sip:username1@sip.mydomain.com Jul 18 11:18:10 sip /usr/sbin/ser[18289]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: [192.168.32.30<http://192.168.32.30>] ACK sip:username1@sip.mydomain.com Jul 18 11:18:11 sip /usr/sbin/ser[18298]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: [192.168.32.30<http://192.168.32.30>] ACK sip:username1@sip.mydomain.com Jul 18 11:18:12 sip /usr/sbin/ser[18298]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: [192.168.32.30<http://192.168.32.30>] ACK sip:username1@sip.mydomain.com Jul 18 11:18:13 sip /usr/sbin/ser[18287]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7(a)192.168.32.18: [192.168.32.30<http://192.168.32.30>] ACK sip:username1@sip.mydomain.com