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

Bogdan-Andrei Iancu bogdan at voice-system.ro
Fri Apr 2 15:21:27 CEST 2010


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




More information about the Users mailing list