Here is what is going on as best as I understand it.  Bear with me as I'm trying to get my head wrapped around how SER works internally.

I've looked through the docs, but still I have these questions:

1. What does failure_route do with the failed branch?  When the DID Alias->Subscriber call fails, should the failed branch automatically get removed from the transaction?  If not, is there a way for me to remove it?

2. How does lookup() work?  README.tm says it looks up and modifies the current ruri only, but when I perform a lookup("hunt") [again, hunt is a copy of aliases for the purpose of hunt sequences] it looks up both the alias and the result of lookup("aliseses") and appends/t_relays them both.

3. Just how does revert_uri work?  If I do a lookup("aliases") followed by an append_branch/t_relay and that fails, does revert_uri remove the failed brach? or should it get removed based on the fact that it has entered the failure_route?

4. Is it possible that failure_route is getting called twice with the same callid for both the DID alias and the SIP target?

When the call times out and goes to failure_route[1], the failed branch is not getting removed from the transaction so when I lookup() and append_branch I am looking up and appending the next target in the hunt sequence for both the DID (alias) and the username (SER account).  What I want to happen is that when the call fails, the failed branch gets removed from the transaction and I can then revert_uri, do a new lookup() [this time from the hunt table] and get the next destination in the hunt [be it voicemail, another SIP UA, or whatever].

If any of what I am describing is unclear, please ask and I will attempt to clarify.  I could really use some advice on this one.  From my perspective it looks as if there is a problem with how something in SER is functioning, but I know it can likely be fixed in my configs. 

Thank you.

Dan

On 7/18/05, Daniel Poulsen <dpoulsen@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@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@192.168.32.18: [ 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@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@192.168.32.18: [ 192.168.32.30] INVITE sip:username1@sip.mydomain.com
Jul 18 11:17:53 sip /usr/sbin/ser[18301]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7@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@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@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@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@192.168.32.18: [ 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@192.168.32.18: [ 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@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@192.168.32.18: [ 192.168.32.30] ACK sip:username1@sip.mydomain.com
Jul 18 11:18:09 sip /usr/sbin/ser[18285]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7@192.168.32.18: [ 192.168.32.30] ACK sip:username1@sip.mydomain.com
Jul 18 11:18:10 sip /usr/sbin/ser[18289]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7@192.168.32.18: [ 192.168.32.30] ACK sip:username1@sip.mydomain.com
Jul 18 11:18:11 sip /usr/sbin/ser[18298]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7@192.168.32.18: [ 192.168.32.30] ACK sip:username1@sip.mydomain.com
Jul 18 11:18:12 sip /usr/sbin/ser[18298]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7@192.168.32.18: [ 192.168.32.30] ACK sip:username1@sip.mydomain.com
Jul 18 11:18:13 sip /usr/sbin/ser[18287]: 29FF0A3-F6D611D9-938FBF07-9CC1DBD7@192.168.32.18: [ 192.168.32.30] ACK sip:username1@sip.mydomain.com