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; >>>> > }; >>>> > >>>> > 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 to sip:+12125551...@192.168.0.99:5060 >>>> <http://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 <mailto:Users@lists.opensips.org> >>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> > >>>> > >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users@lists.opensips.org <mailto: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 >>>> >>>> >>> -- >>> Bogdan-Andrei Iancu >>> www.voice-system.ro >>> >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > Bogdan-Andrei Iancu > www.voice-system.ro > > > _______________________________________________ > 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