3CX Health Check periodically unregisters Snom phones and drops a SIP trunk — can it be disabled or rescheduled?

[haba-beton]

Hi all,

Since updating to the latest 3CX version, the built-in 3CX Health Check now seems to run periodically on its own. Every time it runs, our Snom phones get unregistered for about a minute, and one of our SIP trunks goes red (unregistered) for roughly the same period. Both recover on their own afterwards, but during that minute calls are obviously affected.

The Health Report in the logs shows:

• Firewall check: Failed
• SIP trunks: OK
• Phone Templates: unsupported phones detected

My questions:

1. Can the automatic Health Check be disabled entirely, or at least scheduled to run only at defined / off-peak times?
2. Why does running the check disrupt live registrations in the first place? My suspicion is that the firewall/port-check portion is what temporarily interferes with the SIP traffic (which would also explain the "Firewall check: Failed" result) — can anyone confirm this is the mechanism?
3. Regarding "unsupported phones detected" for the phone templates: these are Snom devices that otherwise register and work without issues. Is this warning related to the disruption, or is it a separate cosmetic/templating issue?

Running version Version 20.0 Update 9 (Build 995 Release - AI 1.4.48)

Any pointers appreciated — thanks!

 

[bitn2]

1. Ive never seen an automatic health check that starts the firewallcheck
2. The firewallcheck interupts the services
3. this could be because of an outdated firmware or custome templates.

 

[haba-beton]

You're right — the firewall check isn't running automatically. The only "Firewall check: Failed" entry (15.07.2026 17:22) was me manually testing it; every automatic run says "Not checked" (screenshot attached).

We're on the latest version ("Sie sind auf dem neuesten Stand. Zuletzt aktualisiert: 16.06.2026 17:35").

Still, the automatic runs line up exactly with the disruption. The trunk that goes red for ~1 min is the one using a custom SIP trunk template — so that template seems to be what the check touches.

On the phones: we don't provision over 3CX, we use our own internal app. So "unsupported phones detected" is likely just cosmetic here.

 

[fxbastler]

Sie sind auf dem neuesten Stand.

Man darf im deutschen Forum auch gern in Deutsch schreiben

 

[fxbastler]

Since updating to the latest 3CX version, the built-in 3CX Health Check now seems to run periodically on its own.

Wie schon geschrieben: der läuft grds. nicht von allein. Das sollte nicht sein. Ich muss gestehen, ich wüsste auch gar nicht wo und wie das in einer 3CX geschehen soll.

Kann es sein, das ein externes Tool benutzt wird das die Systeminformationen o.ä. per API abruft oder etwas anderes separat Installiertes diese Aktionen auslöst?

Ist das eine Windows oder eine Debian 3CX?

Unabhängig davon würde ich mich darüber informieren lassen, ob kritische 3CX Dienste neu gestartet wurden, siehe Admin / System / Warnungen / Option Jeder Kritische 3CX-Dienst wird unerwartet beendet. So würde man auch per E-Mail informiert werden, ob dieser ominöse 3CX Health Check einen Systemdienst (und welchen) beendet und so das IP Telefon und SIP Trunk Problem auslöst.

Grundsätzlich ist es auch so, dass ein Dienst Neustart im Ereignisprotokoll auftaucht. Das würde das Verhalten ansatzweise erklären. Das ist in deinem Bild des Ereignisprotokoll nicht zu sehen - außer die Ausgabe wurde gefiltert, was man aber nicht im Bild sehen kann.

Nachtrag
Ich habe unabhängig davon auf mehreren Anlagen (alles Debian) geschaut. Keine hat einen solchen Eintrag bzgl. Health Report vom Dienst Web Manager.

 

[haba-beton]

Danke dir! Ist eine Debian-Anlage (v20).

Ein externes Tool oder API, das da was anstößt, kann ich eigentlich ausschließen. Und mit dem Ereignisprotokoll hast du recht, ein Dienst-Neustart steht da nirgends drin, der SIP-Server läuft laut Uptime seit Tagen durch.

