SIP 486 Busy Here – wenn „besetzt" gar nicht besetzt ist

Der Kunde schwört: „Da war niemand am Telefon, und trotzdem besetzt!" – und hat oft recht. 486 heißt zwar offiziell besetzt, wird in der Praxis aber von erstaunlich vielen Zuständen erzeugt, die mit einem laufenden Gespräch nichts zu tun haben.

Bedeutung

486 Busy Here (RFC 3261 §21.4.24) sagt: Das kontaktierte Endgerät wurde erreicht, ist aber nicht bereit, den Call an dieser Adresse anzunehmen. Das globale Gegenstück ist 600 Busy Everywhere. Auf ISUP/Q.850-Ebene entspricht 486 dem cause 17 (User busy) – so wird es an TDM-Übergängen gemappt.

Typische Ursachen – neben echtem Besetzt

Do Not Disturb (DND): Viele Endgeräte und PBX-Systeme signalisieren aktivierte Ruhefunktion schlicht als 486. Der Nutzer merkt oft gar nicht, dass DND aktiv ist – der Klassiker beim „Phantom-Besetzt".

Alle Leitungen/Kanäle belegt: Bei Trunks mit Kanalbegrenzung oder Endgeräten mit begrenzten Line-Keys wird der überzählige Call mit 486 abgewiesen – aus Anrufersicht nicht von echtem Besetzt unterscheidbar.

Volle Kanäle auf der Vermittlungsstelle: Auch im Netz selbst kann 486 entstehen – wenn auf der Vermittlungsstelle bzw. dem Zugangs-Gateway zum Zielteilnehmer alle Kanäle oder Sprechwege belegt sind, signalisiert das Netz Richtung Anrufer Besetzt, obwohl weder Anlage noch Endgerät des Angerufenen beteiligt waren. Erkennbar daran, dass das 486 von einem Netzknoten kommt und der INVITE die Zielseite nie erreicht hat; je nach Mapping steht im Reason-Header statt cause 17 auch cause 34 („no circuit/channel available").

Fehlgeschlagene Rufweiterleitung bei Besetzt (CFB): Eigentlich sollte bei Besetzt zur Voicemail oder aufs Handy umgeleitet werden. Greift die Weiterleitung nicht (Konfig, Lizenz, Loop-Schutz), schlägt das nackte 486 bis zum Anrufer durch.

Anrufschutz-/Filterfunktionen: Sperrlisten, anonyme-Anrufer-Ablehnung (ACR) oder Zeitprofile antworten je nach Implementierung mit 486 statt mit 433/603 – der Anrufer hört besetzt, obwohl gefiltert wurde.

Race bei parallelem Ruf (Forking): Bei parallelem Klingeln mehrerer Geräte kann ein Gerät 486 senden (z. B. weil dort DND aktiv ist), während andere klingeln – je nach Proxy-Logik gewinnt manchmal fälschlich das 486.

Was im Trace zu prüfen ist

1. Wer sendet das 486 – Endgerät, PBX/SBC oder das Netz? Kommt es von einem Netzknoten, ohne dass ein INVITE die Zielseite erreicht hat, liegt die Ursache in der Vermittlung (volle Kanäle, Netz-Policy) – nicht beim Angerufenen.
2. Timing: Ein 486 sofort nach dem INVITE (<100 ms) ist praktisch nie ein Mensch im Gespräch – das ist eine automatische Ablehnung.
3. Reason-Header ansehen: Q.850;cause=17 ist Standard; abweichende Causes oder zusätzliche Header verraten Herkunft und echten Grund.
4. Bei Forking: Alle Antworten auf das INVITE sammeln – gab es parallel 180 Ringing von anderen Zweigen, bevor das 486 „gewonnen" hat?
5. Erwartete Weiterleitung prüfen: Hätte auf das 486 hin ein neuer INVITE Richtung Voicemail/CFB-Ziel folgen müssen? Fehlt er, liegt das Problem in der Weiterleitungslogik.
„Da war aber niemand dran" – beweisen statt glauben.
Cause31 zeigt dir im Ladder-Diagramm, wer das 486 wann gesendet hat, und die KI-Diagnose ordnet ein, ob es echtes Besetzt, DND oder eine gescheiterte Weiterleitung war. Kostenlos, Parsing lokal im Browser.
Trace jetzt analysieren →

Lösungsansätze

DND-Status am Endgerät und in der Anlage prüfen (beides!). CFB-Ziele und Lizenzen kontrollieren, Loop-Schutz-Zähler ansehen. Bei Kanal-Limits die Trunk-Dimensionierung gegen das reale Aufkommen halten. Und gegenüber dem Kunden: Der Trace mit Timestamp ist das Ende der Diskussion „bei uns war frei".

Verwandte Themen: SIP 488 · SIP 481 · SIP 503 · Q.850 Cause Codes · alle Artikel