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>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

Reply via email to