Was ich inzwischen gefunden hab ist dass der Server hat gar kein funktionierendes IPv6, unser Polnischer Trunk löst aber per AAAA auf IPv6 auf. 3CX probiert dann zuerst über IPv6, das läuft ins Leere und in einen Timeout. In den Logs kam davor immer "Network is unreachable". Ob das jetzt wirklich die Ursache für die Trunk- und Telefon-Aussetzer ist, kann ich noch nicht mit Sicherheit sagen, aber der Timing-Zusammenhang war schon auffällig.

Ich hab IPv6 auf dem Server erstmal komplett deaktiviert und IPv4 bevorzugt. Interessant: die Meldungen kommen jetzt zwar immer noch, aber statt "Network unreachable" mit Timeout jetzt sofort "Cannot assign requested address", also der Fehlversuch bricht direkt ab statt hängen zu bleiben. Läuft seitdem stabil, seit dem Umstellen keine Aussetzer mehr. Ich beobachte das jetzt mal ein, zwei Tage.

Die Warnungs-Option für die kritischen Dienste mach ich trotzdem mal an, schaden kann's ja nicht.

 

[fxbastler]

Ich hab IPv6 auf dem Server erstmal komplett deaktiviert

Wo und wie? Es gibt zwei Stellen.
Unter Admin / Erweitert / Netzwerk die Option Automatisch an IPv6-Adapter binden ... deaktivieren und hier:
https://www.3cx.de/forum/threads/stun-fehler-in-logs.101470/post-339871

 

[haba-beton]

Danke. Wir hatten IPv6 direkt auf dem Server über die disable_ipv6.conf deaktiviert, dass es die Option direkt in 3CX gibt, wusste ich nicht und hab sie ehrlich gesagt auch nicht gesucht. Ich mach das heute Abend rückgängig und deaktiviere es stattdessen sauber in 3CX.

Wir haben den Server jetzt schon einige Jahre und die Option war eigentlich immer aktiviert, ohne dass wir Probleme hatten ,wahrscheinlich liegts also gar nicht daran. Aber einen Versuch ist es sowieso wert.

 

[fxbastler]

Beides machen: im Betriebssystem z.B. mittels der Datei /etc/sysctl.d/99-disable-ipv6.conf mit dem Inhalt

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

und die Option in der 3CX unter Admin / Erweitert / Netzwerk die Option Automatisch an IPv6-Adapter binden ... deaktivieren.

 

[haba-beton]

Alles klar, dann lass ich die 99-disable-ipv6.conf drin und setz zusätzlich die Option in 3CX. Vielen Dank, ich probier's mal aus und geb noch Bescheid.

 

[fxbastler]

Als nächstes geht es an die Logs der 3CX. Du kannst präventiv schon mal die Protokollierungsstufe des Aktivitätsprotokoll der 3CX auf Ausführlich und die Aufbewahrung auf 10 Tage stellen.

 

[Claas Beyersdorf]

Ich würde im Trunk unter Optionen noch den IP Modus von ANY auf IPv4 only stellen. Dann gibt es auch nicht mehr den Fehler, das die 3CX IPv6 auflöst und dann nicht benutzen kann, weil keine öffentlich geroutete IPv6 existiert.
Folglich gibt es die Fehlermeldungen auch nicht mehr

Und ja genau das kann ansonsten mikroausfälle bei Trunks verursachen. Weiß ich aus Erfahrung.

Natürlich nur wenn die Anlage halt wirklich keine funktionierende IPv6 hat.

Was den Health Report angeht, der läuft automatisch regelmäßig. Ist aber wirklich meines Wissens nach lediglich ein Report. Sprich er teilt einem mit ob all Telefone up to date sind und supportete Templates verwenden ob die VoIP Trunks supportet sind usw.

Sprich wenn alles grün ware also der letzte Firewall Check, Trunk, Telefone dann generiert er glaube ich einfach nur keinen Eintrag. Aber laufen müsste er trotzdem. Und er startet aber keinen Firewall Check sonder greift nur auf das Ergebnis vom letzten Check zurück.
Wie gesagt eigentlich nur ein Report kein Test.

Also soweit jedenfalls mein Kenntnisstand.

 

[haba-beton]

Vielen Dank, das war anscheinend die Ursache. Seit ich das vor zwei Tagen alles deaktiviert habe, läuft es ohne Probleme.

Bei den deutschen Trunks nutzen wir ein vorgefertigtes Template, und dort lässt sich das leider nicht direkt ausschalten. Aber dann erstelle ich einfach ein neues Template und deaktiviere es dort.

