Incomming Ring

[nthomthom]

I am still not convinced that these port translations are to blame.

As I have said just a couple days ago I had a different router at the remote location (also linksys ). With this router I had NO PROBLEMS. As soon as I changed the router the problem started.

The router is interfering. It must be.

 

[albertc]

Since I do not own a Linksys router myself, I can't speak for it. However, based on my experiences, if there is some sort of translation going on between the 3cx server and the remote network, it will cause connection problems. And when that happens, there's not much you can do except for the 4 options I have posted earlier.

BTW, are you using stun on the phones/softphone at your remote network as it said in the 3cx documentation? I just remembered there seem to be some problems with the stun.3cx.com the past few days (at least thats what I think happens) and one of my client cannot connect from remote. I've change the stun server to stun.counterpath.com and it works. Give that a try.

 

[nthomthom]

I am reading an article on the 3cx trying to figure out this issue. The section "keep alive" seems to decribe my issue. do you know what this means:

STUN Client Functionality

This is an absolute requirement for a phone to be able to function as an External Extension. The phone will use the services of a STUN Server to understand what its public IP Address is, and what port address translations will occur as the traffic it sends and receives to/from the PBX traverses the WAN-to-LAN boundary at the remote location.

Without STUN support, it will be necessary to perform some custom configurations on the WAN-to-LAN device in the remote location. This implies that you will need, for each phone in the remote location, to configure on the phones SIP and RTP ports that are unique for each unit, then also statically configure on the phone what is the public IP Address it is using, and then create the necessary port forwarding rules on the remote location’s WAN-to-LAN device. This is inconvenient to say the least, requires a static public IP Address at the remote location, and is definitely to be avoided for anything beyond casual use, or if you have absolutely no other option. Troubleshooting such setups can rapidly consume so much time that purchasing a phone device that has STUN support is a more cost-effective option.
Keep-Alive Functionality

A phone which is NAT-aware will almost always provide Keep-Alive functionality. The phone will periodically send keep-alive messages to the PBX. The scope of sending keep-alive messages is to ensure that the NAT mappings which the WAN-to-LAN device (between the phone and its internet connection) creates remain the same. Without this, shortly after the phone registers the NAT mapping on the WAN-to-LAN device would expire, and there would be no way for the WAN-to-LAN device to know where to route incoming SIP messages from the PBX to the phone.

 

[albertc]

Basically, it is just saying what Stun does and how a remote extension communicate with the server. Stun is required because your phone only knows it own private address within your remote network. Usually address like 192.168.X.X. But for the server to talk to the remote extension, the server needs to know the public ip address of your remote network. Thats what Stun does. Your remote ext will send a request to Stun and check and the stun will see where this request is coming from (your remote public ip address) and send it back to the phone and your phone will send that information to the server so the server will know where to find your remote ext. Because your NAT device will clear its ip address translation table periodically, it is necessary for this information to be renew (Keep alive). You can find that setting under the SIP section within your SPA phones. The default setting for the Keep alive is 15secs and that should be short enough to keep your phone register.

As I mention on my last post, try changing the stun server address to something other than stun.3cx.com. I've been using stun.counterpath.com for a while now and never run into any problem.

 

[nthomthom]

Oldly enough, the NAT keep alive strictly does the trick. I did enable STUN on the phones and this caused the phones NOT to function properly. Everything is working fine when I disable the STUN server and Enable NAT Keep Alive.

 

[albertc]

Good to know it is working fine for you now with Keep Alive enabled. I am a bit surprise that it wasn't enabled for you by default. Anyways, with STUN disable, you may run into connection issue IF your public address on your remote network changes. Just keep that in mind when/IF that happen.

 

[nthomthom]

Thanks for the support albertc.

I started to run into problems again such as NO RTP Packets Received and what not.

SO,

I have replaced my router with a router that is able to disable SIP ALG and I have ran the firewall checker. Everything passes with NO TRANSLATIONS now .

On my remote extension I am now able to enable 15s NAT Re Invite's as long as enable the use of a STUN server. Everything now seems to be working as should. Hopefully I do not have any issues. I did notice this on the server logs:

18:03:22.607 [MS205001] C:1.3 RTP: Party address changed from xxx.xxx.xxx.22:2 to xxx.xxx.xxx.22:59468

where, xxx.xxx.xxx.22 is the ip of the remote extension... do you guys know what this means and if this is normal behavior?

 

[albertc]

That looks normal to me as your firewall in your remote network is translating the port for you. As long as the Keep alive is enable, the NAT will keep that port open for you to receive incoming calls.

 

[SY]

I did notice this on the server logs:

18:03:22.607 [MS205001] C:1.3 RTP: Party address changed from xxx.xxx.xxx.22:2 to xxx.xxx.xxx.22:59468

where, xxx.xxx.xxx.22 is the ip of the remote extension... do you guys know what this means and if this is normal behavior?

It happen in case if remote phone does not provide correct information in SDP message. In this case media server adjust destination of outgoing stream. See description of ALLOWSOURCEASOUTBOUND parameter.