STUN Server Timeout

[JST]

I am seeing the following messages in the Activity Log:

01/25/2017 7:03:08 PM - [CM506004]: STUN request to STUN server 151.80.125.97:3478 has timed out; used Transport: 0.0.0.0:5060
01/25/2017 7:03:05 PM - [CM506004]: STUN request to STUN server 151.80.125.97:3478 has timed out; used Transport: 0.0.0.0:5060
01/25/2017 7:03:02 PM - [CM506004]: STUN request to STUN server 151.80.125.97:3478 has timed out; used Transport: 0.0.0.0:5060
01/25/2017 7:02:59 PM - [CM506004]: STUN request to STUN server 151.80.125.97:3478 has timed out; used Transport: 0.0.0.0:5060
01/25/2017 7:02:56 PM - [CM506004]: STUN request to STUN server 151.80.125.93:3478 has timed out; used Transport: 0.0.0.0:5060
01/25/2017 7:02:53 PM - [CM506004]: STUN request to STUN server 151.80.125.93:3478 has timed out; used Transport: 0.0.0.0:5060
01/25/2017 7:02:50 PM - [CM506004]: STUN request to STUN server 151.80.125.93:3478 has timed out; used Transport: 0.0.0.0:5060

Does that mean that the 3CX STUN server is down or is there a problem on my end?

Thank you!

 

[GiannosC_3CX]

Hi JST,

Please could you run the 3CX firewall checker and let us know if it pass. Also please let us know if you use static public IP address.

 

[Sopock]

I also see this error on some small installs with dynamic IP!
In v15 there is no this checkbox?
Uncheck the “Turn off STUN requests” checkbox.

5  be10-1120.rbx-g2-a9.fr.eu (37.187.232.97)  15.735 ms be100-2.fra-1-a9.de.eu (94.23.122.217)  8.224 ms be10-1120.rbx-g2-a9.fr.eu (37.187.232.97)  15.685 ms
6  be10-1105.rbx-g1-a9.fr.eu (37.187.232.89)  17.738 ms  17.790 ms be100-1188.ldn-5-a9.uk.eu (91.121.128.89)  19.144 ms
7  be100-1187.ldn-1-a9.uk.eu (91.121.128.87)  21.143 ms be100-1298.nwk-5-a9.nj.us (192.99.146.133)  88.084 ms be100-1187.ldn-1-a9.uk.eu (91.121.128.87)  21.136 ms
8  be100-1295.nwk-1-a9.nj.us (192.99.146.127) 90.744 ms be10-1018.bhs-g2-a9.qc.ca (192.99.146.101)  96.541 ms  97.091 ms
9  be10-1037.bhs-g1-a9.qc.ca (192.99.146.99)  97.871 ms vl20.bhs-g2-a75-lo2.qc.ca (192.99.146.51)  95.949 ms be10-1037.bhs-g1-a9.qc.ca (192.99.146.99)  95.806 ms
10 vl20.bhs-g1-a75.qc.ca     (198.27.73.229)  96.207 ms be7.bhs1a-3a-a9.qc.ca (178.32.135.227)  96.723 ms vl20.bhs-g1-a75.qc.ca (198.27.73.229)  98.209 ms
11 * be5.bhs1a-3a-a9.qc.ca   (178.32.135.135) 99.566 ms *
12 * * *

 

[JST]

Yes, it passes the firewall test.

The test box is dynamic IP. Isn't STUN supposed to resolve issues with dynamic IP? I also checked if the dynamic IP is resolved against the FQDN I am using for it and it resolves just fine.

For testing, I have setup a VM at work using a static IP. Since it isn't using STUN, I don't see the message.

 

[JST]

I have resolved most other issues with a configuration backup and re-install. Apparently, some of my installation parameters used a wrong IP address.

That said, the STUN time out message above is now pretty much the only message I am seeing in my log. I am guessing that this message might impact mobile 3CX clients relying on STUN, but the timeout seems to come from the 3CX server and so I don't think there is much I can do.

Maybe we can get some feedback from 3CX on this? I am guessing that it is impacting everyone using dynamic IP. Thank you!

 

[GeorgeW]

Well, I have the same problem, backing up and reinstall is not an option for good design software.
I hope we get some feedback form 3cx too, but honestly I am getting tired of having a lot of issues for a "supposed" serious software

 

