SIP 503 Service Unavailable – wer streikt hier eigentlich?

503 ist die vagste unter den häufigen SIP-Fehlermeldungen: „Dienst gerade nicht verfügbar." Die eigentliche Debugging-Frage ist fast nie was, sondern wer – welcher Knoten in der Kette lehnt ab, und ist es Überlast, Wartung oder Fehlkonfiguration?

Bedeutung

503 Service Unavailable (RFC 3261 §21.5.4) signalisiert eine temporäre Unfähigkeit, den Request zu bearbeiten – durch Überlast oder Wartung. Wichtig: Ein Proxy, der ein 503 empfängt, sollte es nicht blind weiterleiten, sondern alternative Ziele versuchen oder als 500 weitergeben. Ein Retry-After-Header nennt, wann ein neuer Versuch sinnvoll ist.

Typische Ursachen

Echte Überlast / CAC-Limit: Der SBC oder das Softswitch hat sein Call-Admission-Control-Limit erreicht – maximale gleichzeitige Calls oder Calls-per-Second überschritten. Typisch bei Lastspitzen oder falsch dimensionierten Limits nach Migrationen.

Wartung / Graceful Shutdown: Ein Knoten wird kontrolliert aus dem Verkehr genommen und antwortet mit 503, oft mit Retry-After, damit Peers auf redundante Systeme schwenken.

Backend nicht erreichbar: Der antwortende Proxy selbst ist gesund, aber sein Ziel (Registrar, Media-Server, nächster Hop) ist ausgefallen – er übersetzt den internen Fehler in ein 503 Richtung Anrufer.

Fehlerhafte Trunk-/Routing-Konfiguration: Kein passendes Routing-Ziel für die gewählte Rufnummer, deaktivierter Trunk, oder ein Peer im „blacklisted"-Zustand nach fehlgeschlagenen OPTIONS-Pings.

DNS-/Failover-Themen: SRV-Failover greift nicht wie erwartet, und Requests laufen weiter auf den toten Knoten, der (wenn überhaupt) mit 503 antwortet.

Was im Trace zu prüfen ist

1. Wer sendet das 503? Quell-IP der Antwort ansehen und mit der Topologie abgleichen – Endgerät, eigener SBC oder Carrier? Das entscheidet, auf wessen Seite gesucht wird.

2. Retry-After vorhanden? Deutet auf kontrollierte Wartung/Überlast statt Konfigurationsfehler.

3. Reason-Header und Warning auswerten – mancher Carrier liefert dort den Q.850-Cause (z. B. cause 34 „no circuit available" oder 42 „switching equipment congestion") mit.

4. Muster prüfen: Betrifft es alle Calls oder nur bestimmte Ziele/Zeiten? Ein 503 nur zur vollen Stunde riecht nach CPS-Limit, eines nur zu einem Ziel nach Routing.

5. OPTIONS-Verkehr im selben Capture ansehen: Antwortet der Peer auf Keepalives? Ein Peer, der OPTIONS beantwortet, aber INVITEs mit 503 quittiert, hat ein Kapazitäts- oder Policy-Thema, kein Erreichbarkeitsproblem.

Cause31 zeigt dir sofort, welcher Hop das 503 sendet.
pcap laden, End-to-End-Ladder über alle SBC-Hops ansehen, KI-Diagnose mit Ursachen-Hypothese. Kostenlos, ohne Account, Parsing lokal im Browser.
Trace jetzt analysieren →

Lösungsansätze

Bei Überlast: CAC-Limits und Lizenzgrenzen prüfen, ggf. Lastverteilung anpassen. Bei Wartungs-503: Failover-Routing testen – genau dafür ist es da. Bei Routing-Ursachen: Trunk-Status, Dial-Pläne und Peer-Blacklisting kontrollieren. Und wenn der Carrier das 503 sendet: Mit dem Trace als Beleg eskalieren – der Zeitstempel plus Quell-IP der Antwort macht die Zuständigkeit unbestreitbar.

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