[English] - [Français] - [Deutsch]
Unverarbeitete ACK Anzeigen und nochmalige Übertragung von 487
Antworten durch Verizon
Emin Gabrielyan
Übersetzt durch Sebastien Keller
Switzernet
2007-05-24
Wir denken, daß wir die mögliche Quelle des Problems auf der Verizon Seite lokalisiert haben. Wir beobachteten, daß Verizon OpenSER v1.2.0 auf Solaris verwendet. Wir verursachten einen Prüfaufbau, in dem wir den realen Verizon Server mit einem Pseudo-Verizon SIP Server ersetzten. Auf diesem Pseudo-Verizon SIP Server reproduzierten wir genau das gleiche fehlerhafte Verhalten. Hier erklären wir die Störung und zeigen, wie man sie regelt.
Simulation
des Problems an der Verizon Seite
Erinnern an des Problems
Das folgende Diagramm erinnert an das Problem. In diesem Diagramm empfängt unser SIP Server mit zwei Schnittstellen (212.249.15.4 und 195.129.125.74) INVITE von 128.179.67.76 und leitet es an Verizon bei 212.190.89.137 weiter. Wenn der Anruf annulliert wird, schickt Verizon uns die 487 Antwort und wir schicken die ACK Anzeige zurück. Jedoch schließt Verizon nicht die Verhandlung und fährt fort, uns viele 487 Statusanzeigen zu schicken.
[png]
Sie können das Diagramm dieser Verhandlung betrachten auf das vorhergehende Hop (128.179.67.76) [png]
Wie es aussehen muß
Die normalerweise annullierte Anrufverhandlung muß schauen, wie im Diagramm unten gezeigt. In diesem Beispiel stellt der SIP Server 192.168.1.15 unseren SIP Server dar; der SIP Server 192.168.1.16 stellt Verizon dar. Im gezeigten Diagramm schickt das sogenannte Verizon uns Antwort 487 nach der Aufnahme unseres ACK nicht.
192.168.1.10 ist eine SIP telefon.
[png]
Für das gezeigte Diagramm stellen wir die Konfiguration Datei des sogenannten Server SIP des Verizons zur Verfügung [cfg] (in diesem Beispiel, das bei 192.168.1.16 läuft).
Simulation des Problems an der Verizon Seite
Wir könnten das gegenwärtige Problem auf dem 192.168.1.16 SIP Server simulieren, der in diesem Prüfaufbau Verizon darstellt. Im Diagramm unten sehen wir, das problematiche Verhalten von 192.168.1.16. Ähnlich zum real-life Fall, es versteht den ACK unseres Server (dargestellt durch 192.168.1.15) nicht. Es hält, die Antwort 487 die ganze Zeit zu übertragen.
[png]
Sie können das Diagramm dieser Verhandlung betrachten auf 192.168.1.16 (das sogenannte Verizon Server) [png]. Für das gezeigte Diagramm stellen wir die Konfiguration Datei des sogenannten Server SIP des Verizons zur Verfügung [cfg]. Wir vermuten, daß Verizon z.Z. eine Konfiguration Datei mit einer ähnlichen Fehler benutzt.
Erklärung der Störung
Entsprechend RFC 3261, verarbeiten stateful proxies das ACK Austäusche Hop-by-Hop. So ist der ACK Antrag nicht ein Thema der nochmaliger Übertragung. Aus diesem Grund kann man denken, daß die t_relay() Funktion nicht für solche ACK Anzeigen hervorgerufen werden darf. Jedoch müssen Sie betrachten, daß t_relay() Funktion des OpenSER Verhandlungmoduls genug intelligent ist, solche ACK Anzeigen nicht nochmal zu übertragen. Außerdem ist die t_relay() Funktion, nicht für nochmalige Übertragung sehr viel erforderlich (während sein Name vorschlagen kann), aber für, das Modul erklärend, daß die Verhandlung geschlossen ist und daß das Getriebe von 487 Anzeigen nicht mehr benötigt wird.
Als Zusammenfassung: die t_relay() Funktion muß für beide Arten ACK Anzeigen werden, für die einige, die im loose_route() Abschnitt verarbeitet sind (entsprechend beantworteten Anrufen) und für die einige, die nicht im loose_route() Abschnitt verarbeitet sind (entsprechend annullierten Anrufen).
Merken Sie, daß alle next-hop SIP Server (wenn es eine gibt und wenn er das gleiche Problem hat), auch repariert werden müssen, weil die ersten ein-oder-zwei 487 Anzeigen werden durch einen ACK geantwortet, aber alle folgenden 487 Anzeigen werden zurück fortgepflanzt.
* * *