23 Jul
2007
23 Jul
'07
4:51 p.m.
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:
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:
--
James Holden AQ Limited
Senior Systems Architect 13-15 Hunslet Road
james.holden(a)uk.aql.com Leeds, LS10 1JQ
============================================================
Winner - Best Innovation
Winner - Best Mobile Technology
Winner - Best of Best
(Newsco Internet Awards 2007) Hi Stefan,
Stefan Prelle wrote:
_______________________________________________
Users mailing list
Users(a)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.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users