30 Jul
2007
30 Jul
'07
12:13 p.m.
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
30 Jul
30 Jul
12:45 p.m.
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…
http://openser.org/pipermail/users/2007-January/008848.html
Just disable this feature the openser config.
Cheers,
Henning
12:55 p.m.
El Monday 30 July 2007 12:45:41 Henning Westerholt escribió:
On Monday 30 July 2007, Iñaki Baz Castillo wrote:
Thanks a lot, I'll investigate it.
Regards.
--
ilimit...
*Iñaki Baz Castillo*
ibc(a)in.ilimit.es
ÀREA SISTEMES
0034 937 333 375
VOLTA 1, PIS 5
08224 TERRASSA.BCN
Aquest enviament és confidencial i està destinat únicament a la persona a qui
s'ha enviat.
Pot contenir informació privada sotmesa al secret professional, la distribució
de la qual està prohibida per la legislació vigent.
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. 
31 Jul
31 Jul
11:25 a.m.
Henning Westerholt wrote:
On Monday 30 July 2007, Iñaki Baz Castillo wrote:
To start the discussion again: Haven't we come to the conclusion that
the blacklist should be turned of by default?
regards
klaus
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.
11:52 a.m.
El Tuesday 31 July 2007 11:25:15 Klaus Darilion escribió:
Henning Westerholt wrote:
The doc is a little confusing:
Extracted from
http://www.openser.org/dokuwiki/doku.php/core-cookbook:1.2.x#disable_dns_bl…:
-------------------------------------------------------------------------
* 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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
On Monday 30 July 2007, Iñaki Baz Castillo
wrote:
To start the discussion again: Haven't we come to the conclusion that
the blacklist should be turned of by default? 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.
2:15 p.m.
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
2:25 p.m.
On Tuesday 31 July 2007, Klaus Darilion wrote:
Henning Westerholt wrote:
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
On Monday 30 July 2007, Iñaki Baz Castillo
wrote:
To start the discussion again: Haven't we come to the conclusion that
the blacklist should be turned of by default? 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.
3:33 p.m.
Henning Westerholt wrote:
On Tuesday 31 July 2007, Klaus Darilion wrote:
I prefer if someone of the authors would do it.
regards
klaus
Henning Westerholt wrote:
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.. On Monday 30 July 2007, Iñaki Baz Castillo
wrote:
To start the discussion
again: Haven't we come to the conclusion that
the blacklist should be turned of by default? 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. 
4:10 p.m.
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.
--
Zahid
On Jul 31, 2007, at 9:33 AM, Klaus Darilion wrote:
Henning Westerholt wrote:
On Tuesday 31 July 2007, Klaus Darilion wrote:
I prefer if someone of the authors would do it.
regards
klaus
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users Henning Westerholt wrote:
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.. 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?
4:14 p.m.
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
5:53 p.m.
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(a)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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6:38 p.m.
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
6120
days inactive
6121
days old
11 comments
4 participants
participants (4)
-
Henning Westerholt -
Iñaki Baz Castillo -
Klaus Darilion -
Zahid Mehmood