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

[WipeOut]

Olle E. Johansson wrote:

> WipeOut wrote:
>
>> Olle E. Johansson wrote:
>>
>>> WipeOut wrote:
>>>
>>>> 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? 

Not sure about the intimate details of what nat=yes does exactly but it 
defiantely works, also have just found out (thanks to John Todd) the if 
you add "qualify=500" to your UA configuration in the sip.conf then it 
essentially uses keep alives in the form of a OPTIONS request every 60 
seconds.. So by having nat= and qualify= removes the need to have SER 
and the nathelper module.. (No doubt there is more that SER can do and 
if you really need those features then go for it..)

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

Personally I think I would stick with Asterisk to handle all the RTP 
traffic, just by adding canreinvite=no to the sip.conf will cause all 
traffice between the endpoints to go via Asterisk.. The fewer systems 
that need to be tied together the better IMO.. If it can all be done 
with one then there is less to go wrong.. :)

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

I was thinking of the supporting the SIP clients (phones).. I think that 
it is the resposibility of the server to handle as much complexity as 
possible making it easier for the UA's to be configured.. So if you are 
trying to connect Asterisk(as a client) to a third party to route your 
calls I would say that it is their responsibility to handle NAT issues.. 
Thats not to say that Asterisk can be made to help out as well..

> 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 Asterisk as the proxy works quite well when used with NATed 
UA's.. with options like nat= canreinvite= reinvite= and qualify= you 
should be able to get most NATed phones to work.. As for Asterisk as a 
Client I havent really had a lot of experience with that so I am not 
really sure what is needed..

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

I can't really help there either.. I know squat about C coding.. and the 
times I have looked at the source it really didn't really make a lot of 
sense..

Later..