[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