[OpenSIPS-Users] dispatcher "fail-over" doesn't seem happy

Brett Nemeroff brett at nemeroff.com
Fri Apr 2 16:26:48 CEST 2010


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
<bogdan at 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
>> <bogdan at 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 <brett at nemeroff.com
>>>> <mailto:brett at 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.mckechnie at gmail.com <mailto:jock.mckechnie at 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:+12125551212 at 192.168.0.99:5060
>>>>     <http://sip:+12125551212@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:+12125551212 at 192.168.0.99:5060
>>>>     <http://sip:+12125551212@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 at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>>     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>     >
>>>>     >
>>>>
>>>>     _______________________________________________
>>>>     Users mailing list
>>>>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>> --
>>> Bogdan-Andrei Iancu
>>> www.voice-system.ro
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> --
> Bogdan-Andrei Iancu
> www.voice-system.ro
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



More information about the Users mailing list