You need to use the call append_branch() on the failure_route before
calling t_relay().
Check the following sample config and adapt the failure logic for your needs:
http://www.voipembedded.com/resources/openser_cr.cfg
Regards,
Ovidiu Sas
On Fri, Nov 28, 2008 at 9:44 AM, Tyler Brauer <tbtbrauer(a)gmail.com> wrote:
Thank you Klaus for the suggestions. I've
implemented the
configuration below. When the first t_relay fails, Kamailio generates
the 408 Request Timeout and doesn't attempt to try an INVITE to the
second address. This what the syslog says:
Nov 28 06:11:13 server kamailio[1315]: Attempting Carrier 1
Nov 28 06:11:28 server kamailio[1323]: Attempting Carrier 2
Nov 28 06:11:28 server kamailio[1323]: ERROR:tm:t_forward_nonack: no
branch for forwarding
Nov 28 06:11:28 server kamailio[1323]: ERROR:tm:w_t_relay:
t_forward_nonack failed
Nov 28 06:11:28 server kamailio[1317]: Attempting Carrier 1
And here's the watered-down version of my configuration.
# - - - - - - - - - - - - - - - - - - - -
route[0]
{
if($si=='10.10.10.10')
{
# Allowed Host
route(1);
}
else
{
sl_send_reply("603", "Decline");
exit;
}
}
# - - - - - - - - - - - - - - - - - - - -
route[1]
{
if(msg:len > 2048)
{
sl_send_reply("513", "Message Too Big");
exit;
}
if (!mf_process_maxfwd_header("10"))
{
sl_send_reply("483", "Too Many Hops");
exit;
}
if (method==OPTIONS) {
if ((uri==myself) && (! uri=~"sip:.*[@]+.*")) {
options_reply();
exit;
}
}
if (!method=="REGISTER")
{
record_route();
}
if (loose_route())
{
append_hf("P-hint: rr-enforced\r\n");
}
if (is_method("CANCEL"))
{
if (t_check_trans())
{
t_relay();
}
exit;
}
route(2);
}
# - - - - - - - - - - - - - - - - - - - -
route[2]
{
xlog("L_INFO", "Attempting Carrier 1");
t_on_failure("3");
t_relay("udp:1.1.1.1:5090","0x2");
exit;
}
# - - - - - - - - - - - - - - - - - - - -
failure_route[3]
{
xlog("L_INFO", "Attempting Carrier 2");
t_on_failure("4");
t_relay("udp:2.2.2.2:5060");
exit;
}
# - - - - - - - - - - - - - - - - - - - -
failure_route[4]
{
# I would like to know how to redirect the
# original call destined to extension "100"
# to 2015551234, but the originating server
# will get nervous if the username@ part
# of its SIP request is changed. How could
}
# - - - - - - - - - - - - - - - - - - - -
Any further suggestions would be appreciated. Thanks!
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users