Post update Outbound not Working

[JohnS_3CX]

Hi Andrew you check this list here: https://www.3cx.com/docs/ports/

 

[andrewV]

Thanks so JohnS just to clarify if i have a remote server and using stun to connect in a remote location i and my issue is outbound calls can not be made the ports i should be looking for any conflicts would be;
5060 and 5090 correct ?

 

[JohnS_3CX]

You mentioned that even with softphones ext-to-ext calls fails, so lets put STUN aside just for now.

You also mentioned that there is another PBX on the same network, generally that's not a good idea unless you know exactly how to set things up to avoid any conflicts or at the very least have them on separate public IPs and segregate the traffic accordingly.

Run a firewall test on the PBX and ensure that everything passes first, it may be the case that neither STUN phones nor soft clients can communicate properly with the PBX on the first place, and we can take it from there

 

[andrewV]

Do you guys think if i create a vpn tunnel from server site to remote site this issue would clear up ? And reprovision the phones to be on local subnet.

 

[JohnS_3CX]

You can do, and it would be a better solution than STUN (as you would not have to worry about port forwarding per each deskphone).

But I think you should run the firewall checker before you proceed further.

 

[andrewV]

I am clear across the board. All green

 

[JohnS_3CX]

Ok that's a good start, now you have to see if the invite from the phone or client indeed reaches your PBX. If you cannot see the invite in the activity with verbose logs, I would recommend to switch to run a capture if you are familiar with wireshark and see if anything arrives.

By the way have you tried creating a new extension and provisioning a phone or client to see if it works with the *777 echo test?

 

[andrewV]

Would you have me provision a new phone on an new extension however I am not at the local site only remote. Is that fine? I will do that then.

 

[JohnS_3CX]

Yep, so long as the ports are forwarded correctly from the remote site and no SIP-ALG is running you should be fine. You can use a free SIP and RTP port range that is not currently used (if you have another PBX running at the remote site and don't want to disturb its firewall settings) or even better use a desktop client with the tunnel to avoid it altogether

 

[andrewV]

So i went to the site with the server. Reprovision the phone locally and I was able to call out and receive calls. Therefore, there is something with the Stun issue

 

[andrewV]

Update*

I didn't end up finding out what the root issue was. Instead I created a VPN tunnel from Server Site to Remote Site where we are network communication to the 3CX server. My question now is there a way to migrate all the phones settings and everything from the STUN Config to the Local Config ?

 

[cobaltit]

Everything in the firewall checker (and a couple more). The basics are 5060 UDP, 5090 TCP/UDP and 9000-10999 UDP forwarded to 3CX. In addition you'll want 443 or 5001 depending on which port you chose for the web interface. 5060 TCP or 5061 are not currently tested in the firewall checker but would need to be forwarded if SIP over TCP or SIP over TLS is in use.

 

[cobaltit]

Whoops.. apparently I was responding to a post on page 1. If these are all soft phones/apps there really is no local VS STUN. The closest approximation would be to change the interface for provisioning from the FQDN to local IP (assuming you have a standard NAT'd setup. And if you have the settings already set like you mentioned then closing the app and re-opening should cause it to re-provision.

 

[JohnS_3CX]

Hi Andrew,

Once you setup your VPN, rebooting all the phones will make them appear under the "Phones" section. From there you can just assign them one by one to their respective extension again but choose Local instead of STUN in the provisioning. Softphones should not face any issues, I expect they should work normally.

If they still give you trouble it may be worth factory resetting them to make sure.