18 Jul
2005
18 Jul
'05
6:59 p.m.
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
21 Jul
21 Jul
7:38 p.m.
New subject: [Serusers] Re: revert_uri in failure_route
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(a)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(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
25 Jul
25 Jul
5:31 p.m.
New subject: [Serusers] Re: revert_uri in failure_route
Hello all,
Does anybody know the answers to these questions? Am I unclear or is there
more information needed that I should be providing?
Are these serdev questions?
Thanks,
Dan
On 7/21/05, Daniel Poulsen <dpoulsen(a)gmail.com> wrote:
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(a)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(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
11 p.m.
New subject: [Serusers] Re: revert_uri in failure_route
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(a)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(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
7070
days inactive
7077
days old
3 comments
1 participants
participants (1)
-
Daniel Poulsen