SIP 481 Call/Transaction Does Not Exist – der Dialog-Killer

Der Call lief, dann kommt mitten im Gespräch ein 481 auf ein UPDATE, re-INVITE oder BYE – und plötzlich hängt der Abbau oder der Session-Refresh scheitert. 481 heißt: Die Gegenseite kann deinen Request keinem existierenden Dialog zuordnen.

Bedeutung

481 Call/Transaction Does Not Exist (RFC 3261 §21.4.19) sagt: Der Request kam an, aber der Empfänger findet dazu keinen passenden Dialog bzw. keine Transaktion. Ein Dialog wird über drei Werte identifiziert: Call-ID, lokales Tag und Remote-Tag. Stimmt einer davon nicht mit dem State der Gegenseite überein, ist der Request „heimatlos" → 481.

Typische Ursachen

Falsche Dialog-Orientierung: Sendet der Angerufene (UAS) einen Mid-Dialog-Request (z. B. den Session-Refresh per UPDATE bei refresher=uas), müssen From/To gegenüber dem ursprünglichen INVITE getauscht sein – das eigene Tag gehört ins From. Manche PBX-Implementierungen vergessen den Tausch, die Tags passen nicht zum Dialog-State der Gegenseite → 481.

Fehlender Route-Header trotz Record-Route: Wurde der Dialog über Record-Route aufgebaut, ist das Route-Set nicht leer, und jeder Mid-Dialog-Request MUSS den daraus gebildeten Route-Header tragen (RFC 3261 §12.2.1.1). Fehlt er, erreicht der Request den record-routenden Proxy/SBC nicht im erwarteten Dialogkontext.

Dialog existiert wirklich nicht mehr: Session-Timer abgelaufen ohne Refresh (RFC 4028), oder eine Seite hat den Call nach Timeout lokal abgeräumt, während die andere ihn für aktiv hält – der nächste Request der „lebenden" Seite läuft ins Leere.

B2BUA-Mapping-Fehler: Ein SBC verwaltet zwei Legs mit unterschiedlichen Call-IDs. Fehler im internen Mapping (z. B. nach Redirect oder Failover) führen dazu, dass ein durchgereichter Request mit Identifiern des falschen Legs ankommt.

Verspätetes CANCEL oder ACK-Probleme: Ein CANCEL nach der finalen Antwort oder ein Request, dessen zugehörige INVITE-Transaktion serverseitig schon beendet ist.

Was im Trace zu prüfen ist

1. From-/To-Tags des fehlgeschlagenen Requests mit dem 200 OK des Dialogaufbaus vergleichen: Stimmen beide Tags, und stehen sie – je nach Senderichtung – auf der richtigen Seite?

2. Record-Route im INVITE/2xx vorhanden? Dann muss der Mid-Dialog-Request einen Route-Header tragen. Fehlt er, ist das oft schon der Befund.

3. Request-URI gegen den Contact aus dem 2xx prüfen (Remote Target).

4. Timing ansehen: Kommt der Request kurz nach Ablauf von Session-Expires? Dann Richtung Timer/Refresh ermitteln.

5. Bei SBC-Ketten: Auf welchem Leg entsteht das 481 – und was ist unmittelbar davor auf dem anderen Leg passiert (Redirect, Re-INVITE, Failover)?

Genau diese Prüfungen macht Cause31 für dich.
pcap laden, Legs werden automatisch über SBC-Grenzen korreliert, und die KI-Diagnose prüft Tags, Route-Set und Timing gegen den Dialogaufbau – mit RFC-Referenz. Kostenlos, Parsing lokal im Browser.
Trace jetzt analysieren →

Lösungsansätze

Bei Tag-/Orientierungsfehlern: Firmware bzw. SIP-Stack der sendenden Seite prüfen – das ist ein Implementierungsfehler, kein Konfig-Thema. Fehlende Route-Header deuten auf fehlerhafte Loose-Routing-Implementierung; als Workaround kann am SBC die Topologie so angepasst werden, dass kein Record-Routing nötig ist. Bei Timer-Problemen Session-Expires/Min-SE beider Seiten harmonisieren und klären, wer Refresher ist.

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