I administer 3 FreePBX machines all of which run current versions. This morning all of them were experiencing delays between the dial command and the sip phone rining. In each case removing stun.counterpath.com from Settings -> Asterisk SIP Settings was enough to take care of the issue. I first tried adjusting DNS servers but that didn’t make a difference. Is this just my machines or are others running into this?
I came across an old thread someplace online that indicated this would be worth trying while troubleshooting delays caused by DNS. I can’t find it to give them credit. But thanks to whoever it was!
I’m having the same issue too. removing stun.counterpath.com seemed to have fixed the issue.
thanks for posting this… I was pulling out my hair trying to figure out what was going wrong this morning.
Most people don’t need a STUN server for their PBX, so be sure that you really need one before you fill that in.
The only time you need a STUN server in Asterisk is if you don’t know your external IP address (dynamic addresses is the most common case). Using it when you don’t need it might give you a sense of security, but if your system’s NAT settings are correct and the external IP address is set correctly, you should not use it.
Well the issue is counterpath has taken offline their stun server or blocking it from non counterpath user agents. I have reached out to their CTO who is a friend for clarification.
The reason so many people put in a STUN server is you need it for WebRTC and in user management if you try and enable WebRTC it informs you that you need to go setup a STUN server in SIP Settings module.
The issue with enabling this in SIP Settings module is it also enables STUN for all of Asterisk and since chan_sip is single threaded every invite causes chan SIP to hit the STUN Server and wait for it to time out.
We have added into edge release of SIP Settings module a spot now to define just a STUN server for WebRTC which will not effect all of chan_sip in the event that the STUN server goes down. If you are using WebRTC please update your SIP Settings module from edge and define your STUN server for WebRTC and leave the RTP STUN server blank.
The saddest part here is hundreds of users had this issue today and we spent ahwile this morning on the Sangoma PBX with the same issue with a large team debugging this thinking it was related to the new kernel we just published as the invites were making it to the kernel right away just delayed making it to Asterisk. Had Asterisk put in a proper error on this it would of been found in the debug logs in 2 seconds instead of users wasting hours and hours trying to figure out why the delay.
I am going to get a feature request into Asterisk to put in a proper warning when a STUN server can not be reached.
UPDATE The CTO of Counterpath just got back to me. Apparently the lost 2 major servers today and there load balanced stun server happened to be on both servers. They are working on getting it restored but we will recommend users not using WebRTC to make sure they do not have a STUN Server set and users who are using WebRTC update to the latest edge version of SIP Settings module and set a new STUN server for the new WebRTC Stun Server setting.
We got hit by this as well, and it hurt pretty badly. Since both our primary and backup servers were both pointed at Counterpath’s STUN server, our failover was just as broken as our primary, and it took me a few hours (and thankfully, this thread) to find out what was causing the problem. I fully realize that FreePBX is in no way to blame, but I wanted to make an additional suggestion: Does Asterisk support multiple configured entries for a STUN server? If so, could FreePBX support perhaps a delineated list of STUN servers in the General SIP Settings tab?
For what it’s worth, I tried entering multiple lines for stunaddr= in /etc/asterisk/sip_additional.conf, and Asterisk seemingly just tries the first entry and gives up. I tested by entering an invalid STUN address as the first entry, then ran a tcpdump to that address. I could see the attempts being made to the invalid address, but none to the secondary addresses.
My guess is that means Asterisk itself would need to be modified to failover the STUN settings, unless there could be a different way to enter it into the configuration. I also tried a few different variants of semicolon separated addresses as well as multiple lines, and in the cases I tried, Asterisk always seemed to try the first entry for ~20 seconds then give up.