[JST]

I did the reinstall to resolve some IP related problems on my installation. However, this did not resolve the STUN issue and the error continuous to show up from time to time.

For fairness, I have to add that other PBX systems have trouble with STUN as well. As such, a static IP seems to be mandatory for a business environment aiming for reliability.

 

[nb]

If the stun message is this
01/25/2017 7:03:08 PM - [CM506004]: STUN request to STUN server 151.80.125.97:3478 has timed out; used Transport: 0.0.0.0:5060

It means that your pbx could not find a transport to connect to STUN server.
This is a problem from your Configuration, your host or your network.
Restarting, backup or reinstalling is useless and a waste of time. This is an issue on your side. Those stun servers serve all the 3CX installations worldwide and 3cx clients. They are on a network which has Gbit pipes..

Dynamic IP - well yes - STUN is designed to know your public ip. But server software should not be running behind public ip that change. I mean how cheaper do you want this to get.
Dynamic ip is a cheap solution so every so often, your pbx will have these problems because if your public IP changes, you need to do something. Like buying a cheap firewall - you have to restart it every 3 days.
Either restart the services or restart the firewall. STUN is there to tell the pbx what the new ip is. But you also need to tell the firewall and tell the mappings in the routing table and memory (To do this immediately it is impossible without an immediate restart).

You expect the performance of a BMW but you you expect to get this with the price of a Fiesta. Get a static ip and you will see that your OVERALL company performance will start to get better..

You should not have a professional pbx with a dynamic ip. Like you dont have a mail server. Like exchange. Like every other production service in the world.

 

[Sopock]

It means that your pbx could not find a transport to connect to STUN server.
This is a problem from your Configuration, your host or your network.

It seems that Linux version will never detect IP?

Dynamic ip is a cheap solution so every so often, your pbx will have these problems because if your public IP changes, you need to do something. Like buying a cheap firewall - you have to restart it every 3 days.

3CX should listen for new IP?

Spoiler: Announcing Address Changes

Upon boot, acquisition of an external IPv4 address, subsequent change of the external IPv4 address, reboot, or any other event that may indicate possible loss or change of NAT mapping state, the NAT gateway MUST send a gratuitous response to the link-local multicast address 224.0.0.1, port 5350, with the packet format above, to notify clients of the external IPv4 address and Seconds Since Start of Epoch.

 

[DSXVOICE]

Do a trace route on 151.80.125.97. It's possible that the connection between you and the stun server has occasional issues in the middle. If you are not in France or on the same continent, it would not be surprising to see some packet loss.

 

[leejor]

Don't forget, you are not limited to using a 3CX STUN server (they do have multiple servers too). You can try any public STUN server that you wish. You can do this as a test, to see if the log is still there, when the server is changed.
STUN is simply a tool to allow your server to understand the network in which t exists, (type of NAT), and it's public IP.
If you do some searches, you'll come across lists of servers (some, more up-to-date), such as this...
http://www.tek-tips.com/faqs.cfm?fid=7542

 

[Sopock]

Don't forget, you are not limited to using a 3CX STUN server (they do have multiple servers too). You can try any public STUN server that you wish. You can do this as a test, to see if the log is still there, when the server is changed.

Thanks. New servers will detect IP after service restart. From this topic we can see how much time can be wasted on something we may not even need?
It is also not very efficient to check and get same IP 70 times per day? Multicast approach is by far better where available?

Static IP is cost prohibitive in many cases. They can either use dynamic IP or flee to

Spoiler: Cloud provider!

Legacy private branch exchange (PBX) systems are usually cost prohibitive for smaller remote locations consisting of fewer than ten users.

We usually use private SIP trunks, these break out into a private network at our SIP provider and provide external call routing via this. On the internal side we have another NIC with footprint in internal network.

I have a bunch of voip phones on my lan connected to a POTS phone line via a gateway, so I do not use an external VOIP service. All works well, and I have no need to be able to reach the 3cx console from outside my LAN so I don't need fqdn for that purpose.

This issue is for small business and Home Use where costs are a factor but what is the down side or will not having a Static IP and NAT even be possible

Single stun.3cx.com is needed to return closest?

Spoiler: Welcome to Traffic Director