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

[Olle E. Johansson]

Chris Albertson wrote:

> --- John Todd <jtodd at loligo.com> wrote:
> 
>>>WipeOut wrote:
>>>
>>>
>>>>One for the gurus..
>>>
>>>Obviously not for me, but I'll dare to give it a shot anyway ;-)
>>>
>>>
>>>>Anyway, I decided to go and have a quick read through the SER docs 
>>>>and in the section about NAT they say that the best way to address 
>>>>NAT is to use STUN or uPNP..
>>>
>>>STUN is helpful, but as I understand it analyzes the situation and
>>
>>reports
>>
>>>the configuration of a NAT. It doesn't help you keeping the NAT
>>
>>session open,
>>
>>>as SER module nathelper or the FWD/Jasomi solution.
>>>Check here http://www.voip-info.org/wiki-SER+module+nathelper
>>
>>[snip]
>>
>>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.
>>
>>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.
> 
> 
> 
> "Overblown?"  I've get to see one example of Asterisk placing
> and acepting SIP call through a NAT firewall.
> 
> Here s the problem:
> 
> I have an Asterisk server in back of a NAT
> fire wall and I want users to be able to dial a SIP number at
> fwd.pulver.com. by first dialing "97"
> 
> So in extension.conf
> I have something like this:
> exten => _97.,3,Dial(SIP/${EXTEN:2}@fwd.pulver.com,r)
> 
> What goes in sip.conf?
> 
> The problem I see is that the SER server at pulver.com complains
> about the 192.168.x.x address it is getting from me.
> 
> I know you CAN get SIP calls through my firewal because X-Lite
> can do it just fine.  But Asterisk can't, or I can't get it to.
> 
> I'm about ready to hack Asterisk so that it sends _all_ SIP
> requiests to some fixed, (set at compile time) IP address.
> I'll run SER at that address and have SER "mangle" the
> packets.
Chris,
Look in the bug report/feature request I submitted and John
referenced (see above). What you want is exactly what I have requested,
support for an outbound SIP proxy. If you're on the verge of doing it,
I will stand by for testing and applause!

What John stated was that Asterisk as a SIP server handles clients behind
a NAT well. You're problem is Asterisk as a SIP client behind a NAT,
a different problem that requires another solution.

I apologize if I've been unclear in this thread, but I've tried to
separate the two roles.

/Olle