SIP-Ablaufdiagramm lesen

Wozu dient das

Das SIP-Ablaufdiagramm zeigt die Signalisierung eines Anrufs als Folge von Pfeilen zwischen den beteiligten Gegenstellen. Sie finden es in der Anrufdiagnose im Reiter Anrufablauf und in der Anrufanalyse im Reiter Call Flow. Beide verwenden dasselbe Diagramm. Für Teams-Anrufe über den integrierten SBC gibt es ein eigenes Leiterdiagramm mit zwei Spuren, das Sie auf dieselbe Weise lesen.

Dieses Kapitel erklärt den Aufbau des Diagramms und zeigt an sechs typischen Abläufen, welche Nachrichten Sie in welcher Reihenfolge sehen. Mit diesen Mustern erkennen Sie in einem unbekannten Ablauf schnell, an welcher Stelle er vom Normalfall abweicht.

SIP arbeitet mit Anfragen und Antworten. Eine Anfrage trägt eine Methode wie INVITE oder BYE. Jede Antwort trägt einen dreistelligen Code: 1xx ist vorläufig, 2xx Erfolg, 3xx Umleitung, 4xx bis 6xx Fehler. Ein Anruf besteht aus mindestens einem Dialog, erkennbar an der gemeinsamen Call-ID. Der CUCM steht zwischen den Teilnehmern und führt mit jeder Seite einen eigenen Dialog. Ein Anruf von Telefon zu Telefon zeigt deshalb zwei Dialoge.

Voraussetzungen

• Eine abgeschlossene Anrufdiagnose oder ein Anruf mit Call Flow aus der Anrufanalyse. Rolle ROLE_APP_CALL_DIAGNOSTICS.
• Am CUCM ist für Cisco CallManager die Trace-Stufe Detailed mit Enable SIP Call Processing Trace eingestellt. Sonst enthalten die Traces keine SIP-Nachrichten.
• Das Diagramm zeigt nur SIP. Telefone mit SCCP, analoge Anschlüsse und Gateways mit MGCP oder H.323 erscheinen nicht als eigene Spur.
• Für Nachrichten des CUBE: eingeschaltete Debug-Aufzeichnung am CUBE und Leserecht auf die CUBEs.

Schritt für Schritt: So gehen Sie vor

1. Lesen Sie zuerst die Kopfzeile der Spuren. Bestimmen Sie, welche Spur der Anrufer ist, welche der CUCM-Knoten und welche das Ziel oder der Trunk.
2. Suchen Sie das erste INVITE. Es steht oben und geht vom Anrufer zum CUCM.
3. Folgen Sie dem Dialog des Anrufers nach unten bis zur letzten Antwort auf dieses INVITE. Ihre Farbe sagt, wie der Anruf ausging: grün angenommen, rot fehlgeschlagen.
4. Suchen Sie das INVITE, das der CUCM zum Ziel schickt. Vergleichen Sie, ob der Fehler vom Ziel kommt oder vom CUCM selbst erzeugt wurde.
5. Blenden Sie mit 100 Trying ausblenden und NOTIFY, INFO und OPTIONS ausblenden Nebensächliches aus.
6. Schalten Sie über die Dialog-Schaltflächen einzelne Dialoge aus, bis nur die Strecke sichtbar ist, die Sie untersuchen.
7. Klicken Sie auf die entscheidende Nachricht und lesen Sie Kopfzeilen und SDP in der Nachrichtenansicht.
8. Achten Sie auf die Abstände in der Zeitspalte. Eine lange Pause vor einer Antwort zeigt, wo gewartet wurde.
9. Vergleichen Sie den Ablauf mit den Mustern in den folgenden Abschnitten.

Felder und Optionen: Aufbau des Diagramms

Ablauf: erfolgreicher Anruf

1. INVITE mit SDP vom Anrufer zum CUCM. Der Anrufer bietet seine Codecs an.
2. 100 Trying zurück zum Anrufer. Der CUCM hat die Anfrage angenommen.
3. INVITE vom CUCM zum Ziel. Das ist ein neuer Dialog mit anderer Farbe.
4. 180 Ringing vom Ziel zum CUCM und vom CUCM weiter zum Anrufer. Das Ziel klingelt.
5. 200 OK mit SDP vom Ziel. Der Angerufene hat abgehoben und nennt seinen Codec.
6. ACK in beiden Dialogen. Der Verbindungsaufbau ist bestätigt, die Sprache fließt.
7. BYE von der Seite, die auflegt, und 200 OK als Bestätigung. In der Anrufanalyse lautet das Ergebnis Angenommen.

Ablauf: besetzt

1. INVITE vom Anrufer zum CUCM, 100 Trying zurück.
2. INVITE vom CUCM zum Ziel.
3. 486 Busy Here vom Ziel, rot. Seltener 600 Busy Everywhere.
4. ACK vom CUCM zum Ziel. Jede endgültige Antwort auf ein INVITE wird mit ACK quittiert.
5. 486 Busy Here vom CUCM zum Anrufer und dessen ACK. Ergebnis Besetzt, Q.850-Ursache 17.
6. Kommt das 486 nur im Dialog zum Anrufer vor und gibt es kein INVITE zum Ziel, hat der CUCM selbst entschieden, zum Beispiel weil der Busy Trigger der Leitung erreicht ist.

Ablauf: nicht erreichbar oder nicht angenommen