Nochmals vielen Dank!

 

[fxbastler]

dort lässt sich das leider nicht direkt ausschalten

Vorausgesetzt du hast den 3CX Parameter DEVELOPMENT_DNTABLE_EXPOSE auf 1, dann schau unter Admin / Erweitert / Parameter / <SIP-Trunk> / IP_RESTRICTION.

 

[haba-beton]

Nachtrag: leider nicht gelöst

Ich hatte oben gemeldet, dass es nach der IPv6-Abschaltung stabil läuft.
Das war zu früh. Die IPv6-Timeouts sind weg, der eigentliche Fehler tritt
weiter auf, auf 20.0.9.995 und auch auf 20.0.10.1277.

Der SIP-Server stellt ein bis zwei Mal täglich für
etwa 30 Sekunden das Antworten ein. Kein Absturz, kein Dienst-Neustart,
kein Log-Eintrag. Ich habe das mit tcpdump auf derm Server von der
Endgeräte-Seite gemessen:

00:19:55 ~450 Snoms fangen an, REGISTER zu wiederholen (135/s statt normal 8,5/s)
00:20:10 SIP-Trunk verliert die Registrierung (Event 12293)
00:22:10 Trunk wieder registriert (exakt 120 s Retry-Timer)

Entscheidend: in der Spitzenminute sind es 235 verschiedene Geräte, in der
Normalminute davor genau dieselben 235. Es melden sich also nicht mehr
Telefone an, sondern dieselben wiederholen exzessiv, einzelne über 100 Mal
in einer Minute. Ein SIP-Endgerät wiederholt nur bei fehlender Antwort. Und
die Telefone bemerken es 15 Sekunden vor dem Trunk, der Trunk-Ausfall ist
also die Folge, nicht die Ursache. Das erklärt auch, warum es manchmal ganz
ohne Trunk-Meldung passiert.

Ausgeschlossen habe ich mit Messwerten: Speicher (RSS 187 MB von 16 GB,
Swap leer, keine Ein-/Auslagerung), CPU (0 von 32 Threads aktiv), Platte,
Netz (alle Subnetze betroffen, auch das der PBX selbst) sowie unsere eigene
Provisionierung und API.

Dazu, wohl separat, aber dieselbe Komponente:

assertion failed:
/Sources/3rdParty/resiprocate/resip/dum/HandleManager.cxx:113: 0

30 Tage Journal vor dem Upgrade auf 20.0.9.995 (16.06.): null Assertions.
Erste 15 Stunden danach, seither rund 20. Der Vorgänger 20.0.9.670 lief
von Ende März bis Mitte Juni ohne eine einzige.

Meine Fragen:
1. Ist eine zeitweise Nichtbeantwortung von REGISTER in diesen Builds
bekannt?
2. Ich habe einen Vorfall mit eingeschalteter Verbose-Protokollierung
vollständig gesichert (.blrec + .bldef). Wohin damit?
3. Kann die Assertion an die Entwicklung gehen?
4. Gibt es eine Möglichkeit, solche Stillstände serverseitig zu
protokollieren? Aus Sicht der Anlage ist das Ereignis unsichtbar.
5. Unsere Registrierungsrate ist ungewöhnlich hoch: user_expiry steht bei
120 s, bei ~450 Geräten also rund 8,5 REGISTER/s dauerhaft, statt ~0,25/s
bei den üblichen 3600 s. Ist bekannt, ob eine so hohe
Registrierungs-Durchsatzrate den SIP-Server in diesen Zustand bringen
kann? Das wäre eine Erklärung dafür, dass ich zu diesem Fehlerbild
sonst nichts finde.

Messreihen, Sekundenauflösung und die Gerätelisten habe ich vorliegen und
reiche sie gern nach.

 

[fxbastler]

der eigentliche Fehler tritt
weiter auf, auf 20.0.9.995 und auch auf 20.0.10.1277.

Es wird davon abgeraten und ist auch keine gute Idee, eine produktiv genutzte 3CX mit einer nicht produktiv zu nutzenden Softwareversion zu betreiben. Die aktuelle 3CX v20 u10 hat gerade einmal Alpha Status.

Ist eine zeitweise Nichtbeantwortung von REGISTER in diesen Builds
bekannt?

