One Extension Flapping

FreePBX Endpoints
1

So on FreePBX v17 here, remotely hosted. We have one specific extension which seems to be randomly flagged unreachable, then reachable shortly thereafter. Happens maybe one or twice an hour. A Yealink SIP-T54W desk phone.

I’ll paste a snippet of the Asterisk logs below. What’s odd is even this snippet show timestamps when there is literally next to no network activity. No active users, and no active traffic on the network (I should know since I’m also sysadmin of said network :grinning_face: ).

We use a Cisco Meraki network, so I can peek into the managed switches and hardware firewall. Looking at the specific switch port the desk phone is patched into, I see no connectivity loss. And the hardware firewall likewise shows no connectivity loss. There are other Yealink desk phones also patched into the same switch, going out the same hardware firewall, and they don’t exhibit this behavior.

Looking at some config settings, this particular extension has Qualify Frequency defined at the default 60 seconds. The Meraki firewall has a hard-coded UDP connection timeout defined as 300 seconds. When the extension is registered I see the reported latency as around 21 ms. Not terrible.

Checking the logs on the desk phone itself, I don’t see anything popping up. I do have a packet capture that I just snagged, so I can share that once I sanitize it. Any ideas, other than perhaps a bad phone?

[2026-06-18 00:05:18] VERBOSE[3139045] res_pjsip_registrar.c: Added contact 'sip:390-1f3cb539c4e0441c3b385ab9dcf2efce@{provider_public_IP}:5060;x-ast-orig-host=10.18.102.175:5060' to AOR '390' with expiration of 3600 seconds
[2026-06-18 00:05:18] VERBOSE[3139045] res_pjsip_registrar.c: Removed contact 'sip:390@{my_public_IP}:2775;x-ast-orig-host=10.0.0.25:6060' from AOR '390' due to remove existing
[2026-06-18 00:05:18] VERBOSE[3546174] res_pjsip/pjsip_options.c: Contact 390/sip:390@{my_public_IP}:2775;x-ast-orig-host=10.0.0.25:6060 has been deleted
[2026-06-18 00:05:18] VERBOSE[3546174] res_pjsip/pjsip_configuration.c: Endpoint 390 is now Unreachable
[2026-06-18 00:05:18] VERBOSE[3139045] res_pjsip/pjsip_configuration.c: Endpoint 390 is now Reachable
[2026-06-18 00:05:18] VERBOSE[3139045] res_pjsip/pjsip_options.c: Contact 390/sip:390-1f3cb539c4e0441c3b385ab9dcf2efce@{provider_public_IP}:5060;x-ast-orig-host=10.18.102.175:5060 is now Reachable.  RTT: 24.765 msec
[2026-06-18 00:09:58] VERBOSE[3546174] res_pjsip_registrar.c: Added contact 'sip:390@{my_public_IP}:2775;x-ast-orig-host=10.0.0.25:6060' to AOR '390' with expiration of 600 seconds
[2026-06-18 00:09:58] VERBOSE[3546174] res_pjsip_registrar.c: Removed contact 'sip:390-1f3cb539c4e0441c3b385ab9dcf2efce@{provider_public_IP}:5060;x-ast-orig-host=10.18.102.175:5060' from AOR '390' due to remove existing
[2026-06-18 00:09:58] VERBOSE[3217546] res_pjsip/pjsip_options.c: Contact 390/sip:390-1f3cb539c4e0441c3b385ab9dcf2efce@{provider_public_IP}:5060;x-ast-orig-host=10.18.102.175:5060 has been deleted
[2026-06-18 00:09:58] VERBOSE[3217546] res_pjsip/pjsip_configuration.c: Endpoint 390 is now Unreachable
[2026-06-18 00:09:58] VERBOSE[3139045] res_pjsip/pjsip_configuration.c: Endpoint 390 is now Reachable
[2026-06-18 00:09:58] VERBOSE[3139045] res_pjsip/pjsip_options.c: Contact 390/sip:390@{my_public_IP}:2775;x-ast-orig-host=10.0.0.25:6060 is now Reachable.  RTT: 25.517 msec
[2026-06-18 00:53:53] VERBOSE[3177897] res_pjsip_registrar.c: Added contact 'sip:390-1f3cb539c4e0441c3b385ab9dcf2efce@{provider_public_IP}:5060;x-ast-orig-host=10.18.102.175:5060' to AOR '390' with expiration of 3600 seconds
[2026-06-18 00:53:53] VERBOSE[3177897] res_pjsip_registrar.c: Removed contact 'sip:390@{my_public_IP}:2775;x-ast-orig-host=10.0.0.25:6060' from AOR '390' due to remove existing
[2026-06-18 00:53:53] VERBOSE[3139045] res_pjsip/pjsip_options.c: Contact 390/sip:390@{my_public_IP}:2775;x-ast-orig-host=10.0.0.25:6060 has been deleted
[2026-06-18 00:53:53] VERBOSE[3139045] res_pjsip/pjsip_configuration.c: Endpoint 390 is now Unreachable
[2026-06-18 00:53:53] VERBOSE[3177897] res_pjsip/pjsip_configuration.c: Endpoint 390 is now Reachable
[2026-06-18 00:53:53] VERBOSE[3177897] res_pjsip/pjsip_options.c: Contact 390/sip:390-1f3cb539c4e0441c3b385ab9dcf2efce@{provider_public_IP}:5060;x-ast-orig-host=10.18.102.175:5060 is now Reachable.  RTT: 24.809 msec
[2026-06-18 00:54:58] VERBOSE[3217546] res_pjsip_registrar.c: Added contact 'sip:390@{my_public_IP}:2775;x-ast-orig-host=10.0.0.25:6060' to AOR '390' with expiration of 600 seconds
[2026-06-18 00:54:58] VERBOSE[3217546] res_pjsip_registrar.c: Removed contact 'sip:390-1f3cb539c4e0441c3b385ab9dcf2efce@{provider_public_IP}:5060;x-ast-orig-host=10.18.102.175:5060' from AOR '390' due to remove existing
[2026-06-18 00:54:58] VERBOSE[3159935] res_pjsip/pjsip_options.c: Contact 390/sip:390-1f3cb539c4e0441c3b385ab9dcf2efce@{provider_public_IP}:5060;x-ast-orig-host=10.18.102.175:5060 has been deleted
[2026-06-18 00:54:58] VERBOSE[3159935] res_pjsip/pjsip_configuration.c: Endpoint 390 is now Unreachable
[2026-06-18 00:54:59] VERBOSE[3217546] res_pjsip/pjsip_configuration.c: Endpoint 390 is now Reachable
[2026-06-18 00:54:59] VERBOSE[3217546] res_pjsip/pjsip_options.c: Contact 390/sip:390@{my_public_IP}:2775;x-ast-orig-host=10.0.0.25:6060 is now Reachable.  RTT: 26.083 msec
2

