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

Bogdan-Andrei Iancu bogdan at voice-system.ro
Fri Apr 2 16:31:12 CEST 2010


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