Olle E. Johansson 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
It's ugly, but what it does is sending UDP packets from the outside to the
NAT to keep the ports open for incoming calls. NAT is an ugly thing,
so it propably needs ugly solutions... ;-)
Looking at that page you mentioned it still seems to me that the "nathelper" module for SER and adding nat=yes to the sip.conf essentially do the same thing apart from the "NAT pings" you mentioned below..
Right. There's also more commands so that you can tweak SER into doing different kinds of SIP message mangling than the - still rather undocumented - nat=yes. My guess is that nat=yes changes the Contact to the actual IP used to contact Asterisk, not the IP given in the SIP headers. Right?
As I understand it, it works like this: * Client on the inside of a NAT registers to an outside SIP Proxy * THe outside SIP Proxy keeps sending UDP packets ("NAT PINGS") to the client to keep the UDP session open in the NAT * When someone calls, the session is open and the client (UAC/S) may answer... * In addition to the solution for handling SIP this way, there's a need for an RTP media server to handle the RTP stream.
I guess that if you use SER or STUN and Asterisk the RTP is still going to be an issue if the call is needing to go between two SIP UA's that are both behind NAT (UA---NAT--Internet--NAT--UA) so the RTP streams are going to have to go via the central server (aka canreinvite=no in Asterisk).. So if NAT is in the picture you have no choice but to load the server with all the traffic..
Right. That's where the PortaOne RTP proxy - or Asterisk - come in. The RTP proxy in combination with SERs nathelper changes the SDP to point to the RTP proxy in this case and informs the RTP proxy of the session through a Unix pipe.
So my question is would it not be better to couple STUND (Vovida.org) with Asterisk and then use nat=yes in the sip.conf for UA's that do not support STUN, instead of using SER which would be like learning Asterisk all over again and would require you to learn how to use the SER config language to manage your NAT transtaltions..
Integrating a STUN server into ASterisk... I don't see the point. But if you're talking about asterisk as a SIP client (registrering to other SIP servers) supporting STUN to find out if it's behind a NAT and how the NAT works, yes, that's a good idea.
I wasn't talking about intergrating STUN into asterisk, I was thinking more along the lines of using STUND in conjunction with Asterisk instead of SER and Asterisk.. :)
Sorry, my misunderstanding. Are you thinking the way I did, with Asterisk as a SIP client or are you thinking of supporting Asterisk's SIP clients, the phones, with a STUND?
We need to form a strategy of what can be done with Asterisk's SIP channel to better support NAT. One part is how Asterisk acts as a SIP client (registering to FWD) and another part of the strategy must handle Asterisk being the SIP proxy.
I think a lot of things can be added to channel_sip.c without doing the channel_sip.c-ng++ rearchitecture. This said standing on thin ice since I haven't got full insight into how channel_sip works, source-code wise.
/O
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
