Hi,
recently moved from SER > OpenSER 1.2.0, but after some time when the server is running OpenSER starts to respond with: "SIP/2.0 473 Filtered destination (473/TM)." to my INVITEs.
I don't have any blacklists/accesslist configured (the config is from SER which doesn't support that), why am I seeing this problem?
Br, /Tobias
Hi Tobias,
You can disable the dns blacklist feature in openser.cfg: disable_dns_blacklist=true
See: http://openser.org/pipermail/users/2007-January/008848.html
Also check: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1653954... https://sourceforge.net/tracker/index.php?func=detail&aid=1655364&gr...
Regards, Ovidiu Sas
On 3/29/07, Tobias Lindgren tobias.lindgren@ip-only.se wrote:
Hi,
recently moved from SER > OpenSER 1.2.0, but after some time when the server is running OpenSER starts to respond with: "SIP/2.0 473 Filtered destination (473/TM)." to my INVITEs.
I don't have any blacklists/accesslist configured (the config is from SER which doesn't support that), why am I seeing this problem?
Br, /Tobias
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi!
Aha, thanks a lot!
Br, /Tobias
Ovidiu Sas said the following on 2007-03-29 15:17:
Hi Tobias,
You can disable the dns blacklist feature in openser.cfg: disable_dns_blacklist=true
See: http://openser.org/pipermail/users/2007-January/008848.html
Also check: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1653954... https://sourceforge.net/tracker/index.php?func=detail&aid=1655364&gr...
Regards, Ovidiu Sas
On 3/29/07, Tobias Lindgren tobias.lindgren@ip-only.se wrote:
Hi,
recently moved from SER > OpenSER 1.2.0, but after some time when the server is running OpenSER starts to respond with: "SIP/2.0 473 Filtered destination (473/TM)." to my INVITEs.
I don't have any blacklists/accesslist configured (the config is from SER which doesn't support that), why am I seeing this problem?
Br, /Tobias
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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:
Hi!
Aha, thanks a lot!
Br, /Tobias
Ovidiu Sas said the following on 2007-03-29 15:17:
Hi Tobias,
You can disable the dns blacklist feature in openser.cfg: disable_dns_blacklist=true
See: http://openser.org/pipermail/users/2007-January/008848.html
Also check: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1653954... https://sourceforge.net/tracker/index.php?func=detail&aid=1655364&gr...
Regards, Ovidiu Sas
On 3/29/07, Tobias Lindgren tobias.lindgren@ip-only.se wrote:
Hi,
recently moved from SER > OpenSER 1.2.0, but after some time when the server is running OpenSER starts to respond with: "SIP/2.0 473 Filtered destination (473/TM)." to my INVITEs.
I don't have any blacklists/accesslist configured (the config is from SER which doesn't support that), why am I seeing this problem?
Br, /Tobias
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi all,
Am Donnerstag, den 29.03.2007, 09:17 -0400 schrieb Ovidiu Sas:
You can disable the dns blacklist feature in openser.cfg: disable_dns_blacklist=true
I ran into the same problem when trying to upgrade to 1.2. Our PSTN-Gateway regulary maps some SS7 reason codes to a SIP 503.
From what I understand from
http://www.openser.org/docs/modules/1.2.x/tm.html#AEN103 , the first 503 received, blacklists the originating IP address (our gateway). So, a few seconds after starting the 1.2 version, the OpenSER blocked the whole trunk (running several thousand calls), just because one call produced an 503, which originated in the PSTN.
I think the blacklisting feature shouldn't be enabled by default or at least should the release notes carry a huge red blinking warning that this auto blocking might be harmful.
Regards, Stefan
yeah, as I mentioned, the doc part still needs to be addressed: https://sourceforge.net/tracker/index.php?func=detail&aid=1655364&gr...
Regards, Ovidiu Sas
On 3/30/07, Stefan Prelle s.prelle@broadnet.de wrote:
Hi all,
Am Donnerstag, den 29.03.2007, 09:17 -0400 schrieb Ovidiu Sas:
You can disable the dns blacklist feature in openser.cfg: disable_dns_blacklist=true
I ran into the same problem when trying to upgrade to 1.2. Our PSTN-Gateway regulary maps some SS7 reason codes to a SIP 503.
From what I understand from
http://www.openser.org/docs/modules/1.2.x/tm.html#AEN103 , the first 503 received, blacklists the originating IP address (our gateway). So, a few seconds after starting the 1.2 version, the OpenSER blocked the whole trunk (running several thousand calls), just because one call produced an 503, which originated in the PSTN.
I think the blacklisting feature shouldn't be enabled by default or at least should the release notes carry a huge red blinking warning that this auto blocking might be harmful.
Regards, Stefan
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Stefan,
Stefan Prelle wrote:
Hi all,
Am Donnerstag, den 29.03.2007, 09:17 -0400 schrieb Ovidiu Sas:
You can disable the dns blacklist feature in openser.cfg: disable_dns_blacklist=true
I ran into the same problem when trying to upgrade to 1.2. Our PSTN-Gateway regulary maps some SS7 reason codes to a SIP 503.
From what I understand from
http://www.openser.org/docs/modules/1.2.x/tm.html#AEN103 , the first 503 received, blacklists the originating IP address (our gateway). So, a few seconds after starting the 1.2 version, the OpenSER blocked the whole trunk (running several thousand calls), just because one call produced an 503, which originated in the PSTN.
unfortunately we have again an example of differences between theory and practice. The RFC 3263, section 4.3 says:
For SIP requests, failure occurs if the transaction layer reports a 503 error response or a transport failure of some sort.......
also RFC 3261 says:
1.5.4 503 Service Unavailable
The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response.
A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present.
Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable).
so, my impression is that the GW does not follow the RFC specs when come to error codes.
I think the blacklisting feature shouldn't be enabled by default or at least should the release notes carry a huge red blinking warning that this auto blocking might be harmful.
yes, we need to work out this for the future.
Regards, Bogdan
Regards, Stefan
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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.
Hi Zahid,
On Fri, Jul 20, 2007 at 12:51:20PM -0400, Zahid Mehmood 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?
Yes - you need to call next_gw() from the failure route.
james
Thanks in advance for your help.
Zahid
On Mar 30, 2007, at 10:12 AM, Bogdan-Andrei Iancu wrote:
Hi Stefan,
Stefan Prelle wrote:
Hi all,
Am Donnerstag, den 29.03.2007, 09:17 -0400 schrieb Ovidiu Sas:
You can disable the dns blacklist feature in openser.cfg: disable_dns_blacklist=true
I ran into the same problem when trying to upgrade to 1.2. Our PSTN-Gateway regulary maps some SS7 reason codes to a SIP 503.
From what I understand from
http://www.openser.org/docs/modules/1.2.x/tm.html#AEN103 , the first 503 received, blacklists the originating IP address (our gateway). So, a few seconds after starting the 1.2 version, the OpenSER blocked the whole trunk (running several thousand calls), just because one call produced an 503, which originated in the PSTN.
unfortunately we have again an example of differences between theory and practice. The RFC 3263, section 4.3 says:
For SIP requests, failure occurs if the transaction layer reports a 503 error response or a transport failure of some sort.......
also RFC 3261 says:
1.5.4 503 Service Unavailable
The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response.
A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present.
Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable).
so, my impression is that the GW does not follow the RFC specs when come to error codes.
I think the blacklisting feature shouldn't be enabled by default or at least should the release notes carry a huge red blinking warning that this auto blocking might be harmful.
yes, we need to work out this for the future.
Regards, Bogdan
Regards, Stefan
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@192.168.12.174;code=473;reason=Request Failure
Thanks again for your help.
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:
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=;call_id=2af22500-d6298d67-9e8a6d1a@192.168.12.174;code=473;reason=Request Failure
Thanks again for your help.
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@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:
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=; call_id=2af22500-d6298d67-9e8a6d1a@192.168.12.174;code=473;reason=Requ est Failure
Thanks again for your help.
-
Bogdan-Andrei Iancu -
Christian Schlatter -
James Holden -
Ovidiu Sas -
Stefan Prelle -
Tobias Lindgren -
Zahid Mehmood