1. INVITE vom Anrufer zum CUCM, 100 Trying zurück.
2. Nummer unbekannt: 404 Not Found direkt vom CUCM, ohne INVITE zu einem Ziel. Ebenso 410 Gone, 484 Address Incomplete, 485 Ambiguous oder 604 Does Not Exist Anywhere. Ergebnis Nicht erreichbar.
3. Ziel nicht registriert oder vorübergehend nicht verfügbar: 480 Temporarily Unavailable. Ergebnis Nicht angenommen.
4. Ziel antwortet nicht: Nach 180 Ringing folgt lange nichts, dann 408 Request Timeout oder 480. Die Zeitspalte zeigt die Wartezeit.
5. Trunk oder Gateway gestört: 503 Service Unavailable oder 502 Bad Gateway von der Spur des Trunks. Ergebnis Fehlgeschlagen.
6. Codecs passen nicht: 488 Not Acceptable Here. Vergleichen Sie die SDP im INVITE mit den Codecs, die das Ziel unterstützt.
7. Ziel weist ab: 403 Forbidden oder 603 Decline. Ergebnis Abgewiesen.

Ablauf: Abbruch durch den Anrufer

1. INVITE vom Anrufer, 100 Trying, INVITE zum Ziel, 180 Ringing.
2. CANCEL vom Anrufer zum CUCM. Der Anrufer legt auf, bevor jemand abhebt.
3. 200 OK auf das CANCEL.
4. CANCEL vom CUCM zum Ziel und dessen 200 OK.
5. 487 Request Terminated als Antwort auf das ursprüngliche INVITE, in beiden Dialogen, jeweils mit ACK.
6. Das 487 ist rot, obwohl kein Fehler vorliegt. Entscheidend ist das CANCEL davor. Ergebnis Vom Anrufer abgebrochen.

Ablauf: Umleitung

1. INVITE vom Anrufer zum CUCM.
2. Bei einer Rufumleitung im CUCM geht das INVITE nicht an das gewählte Ziel, sondern an das Umleitungsziel. Es trägt einen Header Diversion mit der ursprünglich gewählten Nummer und dem Grund.
3. Bei einer Umleitung bei Nichtmelden sehen Sie zuerst INVITE und 180 Ringing zum ersten Ziel, dann CANCEL an dieses Ziel und ein neues INVITE mit Diversion an das zweite.
4. Leitet eine Gegenstelle selbst um, antwortet sie mit 302 Moved Temporarily, orange. Der Header Contact nennt das neue Ziel. Darauf folgt ein neues INVITE dorthin.
5. Der weitere Verlauf entspricht dem erfolgreichen Anruf. In der Anrufanalyse trägt der Anruf das Merkmal Weiterleitung, und der Reiter Überblick zeigt die Umleitungskette.
6. Klicken Sie auf das INVITE zum Umleitungsziel und lesen Sie den Header Diversion, um Herkunft und Grund zu sehen.

Ablauf: Transfer

1. Der erste Anruf besteht wie im erfolgreichen Ablauf.
2. Der Vermittelnde hält das Gespräch: ein weiteres INVITE im bestehenden Dialog (Re-INVITE) mit SDP, beantwortet mit 200 OK und ACK.
3. Er baut ein Rückfragegespräch zum Transferziel auf: ein neuer Dialog mit INVITE, 180 Ringing, 200 OK, ACK.
4. REFER vom Vermittelnden zum CUCM. Der Header Refer-To nennt das Transferziel, bei einem Transfer mit Rückfrage zusammen mit Replaces.
5. 202 Accepted auf das REFER, danach NOTIFY mit dem Fortschritt.
6. Der CUCM verbindet Anrufer und Transferziel mit Re-INVITE oder UPDATE und neuer SDP in beiden Dialogen.
7. BYE zum Vermittelnden. Die beiden übrigen Dialoge laufen weiter. In der Anrufanalyse trägt der Anruf das Merkmal Transfer.

Ergebnis prüfen und Fehler eingrenzen

• Sie haben den Ablauf verstanden, wenn Sie in einem Satz sagen können, wer den Anruf beendet hat und mit welcher Nachricht.
• 401 Unauthorized oder 407 Proxy Authentication Required direkt nach dem ersten INVITE, gefolgt von ACK und einem zweiten INVITE mit derselben Call-ID, ist die normale Anmeldung des Geräts und kein Fehler.
• Das Diagramm beginnt nicht mit INVITE: Die Traces am CUCM begannen erst nach dem Anrufbeginn. Der Hinweis über dem Diagramm nennt das.
• Das Diagramm endet ohne BYE: Der Anruf lief noch, als die Traces gelesen wurden, oder die Grenze von 800 Nachrichten wurde erreicht.
• Eine Strecke fehlt ganz: Das Gerät spricht kein SIP, ein Knoten konnte nicht gelesen werden, oder der Anruf lief über einen Knoten außerhalb der Grenze von 8 Knoten. Prüfen Sie die Tabelle der Knoten.
• Beide Teilnehmer liegen auf derselben Spur: Sie teilen sich eine IP-Adresse. Unterscheiden Sie sie über die Dialog-Schaltflächen.
• 200 OK und ACK sind vorhanden, aber es gab keinen Ton: Die Signalisierung ist in Ordnung. Vergleichen Sie in der SDP beider Seiten Adresse, Port und Codec und prüfen Sie den Medienweg im Netz.
• Zugangsdaten und SRTP-Schlüssel sind in der Nachrichtenansicht entfernt. Sehr lange Nachrichten sind auf 8 KB gekürzt.