Re: [OpenSIPS-Users] dispatcher fail-over doesn't seem happy
Hi Jock,
My approach was to use a common subroute (try_next) to be used from
both failure route (if you get a failure at SIP level) and from main
route, if relay fails. Of course the t_was_cancelled() needs to be kept
in failure route (as it is specific to that type of route) :
oute[try_next] {
here put the next stuff
}
{
...
t_on_failure(sip_failure);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
route(try_next);
}
...
}
failure_route[sip_failure]
{
if (t_was_cancelled()) {
..
}
if (t_check_status() {
# is a destination failure
route(try_next);
}
}
on the ds_next_xxx () - it is documented to be triggered only from
failure route, but it is a bit too restrictive - you can safely call it
from this shared try_next subroute.
Regards,
Bogdan
Jock McKechnie wrote:
Greetings Bogdan;
Unfortunately there's a minor hitch in the getalong with this
suggestion - the failure route utilises two functions that can only be
called from a failure_route block (t_was_cancelled() and
ds_next_domain()).
From my understanding of what you're suggesting below, I should move
my failure logic into its own route block and then call it, both from
the failure_route block and from the t_relay() failed section. This
would be a very elegant way to handle it, if I could use it :)
It appears there is no 'back door' method of calling a failure_route()
block from inside a route block, as in:
if (!t_relay()) {
failure_route(2);
}
Any new thoughts?
Many thanks, both of you.
- JP
On Fri, Apr 2, 2010 at 2:58 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro mailto:bog...@voice-system.ro wrote:
Hi Jock,
I guess the problem is detecting the failure . The failure route
catches
only SIP failures (like you sent the requests and you get nothing or
negative reply); but failure route does not catch sending error
(like in
your case).
So, you should do something like:
route[try_next] {
here put the next stuff
}
{
...
t_on_failure(sip_failure);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
route(try_next);
}
...
}
failure_route[sip_failure]
{
if (t_check_status() {
# is a destination failure
route(try_next);
}
}
Regards,
bogdan
Jock McKechnie wrote:
On Thu, Apr 1, 2010 at 10:26 AM, Brett Nemeroff
br...@nemeroff.com mailto:br...@nemeroff.com
mailto:br...@nemeroff.com mailto:br...@nemeroff.com wrote:
Where is your failure route? :)
-Brett
I intentionally chose to not include it, along with the other 200
lines of config, for simplicity, but you're right, given this is a
failure, I clearly should've, duh :)
failure_route[2] {
if (t_was_cancelled()) {
xlog( L_NOTICE, [$Tf] FR: transaction cancelled -
exiting\n );
exit;
}
# If fr_timer expires t_check_status(408) is true,
although
$rs is null
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd\n );
} else {
xlog( L_NOTICE, [$Tf] FR: $ci -- $rs reason
$rr\n );
}
# 403 -- typically ISDN network says 'not a valid
number' etc..
if( t_check_status(403) ){
xlog(L_WARN, [$Tf] FR: $ci -- SIP-$rs
Forbidden -
ISDN Cause Code 1\n );
return;
}
if( ds_next_domain() ){
xlog( L_NOTICE, [$Tf] FR: $ci Next gateway $fU -
$tU via $rd \n );
t_on_failure(2);
if( !t_relay() ){
xlog( L_WARN, [$Tf] FR: $ci -- ERROR -
Cannot t_relay() -- $fU - $tU via $rd\n );
return;
}
return;
} else {
xlog( L_WARN, [$Tf] FR: $ci No more gateways -
503.\n );
t_reply(503, Service unavailable -- no more
gateways );
return;
}
}
- Jock
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com mailto:jock.mckech...@gmail.com
mailto:jock.mckech...@gmail.com
mailto:jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using
dispatcher and am
encountering some problems. I'm using dispatcher since
we're already
Re: [OpenSIPS-Users] dispatcher fail-over doesn't seem happy
Bogdan,
I think the ds_next_doman in the failure route should have been
called. On the initial t_relay, the failure route was already armed
and should have caught send failures. The top of the failure route
catches specific SIP codes, but the bottom half, including the
ds_next_domain should have fired for the send failure. Right?
Jock,
What's showing up in the logs around the send failure?
-Brett
On Fri, Apr 2, 2010 at 3:58 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Hi Jock,
I guess the problem is detecting the failure . The failure route catches
only SIP failures (like you sent the requests and you get nothing or
negative reply); but failure route does not catch sending error (like in
your case).
So, you should do something like:
route[try_next] {
here put the next stuff
}
{
...
t_on_failure(sip_failure);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
route(try_next);
}
...
}
failure_route[sip_failure]
{
if (t_check_status() {
# is a destination failure
route(try_next);
}
}
Regards,
bogdan
Jock McKechnie wrote:
On Thu, Apr 1, 2010 at 10:26 AM, Brett Nemeroff br...@nemeroff.com
mailto:br...@nemeroff.com wrote:
Where is your failure route? :)
-Brett
I intentionally chose to not include it, along with the other 200
lines of config, for simplicity, but you're right, given this is a
failure, I clearly should've, duh :)
failure_route[2] {
if (t_was_cancelled()) {
xlog( L_NOTICE, [$Tf] FR: transaction cancelled -
exiting\n );
exit;
}
# If fr_timer expires t_check_status(408) is true, although
$rs is null
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd\n );
} else {
xlog( L_NOTICE, [$Tf] FR: $ci -- $rs reason $rr\n );
}
# 403 -- typically ISDN network says 'not a valid number' etc..
if( t_check_status(403) ){
xlog(L_WARN, [$Tf] FR: $ci -- SIP-$rs Forbidden -
ISDN Cause Code 1\n );
return;
}
if( ds_next_domain() ){
xlog( L_NOTICE, [$Tf] FR: $ci Next gateway $fU -
$tU via $rd \n );
t_on_failure(2);
if( !t_relay() ){
xlog( L_WARN, [$Tf] FR: $ci -- ERROR -
Cannot t_relay() -- $fU - $tU via $rd\n );
return;
}
return;
} else {
xlog( L_WARN, [$Tf] FR: $ci No more gateways -
503.\n );
t_reply(503, Service unavailable -- no more
gateways );
return;
}
}
- Jock
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com mailto:jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using
dispatcher and am
encountering some problems. I'm using dispatcher since we're already
utilising it for load balancing, so it makes sense to reuse the
tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it
supports
fail-over.
If the destination server is running, everything works as
expected - algo 8
(which OpenSIPS logs as not found and defaulting to the first
entry) pushes
the call to the first server at all times. However if I block
the route to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$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] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
The log contains:
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using
first
entry...
Attempting to relay call to sip:+12125551...@192.168.0.99:5060
http://sip:+12125551...@192.168.0.99:5060
ERROR:core:udp_send:
sendto(sock,0xb3b9bd28,1039,0,0xb3ba2cf4,16): Network
is unreachable(101)
ERROR:tm:msg_send: udp_send failed
ERROR:tm:t_forward_nonack: sending request failed
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using
first
entry...
Attempting to relay call
Re: [OpenSIPS-Users] dispatcher fail-over doesn't seem happy
Brett,
if t_relay() fails (whatever reason, like transport issues, IP problems,
URI problems, etc), it will not end up in failure route! failure route
is for SIP failures, not for any kind of failures.
Also see the 0x02 flag in t_relay() docs:
http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id266164
Regards,
Bogdan
Brett Nemeroff wrote:
Bogdan,
I think the ds_next_doman in the failure route should have been
called. On the initial t_relay, the failure route was already armed
and should have caught send failures. The top of the failure route
catches specific SIP codes, but the bottom half, including the
ds_next_domain should have fired for the send failure. Right?
Jock,
What's showing up in the logs around the send failure?
-Brett
On Fri, Apr 2, 2010 at 3:58 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Hi Jock,
I guess the problem is detecting the failure . The failure route catches
only SIP failures (like you sent the requests and you get nothing or
negative reply); but failure route does not catch sending error (like in
your case).
So, you should do something like:
route[try_next] {
here put the next stuff
}
{
...
t_on_failure(sip_failure);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
route(try_next);
}
...
}
failure_route[sip_failure]
{
if (t_check_status() {
# is a destination failure
route(try_next);
}
}
Regards,
bogdan
Jock McKechnie wrote:
On Thu, Apr 1, 2010 at 10:26 AM, Brett Nemeroff br...@nemeroff.com
mailto:br...@nemeroff.com wrote:
Where is your failure route? :)
-Brett
I intentionally chose to not include it, along with the other 200
lines of config, for simplicity, but you're right, given this is a
failure, I clearly should've, duh :)
failure_route[2] {
if (t_was_cancelled()) {
xlog( L_NOTICE, [$Tf] FR: transaction cancelled -
exiting\n );
exit;
}
# If fr_timer expires t_check_status(408) is true, although
$rs is null
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd\n );
} else {
xlog( L_NOTICE, [$Tf] FR: $ci -- $rs reason $rr\n );
}
# 403 -- typically ISDN network says 'not a valid number' etc..
if( t_check_status(403) ){
xlog(L_WARN, [$Tf] FR: $ci -- SIP-$rs Forbidden -
ISDN Cause Code 1\n );
return;
}
if( ds_next_domain() ){
xlog( L_NOTICE, [$Tf] FR: $ci Next gateway $fU -
$tU via $rd \n );
t_on_failure(2);
if( !t_relay() ){
xlog( L_WARN, [$Tf] FR: $ci -- ERROR -
Cannot t_relay() -- $fU - $tU via $rd\n );
return;
}
return;
} else {
xlog( L_WARN, [$Tf] FR: $ci No more gateways -
503.\n );
t_reply(503, Service unavailable -- no more
gateways );
return;
}
}
- Jock
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com mailto:jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using
dispatcher and am
encountering some problems. I'm using dispatcher since we're already
utilising it for load balancing, so it makes sense to reuse the
tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it
supports
fail-over.
If the destination server is running, everything works as
expected - algo 8
(which OpenSIPS logs as not found and defaulting to the first
entry) pushes
the call to the first server at all times. However if I block
the route to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$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] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
The log contains:
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using
first
entry...
Attempting to relay call to sip:+12125551...@192.168.0.99:5060
http://sip:+12125551...@192.168.0.99:5060
ERROR:core:udp_send:
Re: [OpenSIPS-Users] dispatcher fail-over doesn't seem happy
Ok, that makes sense actually..
so this block:
route[1] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
Instead of firing failure_route[2] (since it isn't a SIP failure)
it'll hit the xlog and return.
So what kind of send failures cause this? unroutable addresses? DNS
resolution errors? bad data? I've noticed that if I t_relay to
something fake like 1.2.3.4 that I'll end up with a 408 in a failure
route.. I think...
Thanks,
Brett
On Fri, Apr 2, 2010 at 8:21 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Brett,
if t_relay() fails (whatever reason, like transport issues, IP problems,
URI problems, etc), it will not end up in failure route! failure route
is for SIP failures, not for any kind of failures.
Also see the 0x02 flag in t_relay() docs:
http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id266164
Regards,
Bogdan
Brett Nemeroff wrote:
Bogdan,
I think the ds_next_doman in the failure route should have been
called. On the initial t_relay, the failure route was already armed
and should have caught send failures. The top of the failure route
catches specific SIP codes, but the bottom half, including the
ds_next_domain should have fired for the send failure. Right?
Jock,
What's showing up in the logs around the send failure?
-Brett
On Fri, Apr 2, 2010 at 3:58 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Hi Jock,
I guess the problem is detecting the failure . The failure route catches
only SIP failures (like you sent the requests and you get nothing or
negative reply); but failure route does not catch sending error (like in
your case).
So, you should do something like:
route[try_next] {
here put the next stuff
}
{
...
t_on_failure(sip_failure);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
route(try_next);
}
...
}
failure_route[sip_failure]
{
if (t_check_status() {
# is a destination failure
route(try_next);
}
}
Regards,
bogdan
Jock McKechnie wrote:
On Thu, Apr 1, 2010 at 10:26 AM, Brett Nemeroff br...@nemeroff.com
mailto:br...@nemeroff.com wrote:
Where is your failure route? :)
-Brett
I intentionally chose to not include it, along with the other 200
lines of config, for simplicity, but you're right, given this is a
failure, I clearly should've, duh :)
failure_route[2] {
if (t_was_cancelled()) {
xlog( L_NOTICE, [$Tf] FR: transaction cancelled -
exiting\n );
exit;
}
# If fr_timer expires t_check_status(408) is true, although
$rs is null
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd\n );
} else {
xlog( L_NOTICE, [$Tf] FR: $ci -- $rs reason $rr\n );
}
# 403 -- typically ISDN network says 'not a valid number' etc..
if( t_check_status(403) ){
xlog(L_WARN, [$Tf] FR: $ci -- SIP-$rs Forbidden -
ISDN Cause Code 1\n );
return;
}
if( ds_next_domain() ){
xlog( L_NOTICE, [$Tf] FR: $ci Next gateway $fU -
$tU via $rd \n );
t_on_failure(2);
if( !t_relay() ){
xlog( L_WARN, [$Tf] FR: $ci -- ERROR -
Cannot t_relay() -- $fU - $tU via $rd\n );
return;
}
return;
} else {
xlog( L_WARN, [$Tf] FR: $ci No more gateways -
503.\n );
t_reply(503, Service unavailable -- no more
gateways );
return;
}
}
- Jock
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com mailto:jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using
dispatcher and am
encountering some problems. I'm using dispatcher since we're already
utilising it for load balancing, so it makes sense to reuse the
tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it
supports
fail-over.
If the destination server is running, everything works as
expected - algo 8
(which OpenSIPS logs as not found and defaulting to the first
entry) pushes
the call to the first server at all times. However if I block
the route to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$Tf] Found failover, working on set: 1101\n);
if (!ds_select_domain(1101, 8)) {
t_reply(503, Unable to locate failover set requested);
return;
Re: [OpenSIPS-Users] dispatcher fail-over doesn't seem happy
I think jock case was internal blacklisting (in opensips) of the
destination IP.
Regards,
Bogdan
Brett Nemeroff wrote:
Ok, that makes sense actually..
so this block:
route[1] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
Instead of firing failure_route[2] (since it isn't a SIP failure)
it'll hit the xlog and return.
So what kind of send failures cause this? unroutable addresses? DNS
resolution errors? bad data? I've noticed that if I t_relay to
something fake like 1.2.3.4 that I'll end up with a 408 in a failure
route.. I think...
Thanks,
Brett
On Fri, Apr 2, 2010 at 8:21 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Brett,
if t_relay() fails (whatever reason, like transport issues, IP problems,
URI problems, etc), it will not end up in failure route! failure route
is for SIP failures, not for any kind of failures.
Also see the 0x02 flag in t_relay() docs:
http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id266164
Regards,
Bogdan
Brett Nemeroff wrote:
Bogdan,
I think the ds_next_doman in the failure route should have been
called. On the initial t_relay, the failure route was already armed
and should have caught send failures. The top of the failure route
catches specific SIP codes, but the bottom half, including the
ds_next_domain should have fired for the send failure. Right?
Jock,
What's showing up in the logs around the send failure?
-Brett
On Fri, Apr 2, 2010 at 3:58 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Hi Jock,
I guess the problem is detecting the failure . The failure route catches
only SIP failures (like you sent the requests and you get nothing or
negative reply); but failure route does not catch sending error (like in
your case).
So, you should do something like:
route[try_next] {
here put the next stuff
}
{
...
t_on_failure(sip_failure);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
route(try_next);
}
...
}
failure_route[sip_failure]
{
if (t_check_status() {
# is a destination failure
route(try_next);
}
}
Regards,
bogdan
Jock McKechnie wrote:
On Thu, Apr 1, 2010 at 10:26 AM, Brett Nemeroff br...@nemeroff.com
mailto:br...@nemeroff.com wrote:
Where is your failure route? :)
-Brett
I intentionally chose to not include it, along with the other 200
lines of config, for simplicity, but you're right, given this is a
failure, I clearly should've, duh :)
failure_route[2] {
if (t_was_cancelled()) {
xlog( L_NOTICE, [$Tf] FR: transaction cancelled -
exiting\n );
exit;
}
# If fr_timer expires t_check_status(408) is true, although
$rs is null
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd\n );
} else {
xlog( L_NOTICE, [$Tf] FR: $ci -- $rs reason $rr\n );
}
# 403 -- typically ISDN network says 'not a valid number' etc..
if( t_check_status(403) ){
xlog(L_WARN, [$Tf] FR: $ci -- SIP-$rs Forbidden -
ISDN Cause Code 1\n );
return;
}
if( ds_next_domain() ){
xlog( L_NOTICE, [$Tf] FR: $ci Next gateway $fU -
$tU via $rd \n );
t_on_failure(2);
if( !t_relay() ){
xlog( L_WARN, [$Tf] FR: $ci -- ERROR -
Cannot t_relay() -- $fU - $tU via $rd\n );
return;
}
return;
} else {
xlog( L_WARN, [$Tf] FR: $ci No more gateways -
503.\n );
t_reply(503, Service unavailable -- no more
gateways );
return;
}
}
- Jock
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com mailto:jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using
dispatcher and am
encountering some problems. I'm using dispatcher since we're already
utilising it for load balancing, so it makes sense to reuse the
tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it
supports
fail-over.
If the destination server is running, everything works as
expected - algo 8
(which OpenSIPS logs as not found and defaulting to the first
entry) pushes
the call to the first server at all times. However if I block
the route to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$Tf]
Re: [OpenSIPS-Users] dispatcher fail-over doesn't seem happy
Greetings Bogdan;
Unfortunately there's a minor hitch in the getalong with this suggestion -
the failure route utilises two functions that can only be called from a
failure_route block (t_was_cancelled() and ds_next_domain()).
From my understanding of what you're suggesting below, I should move my
failure logic into its own route block and then call it, both from the
failure_route block and from the t_relay() failed section. This would be a
very elegant way to handle it, if I could use it :)
It appears there is no 'back door' method of calling a failure_route() block
from inside a route block, as in:
if (!t_relay()) {
failure_route(2);
}
Any new thoughts?
Many thanks, both of you.
- JP
On Fri, Apr 2, 2010 at 2:58 AM, Bogdan-Andrei Iancu
bog...@voice-system.rowrote:
Hi Jock,
I guess the problem is detecting the failure . The failure route catches
only SIP failures (like you sent the requests and you get nothing or
negative reply); but failure route does not catch sending error (like in
your case).
So, you should do something like:
route[try_next] {
here put the next stuff
}
{
...
t_on_failure(sip_failure);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
route(try_next);
}
...
}
failure_route[sip_failure]
{
if (t_check_status() {
# is a destination failure
route(try_next);
}
}
Regards,
bogdan
Jock McKechnie wrote:
On Thu, Apr 1, 2010 at 10:26 AM, Brett Nemeroff br...@nemeroff.com
mailto:br...@nemeroff.com wrote:
Where is your failure route? :)
-Brett
I intentionally chose to not include it, along with the other 200
lines of config, for simplicity, but you're right, given this is a
failure, I clearly should've, duh :)
failure_route[2] {
if (t_was_cancelled()) {
xlog( L_NOTICE, [$Tf] FR: transaction cancelled -
exiting\n );
exit;
}
# If fr_timer expires t_check_status(408) is true, although
$rs is null
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd\n );
} else {
xlog( L_NOTICE, [$Tf] FR: $ci -- $rs reason $rr\n );
}
# 403 -- typically ISDN network says 'not a valid number' etc..
if( t_check_status(403) ){
xlog(L_WARN, [$Tf] FR: $ci -- SIP-$rs Forbidden -
ISDN Cause Code 1\n );
return;
}
if( ds_next_domain() ){
xlog( L_NOTICE, [$Tf] FR: $ci Next gateway $fU -
$tU via $rd \n );
t_on_failure(2);
if( !t_relay() ){
xlog( L_WARN, [$Tf] FR: $ci -- ERROR -
Cannot t_relay() -- $fU - $tU via $rd\n );
return;
}
return;
} else {
xlog( L_WARN, [$Tf] FR: $ci No more gateways -
503.\n );
t_reply(503, Service unavailable -- no more
gateways );
return;
}
}
- Jock
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com mailto:jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using
dispatcher and am
encountering some problems. I'm using dispatcher since we're
already
utilising it for load balancing, so it makes sense to reuse the
tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it
supports
fail-over.
If the destination server is running, everything works as
expected - algo 8
(which OpenSIPS logs as not found and defaulting to the first
entry) pushes
the call to the first server at all times. However if I block
the route to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$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] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
The log contains:
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using
first
entry...
Attempting to relay call to sip:+12125551...@192.168.0.99:5060
[OpenSIPS-Users] dispatcher fail-over doesn't seem happy
Greetings all;
I'm attempting to set up a fail-over only scenario using dispatcher and am
encountering some problems. I'm using dispatcher since we're already
utilising it for load balancing, so it makes sense to reuse the tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it supports
fail-over.
If the destination server is running, everything works as expected - algo 8
(which OpenSIPS logs as not found and defaulting to the first entry) pushes
the call to the first server at all times. However if I block the route to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$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] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
The log contains:
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using first
entry...
Attempting to relay call to sip:+12125551...@192.168.0.99:5060
ERROR:core:udp_send: sendto(sock,0xb3b9bd28,1039,0,0xb3ba2cf4,16): Network
is unreachable(101)
ERROR:tm:msg_send: udp_send failed
ERROR:tm:t_forward_nonack: sending request failed
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using first
entry...
Attempting to relay call to sip:+12125551...@192.168.0.99:5060
This suggests to me that instead of failing over it's simply retrying the
first entry, which it shouldn't be, and after finding it out for a second
time (and thus exhausting the two-entry set), gives up.
Any thoughts?
- JP
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] dispatcher fail-over doesn't seem happy
Where is your failure route? :)
-Brett
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using dispatcher and am
encountering some problems. I'm using dispatcher since we're already
utilising it for load balancing, so it makes sense to reuse the tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it supports
fail-over.
If the destination server is running, everything works as expected - algo 8
(which OpenSIPS logs as not found and defaulting to the first entry) pushes
the call to the first server at all times. However if I block the route to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$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] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
The log contains:
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using first
entry...
Attempting to relay call to sip:+12125551...@192.168.0.99:5060
ERROR:core:udp_send: sendto(sock,0xb3b9bd28,1039,0,0xb3ba2cf4,16): Network
is unreachable(101)
ERROR:tm:msg_send: udp_send failed
ERROR:tm:t_forward_nonack: sending request failed
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using first
entry...
Attempting to relay call to sip:+12125551...@192.168.0.99:5060
This suggests to me that instead of failing over it's simply retrying the
first entry, which it shouldn't be, and after finding it out for a second
time (and thus exhausting the two-entry set), gives up.
Any thoughts?
- JP
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] dispatcher fail-over doesn't seem happy
On Thu, Apr 1, 2010 at 10:26 AM, Brett Nemeroff br...@nemeroff.com wrote:
Where is your failure route? :)
-Brett
I intentionally chose to not include it, along with the other 200 lines of
config, for simplicity, but you're right, given this is a failure, I clearly
should've, duh :)
failure_route[2] {
if (t_was_cancelled()) {
xlog( L_NOTICE, [$Tf] FR: transaction cancelled -
exiting\n );
exit;
}
# If fr_timer expires t_check_status(408) is true, although $rs is
null
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for Gateway
$rd\n );
} else {
xlog( L_NOTICE, [$Tf] FR: $ci -- $rs reason $rr\n );
}
# 403 -- typically ISDN network says 'not a valid number' etc..
if( t_check_status(403) ){
xlog(L_WARN, [$Tf] FR: $ci -- SIP-$rs Forbidden - ISDN
Cause Code 1\n );
return;
}
if( ds_next_domain() ){
xlog( L_NOTICE, [$Tf] FR: $ci Next gateway $fU - $tU via
$rd \n );
t_on_failure(2);
if( !t_relay() ){
xlog( L_WARN, [$Tf] FR: $ci -- ERROR - Cannot
t_relay() -- $fU - $tU via $rd\n );
return;
}
return;
} else {
xlog( L_WARN, [$Tf] FR: $ci No more gateways - 503.\n
);
t_reply(503, Service unavailable -- no more gateways );
return;
}
}
- Jock
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using dispatcher and
am
encountering some problems. I'm using dispatcher since we're already
utilising it for load balancing, so it makes sense to reuse the tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it supports
fail-over.
If the destination server is running, everything works as expected - algo
8
(which OpenSIPS logs as not found and defaulting to the first entry)
pushes
the call to the first server at all times. However if I block the route
to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$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] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
The log contains:
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using first
entry...
Attempting to relay call to sip:+12125551...@192.168.0.99:5060
ERROR:core:udp_send: sendto(sock,0xb3b9bd28,1039,0,0xb3ba2cf4,16):
Network
is unreachable(101)
ERROR:tm:msg_send: udp_send failed
ERROR:tm:t_forward_nonack: sending request failed
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using first
entry...
Attempting to relay call to sip:+12125551...@192.168.0.99:5060
This suggests to me that instead of failing over it's simply retrying the
first entry, which it shouldn't be, and after finding it out for a second
time (and thus exhausting the two-entry set), gives up.
Any thoughts?
- JP
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
