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

[John Todd]

At 10:22 AM +0100 10/16/03, WipeOut wrote:
>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..

My example line will send an "OPTIONS" request every 45 seconds.  If 
the response time to the OPTIONS request is more than 500 
milliseconds, the SIP host is tagged as "unavailable" and removed 
from the operational list.


>>[snip]
>
>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..

It's extremely difficult to get two devices talking to each other 
that are behind NAT.  Almost impossible, actually, due to the nature 
of NAT.  If you read the fine print on Skype, as an example, you'll 
discover that NAT'ed users can reach each other by using a third 
party "helper" user, without that third party's explicit knowledge of 
transit'ed connections.

   This difficulty is not a SIP failing; this is an inherent problem 
with NAT.  However, there are some clever ways around this, but the 
problem has been that there are too many half-baked NAT routers and 
SIP clients that have had their firmware concocted by cut-rate 
programming sweatshops, where there has been no understanding of the 
actual use of the protocols in the real world.

JT