3CX SIP-Trunk-Fehlerdiagnose: Wenn der Trunk sich nicht registriert
Ein 3CX-Trunk, der sich nicht registriert, ist selten ein Rätsel — der SIP-Fehlercode sagt fast immer ziemlich genau, wo das Problem liegt. Diese Seite ordnet die wichtigsten Codes systematisch ein, liefert einen Entscheidungsbaum von der schnellen zur aufwendigen Prüfung und zeigt an einem realen Fall, warum ein nachweislich korrekt konfigurierter Trunk trotzdem wochenlang scheitern kann, ohne dass es jemandem auffällt.
1. Symptom erkennen: Woran Sie einen hängenden Trunk erkennen
Vier Anzeichen deuten auf ein Trunk-Problem hin, unterschiedlich leicht zu bemerken:
- Trunk-Status rot in „Trunks & Chat": die offensichtlichste Variante — die Statusanzeige zeigt direkt, dass keine aktive Registrierung besteht.
- Wiederkehrende Meldungen im Ereignisprotokoll: auch wenn der Status zwischenzeitlich grün erscheint, können im Hintergrund einzelne Registrierungsversuche fehlschlagen.
- Keine eingehenden Anrufe, Anrufer hören „besetzt" oder werden direkt zur Mailbox des Providers weitergeleitet: das Signal kommt nie bei 3CX an, weil keine gültige Registrierung besteht, über die der Provider zustellen könnte.
- Der stille Fall — ausgehend geht, eingehend nicht: Manche Trunks sind bewusst „nur ausgehend" konfiguriert und registrieren sich grundsätzlich nicht — das ist normal. Problematisch wird es, wenn ein Trunk registrierungsbasiert sein sollte, es aber nicht mehr ist: Ausgehende Anrufe können über statische Routen trotzdem funktionieren, während eingehende Anrufe komplett ausbleiben, weil der Provider die Zieladresse nicht mehr kennt.
2. Diagnose-Entscheidungsbaum: vom Symptom zur Ursache
Erst prüfen, was kostenlos und in Minuten erledigt ist — erst danach zu aufwendigeren Mitteln wie SIP-Trace oder Provider-Ticket greifen:
| Schritt | Prüfung | Aufwand | Ergebnis |
|---|---|---|---|
| 1 | Trunk-Status in Trunks & Chat ansehen | ~10 Sekunden | Rot → weiter zu Schritt 2. Grün, aber trotzdem Probleme → direkt zu Schritt 4 (Codec/Routing statt Registrierung) |
| 2 | Ereignisprotokoll nach dem Trunk-Namen filtern, letzte 24–48 Std. | ~2 Minuten | Fehlercode notieren (z. B. 401, 403, 408) → Fehlercode-Tabelle unten konsultieren |
| 3 | Zugangsdaten im Trunk-Tab Allgemein zeichenweise mit dem Provider-Portal abgleichen | ~5 Minuten | Abweichung gefunden → korrigieren und Registrierung neu anstossen. Keine Abweichung → weiter zu Schritt 4 |
| 4 | Firewall-Ports, Erweitert → IP-Sperrliste und SIP ALG am Router prüfen | ~10–15 Minuten | Blockierender Eintrag oder aktives SIP ALG gefunden → entfernen/deaktivieren. Sonst weiter zu Schritt 5 |
| 5 | SIP-Logging aktivieren (Dashboard → Aktivitätsprotokoll → Einstellungen, Stufe „Verbose") und nächsten Registrierungsversuch im Trace auswerten | ~15–30 Min. (inkl. Wartezeit) | Fehlerdetails im SIP-Header sichtbar → häufig eindeutiger Hinweis auf Provider- oder Netzwerkursache |
| 6 | 3CX Firewall Checker ausführen und/oder Provider-Ticket mit den gesammelten Daten öffnen | ab 30 Minuten | Bestätigt oder schliesst Netzwerkursache aus; Ticket klärt providerseitige Ursachen |
3. Fehlercode-Referenztabelle
Die Kurzform: Was der Provider mit dem jeweiligen Code eigentlich sagt, die wahrscheinlichste Ursache und der sinnvolle nächste Schritt.
| Code | Was der Provider damit sagt | Wahrscheinlichste Ursache | Nächster Schritt |
|---|---|---|---|
401 Unauthorized | „Weise dich aus" — normale Authentifizierungs-Herausforderung im Registrierungsablauf | Bleibt sie dauerhaft bestehen statt in ein 200 OK überzugehen: falsche oder vom Provider zurückgewiesene Zugangsdaten | Auth-ID und Passwort im Provider-Portal neu abrufen und exakt übernehmen; siehe Fall unten |
403 Forbidden | „Ich verstehe die Anfrage, lehne sie aber bewusst und endgültig ab" | Konto gesperrt, IP-Adresse beim Provider blockiert, oder Trunk vertraglich deaktiviert | Provider-Support kontaktieren — 3CX-seitig ist hier meist nichts mehr zu korrigieren |
407 Proxy Authentication Required | Ein zwischengeschalteter Proxy im Signalweg verlangt eigene Zugangsdaten, unabhängig vom Registrar | Proxy-spezifische Credentials fehlen oder Realm im Trunk stimmt nicht mit der Angabe des Proxys überein | Providerdoku prüfen, ob ein separater Proxy im Signalweg liegt; Realm/Domain-Feld im Trunk kontrollieren |
408 Request Timeout | Keine Antwort erhalten — kein inhaltlicher Fehler, sondern Netzwerkstille | Firewall verwirft Pakete, Provider nicht erreichbar, oder Antwortpaket geht auf dem Rückweg verloren | Erreichbarkeit des Registrars prüfen (Ports, Routing), danach SIP-Trace auswerten |
480 Temporarily Unavailable | Der Provider hat geantwortet, das Ziel ist aber aktuell nicht erreichbar | Bei Trunks selten die Ursache für Registrierungsfehler, häufiger bei einzelnen Anrufen — Zielrufnummer oder providerseitige Route vorübergehend gestört | Nach kurzer Zeit erneut prüfen; hält der Zustand an, Provider-Ticket öffnen |
488 Not Acceptable Here | Die angebotenen Sitzungsparameter (meist Audio-Codec) werden abgelehnt | Codec-Mismatch zwischen 3CX-Trunk-Template und Provider — betrifft laufende Anrufe, nicht die Registrierung selbst | Codec-Reihenfolge im Trunk-Template prüfen (häufig G.711 vs. G.729), bei Fax explizit T.38 bzw. G.711 sicherstellen |
503 Service Unavailable | Der Server antwortet, ist aber aktuell überlastet oder in Wartung | Providerseitiges Kapazitäts- oder Wartungsproblem, seltener eigene Serverüberlastung | Providerstatus prüfen, nach kurzer Wartezeit erneut versuchen, bei Dauerzustand Ticket öffnen |
| Kein Response / Trunk bleibt „nicht registriert" ohne Fehlermeldung | Die Anfrage kommt nie beim Provider an oder die Antwort nie zurück — kein SIP-Fehlercode, weil gar kein Dialog zustande kommt | Firewall blockiert Port 5060 komplett, falscher Registrar-Hostname, oder fehlendes Routing zum Provider | Erreichbarkeit des Registrar-Hostnamens und der Ports 5060/UDP bzw. TCP von aussen und innen prüfen |
4. Der 401-Fall im Detail: ein durchgerechnetes Beispiel
Die folgende Diagnose stammt von einer produktiven 3CX-Anlage (V20 Update 9, 51 Nutzer) und ist anonymisiert dargestellt — ohne echte Firmen-, Provider-Kontodaten oder Rufnummern.
Ausgangslage
Im Ereignisprotokoll fand sich eine Meldung mit Ereignis-ID 12294, Schweregrad „Warnung", Quelle „SIP Server":
Call or Registration to <Trunkname> has failed. sip:<user>@<registrar>:5060 replied: 401 Unauthorized; from IP:<ip>
Frequenz: exakt alle 5 Minuten, ohne Unterbrechung. Das Ereignisprotokoll bestand über 232 Seiten fast ausschliesslich aus dieser einen Meldung — ein Zeitraum von deutlich über einem Monat, ohne dass es jemandem aufgefallen war.
Was die Konfiguration ausschloss
Die Prüfung nach dem Entscheidungsbaum oben ergab: richtiger Registrar-Hostname, Port 5060, Transport UDP, registrierungsbasierte Authentifizierung korrekt hinterlegt, keine Doppelregistrierung desselben Kontos von zwei Systemen aus, und die IP der Anlage stand auf keiner Sperrliste beim Provider. Ein zweiter Trunk desselben Providers, mit anderer Auth-ID, lief zur selben Zeit einwandfrei — allerdings war dieser bewusst „nur ausgehend" konfiguriert und registrierte sich gar nicht, sodass sich seine Funktionstüchtigkeit nicht direkt mit dem gescheiterten Trunk vergleichen liess.
Fazit
Da 3CX-seitig jede erreichbare Ursache ausgeschlossen war und der 401-Code exakt und dauerhaft denselben Ablauf zeigte, lag die Ursache mit hoher Wahrscheinlichkeit bei den providerseitig hinterlegten Zugangsdaten für diesen konkreten Trunk-Account — nicht in der 3CX-Konfiguration. Die Klärung musste über ein Provider-Ticket erfolgen (siehe Abschnitt 6).
Der Fall zeigt die Kernlehre dieser Seite doppelt: Erstens schliesst ein nachweislich korrektes Setup einen Trunk-Fehler nicht aus, wenn die Ursache ausserhalb der eigenen Konfiguration liegt. Zweitens vergiftet ein dauerhaft scheiternder Trunk das Ereignisprotokoll bis zur Unbrauchbarkeit — bei einer Frequenz von alle 5 Minuten entstehen in einem Monat weit über 8.000 identische Einträge, in denen ein einzelner echter Fehler an anderer Stelle leicht übersehen wird.
5. Netzwerk- und Firewall-Ursachen
Bevor eine Ursache beim Provider vermutet wird, lohnt sich ein Blick auf die eigene Netzwerkseite — besonders bei sporadischen statt permanenten Fehlern.
NAT und SIP ALG
SIP ALG („Application Layer Gateway") ist eine Router-Funktion, die SIP-Pakete beim Durchleiten inhaltlich verändert, um NAT-Probleme zu „reparieren" — in der Praxis verursacht sie in den meisten Fällen genau die Probleme, die sie eigentlich lösen soll. Sie ist der Klassiker unter den Firewall-Ursachen und praktisch immer die erste Vermutung, wenn ein Trunk-Fehler sporadisch statt dauerhaft auftritt oder nach einem Router-Firmware-Update neu einsetzt. 3CX bietet dafür einen eingebauten SIP-ALG-Check im Firewall Checker: Er sendet ein generisches INVITE an einen 3CX-Onlinedienst und vergleicht eine lokal berechnete Prüfsumme mit der zurückgemeldeten — weicht sie ab, hat ein Zwischenschritt (in aller Regel der Router) die Nachricht verändert. Empfehlung: SIP ALG am Router deaktivieren, sofern der Hersteller das zulässt.
Ports, RTP-Bereich und IP-Sperrliste
Für Signalisierung wird Port 5060/UDP (bzw. 5060–5061/TCP) benötigt, für die Sprachdaten der RTP-Bereich 9000–10999/UDP — zwei Ports je gleichzeitigem Gespräch. Fehlt die Freigabe für den RTP-Bereich, registriert sich der Trunk zwar oft trotzdem, aber Gespräche bauen ohne Audio auf oder brechen ab. Zusätzlich lohnt ein Blick in Erweitert → IP-Sperrliste: Diese Liste kann sowohl Sperr- als auch Erlauben-Einträge enthalten — ein zu restriktiver oder versehentlich gelöschter Erlauben-Eintrag für die Provider-IP kann Registrierungsversuche stillschweigend verwerfen, ohne dass 3CX selbst einen Fehlercode protokolliert.
Keepalive und technische Parameter
Unter Erweitert → Parameter lassen sich technische Werte wie KEEPALIVE_TIME_UDP (Standard 30 Sekunden) und LOCALSUBNETS einsehen — Letzteres definiert, welche IP-Bereiche 3CX als „lokal" statt als „extern über NAT" behandelt (Standard u. a. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Ein zu kurzes oder fehlendes UDP-Keepalive kann dazu führen, dass NAT-Bindungen von Router oder Provider-seitigem Firewall zwischen zwei Registrierungsversuchen verfallen — die anschliessende Anfrage findet dann keinen offenen Rückweg mehr, was sich häufig als 408 Request Timeout statt als Auth-Fehler zeigt.
6. Wenn es am Provider liegt: was ins Ticket gehört
Ist die 3CX-seitige und netzwerkseitige Prüfung abgeschlossen und die Ursache bleibt unklar oder liegt nachweislich beim Provider, entscheidet die Qualität des Tickets darüber, ob der Support sofort helfen kann oder erst drei Rückfragen stellt. Ins Ticket gehören:
- Exakter Zeitstempel mindestens eines fehlgeschlagenen Versuchs (mit Zeitzone) — der Provider sucht damit gezielt in seinen eigenen Logs statt im Blindflug
- Der SIP-Fehlercode im Wortlaut aus dem Ereignisprotokoll, z. B. „401 Unauthorized"
- Registrar-Hostname bzw. Server-Adresse, gegen den registriert wurde
- Authentifizierungs-ID des betroffenen Trunk-Accounts — niemals das Passwort im Ticket oder per E-Mail mitschicken
- Die eigene öffentliche IP-Adresse, von der aus registriert wird — wichtig, falls der Provider IP-basiert filtert oder eine hinterlegte IP veraltet ist
Mit diesen fünf Angaben kann ein Provider-Support in aller Regel innerhalb der eigenen Systeme nachvollziehen, ob die Zugangsdaten serverseitig korrekt hinterlegt sind, ohne weitere Rückfragen zu stellen.
7. Vorbeugen: Trunk-Ausfälle überwachen statt im Protokoll begraben
Der reale Fall oben lief über einen Monat unbemerkt, weil niemand aktiv ins Ereignisprotokoll geschaut hat — der Trunk-Status selbst kann zwischenzeitlich unauffällig wirken, wenn andere Trunks oder Teile der Anlage weiterlaufen. Sinnvoller Gegenschritt: Im Ereignisprotokoll steht neben den Filtereinstellungen eine Benachrichtigungsfunktion (Glocken-Symbol) zur Verfügung, über die sich E-Mail-Benachrichtigungen für bestimmte Ereignistypen aktivieren lassen, darunter eine Option für „Trunk/SBC sind down". Aktiviert, meldet sich die Anlage aktiv, statt dass ein Ausfall erst auffällt, wenn ein Kunde sich über nicht erreichbare Rufnummern beschwert.
Ergänzend hilft eine einfache Routine: Das Ereignisprotokoll nicht nur bei akuten Problemen, sondern in regelmässigen Abständen stichprobenartig auf ungewöhnlich häufige Wiederholungen derselben Meldung zu prüfen — genau das Muster, das im beschriebenen Fall über Wochen unbemerkt blieb.
8. Häufig gestellte Fragen
Was bedeutet 401 Unauthorized bei einem 3CX-Trunk?
401 Unauthorized ist die Aufforderung des Providers, sich mit Zugangsdaten auszuweisen — 3CX sendet daraufhin die Registrierung erneut mit Authentifizierungsheader. Kommt diese Antwort dauerhaft statt eines erfolgreichen 200 OK zurück, akzeptiert der Provider die gesendeten Zugangsdaten nicht.
Worin unterscheidet sich 401 von 403 Forbidden?
401 ist eine normale Authentifizierungs-Herausforderung im Registrierungsablauf. 403 ist eine endgültige Ablehnung: Der Provider hat die Zugangsdaten geprüft und lehnt sie bewusst ab, oft verbunden mit einer IP- oder Kontosperre.
Warum bestand das Ereignisprotokoll fast nur aus einer einzigen Meldung?
Ein Trunk, der alle 5 Minuten erneut zu registrieren versucht und dabei jedes Mal scheitert, erzeugt bei jedem Versuch einen neuen Protokolleintrag. Über Wochen summiert sich das zu Hunderten Seiten derselben Meldung, in denen seltene, echte Fehler untergehen.
Wie aktiviere ich SIP-Logging in 3CX?
Im Dashboard unter Aktivitätsprotokoll (Activity Log) die Einstellungen öffnen und die Logging-Stufe auf die ausführliche Stufe (Verbose) setzen. Damit werden auch die SIP-Meldungen selbst protokolliert, nicht nur deren Ergebnis.
Kann SIP ALG schuld sein, auch wenn der Trunk vorher funktioniert hat?
Ja. SIP ALG wird oft erst nach einem Router-Firmware-Update aktiv oder verändert sein Verhalten. Typisches Muster ist ein sporadischer statt eines permanenten Fehlers — der Trunk registriert sich meistens, bricht aber unter bestimmten Bedingungen ab.
9. Häufige Fehler und Lösungen
Trunk zeigt grün, aber alle paar Minuten erscheint dieselbe Warnmeldung
Ein grüner Status bedeutet nur, dass zum Anzeigezeitpunkt eine Registrierung besteht — nicht, dass alle Versuche erfolgreich sind. Ereignisprotokoll gezielt nach dem Trunk-Namen filtern statt sich allein auf die Statusfarbe zu verlassen.
Zweiter Trunk desselben Providers läuft, der andere nicht
Erst prüfen, ob der funktionierende Trunk überhaupt registrierungsbasiert ist — ein „nur ausgehend" konfigurierter Trunk registriert sich gar nicht und ist daher kein gültiger Vergleichsmassstab für einen Registrierungsfehler beim zweiten Trunk.
Fehlercode wechselt zwischen 401 und 408
Ein wechselndes Bild zwischen Auth-Fehler und Timeout deutet eher auf eine instabile Verbindung oder ein Firewall-/SIP-ALG-Problem hin als auf durchgehend falsche Zugangsdaten — ein permanenter Auth-Fehler wäre bei jedem Versuch identisch.
Trunk registriert sich, aber eingehende Anrufe kommen nicht an
Kein Registrierungsproblem mehr, sondern meist eine fehlende oder falsche DID-Zuordnung im Trunk-Tab „DID-Nummern" oder ein nicht zugewiesenes Ziel in der Anrufverwaltung — siehe die SIP-Trunk-Übersicht für den generellen Einrichtungsweg.
Weiterführend
- SIP-Trunk-Übersicht
- Deutsche Telekom CompanyFlex
- sipgate Trunking
- Swisscom Enterprise SIP
- Sicherheit & Firewall-Ports
- Troubleshooting & Logs
- Beratung anfragen
Trunk-Fehler nicht selbst durchsuchen wollen?
Wir übernehmen die Diagnose Ihres SIP-Trunks direkt in der Anlage, klären mit dem Provider und richten bei Bedarf ein Monitoring ein, das Ausfälle aktiv meldet.
Beratung anfragen Hosting ansehen