[OpenSIPS-Users] One dispatcher mystery solved; Doesn't seem to be "remembering" a gateway is failed however
Jock McKechnie
jock.mckechnie at gmail.com
Thu Apr 8 20:45:46 CEST 2010
Hey all;
So I worked out what was going on with my previous test, where the failover
route wasn't being called - as Bogdan pointed out, it was a TCP failure,
because I was /sbin/route rejecting. If I actually simulated a failure on
the destination server OpenSIPS' fr_timer caught it and it was pushed into
the failure_block correctly. I was, apparently, being too clever for my own
good.
My next problem is along the same vein - I continue to get dispatcher
failing over reliably (which it is now doing, hurrah!): I'm marking the
gateway as bad on a timeout, however it doesn't seem to want to remember
that the gateway is bad. I've got probing turned on, and I'm marking it to
be probed, but even an immediately subsequent call (within seconds of the
first call marking the gateway as bad) is routed back to that first gateway.
Now the failover works, it's cleanly moving onto the next host, which is
nice - but I'd still like to utilise the probing scheme, if I can.
I'm also getting a rather curious error in the logs:
Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using first
entry...
Attempting to relay call to sip:+12125551212 at 192.168.0.99:5060
FR: 204c758872fc3aa520599fd52a404783 at 192.168.0.2 -- TIMEOUT for Gateway
192.168.0.99 (marking as bad)
ERROR:core:search_first_avp: 0 ID or NULL NAME AVP!
I'm wondering if the above error is some kind of AVP storage thing I haven't
set up that is causing it not to properly "mark" the gateway, or more
likely, not remember the mark. But I can't spot anything in the dispatcher
documentation that says as such.
Relevant (hopefully) sections (cut-up config, this is not whole):
Parameters initialisation:
# Timers and failover flags
modparam("tm", "wt_timer", 30)
modparam("tm", "fr_timer", 3)
modparam("tm", "fr_inv_timer", 120)
modparam("tm", "disable_6xx_block", 1)
# Set up the dispatcher
modparam("dispatcher", "db_url", "mysql://
openser:password at 192.168.0.20/company")
modparam("dispatcher", "table_name", "dispatcher")
modparam("dispatcher", "flags", 2 )
modparam("dispatcher", "dst_avp", "$avp(i:271)")
modparam("dispatcher", "grp_avp", "$avp(i:272)")
modparam("dispatcher", "cnt_avp", "$avp(i:273)")
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_interval", 5)
modparam("dispatcher", "ds_ping_from",
"sip:+14109999351 at 192.168.0.2<sip%3A%2B14109999351 at 192.168.0.2>
")
modparam("dispatcher", "ds_probing_threshhold", 3)
Abbreviated main route block with route/failure_route blocks
route{
xlog( "L_INFO", "[$Tf] Found failover, working on set: 1101\n");
if (!ds_select_domain("1101","8")) {
t_reply("503","Unable to locate failover set requested");
return;
};
route(1);
}
route[1] {
# Enable the failure block only on dispatcher lists which we can
fail over
t_on_failure("2");
xlog( "L_NOTICE", "[$Tf] Attempting to relay call to $ru\n");
if( !t_relay() ){
return;
}
return;
}
failure_route[2] {
if (t_was_cancelled()) {
exit;
}
if( t_check_status("408") ){
xlog( "L_NOTICE", "[$Tf] FR: $ci -- TIMEOUT for Gateway $rd
(marking as bad)\n" );
ds_mark_dst("p");
}
if( ds_next_domain() ){
t_on_failure("2");
if (!t_relay()) {
return;
}
return;
} else {
t_reply("503", "Service unavailable -- no more gateways" );
return;
}
}
As always, folks, I appreciate all your help. Enjoy your Thursday;
- Jock
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20100408/c5c8ec41/attachment-0001.htm
More information about the Users
mailing list