Mir nicht, selber auf keiner Anlage erfahren und noch nirgends gelesen. Aber das hat nicht viel zu bedeuten.
Es steht auch nichts darüber im gerade erschienenen Changelog der 3CX v20 u10.

Ich habe einen Vorfall mit eingeschalteter Verbose-Protokollierung
vollständig gesichert (.blrec + .bldef). Wohin damit

Ab hier:
Wir können das noch eine Weile im Forum ausdiskutieren. Ich finde es sinnvoller, wenn das (der weitere Vorgang) über den eigenen Partner oder mit 3CX direkt geklärt wird. Das ist produktiver. Die benötigen dann diese Dateien.

4. Gibt es eine Möglichkeit, solche Stillstände serverseitig zu
protokollieren?

Ein Shell Skript auf der 3CX oder dem Switch ist eine Möglichkeit. Ein Monitoring - vorausgesetzt es ist schon eine entspr. Software im Einsatz (wir setzen z.B. Zabbix ein) - mit speziellen Erweiterungen ist auch eine Möglichkeit.
Es würde ja reichen, wenn schon die Menge an SIP Traffic überwacht wird: welche Art / wie viele Anfragen von welchen Geräte in welchem Zeitraum. Da gibt es mehrere Möglichkeiten.

Ist bekannt, ob eine so hohe
Registrierungs-Durchsatzrate den SIP-Server in diesen Zustand bringen
kann?

Ist mir nicht bekannt, aber das sollte noch lange kein Grund sein.

Wenn ich das so lese stellen sich mir noch ganz andere Fragen:

1. Läuft die 3CX physisch auf der Hardware oder ist die virtualisiert?
2. Wenn physisch: Was für eine Netzwerkkarte (Hersteller) ist in Verwendung?
3. Wenn virtualisiert: Was für ein Virtualisierer wird verwendet?
   Stichworte dazu: Zeitweitergabe vom Host unterbinden, ntp installieren und kontrollieren (sollte man immer tun)

 

[mbehrens]

Die IPv6-Timeouts sind weg, der eigentliche Fehler tritt
weiter auf, auf 20.0.9.995 und auch auf 20.0.10.1277.

Eine Alpha Version produktiv zu betreiben ist nicht unterstützt und eher suboptimal.

Ausgeschlossen habe ich mit Messwerten: Speicher (RSS 187 MB von 16 GB,
Swap leer, keine Ein-/Auslagerung), CPU (0 von 32 Threads aktiv), Platte,
Netz (alle Subnetze betroffen, auch das der PBX selbst) sowie unsere eigene
Provisionierung und API.

Das dürfte von der Leistung her mehr als ausreichend sein. Was ist aber
"sowie unsere eigene Provisionierung und API" ?

Ist eine zeitweise Nichtbeantwortung von REGISTER in diesen Builds bekannt?

Bisher nicht, aber das muss nichts heißen.

Ich habe einen Vorfall mit eingeschalteter Verbose-Protokollierung vollständig gesichert (.blrec + .bldef). Wohin damit?

An den 3X Support.

 

[haba-beton]

Erst mal danke für die Geduld und die Hilfe hier im Thread. Ich hab die Ursache gefunden, und ich muss sagen: sie lag bei uns, nicht an 3CX. Rausgefunden hab ich's zusammen mit meinem Kumpel (Claude ), wir haben zwei Tage lang auf der PBX mitgeschnitten und gezählt, bis das Muster rausgefallen ist.

Bei uns läuft neben den ~450 snom-Telefonen eine eigene Java-Anwendung (JAIN-SIP), die die Besetztlampen anzeigt. Die abonniert pro Arbeitsplatz alle 234 Nebenstellen mit SUBSCRIBE / Event: dialog, bei rund 70 Arbeitsplätzen sind das etwa 16.400 offene Abos.

Der Fehler steckte im Beenden. Unsere Abmeldungen (Expires: 0) gingen noch raus, 3CX hat dafür brav eine Digest-Anmeldung nachgefordert (407), und die Antwort darauf kam nie, weil wir den SIP-Stack im selben Moment schon abgeräumt haben. Damit sind pro geschlossenem Arbeitsplatz 234 Abos als Waisen stehen geblieben. Die verfallen später gemeinsam, 3CX schickt für jedes ein NOTIFY mit Subscription-State: terminated;reason=timeout, es quittiert aber keiner mehr, und dann wird jedes einzelne im 4-Sekunden-Takt neu übertragen.

