> > By the way, there is a reason for this. It ensures that there is > > traffic (initiated by the client) often > > enough to keep the 'connection' in a NATing firewall's map of ports. > > This means that a > > 'new' call (ie incoming) message from asterisk to the client will be > > seen by the firewall as part of that > > 'recent' conversation and allowed through (and correctly forwarded). > > Ostensibly that was the reason, yes, but it's flawed... 'qualify' is > much better for that purpose, for three reasons: > > 1) It is initiated from the server end instead of the peer end, so there > is no chance the firewall will drop the association. > 2) It is far less work on the server; registrations require > authentication and database updates. > 3) It will also make your Asterisk server aware of when the peer becomes > unreachable. > > Personally, I'd recommend changing the minexpiry time to something like > 300 seconds or longer, and using 'qualify' to keep the NAT mapping alive.
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. I'm not arguing or proposing alternatives, just simply stating actual observations. _______________________________________________ --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
