[Asterisk-Users] SER vs STUND with Asterisk..

[WipeOut]

John Todd wrote:

>
> 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..