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

James Holden james.holden at uk.aql.com
Mon Jul 23 12:17:01 CEST 2007


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