Okay, here are a couple of screen shots. First of what the packet capture from the Meraki switch shows. The FreePBX server sending the OPTIONS to the extension, and the extension responding. The second showing the extension flagged unreachable by the FreePBX server. Just seems odd since it’s this one particular desk phone extension.

Not the end of the world, since the user doesn’t utilize their desk phone a ton. But still strange to me at least.

image
image2902×150 42.8 KB

image
image1152×246 130 KB

3

Sorry if this seems obvious and you’ve already done it, but the first thing I would do is move the phone as far away as physically possible from where it is now and see if it settles down. I’d change the network cable at the same time, and ideally test it on a different switch port too. Also plug straight into the router to test for a couple of hours, if possible. It beats messing with the PBX or the phone itself before ruling out the local network.

4

Thanks for the feedback! What’s odd is that tracing things on the switch I can see OPTIONS being sent from the FreePBX and see the response being sent from the desk phone. But I just pulled the FreePBX side, based on the AWS EC2 instance’s Cloudwatch logs. Around that same timestamp (converting 15:29:59 local Eastern Time to 19:29:59 UTC), I don’t see the same activity. Neither the EC2 instance’s FreePBX sending OPTIONS nor the desk phone sending back the OK.

I will suggest the desk phone be relocated for testing. Like I said, not a huge deal but just strange. Now post-v17 I’m actually monitoring things closer than usual and not just waiting for trouble reports. lol.

image
image1530×366 81.3 KB

5

This sort of sounds more like a network issue, hardware. I see the specs on that phone and it has WiFi. Is it possible it is flipping from wired to wifi when it tries to connect ? Is the wifi on a different vlan or something ?

6

The Wi-Fi option on these phones isn’t configured. But I can see the two-sided traffic working from the switch to the hardware firewall to the AWS EC2 FreePBX. I’ll just chalk it up to gremlins, and hava the onsite folks try moving the desk phone to different spot in the network. If the problem persists then it might just be a buggy phone.

And I can see why the timestamps don’t align in terms of the traffic versus being flagged unreachable. The delay is on the FreePBX end in deciding the extension is indeed unreachable. The traffic is moving along as expected based on what I see.

7

Quick follow-up on this. Looking at the logs a bit before and after the flapping, I see the issue. This one specific user also has a softphone app used for testing. The FreePBX config only allows one registered extension per contact/user. So when the softphone app pushes its registration, the extension at the desk phone quickly flaps. The softphone mobile app isn’t actively running or being used. It’s just the push server’s background actions apparently. So at least a reasonable explanation for what I was seeing didn’t appear to be a networking issue. :upside_down_face: