<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hey All,<br>
<br>
Ok, so I've been messing around with this all day. From what I can
tell the best way to do this might be with AVP Ops. <br>
<br>
So I'm trying to serial forking to work with AVPOps based on the
examples at
<a class="moz-txt-link-freetext" href="http://www.voice-system.ro/docs/avpops/ar01s08.html#ex_serial_forking">http://www.voice-system.ro/docs/avpops/ar01s08.html#ex_serial_forking</a>
. However, the documentation seems to be lacking a bit. Either that,
or I'm just making it more difficult than it should be.. which is
possible. :) There's no mention of how to create the necessary
database table, what the schema should be, or how the data should be
entered into the DB for it to be loaded correctly for serial forking
with avp_db_load.<br>
<br>
My question is, does anyone have this working? and if so.. Do you have
a working config example that I can look at? Plus, the corresponding
database entries?<br>
<br>
Thank you!<br>
Darren Nay<br>
<br>
<br>
Darren Nay wrote:
<blockquote cite="mid44282C6E.8010900@ionosphere.net" type="cite">Hello
All,
<br>
<br>
I am having a problem with the t_on_failure failure route using SER. I
have been using SER for 2+ years now and am servicing 5000+ voip
customers but now we are moving to a PSTN termination partner who does
not have redundant gateways. So I would like to setup SER so that I
have call route advance to a 2nd PSTN carrier if the 1st fails.
However, I am running into some snags...
<br>
<br>
With my configuration the call is processed correctly if the 1st PSTN
carrier takes the call. However, when the failover happens then I get
some odd behavior. The call is initially setup correctly with the
failover carrier, but then it hangs up after about 5-7 seconds and a
new call comes in to the called number, and a loop begins where this
same call keeps coming in one after another until SER is restarted.
<br>
<br>
I do get the following errors on the SER console.
<br>
<br>
0(17304) forward_req: ERROR: cannot forward to af 2, proto 2 no
corresponding listening socket
<br>
0(17304) Warning: sl_send_reply: I won't send a reply for ACK!!
<br>
0(17304) ERROR: sl_reply_error used: I'm terribly sorry, server error
occurred (7/SL)
<br>
<br>
It almost seems as if the the 1st route PSTN carrier is not accepting
my ACK when I send it in response to the 403 Forbidden that they send
to me. Then they just keep sending the 403 Forbidden over and over
again. Each time that they do that then SER processes it as a failed
call and starts a new call to the secondary PSTN carrier. Does this
sound possible? Or am I way off base here? <br>
I have attached my basic lab test SER cfg that I have been using to
test with. Perhaps someone can tell me what I might be doing
incorrectly?
<br>
<br>
Or - Is there a better way to do this? ie. With AVP-Pops? If so, does
anyone have a sample configuration that I can look at?
<br>
<br>
Thanks so much for any help provided!!
<br>
<br>
Darren Nay
<br>
Ionosphere, Inc.
<br>
<a class="moz-txt-link-abbreviated" href="mailto:dnay@ionosphere.net">dnay@ionosphere.net</a>
<br>
+1 864-678-3158
<br>
<br>
<br>
<br>
<pre wrap="">
<hr size="4" width="90%">
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=no # (cmd line: -E)
memlog=0
#uncomment for debug mode
debug=3
fork=no
log_stderror=yes
#Bind IP
listen=XX.XX.XX.XX
check_via=no # (cmd. line: -v)
dns=yes # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=5
mhomed=no # multi-homed?
fifo="/tmp/ser_fifo"
# ------------------ module loading ----------------------------------
loadmodule "/usr/local/lib/ser/modules/nathelper.so"
loadmodule "/usr/local/lib/ser/modules/textops.so"
loadmodule "/usr/local/lib/ser/modules/sl.so"
loadmodule "/usr/local/lib/ser/modules/tm.so"
loadmodule "/usr/local/lib/ser/modules/rr.so"
loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
loadmodule "/usr/local/lib/ser/modules/usrloc.so"
loadmodule "/usr/local/lib/ser/modules/registrar.so"
loadmodule "/usr/local/lib/ser/modules/xlog.so"
# ----------------- setting module-specific parameters ---------------
# -- timers --
modparam("tm", "wt_timer", 10)
modparam("tm", "retr_timer1p1", 2)
# -- usrloc params --
modparam("usrloc", "db_mode", 0)
# -- rr params --
modparam("rr", "enable_full_lr", 1)
# -- Nathelper --
modparam("registrar", "nat_flag", 6)
modparam("nathelper", "natping_interval", 10)
modparam("nathelper", "ping_nated_only", 1)
modparam("nathelper", "rtpproxy_disable", 1)
alias=proxy.ionosphere.net
# ------------------------- request routing logic -------------------
# main routing logic
route {
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if (msg:len > max_len) {
sl_send_reply("513", "Message too big");
break;
};
# Nathelper
if (method == "REGISTER" || !search("^Record-Route:.*XX.XX.XX.XX")) {
fix_nated_contact(); # Rewrite contact with source IP of signaling
force_rport();
setflag(6);
};
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
if (!method=="REGISTER") record_route();
# loose-route processing
if (loose_route()) {
route(1);
break;
};
lookup("aliases");
if (!uri==myself) {
route(1);
break;
};
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
if (method=="REGISTER") {
fix_nated_register();
save("location");
break;
};
};
### Process URI routing
# Now we determine if called number is on
# or off net and route accordingly
if (!lookup("location")) {
route(2); # Nothing found - Route Off-Net
} else {
route(1); # Direct match - Route On-Net
};
}
#
# No direct route via location or location_novm (Off-Net Route)
#
route[2]
{
t_on_failure("2");
#Send the call to Level3
rewritehostport("XX.XX.XX.XX:5060");
if (!t_relay()) {
sl_reply_error();
};
break;
}
#
# Direct route found via location or location_novm (On-Net Route)
#
route[1]
{
# !! Nathelper
if (uri=~<a class="moz-txt-link-rfc2396E" href="mailto:[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)">"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)"</a> && !search("^Route:")) {
sl_send_reply("479", "We don't forward to private IP addresses");
break;
};
# if client or server know to be behind a NAT, enable relay
if (isflagset(6)) {
# NAT processing of replies; apply to all transactions (for example,
# re-INVITEs from public to private UA are hard to identify as
# NATed at the moment of request processing); look at replies
t_on_reply("1");
append_hf("P-Behind-NAT: Yes\r\n");
};
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
}
onreply_route[1] {
if (status =~ "(183)|(180)|2[0-9][0-9]") {
fix_nated_contact();
};
if (nat_uac_test("1")) {
fix_nated_contact();
};
break;
}
failure_route[2] {
# forwarding failed try again at another destination
rewritehostport("XX.XX.XX.XX:5060");
append_branch();
t_relay();
break;
}
</pre>
</blockquote>
</body>
</html>