In Zahlen: 463 verschiedene Call-IDs, aber 4.134 NOTIFYs. Faktor knapp 9. Über die ganze Flotte waren es in der Spitze 8.317 Kündigungen in einer einzigen Sekunde. Da kommt der SIP-Server nicht mehr nach, die Registrierungen verhungern, und unser polnischer Trunk ist als einziger UDP-Trunk der erste, der aufgibt. Trunk und Telefone waren also beides nur Folge.

Falls das bei jemandem anders auch so aussieht: das Erkennungszeichen sind Schwälle von „terminated"-NOTIFYs mit immer gleicher Stückzahl im 4-Sekunden-Abstand, aber jedes Mal anderen Call-IDs. Gleiche Menge, gleicher Abstand heißt, die PBX wiederholt ins Leere, weil da keiner mehr zuhört.

Geändert haben wir jetzt, dass die Abmeldung sauber zu Ende läuft, bevor der Stack fällt..

Zu den Fragen von oben: Das mit dem Alpha-Build hab ich verstanden, der Fehler war allerdings auf 20.0.9.995 genauso da. Eigene Provisionierung heißt bei uns, dass wir die snom-Konfiguration über eine Java API ausliefern; die XAPI nutzen wir nur lesend und zum Konfigurieren, beides war unbeteiligt. Läuft auf Debian 12 in einer Hyper-V-VM (Gen 2).

 

[fxbastler]

Danke für die Rückmeldung und die Information. Das hilft anderen sicher auch irgendwann irgendwo.

Letzten Endes ein Problem einer zusätzlich eingebundenen Drittanwendung. Gut dass es jetzt funktioniert.

Bei uns läuft neben den ~450 snom-Telefonen eine eigene Java-Anwendung (JAIN-SIP), die die Besetztlampen anzeigt. Die abonniert pro Arbeitsplatz alle 234 Nebenstellen mit SUBSCRIBE / Event: dialog, bei rund 70 Arbeitsplätzen sind das etwa 16.400 offene Abos.

Der Fehler steckte im Beenden. Unsere Abmeldungen (Expires: 0) gingen noch raus, 3CX hat dafür brav eine Digest-Anmeldung nachgefordert (407), und die Antwort darauf kam nie, weil wir den SIP-Stack im selben Moment schon abgeräumt haben. Damit sind pro geschlossenem Arbeitsplatz 234 Abos als Waisen stehen geblieben. Die verfallen später gemeinsam, 3CX schickt für jedes ein NOTIFY mit Subscription-State: terminated;reason=timeout, es quittiert aber keiner mehr, und dann wird jedes einzelne im 4-Sekunden-Takt neu übertragen.

Da muss man aber auch erst einmal drauf kommen. Im Aktivitätsprotokoll der 3CX im Modus ausführlich sollte das auch zu finden sein.

Über die ganze Flotte waren es in der Spitze 8.317 Kündigungen in einer einzigen Sekunde. Da kommt der SIP-Server nicht mehr nach

Schwer vorstellbar, dass der SIP Server das nicht schafft. Grundsätzlich ist der für hohe Lasten ausgelegt wenn die dafür nötige Leistung (speziell hier die Single Thread Performance der CPU und ausreichend Disk IO für die DB u.a.) vorhanden ist. Es gibt anderswo 3CX die weit größer sind.

Läuft auf Debian 12 in einer Hyper-V-VM (Gen 2).

Mein letzter Stand ist, dass das seitens 3CX grds. nicht unterstützt wird (auch wenn es funktioniert).

Aber:

Bei uns läuft ... eine eigene Java-Anwendung (JAIN-SIP), die die Besetztlampen anzeigt. Die abonniert pro Arbeitsplatz alle 234 Nebenstellen mit SUBSCRIBE / Event: dialog,

Das interessiert mich jetzt schon. Was für eine Art Besetztlampen verwendet ihr die ihr mit JAIN-SIP steuert?

 

[Josef L]

das würde mich auch interessieren, welche Funktionen steuert ihr mit Jain-Sip.