You could do this with Asterisk via the existing "qualify=500" syntax or similar in sip.conf to keep a packet going between Asterisk and the SIP device every 45 seconds (or whatever you hacked the timer to use, if you don't like that value.) This keeps the mapping open just fine for any NAT device I've ever seen. It works fine with dynamic hosts, even behind NAT - I just triple-checked and it does do what I expected it to do.
I did not know that "qualify=" caused Asterisk to send a "keep-alive" packet, I thought it was only to set a timeout for the UA to respond when a call needed to be terminated there before moving to the next priority.. If it does what you say then I can definately use it.. Thanks..
STUN is useful and works well for those clients that support it, but should not be a part of Asterisk at this time. The NAT trick that Ciscos (and others) use to determine outside NAT address in the Via: header is almost always sufficient, and is already part of Asterisk's handling of registering agents. All that is missing is the ability for the Asterisk server to implement one or both methods of NAT traversal for outbound REGISTER requests, and then (in an optional and slightly different functionality mode) to proxy all SIP requests outbound through some particular host for those sites that may choose an external method of handling SIP NAT translations.
For anyone who wants further information as to Asterisk's use behind a NAT or firewall, pleaase check these two bugnotes:
NAT trick: http://bugs.digium.com/bug_view_page.php?bug_id=0000104 Proxy: http://bugs.digium.com/bug_view_page.php?bug_id=0000359
There continues to be a great deal of confusion about how Asterisk works with NATs using SIP. It works quite well. Your SIP client needs to have some method of understanding that it's behind a NAT, but pretty much any modern client written by someone with half a clue will do that. STUN or the Via: header trick have worked in every situation that I've come across. There are still some problems with NAT, but they are for the most part overblown - most of the problem lies in the confusing explanations and half-understood problems by SIP system administrators. The hopefully-soon-to-be-approved ICE RFC's will make things even easier by testing even the RTP ports, but it will be some time before we see clients with that functionality built in.
It will be nice when the RTP traffice can go point-to-point and not have to be routed through the proxy (Asterisk) when both UA's are behind NAT.. I still finf it amazing how after the downfall of H.323 and NAT the SIP developers made the exact same mistake.. :)
Later..
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
