Wenn der Trunk nicht kaputt ist, sondern gekündigt

Datum der Analyse: 7. September 2026 System: 3CX V20 Update 9 (Build 995), PRO Edition, 8 gleichzeitige Gespräche, selbst gehostet Kunde: Ein Beratungsunternehmen mit Kundschaft in der Schweiz Betreuung: Bitblade Solutions UG

Anonymisiertes Fallbeispiel aus dem Alltag — Firmenname, Rufnummern und IP-Adressen wurden entfernt.

Das Symptom

Meldung des Kunden: „Die Anlage ist tot bzw. funktioniert nur teilweise."

Genau diese Formulierung ist der interessante Teil. „Tot" wäre einfach — dann läuft der Dienst nicht, und man startet ihn neu. „Teilweise" heißt: irgendetwas funktioniert, irgendetwas nicht, und niemand weiß, wo die Grenze verläuft.

Der erste Blick auf den Webclient bestätigte das: Die Oberfläche lud, alle 35 Nebenstellen wurden angezeigt — aber praktisch jede mit dem Status „Nicht angemeldet".

Der Diagnoseweg

Schritt 1: Systemübersicht statt Bauchgefühl

Die Admin-Konsole (#/office/dashboard) liefert in 30 Sekunden mehr als eine Stunde Raten:

Direkt darunter das Ereignisprotokoll — und dort stand die Antwort bereits:

Warnung 12294  07.09.2026 12:03  SIP Server
Call or Registration to iway has failed.
sip:10001@sip3.phone.iway.ch replied: 401 Unauthorized;

Dieselbe Zeile, alle fünf Minuten, über 240 Protokollseiten hinweg. Die ältesten erhaltenen Einträge stammten von rund einem Monat zuvor — das ist nicht der Beginn des Fehlers, sondern das Ende der Protokoll-Aufbewahrung.

Schritt 2: Trunk-Status

Unter Trunks & Chat das erwartete Bild:

Damit war „funktioniert nur teilweise" erklärt: Der deutsche Trunk nahm Anrufe an, der Schweizer war tot.

Schritt 3: Die falsche Fährte

Ein 401 Unauthorized sieht nach falschem Passwort aus. Der Reflex: SIP-Zugangsdaten neu eintragen, fertig.

Dieser Reflex hätte eine Stunde gekostet und nichts gelöst.

Schritt 4: Beim Provider nachsehen

Statt in 3CX zu raten, der Blick ins iWay-Kundenportal:

• Aktive Produkte: 0
• Offene Rechnungen: 0 — Offener Betrag: 0,00 CHF
• Unter inaktive Produkte: ein VoIP-Business-Trunk-Flat-Tarif, quartalsweise, rund 150 CHF

Und der Rechnungsverlauf zeigte drei reguläre Abrechnungen aus der Vergangenheit — und an einem späteren Stichtag drei Einträge mit dem Vermerk „Debitorenverlust" für genau dieselben drei Abrechnungen.

Die Ursache

Der Trunk war nicht gestört. Er war gekündigt.

„Debitorenverlust" ist der buchhalterische Begriff für eine Forderungsausbuchung. Der Provider hat die offenen Beträge aus drei Abrechnungsperioden abgeschrieben und das Produkt deaktiviert. Der hinterlegte SIP-Account existiert seitdem nicht mehr — deshalb der 401 Unauthorized, und deshalb hätte kein neu eingetragenes Passwort je funktioniert.

Dass „Offene Rechnungen: 0" im Portal stand, war dabei die tückischste Anzeige des ganzen Falls: Sie sah aus wie „alles bezahlt, alles in Ordnung". Tatsächlich hieß sie „abgeschrieben, Vertrag beendet".

Die Schweizer Rufnummer des Kunden ist damit seit rund anderthalb Jahren tot.

Der eigentliche Schaden

Der tote Trunk war nur die halbe Geschichte. Der Blick in die ausgehenden Regeln zeigte den teureren Teil:

Vorher:

Drei Regeln schickten jeden Anruf in die Schweiz auf den toten Trunk — ohne jede Ersatzroute. Routen 2 bis 5 standen durchgehend auf „Gesperrt".

3CX arbeitet Regeln von oben nach unten ab. Die +41-Regel greift vor der allgemeinen +-Regel. Ergebnis: Jeder Wahlversuch nach +41… oder 0041… lief in den toten Trunk, fand keinen Fallback und brach ab.

Der Kunde konnte über Monate keinen einzigen Schweizer Kunden anrufen. Das Routing hatte den Ausfall des Providers nicht abgefedert, sondern verdoppelt: Erst fiel die eingehende CH-Nummer weg, dann die gesamte ausgehende CH-Erreichbarkeit — und beides fiel niemandem als ein Problem auf, weil im Alltag ja „das Telefon ging".

Nebenbefund: die unbesetzte Warteschleife

Parallel im Protokoll:

Info 105  07.09.2026 11:30  Queue Manager
Lost Call in Queue (800)

Vier verlorene Anrufe allein am Vormittag des Analysetags. Der Grund war unabhängig vom Trunk:

• Unter Telefone war ein einziges Gerät registriert: die 3CX App für Windows an einer einzelnen Nebenstelle
• Eine weitere Nebenstelle hatte ein Tischtelefon hinterlegt — Status rot, nicht registriert
• 33 weitere Nutzer: kein Gerät, keine App

Geprüft, ob etwas sperrt:

• IP-Sperrliste: leer
• Stichprobe an einer Nebenstelle: „Nebenstelle deaktivieren" nicht gesetzt, „Externe Anrufe deaktivieren" nicht gesetzt

Kein technischer Block. Die Anlage nahm Anrufe an, stellte sie in die Warteschleife 800 — und dort war niemand.

Der zweite Boden, der auch fehlte

Die naheliegende Frage: Eine Warteschleife hat doch ein Überlaufziel. Wohin gehen die Anrufe, wenn keiner abnimmt?

Die Konfiguration der Warteschleife:

Zwei Dinge stechen heraus.

Erstens: Der einzige Agent der Warteschleife ist das Admin-Konto — kein Mensch am Telefon. Es war nie angemeldet. Die Warteschleife hatte damit strukturell null Agenten.

Zweitens: Der Überlauf funktionierte — er zeigte nur auf einen toten Anschluss. Genau diese externe Nummer fällt im Ereignisprotokoll den ganzen Tag über durch:

08:22 → 408 Request Timeout
08:26 → 408 Request Timeout
08:32 → 486 Busy Here
08:33 → 408 Request Timeout
10:29 → 408 Request Timeout
10:31 → 408 Request Timeout
13:59 → 408 Request Timeout
15:11 → 486 Busy Here

Damit schließt sich die Kette: Anruf kommt über den deutschen Trunk herein → landet in der Warteschleife → 15 Sekunden klingelt es bei einem Konto, das nie angemeldet ist → Weiterleitung auf eine externe Nummer, die nicht antwortet → der Anrufer hört nichts und legt auf → Lost Call in Queue.

Die Anlage hatte also nicht einen ausgefallenen Sicherungsmechanismus, sondern zwei hintereinander. Und weil beide still versagten, sah von außen alles normal aus: Es klingelte ja.

Und warum die Weiterleitung scheiterte

Naheliegender Verdacht: der Anschluss ist tot wie der iWay-Trunk. Die SIP-Codes sagten etwas anderes.

486 Busy Here bedeutet, dass die Gegenstelle erreicht wurde und besetzt war. Ein nicht vergebener Anschluss liefert 404 Not Found, keine Besetztmeldung. Zweimal am Tag ist der Anruf also bis zum Ziel durchgegangen. 408 Request Timeout heißt, dass Reventix den INVITE angenommen, weitergeleitet und dann vergeblich auf eine endgültige Antwort gewartet hat.

Der Gegentest bestätigte es: Ein Anruf vom Mobiltelefon auf die externe Nummer kam problemlos durch. Der Anschluss lebt, das Weiterleitungsziel ist gewollt und richtig.

Damit blieb ein Verdächtiger übrig — das Wählformat. Hinterlegt war die Nummer im nationalen Format mit vorangestellter 0049, also eine international nach Deutschland gewählte Nummer, abgesetzt von einem deutschen Trunk. Über die Regel „Standard 0" ging das ohne jede Ziffernmanipulation genau so an Reventix hinaus. Manche Provider schlucken das klaglos, manche routen es über eine internationale Strecke — und dort entstehen exakt solche Timeouts.

Korrigiert auf E.164-Format, in allen vier Zielen der Warteschleife (Nichtannahme, außerhalb der Geschäftszeiten, Pausen, Feiertag) und in beiden Zielen der zugehörigen Rufgruppe, die dieselbe Nummer im selben falschen Format trug.

Bemerkenswert daran: Der Fehler war weder beim Provider noch bei der Gegenstelle, sondern in einem Feld, das seit Jahren so dasteht und in 95 % der Fälle wahrscheinlich funktioniert hat.

Die Lösung

Reventix ersetzt iway vollständig. In 3CX gibt es für Trunks keinen Deaktivieren-Schalter (das Kontextmenü kennt nur bearbeiten und löschen), also läuft die Umstellung über das Routing.

Nachher:

Regel 5 wurde zusätzlich von „Outbound rule for iway" umbenannt — ein Regelname, der auf einen nicht mehr existierenden Provider zeigt, ist eine Zeitbombe für den nächsten Techniker.

Zusätzlich wurde in allen fünf Regeln bei Route 1 die ausgehende Rufnummer auf die öffentlich kommunizierte Hauptnummer des Unternehmens gesetzt. Ohne diesen Eintrag hätte jeder ausgehende Anruf die Trunk-Hauptnummer gezeigt — eine Nummer, die kein Kunde kennt.

Wichtig dabei: Diese Hauptnummer liegt nicht im Nummernblock des Reventix-Trunks und ist in 3CX auch nicht als DID hinterlegt. Das ist kein Fehler — die DID-Liste in 3CX steuert ausschließlich die eingehende Zuordnung und ist keine Whitelist für ausgehende Rufnummern. Ob eine fremde CLI durchgeht, entscheidet allein der Provider: Sie muss beim Trunk-Anbieter als zulässige Absendernummer freigegeben sein (CLIP no screening). Ist sie das nicht, weist der Provider den Anruf ab oder überschreibt die Nummer stillschweigend. Die Freigabe war hier laut Kunde vorhanden.

Keine Ziffernmanipulation war nötig: Beide betroffenen Regeln standen auf „Keine Ziffern entfernen" ohne Voranstellung. +41… geht als E.164 an Reventix, 0041… als international gewählte Nummer — beides akzeptiert der deutsche Trunk.

Nach dem Speichern und einem Reload verifiziert: keine Regel verweist mehr auf iway.

Offene Punkte

Sofort:

• Der iway-Trunk existiert weiterhin und versucht sich alle 5 Minuten erfolglos zu registrieren. Er routet nichts mehr, produziert aber weiter Protokollrauschen. Löschen beendet das — die Konfiguration ist dokumentiert und wiederherstellbar.
• Ausgehende Anrufe in die Schweiz zeigen jetzt eine deutsche Rufnummer als Anrufer-ID. Für ein Unternehmen mit Schweizer Kundschaft ist das eine Geschäftsentscheidung, keine technische.
• Testanruf ausstehend: Die neue ausgehende Rufnummer wurde in allen fünf Regeln gesetzt, aber noch nicht im Livebetrieb geprüft. Ein Anruf auf ein Mobiltelefon zeigt in Sekunden, ob Reventix die CLI durchreicht, überschreibt oder den Anruf ablehnt. Zwei der fünf Regeln (+41 und 0041) wurden nach dem Speichern visuell rückgeprüft; die übrigen drei (+, Standard 0, CH Ausland) sollten bei Gelegenheit noch einmal geöffnet werden, da die Admin-Konsole während der Arbeit mehrfach hängen blieb.

Mit dem Provider zu klären:

• Ist die alte Schweizer Rufnummer noch zugeordnet oder bereits freigegeben? Nach anderthalb Jahren ist Letzteres wahrscheinlich.
• Reaktivierung oder Neubestellung möglich? Nach einem Debitorenverlust ist mit Vorauskasse oder Bonitätsprüfung zu rechnen.
• Falls die Nummer verloren ist: neue CH-Nummer bei einem Schweizer VoIP-Anbieter. Eine Portierung ist bei ausgebuchtem Vertrag praktisch ausgeschlossen.

Unabhängig davon:

• 34 von 35 Nutzern haben kein Endgerät. Das kostet aktuell mehr Anrufe als die tote CH-Nummer je gekostet hat.
• Die Warteschleife hat als einzigen Agenten das Admin-Konto. Echte Berater müssen als Agenten eingetragen und angemeldet sein, sonst ändert sich nichts.
• Das Überlaufziel wurde auf E.164 korrigiert. Ob damit die 408er verschwinden, zeigt erst der Livebetrieb — ein Testanruf in die Warteschleife, den niemand annimmt, ist die schnellste Probe.
• 15 Sekunden maximale Wartezeit in der Schleife ist sehr kurz. Selbst mit angemeldeten Agenten bleibt kaum Zeit, den Hörer abzunehmen.
• Remote-Speicher ist nicht konfiguriert — Backups liegen auf derselben Maschine.
• Die Lizenz läuft in Kürze ab.
• Der Reventix-Trunk flappt gelegentlich (kurze De- und Neuregistrierung, vereinzelte Timeouts bei ausgehenden Anrufen). Beobachten.

Was man daraus mitnimmt

Ein 401 ist nicht immer ein Passwortproblem. SIP kennt keinen Statuscode für „Ihr Vertrag wurde gekündigt". Der Provider antwortet mit demselben 401 Unauthorized wie bei einem Tippfehler. Die Fehlermeldung beschreibt das Symptom, nicht die Ursache — und wer nur in der Telefonanlage sucht, findet die Ursache nie.

Prüfe die Vertragsebene, bevor du die Technik anfasst. Der entscheidende Befund lag nicht in 3CX, sondern in einem Rechnungsverlauf. Fünf Minuten im Kundenportal des Providers ersparen Stunden im SIP-Trace.

„Offene Rechnungen: 0" heißt nicht „alles bezahlt". Es kann auch „ausgebucht" heißen. Ein Portal, das saubere Zahlen zeigt, kann trotzdem einen beendeten Vertrag beschreiben.

Routing ohne Fallback ist ein Single Point of Failure mit Ansage. Routen 2 bis 5 standen auf „Gesperrt". Wäre auch nur der bestehende Reventix-Trunk als Ersatzroute eingetragen gewesen, hätte der Providerausfall die ausgehende Erreichbarkeit nie berührt — der Ausfall wäre unsichtbar geblieben, statt monatelang unbemerkt zu bleiben.

Ein stiller Ausfall ist teurer als ein lauter. Hätte die Anlage komplett nicht funktioniert, wäre sie am selben Tag repariert worden. Weil „das Telefon ja ging", lief ein halbes Ausfallszenario monatelang mit — inklusive verlorener Anrufe in einer unbesetzten Warteschleife.

Benenne Regeln nach ihrer Funktion, nicht nach dem aktuellen Provider. „Outbound rule for iway" war seit der Kündigung eine Lüge im Konfigurationsbaum.

Ereignisprotokolle haben ein Verfallsdatum. 240 Seiten klingen nach viel; sie reichten hier 30 Tage zurück. Wer den Beginn eines Fehlers rekonstruieren will, braucht externes Monitoring — nicht das Log der Anlage, die selbst betroffen ist.

---

Alle Angaben aus einem konkreten Kundenprojekt. Firmenname, Rufnummern, IP-Adressen und Rechnungsbeträge anonymisiert. Stand: September 2026.