Good morning, all.
This morning our system was unable to process any calls. I had previously been running on the beta for FPBX13 and had since loaded a fresh box with the GA release and restored the config. A couple of minor tweaks that weren’t part of the restore (like users who had voicemail active, no longer did).
The new system has been working fine for a couple days. This morning, however, it was unable to process any calls. After troubleshooting for a little while, I was able to identify some seemingly odd behavior - an attempt to make an internal call would reply with NO RESPONSE from the system - but about a minute later, the target extension would ring (even though the initiating extension had already been presented with “no response” and hung up. This immediately pointed to a STUN issue to me, as I’ve seen this type of odd behavior before.
Sure enough, the STUN server we had been using was off-line. As soon as I removed the STUN server from SIP SETTINGS (and applied, of course), everything began to function again.
My question is, why was STUN in use for internal (and direct to VM) calls? I thought the whole purpose of defining your internal IPs in SIP SETTINGS was so the system could decide whether it required the use of STUN or not, and since my phones IPs are in that list (192.168.101.0/24), I would have expected internal calls to work properly, while calls to/from outside to fail.
Does anyone have any thoughts on this, as we had been seeing some higher than normal utilization on our STUN server as well, and it appears that was likely the cause if every internal call was utilizing it (also explains some station-to-station latency we had been hearing).
It’s also very possible (likely) I still don’t have a full grasp of how Asterisk/FPBX “thinks” in regards to SIP traffic since my past lives involved another brand (Avaya).