Intermittent Random “Not Registered” Events on Snom D785 Phones – 3CX v20 Update 8 – Phones Recover Automatically

[noneya]

Environment

PBX
Software: 3CX Phone System
Version: Version 20.0 Update 8 (Build 1109 Release)
Deployment: On-premises

Phones
Model: Snom D785 IP Phone (fw. version 10.1.175.16)
Provisioning: Standard 3CX auto-provisioning using the stock 3CX Snom template

Network

• Phones and PBX reside on the same Layer-2 network
• No NAT traversal involved
• No SBC in use for these endpoints
• Multiple access switches in the environment (mostly Cisco 3750X)
• Phones experiencing the issue are distributed across different switches and ports
• No switch link failures observed during events
• Devices do not drop simultaneously

Behavior Observed

Random phones will briefly show “Not Registered” on the handset display.

Key characteristics:

• Occurs randomly throughout the day
• Affects different phones each time
• No pattern tied to a specific switch or location
• Phones recover automatically within ~60 seconds
• Calls may already be idle when this occurs
• No mass deregistration event occurs

No instance has been observed where all phones deregister simultaneously.

3CX Server Logs

During the time windows where phones display “Not Registered”, the 3CX activity logs do not show extension deregistration events.

The phones appear to continue performing SIP REGISTER challenges normally.

Example handset log snippet during the timeframe of a reported event:

SIP registration cadence continues normally:

Mar 11 15:56:36
SIP: ProcessChallenge for active reg=0,0
process auth: Match challenge for user=[redacted], realm=3CXPhoneSystem, method=REGISTER

Mar 11 15:57:36
SIP: ProcessChallenge for active reg=0,0
process auth: Match challenge for user=[redacted], realm=3CXPhoneSystem, method=REGISTER

However, during the same window we observe transport instability on the phone:

Mar 11 15:56:39
SIP: Mid-Call Request INFO:(…) no failover. registration=?:()

Followed shortly by subscription refresh activity:

Mar 11 15:57:06
SIP: Subscription_refresh delay

Then transport socket timeouts:

Mar 11 15:57:45
PHN: TPL: Socket 1102 idle/connect timeout
PHN: TPL: Socket 1104 idle/connect timeout
PHN: TPL: Socket 1105 idle/connect timeout
PHN: TPL: Socket 1106 idle/connect timeout
PHN: TPL: Socket 1107 idle/connect timeout

Additional logs later show:

PHN: TPL: Socket Error: … Connection refused (111)
SIP: sip_transport_state_cb context lost

Provisioning Context

Phones are provisioned via:

https://[redacted-domain]:[port]/provisioning/...

with internal pulls from:

http://[internal-ip]:[port]/provisioning/...

Provisioning completes successfully after these events.

Phone firmware is managed through the standard 3CX firmware mechanism.

Other Observations

• Phones continue to authenticate with REGISTER every ~60 seconds
• No authentication failures are present
• No DNS failures are observed in logs
• Phones re-establish subscriptions and registration automatically
• Issue has occurred on multiple phones and extensions

Summary

The behavior appears to be:

1. Phone temporarily loses SIP/transport context
2. Handset UI reports Not Registered
3. Subscriptions and sockets reset
4. Phone re-registers successfully within ~60 seconds

We have not been able to identify:

• network interruptions
• DNS failures
• switch port flaps
• PBX-side deregistration events

Request

Has anyone encountered similar intermittent handset deregistration behavior with Snom D785 phones under 3CX v20?

Specifically:

• transient “Not Registered” state on the handset
• no corresponding deregistration event on the PBX
• socket timeout messages in handset logs
• automatic recovery within ~1 minute

Any guidance on further diagnostics or known firmware / transport issues would be appreciated.

Thank you for any assistance.

 

[Alphabetic]

Just a bit of background if you will..

How long has this set up been in place?

Has it just started happening?

My suspicion would be on the network.

can it be restarted?

Can you stick in a dumb switch that isnt cisco to see if a phone that had previously had this issue gets it again?

Are the phones POE?

are the switches managed?

Can you run a continuous ping over the switch(es) to see if you get any drops?

 

[noneya]

Thanks for the quick reply!

How long has this set up been in place?

A couple years

Has it just started happening?

No, this apparently has happened for a long time, but happens infrequently and short enough that it hasn't been a problem.

My suspicion would be on the network.
Can you run a continuous ping over the switch(es) to see if you get any drops?

It is possible, I am gathering that data, but as it only happens once ot twice a day it gets tricky.

can it be restarted?

I can restart anything (and have)

Can you stick in a dumb switch that isnt cisco to see if a phone that had previously had this issue gets it again?

We have a couple on a UBNT switch which have the same problem

Are the phones POE?

Yes

are the switches managed?

Yes

 

[noneya]

It is also of note that this is replacing a Cisco Call Manager installation, same switches, same network etc. and the UCS system did NOT have this issue.

 

[Alphabetic]

Could this be a DHCP lease issue?
Can anyone check the IP of the phone when this is occurring?

 

[noneya]

Pool is wide open, and there, and leases are unlimited. I can check though.

Is that phone firmware correct though? I am getting conflicting info if that is correct, it says upgrade is "available" but when I check the firmware file that 3CX is sending to the phone, it is the version that it is on...



When I click "upgrade" (which is a 500 network error):

 

[Alphabetic]

https://www.3cx.com/docs/phone-firmwares/ suggests this is the latest firmware.

 

[Alphabetic]

What happens if you go to System > Maintenance > Clear unused firmware and try again?

Maybe you have to delete the firmware manually from the firmware folder if this doesnt solve it.

 

[noneya]

What happens if you go to System > Maintenance > Clear unused firmware and try again?

Maybe you have to delete the firmware manually from the firmware folder if this doesnt solve it.

I tried it, no help unfortunately.

Here's the weird part, when I go to /provisioning/t4livjtim9/firmware/snom/snomD785.xml

I get this, which is why I almost think I am suppose to be on this version, but that URL suggests 10.1.215.13?

<firmware-settings>
<firmware perm="">http://xxx/provisioning/t4livjtim9/firmware/snom/snomD785-10.1.175.16-SIP-r.bin</firmware>
</firmware-settings>

 

[SteveITS]

For the firmware, try https://www.3cx.com/community/threa...-sip-t42s-–-3cx-hosted-v20.135742/post-649735

 

[JohnS_3CX]

Hi,

Have the phones been upgraded now? And how is it going after the upgrade?