Hi Tobias, just as an ad-on : if your proxy generated this reply, it means a destination was temporary blocked because of some fwd problem (timeout, tcp denied, etc)....maybe you should inspect the cause first. You can inspect the content of the blacklist via the MI command: "list_blacklists" regards, bogdan Tobias Lindgren wrote:

yeah, as I mentioned, the doc part still needs to be addressed: https://sourceforge.net/tracker/index.php?func=detail&aid=1655364&g… Regards, Ovidiu Sas On 3/30/07, Stefan Prelle <s.prelle(a)broadnet.de> wrote:

I need help dealing with this as well. One of our sip carrier was unavailable and that ip got blacklisted in openser. I started seeing the 473 filtered messages. We do have multiple routes defined in our lcr but the call did not failover to the next gateway. What do I need to do to ensure that the call does get routed? can I capture this in failure route? Thanks in advance for your help. -- Zahid On Mar 30, 2007, at 10:12 AM, Bogdan-Andrei Iancu wrote:

James, thanks for your reply. I tried capturing the 473 in failure route but it doesn't look like it makes it that far. t_on_failure("4"); t_on_reply("4"); if (!next_gw()) { sl_send_reply("503", "Service not available - No gateways"); xlog("L_ERR","$ci: 503 Service not available - No gateways rU=<$rU>, ruri=<$ru>\n"); return; }; if (!t_relay()) { xlog..... msg1 sl_reply_error (); } else { xlog msg 2 } and I don't see either one of the messages from if (!t_relay()) logged. There is an xlog right at the top of failure route which is not logged either. This is what I see in openser log when using dubug=9 Jul 23 09:35:06 mousse openser[5276]: DBG:check_against_rule_list: using list dns Jul 23 09:35:06 mousse openser[5276]: DBG:check_against_rule_list: matched list dns Jul 23 09:35:06 mousse openser[5276]: DEBUG:tm:t_forward_nonack: blocked by blacklists Jul 23 09:35:06 mousse openser[5276]: ERROR:tm:t_relay_to: t_forward_nonack returned error Jul 23 09:35:06 mousse openser[5276]: parse_headers: flags=ffffffffffffffff Jul 23 09:35:06 mousse openser[5276]: check_via_address (192.168.12.174, 192.168. 12.174, 0) ( Jul 23 09:35:06 mousse openser[5276]: DBG: trans=0xb604f518, callback type 128, id 0 entered Jul 23 09:35:06 mousse openser[5276]: ACC: call missed: timestamp=1185197706;method=INVITE;from_tag=F2953709-6DD8ACE4;to_tag=;ca ll_id=2af22500- d6298d67-9e8a6d1a(a)192.168.12.174;code=473;reason=Request Failure Thanks again for your help. -- Zahid On Jul 23, 2007, at 6:17 AM, James Holden wrote:

Christian, In our case IP gets blacklisted for about 4 minutes as described on http://openser.org/pipermail/users/2007-January/008848.html (.. The rules from this list have a life time of 4 minutes - you can change it at compile time, from blacklists.h ) The behaviour is consistent during that time. We get a 473 immediately and all the time. To test I simply entered a wrong ip for our first gateway returned by the lcr. Openser timed out and failed over to the next gateway for the first call. I checked the blacklist at that time and the gateway with wrong IP was on the list. Redialing got a 473 consistently at that time. Problem is that at that point ALL calls to that gateway start failing. We also have another scenario where a particular gateway is used as a default for all outbound calls. Calls sent to this gateway are routed to our legacy PBX which routes them according to its own LCR. In this scenario if a 503 is returned for one particular type of call, OpenSER blacklists the gateway even though the gateway is available to route all other calls. Double trouble :) -----Original Message----- From: Christian Schlatter [mailto:cs@unc.edu] Sent: Monday, July 23, 2007 10:34 AM To: users(a)openser.org Cc: Zahid Mehmood Subject: Re: [OpenSER-Users] Re: [Users] 473 Filtered destination? We recently had some issues with dns blacklisting and 473 as well, we had to disable blacklisting on our production proxies. Unfortunately I wasn't able to reproduce the problem so far. It *seems* that sometimes the blacklist gets activated mistakenly for targets that are alive. E.g. we weren't able to call our gateways anymore (always got back 473 immediately from the proxy) even though these gateways always have been up. Do you always get back 473 or does this only happen occasionally? Christian Zahid Mehmood wrote: logged. check_via_address(192.168.12.174,