[Serusers] Re: revert_uri in failure_route

Daniel Poulsen dpoulsen at gmail.com
Mon Jul 25 23:00:34 CEST 2005 

Is there a problem with calling a route block from within a failure_route 
rather than doing a t_relay()? 

I have noticed that if I add xlog NOTICEs to my failure routes and route[7] 
(which gets called from failure_route), calls hit the failure route once, 
but hit the route[7] block twice (once for the alias and once for the 
subscriber ID) . Is this a BUG?



On 7/18/05, Daniel Poulsen <dpoulsen at gmail.com> wrote:
> 
> 
> 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 at 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 at 192.168.32.18: [192.168.32.18<http://192.168.32.18>] 
> INVITE sip:2125551234 at 192.168.32.30:5060
> Jul 18 11:17:23 sip /usr/sbin/ser[18279]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: alias lookup changed uri 
> to sip:username1 at sip.mydomain.com
> Jul 18 11:17:23 sip /usr/sbin/ser[18279]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: [192.168.32.30<http://192.168.32.30>] 
> INVITE sip:username1 at sip.mydomain.com
> Jul 18 11:17:53 sip /usr/sbin/ser[18301]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: r8: hunt on 
> sip:h1-username1 at sip.mydomain.com
> Jul 18 11:17:53 sip /usr/sbin/ser[18301]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: r8: hunt changed URI to 
> sip:2125551234 at vm.packetalk.net, relaying
> Jul 18 11:17:53 sip /usr/sbin/ser[18301]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: r8: hunt on 
> sip:h1-2125551234 at 192.168.32.30:5060
> Jul 18 11:17:53 sip /usr/sbin/ser[18301]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: r8: hunt changed URI to 
> sip:2125551234 at vm.packetalk.net, relaying
> Jul 18 11:17:53 sip /usr/sbin/ser[18281]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: [192.168.32.30<http://192.168.32.30>] 
> CANCEL sip:username1 at 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 at 192.168.32.18: [192.168.32.18<http://192.168.32.18>] 
> CANCEL sip:2125551234 at 192.168.32.30:5060
> Jul 18 11:18:08 sip /usr/sbin/ser[18280]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: alias lookup changed uri 
> to sip:username1 at sip.mydomain.com
> Jul 18 11:18:08 sip /usr/sbin/ser[18289]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: [192.168.32.30<http://192.168.32.30>] 
> ACK sip:username1 at sip.mydomain.com
> Jul 18 11:18:09 sip /usr/sbin/ser[18285]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: [192.168.32.30<http://192.168.32.30>] 
> ACK sip:username1 at sip.mydomain.com
> Jul 18 11:18:10 sip /usr/sbin/ser[18289]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: [192.168.32.30<http://192.168.32.30>] 
> ACK sip:username1 at sip.mydomain.com
> Jul 18 11:18:11 sip /usr/sbin/ser[18298]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: [192.168.32.30<http://192.168.32.30>] 
> ACK sip:username1 at sip.mydomain.com
> Jul 18 11:18:12 sip /usr/sbin/ser[18298]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: [192.168.32.30<http://192.168.32.30>] 
> ACK sip:username1 at sip.mydomain.com
> Jul 18 11:18:13 sip /usr/sbin/ser[18287]: 
> 29FF0A3-F6D611D9-938FBF07-9CC1DBD7 at 192.168.32.18: [192.168.32.30<http://192.168.32.30>] 
> ACK sip:username1 at sip.mydomain.com
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050725/81821402/attachment.htm>

More information about the sr-users mailing list