Hello everyone, I’ve encountered an unexpected issue after upgrading to Asterisk 20.9.3 with FreePBX 17. I’m not sure exactly when it started, as we don’t update frequently.
Here’s the problem: after running asterisk -rx 'core restart now' (or restarting Asterisk with systemctl restart asterisk, or even rebooting the server), all UDP clients quickly re-register and restore within about a minute. However, TLS clients take the maximum time configured on the device before re-registering for incoming calls. They only start receiving incoming calls after that timeout, although outgoing calls work fine in the meantime.
To speed things up, I have to manually re-register TLS clients. In FreePBX, we have Maximum Expiration = 7200, and on the devices, it’s set to 3600 (Qualify Frequency = 60). I’ve now had to adjust the registration time to 300 seconds as a workaround.
P.S. On Asterisk 20.5.0 with FreePBX 16, this issue didn’t exist: all clients, including TLS, would recover within a minute after a restart.
Has anyone else found a more permanent solution to this issue with TLS clients in Asterisk 20.9.3 and FreePBX 17?
I’m not really sure why there would be a difference, unless something outside of Asterisk is having an influence. Once Asterisk itself is restarted the TLS connection from it is lost including the registration, and it’s not involved in having the remote side re-register. It can’t even tell it to. It’s up to the remote side to determine the connection has been dropped, re-establish it, and re-register.
You’re absolutely right; that’s exactly what I’m trying to figure out. It’s puzzling why, in one instance, the phone detects the registration loss, while in another, it doesn’t, despite still allowing outgoing calls. Meanwhile, incoming calls won’t work.
@alexey_astashov
In that case, you can troubleshoot by running tcpdump on the FreePBX machine after restarting Asterisk to capture packets from the TLS device. This will help to determine how long the device takes to reconnect, as tls should typically reconnect immediately after losing the connection. It will confirm whether the issue is on the FreePBX side or elsewhere.
The controlled shutdown of a connection should be detected immediately, but there is no requirement to reconnect. Also, at least for normal SIP, the connection used for registration is not the connection used for outgoing calls, as they are set up in opposite directions.
TLS will normally keep a connection up, for reuse, but will not remake it, if it drops, until it is next needed.
What is strange here is that, with TLS, and a controlled restart, the remote endpoint should be notified that something has happened, but, with UDP, the only sign that something has gone wrong will be that they no longer receive calls. I can’t understand how UDP can possibly recover in less than the normal re-registration time.