[OpenSER-Users] Re: [Users] 473 Filtered destination?

Zahid Mehmood zm23 at columbia.edu
Mon Jul 23 15:51:08 CEST 2007


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





More information about the Users mailing list