Hi, I'd like to understand how TM module filters "sometimes" some calls. For now, I just think it there isn't response and the call is repeated sometimes then TM module filteres the following calls.
I find no info about how it works in the doc, could somebody give me a link or so to a document with the explanation of this issue?
Thanks a lot.
On Monday 30 July 2007, Iñaki Baz Castillo wrote:
Hi, I'd like to understand how TM module filters "sometimes" some calls. For now, I just think it there isn't response and the call is repeated sometimes then TM module filteres the following calls.
I find no info about how it works in the doc, could somebody give me a link or so to a document with the explanation of this issue?
Thanks a lot.
This cause for this problem is probably the auto blacklisting feature of openser, that is unfortunally (IMHO) enabled by default.
http://www.openser.org/dokuwiki/doku.php/core-cookbook:1.2.x#disable_dns_bla... http://openser.org/pipermail/users/2007-January/008848.html
Just disable this feature the openser config.
Cheers,
Henning
El Monday 30 July 2007 12:45:41 Henning Westerholt escribió:
On Monday 30 July 2007, Iñaki Baz Castillo wrote:
Hi, I'd like to understand how TM module filters "sometimes" some calls. For now, I just think it there isn't response and the call is repeated sometimes then TM module filteres the following calls.
I find no info about how it works in the doc, could somebody give me a link or so to a document with the explanation of this issue?
Thanks a lot.
This cause for this problem is probably the auto blacklisting feature of openser, that is unfortunally (IMHO) enabled by default.
http://www.openser.org/dokuwiki/doku.php/core-cookbook:1.2.x#disable_dns_bl acklist http://openser.org/pipermail/users/2007-January/008848.html
Just disable this feature the openser config.
Thanks a lot, I'll investigate it.
Regards.
Henning Westerholt wrote:
On Monday 30 July 2007, Iñaki Baz Castillo wrote:
Hi, I'd like to understand how TM module filters "sometimes" some calls. For now, I just think it there isn't response and the call is repeated sometimes then TM module filteres the following calls.
I find no info about how it works in the doc, could somebody give me a link or so to a document with the explanation of this issue?
Thanks a lot.
This cause for this problem is probably the auto blacklisting feature of openser, that is unfortunally (IMHO) enabled by default.
To start the discussion again: Haven't we come to the conclusion that the blacklist should be turned of by default?
regards klaus
El Tuesday 31 July 2007 11:25:15 Klaus Darilion escribió:
Henning Westerholt wrote:
On Monday 30 July 2007, Iñaki Baz Castillo wrote:
Hi, I'd like to understand how TM module filters "sometimes" some calls. For now, I just think it there isn't response and the call is repeated sometimes then TM module filteres the following calls.
I find no info about how it works in the doc, could somebody give me a link or so to a document with the explanation of this issue?
Thanks a lot.
This cause for this problem is probably the auto blacklisting feature of openser, that is unfortunally (IMHO) enabled by default.
To start the discussion again: Haven't we come to the conclusion that the blacklist should be turned of by default?
The doc is a little confusing:
Extracted from http://www.openser.org/dokuwiki/doku.php/core-cookbook:1.2.x#disable_dns_bla...:
------------------------------------------------------------------------- * disable_dns_blacklist Can be 'yes' or 'no'. By default it is enabled. -------------------------------------------------------------------------
So, does "enabled" mean "yes" (so blacklist is dissabled) or "no" (so blacklist is enabled)?
I understand it means "no" so blacklist is enabled by default. But in the mail of the author it appears:
------------------------------------------------------------------------- To use it, you have to enabled it - the rest is done automatically. disable_dns_blacklist = no By default is enabled -------------------------------------------------------------------------
Humm, a little confusing IMHO.
Regards.
On Tuesday 31 July 2007, Iñaki Baz Castillo wrote:
- disable_dns_blacklist Can be 'yes' or 'no'. By default it is enabled.
So, does "enabled" mean "yes" (so blacklist is dissabled) or "no" (so blacklist is enabled)?
The setting disable_dns_blacklist = yes means the blacklist is disabled. But its a little bit confusing, you're right.
Cheers,
Henning
On Tuesday 31 July 2007, Klaus Darilion wrote:
Henning Westerholt wrote:
On Monday 30 July 2007, Iñaki Baz Castillo wrote:
Hi, I'd like to understand how TM module filters "sometimes" some calls. For now, I just think it there isn't response and the call is repeated sometimes then TM module filteres the following calls.
I find no info about how it works in the doc, could somebody give me a link or so to a document with the explanation of this issue?
Thanks a lot.
This cause for this problem is probably the auto blacklisting feature of openser, that is unfortunally (IMHO) enabled by default.
To start the discussion again: Haven't we come to the conclusion that the blacklist should be turned of by default?
Yes, i think so. Klaus, could you perhaps do the change in the wiki and resolve.c? I'm today unfortunally a little bit busy with other stuff..
Thank you,
Henning
Henning Westerholt wrote:
On Tuesday 31 July 2007, Klaus Darilion wrote:
Henning Westerholt wrote:
On Monday 30 July 2007, Iñaki Baz Castillo wrote:
Hi, I'd like to understand how TM module filters "sometimes" some calls. For now, I just think it there isn't response and the call is repeated sometimes then TM module filteres the following calls.
I find no info about how it works in the doc, could somebody give me a link or so to a document with the explanation of this issue?
Thanks a lot.
This cause for this problem is probably the auto blacklisting feature of openser, that is unfortunally (IMHO) enabled by default.
To start the discussion again: Haven't we come to the conclusion that the blacklist should be turned of by default?
Yes, i think so. Klaus, could you perhaps do the change in the wiki and resolve.c? I'm today unfortunally a little bit busy with other stuff..
I prefer if someone of the authors would do it.
regards klaus
Hi, Can someone please comment on how to capture and act on this 473 filtered from within OpenSER config, i.e., ability to failover to next gateway returned by the LCR. I have tried to capture that with no success.
Thanks.
On Tuesday 31 July 2007, you wrote:
Hi, Can someone please comment on how to capture and act on this 473 filtered from within OpenSER config, i.e., ability to failover to next gateway returned by the LCR. I have tried to capture that with no success.
Hello,
have tried to call next_gw() in the failure route?
http://www.mail-archive.com/users%40openser.org/msg11829.html
Cheers,
Henning
I am trying that but it seems like that when an IP is filtered it doesn't even go to failure route.
This is what i have in my config:
In route[4] I have:
t_on_reply("4"); # grab replies so we can log reply code/status t_on_failure("4"); # if gateway unavail go to 4 if (!next_gw()) { sl_send_reply("503", "Service not available - No gateways"); return; }; if (!t_relay()) { sl_reply_error(); }; xlog("L_INFO","$ci: leave route[4]: - M=$rm RURI=$ru F=$fu T=$tu IP=$si\n"); } # end of route[4]
failure_route[4] { xlog("L_INFO","$ci: failure_route[4] - M=$rm RURI=$ru F=$fu T= $tu IP=$si\n"); if (t_check_status("(5..)|(6..)|(403)|(408)|(473)|(480)")) { # gateway failure/refusal xlog("L_INFO","$ci: failure_route[4] gateway failure/refusal \n"); if (!next_gw()) { xlog("L_CRIT","$ci: No more gateways for <$tu>\n"); t_reply("503", "Service not available - No more gateways"); return; } else { xlog("L_INFO","$ci: failure_route[4] next gw r-uri <$ru> \n"); t_on_reply("4"); t_on_failure("4"); t_relay(); # send it off to try next gw. return; } } xlog("L_INFO","$ci: failure_route[4]: relaying normal error\n"); t_relay(); }
First time around calls do make it to failure route, however, when an IP is blacklisted, it never makes it to to the failure route.
Debug=9 openser.log snippet:
First time around:
DEBUG: timer routine:0,tl=0xb6023120 next=(nil), timeout=53 Jul 31 11:36:50 mousse /usr/sbin/openser[22814]: DEBUG: final_response_handler:stop retr. and send CANCEL (0xb6022fb8) Jul 31 11:36:50 mousse /usr/sbin/openser[22814]: DEBUG:tm:t_should_relay_response: T_code=100, new_code=408 Jul 31 11:36:50 mousse /usr/sbin/openser[22814]: DEBUG:tm:t_pick_branch: picked branch 0, code 408 Jul 31 11:36:50 mousse /usr/sbin/openser[22814]: DEBUG:tm:t_should_relay_response: dns-failover test: branch=0, last_recv=408, flags=1 Jul 31 11:36:50 mousse /usr/sbin/openser[22814]: DEBUG:tm:t_should_relay_response: trying DNS-based failover Jul 31 11:36:50 mousse /usr/sbin/openser[22814]: DBG:add_list_to_head: adding to bl dns 0xb6025718,0xb6025718 Jul 31 11:36:50 mousse /usr/sbin/openser[22814]: ZDZiZjJhOTAzYTY3ZTQ4ZTA0ZjhkZGUyMTE5MTUyMzc.: failure_route[4] - M=INVITE RURI=sip:16460000000@67.151.91.91:5060;transport=udp F=sip: 10510@host.columbia.edu T=sip:9316466756523@host.columbia.edu IP=10.39.244.21 Jul 31 11:36:50 mousse /usr/sbin/openser[22814]: DEBUG:t_check_status: checked status is <408> Jul 31 11:36:50 mousse /usr/sbin/openser[22814]: ZDZiZjJhOTAzYTY3ZTQ4ZTA0ZjhkZGUyMTE5MTUyMzc.: failure_route[4] gateway failure/refusal Jul 31 11:36:50 mousse /usr/sbin/openser[22814]: ******* setting for branch 0 flags 0
After ip is blacklisted:
openserctl fifo list_blacklists List:: dns owner=17 flags=6 Rule:: flags=0 IP:: 72.10.111.22 Mask:: 255.255.255.255 Proto:: 1 Port:: 5060 Expire:: 293 Rule:: flags=0 IP:: 67.151.91.91 Mask:: 255.255.255.255 Proto:: 1 Port:: 5060 Expire:: 293
openser.log:
Jul 31 11:24:36 mousse /usr/sbin/openser[22609]: DEBUG:lcr:load_gws: add matched_gws[0]=[4,8] Jul 31 11:24:36 mousse /usr/sbin/openser[22609]: DEBUG:lcr:load_gws: add matched_gws[1]=[5,10] Jul 31 11:24:36 mousse /usr/sbin/openser[22609]: DEBUG:lcr:load_gws: add matched_gws[2]=[6,5] Jul 31 11:24:36 mousse /usr/sbin/openser[22609]: DEBUG:lcr:load_gws: add matched_gws[3]=[7,1] Jul 31 11:24:36 mousse /usr/sbin/openser[22609]: DEBUG:lcr:load_gws: add matched_gws[4]=[28,13] Jul 31 11:24:36 mousse /usr/sbin/openser[22609]: load_gws(): DEBUG: Added gw_uri_avp sip:|7@10.10.9.32:5060;transport=udp Jul 31 11:24:36 mousse /usr/sbin/openser[22609]: load_gws(): DEBUG: Added gw_uri_avp sip:|7@10.10.9.13:5060;transport=udp Jul 31 11:24:36 mousse /usr/sbin/openser[22609]: load_gws(): DEBUG: Added gw_uri_avp sip:|7@10.10.9.14:5060;transport=udp Jul 31 11:24:36 mousse /usr/sbin/openser[22609]: load_gws(): DEBUG: Added gw_uri_avp sip:|7@72.10.111.22:5060;transport=udp Jul 31 11:24:36 mousse /usr/sbin/openser[22609]: load_gws(): DEBUG: Added gw_uri_avp sip:|6@67.151.91.91:5060;transport=udp . . .
: DEBUG: noisy_timer set for accounting Jul 31 11:25:41 mousse /usr/sbin/openser[22604]: parse_headers: flags=ffffffffffffffff Jul 31 11:25:41 mousse /usr/sbin/openser[22604]: check_via_address (160.39.244.21, 160.39.244.21, 0) Jul 31 11:25:41 mousse /usr/sbin/openser[22604]: WARNING:vqm_resize: resize(0) called Jul 31 11:25:41 mousse /usr/sbin/openser[22604]: DEBUG:tm:_reply_light: reply sent out. buf=0x81a07c8: SIP/2.0 1..., shmem=0xb60c2fe0: SIP/2.0 1 Jul 31 11:25:41 mousse /usr/sbin/openser[22604]: DEBUG:tm:_reply_light: finished Jul 31 11:25:41 mousse /usr/sbin/openser[22604]: DEBUG: mk_proxy: doing DNS lookup... Jul 31 11:25:41 mousse /usr/sbin/openser[22604]: check_via_address (10.39.244.21, 10.39.244.21, 0) Jul 31 11:25:41 mousse /usr/sbin/openser[22604]: DBG:check_against_rule_list: using list dns Jul 31 11:25:41 mousse /usr/sbin/openser[22604]: DBG:check_against_rule_list: matched list dns Jul 31 11:25:41 mousse /usr/sbin/openser[22604]: DEBUG:tm:t_forward_nonack: blocked by blacklists Jul 31 11:25:41 mousse /usr/sbin/openser[22604]: ERROR:tm:t_relay_to: t_forward_nonack returned error Jul 31 11:25:41 mousse /usr/sbin/openser[22604]: parse_headers: flags=ffffffffffffffff
On Jul 31, 2007, at 10:14 AM, Henning Westerholt wrote:
On Tuesday 31 July 2007, you wrote:
Hi, Can someone please comment on how to capture and act on this 473 filtered from within OpenSER config, i.e., ability to failover to next gateway returned by the LCR. I have tried to capture that with no success.
Hello,
have tried to call next_gw() in the failure route?
http://www.mail-archive.com/users%40openser.org/msg11829.html
Cheers,
Henning
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Zahid Mehmood wrote:
I am trying that but it seems like that when an IP is filtered it doesn't even go to failure route.
I remember this was reported recently too.
You could disable the blacklist: disable_dns_blacklist=true
Nevertheless IMO it should go to failure_route. Please open a bug report at the bug tracker on sourceforge.
regards klaus
-
Henning Westerholt -
Iñaki Baz Castillo -
Klaus Darilion -
Zahid Mehmood