Not sure but I do not think STUN will solve your issue. Are you using the same type of firewall at each site. There is a NAT keepalive setting in the Linksys devices.

Cheers,
Chris A

Hi Chris,

Different firewalls at each site. I have set the keepalive time to 5 sec's on all phones.
I would have thought if nat was working correctly back to our hosted server, we would have seen Y under nat in pbx info page?

Cheers Chris
Dion

all nat=yes does is send sip replies back to the IP address that sent the message INSTEAD of the address in the URI, because the phone is sending things from sip:exten@some.private.ip which you cant route to.

btw the 'N' means that its configured to use nat. It will ether be empty or an N. Nat problems with sip are one of the big reasons why I use firewalls with built-in sip proxies.

Erik Smith
CTO
BluegrassNet Voice
dCAP

Hi Dion,

are you using provisioning ..? if so we had a LOT of problem with the NAT settings..

this setting is controlled by the NAT setting in the extensions

${NAT_MAPPING}

This setting is hard setup to YES in TL, (BAD TL) as you can see I changed the setting to NO in our scripts and it corrected the problem.

no

the problem this caused us was the phone once brought online, provision and work fine, either after a couple hours OR a few back to back calls the phone would go offline stay that way.

if you are not using provisioning you need to check the port settings in your firewalls and make sure sip ports are open.

being the phone do register says the system and the phones are set correctly and by fact that they go off line after a while points to your firewall settings..

one other item that can cause SIP devices to lose their registrations are the

ip_nat_sip and ip_conntract_sip kernel modules. Check to make sure they arent loaded

'lsmod | grep sip'

Erik Smith
CTO
BluegrassNet Voice
dCAP

Hi Guys,

Thanks for the feedback. I will let you know the outcome.

I have changed nat keep alive to 5 secs.
I have turned off nat mapping.
Turned off STUN, and Erik none of the modules were loaded either.

Thanks again

Dion

Well, now I have disabled nat mapping I am getting my phone dropping off line more often. If I make 2 calls within 10 secs, the phone de-registers and comes up with proxy unreachable comes right after 20 sec's or so.

In the linksys phones there is a whole lot of nat/via settings, does anyone have any info on these? I have had a good look around the net and have failed to find any decent info?

NAT Support Parameters

Handle VIA received: yes/no Handle VIA rport: yes/no
Insert VIA received: yes/no Insert VIA rport: yes/no
Substitute VIA Addr: yes/no Send Resp To Src Port: yes/no

Thanks

Dion

Thought I'd chime in as I am fighting a NAT issue tonight as well. I just changed from a Cisco PIX-501 10-user to a Linksys RV042 50-user router at my house. My phones have multiple extensions on two different SIP servers; the (non-asterisk) VoIP switch from my day job company, and my Thirdlane Asterisk MT system. Before the change, all extensions worked; both SIP servers showed the public IP address for the phones. After the change, the Thirdlane extensions stopped registering, but the extensions on the day job SIP server still functioned. However, when I look at the day job server, it now shows both a public IP and the original private IP address of each phone behind the firewall. On my Thirdlane MT, it looks like the phones are trying; I see the private addresses of the phones in PBX info, but no reference to the public IP address of the firewall. The phones never think they are registered on those extensions. NAT is checked on all of the User Extensions in PBX Mgr, no difference either way.
So what it looks like to me is that the RV042 is fixing up the SIP protocol in such a way as to map multiple phones better (it works great on the day job switch, better than anything else), but Asterisk doesn't like it that way. I guess the SIP fixup in the PIX could be older and more compatible, sending out the public IP in the URI more to what asterisk expects.
Hell I'm just guessing at this point...

Be sure to turn off NAT for the extensions that are having the issue. I find that if the router is trying to change the packet payload you do not want NAT enabled for those extensions.

-Matt

Well I figured out my mistake. It was the NAT box in User Extension. Only I was in the wrong tenant (duh). So I guess RV042 works after all.