Qualify=0 fixed endpoint unreachable issues

FreePBX Endpoints
, ,
#1

On my FreePBX server (PBXAct to be precise), I have several remote PJSIP extensions and PJSIP trunks.

With the default configuration of qualify=60 secs, the SIP trunks and remote extensions were CONSTANTLY becoming ‘unreachable’ (log showed for example: ‘endpoint voipms is now unreachable’; ‘endpoint 123 is now unreachable’) / PBX was deciding they are unreachable and temporarily freezing the trunk / remote extension from use (it would become useless - no in/out calls etc. - until after a few minutes when the trunk/ext re-established correctly but then it kept happening again). For the record, I tested the PBX on several networks with different firewalls and internet connections, and with qualify enabled (no matter what value except 0), the remote extensions+trunks were becoming unreachable all the time.

(For background info - the trunks I used were voipms and telnyx. Remote extensions were connected thru to the static IP of the PBX network and some also via DDNS. NAT was properly set.)

To fix this for the trunks and remote extensions, I set qualify=0 (to turn it off) for all the remote extensions and the SIP trunks. Now after setting it to zero, there are absolutely NO issues with unreachability on both the trunks and remote extensions for several months now (previously they would constantly show as unreachable for several minutes and be useless during that period) and there hasn’t been a single instance where the phone is flashing as useless (when unreachable, the phones no matter what model, flashed as unregistered and then once reachable again they worked for a few more minutes until this repeated, and it also happened in the middle of calls).

There also hasn’t been a single entry in the log with the word ‘unreachable’ for all this time since qualify is set to zero therefore no more of these issues and I have been happy with my 100% stability for the remote extensions and trunks… (I have been checking the logs all the time and downloading copies to analyze and didn’t see anything with the word unreachable, and before setting qualify=0, it was happening every few minutes for all the remote extensions and trunks).

Can someone please explain why disabling qualify fixed this.

#2

Fixed is an optimistic assessment of the result.

When Asterisk logs “unreachable” it has one meaning. A SIP OPTIONS packet was sent from Asterisk to an endpoint and it did not receive an OK back. Either the OPTIONS packet was lost/blocked on the way to the endpoint, the endpoint received the OPTIONS and ignored it (unlikely) or the OK was lost/blocked on the way back. If the OK is received late, then Asterisk logs the endpoint as being ‘Lagged’. When an endpoint is in an unreachable state Asterisk will not send an INVITE (a call) to it, tho it will accept an INVITE. It can serve as a way of keeping paths open in NAT devices and keeps a current status on the health of registrations.

When you set the qualify parameter, you’re defining the frequency for Asterisk to send the OPTIONS packet. By disabling it, you disable the mechanism that generates the unreachable messages. So it’s not surprising that your logs are cleaner, but there is still a possibility (likelihood even) that you have an issue with SIP packets going astray.