> > The only issue I see with that approach is that customers tend to buy > > crap for firewalls without any knowledge/experience relative to nat > > timeouts, etc. We've seen some that never timeout the nat entries (unless > > the nat table becomes full), and others with very short duration timeouts. > > Using the server-based qualify assumes you either know the nat table > > timeout value, or, one must pick a very short duration qualify generating > > wasteful traffic. > > Wouldn't the same be true of the registration interval though? If you > need the NAT mapping to stay in effect, _something_ is going to have to > generate two-way traffic before it expires... I don't see how it matters > whether that is a registration or a qualify.
Sure, which is part of the logic behind a relatively short registration period (re-opening the nat table entry). Likely the best approach to maintain customer availability (and customer relationships) is a combination of a relatively short registration period plus qualify. This might be a rather poor example, but our company does a fair amount of work with isp's and itsp's. We've purposefuly placed all customers behind a Cisco 7206 nat router (customer's are very happy), but since some still become infected from emails, etc, their PC's scan hundreds of IP's on the Internet in an attempt to infect others. Since even a fully loaded 7206 will eventually run out of nat table space, we've had to reduce the nat timeout (for udp) to 30 seconds. In this unusual case, a short duration qualify does handle the issue with the exception of missed qualify attempts. When that happens, the typical sip adapter/phone is out of service for a relatively long period. Not cool from a customer satisfaction perspective. Some of the Linksys products also have very short nat table timeouts. In a recent case, a ten second qualify on a 784k residential dsl link would occassionally be missed, and the Cisco 7960 became unreachable for lengthy periods of time. Cranking down both the registration and qualify seems to have addressed it (waiting for recurrance). It would seem on the surface that sip devices would benefit significantly if the qualify-type function actually originated from the adapter/phone. Then all of the above would become more of a non-issue. Obviously none of us can actually influence that approach, so we're kind of stuck addressing the issue with a combination as noted. _______________________________________________ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
