2
Problem durch Konvertierung von TCP zu UDP
Hallo Administratoren,
ich habe folgenden Aufbau, damit man das Problem dann auch versteht:
Softgate <--TCP--> SBC (Session Border Controller) <--UDP--> SIP-Proxy
Problem: Es kommt eine Verbindung rein technisch zu stande. Der SBC registriert sich beim SIP-Provider und die Kommunikation soweit läuft. Es sind eingehende Anrufe möglich. Bei ausgehenden Anrufen wird das Paket leider rund 1620 Bytes groß, das ist bei einer MTU von 1500 schon ungünstig, weil nun das Paket in 2 Frames 1500 und 120 geteilt wird. Und dieses Teilen führt zum Problem. Da das zweite Paket den SIP-Proxy nie erreicht, sei es aus Sicherheitsgründen oder ähnlichem. Dadurch kommt halt nur ein Teil der Invite-Meldung beim SIP-Proxy an und es ist kein Verbindungsaufbau möglich.
Das Invite-Paket welches vom Softgate zum SBC gelangt ist nur 1000-1100 Bytes groß also noch vollkommen in Ordnung.
Man kann zwischen Softgate und SBC das Protokoll nicht auf UDP ändern, ich versuche aktuell mit dem SIP-Provider zu klären, ob eine Änderung von UCP zu TCP bei denen möglich ist. (Technisch ist es möglich, das ist mir bewusst.)
Ich hole noch etwas aus.
Anfangs war das Softgate direkt per UDP an dem SIP-Provider, das problemlos funktionierte. Ich habe über tethereal (ja leider kein tshark vorhanden, aber macht ja auch keinen großen Unterschied) auf dem Softgate das Paket mit geschnitten als noch kein SBC dazwischen hing. Die Invite-Pakete waren zwischen 1000 und 1100 Bytes groß und hatten die Kennzeichnung "Don't Fragment", dadurch waren ein und ausgehende Gespräche problemlos möglich.
Eingehende Gespräche sind sowohl ohne als auch mit SBC vollkommen problemlos möglich. Die Invite-Pakete sind um die 1000 Bytes groß.
So meine Fragen dazu sind folgende:
1. Die Konvertierung von einem TCP- zu UDP-Paket ändert die Größe, das ist mir bewusst. Jedoch würde ich gerne wissen, ob man verallgemeinert sagen kann, dass diese Konvertierung von TCP zu UDP, das Paket um 10% größer werden lässt?
2. Wenn es nicht generell so gesagt werden kann, würde mich interessieren, welche Faktoren dazu reinspielen? (Denkanstöße genügen)
3. Die Konvertierung von UDP- zu TCP-Pakete würde die Paketgröße dann verkleinern?
Die Fragen kann man mit einem gewissen Netzwerkwissen sicherlich sich selber auch schon beantworten, aber ich möchte mich hier Meinungen und Erfahrungen aus der Praxis von euch holen. Da die Theorie und Praxis nicht immer übereinstimmt. ;)
Vielen Dank schon mal, LiN
Ich wünsche allen ein schönes Wochenende.
ich habe folgenden Aufbau, damit man das Problem dann auch versteht:
Softgate <--TCP--> SBC (Session Border Controller) <--UDP--> SIP-Proxy
Problem: Es kommt eine Verbindung rein technisch zu stande. Der SBC registriert sich beim SIP-Provider und die Kommunikation soweit läuft. Es sind eingehende Anrufe möglich. Bei ausgehenden Anrufen wird das Paket leider rund 1620 Bytes groß, das ist bei einer MTU von 1500 schon ungünstig, weil nun das Paket in 2 Frames 1500 und 120 geteilt wird. Und dieses Teilen führt zum Problem. Da das zweite Paket den SIP-Proxy nie erreicht, sei es aus Sicherheitsgründen oder ähnlichem. Dadurch kommt halt nur ein Teil der Invite-Meldung beim SIP-Proxy an und es ist kein Verbindungsaufbau möglich.
Das Invite-Paket welches vom Softgate zum SBC gelangt ist nur 1000-1100 Bytes groß also noch vollkommen in Ordnung.
Man kann zwischen Softgate und SBC das Protokoll nicht auf UDP ändern, ich versuche aktuell mit dem SIP-Provider zu klären, ob eine Änderung von UCP zu TCP bei denen möglich ist. (Technisch ist es möglich, das ist mir bewusst.)
Ich hole noch etwas aus.
Anfangs war das Softgate direkt per UDP an dem SIP-Provider, das problemlos funktionierte. Ich habe über tethereal (ja leider kein tshark vorhanden, aber macht ja auch keinen großen Unterschied) auf dem Softgate das Paket mit geschnitten als noch kein SBC dazwischen hing. Die Invite-Pakete waren zwischen 1000 und 1100 Bytes groß und hatten die Kennzeichnung "Don't Fragment", dadurch waren ein und ausgehende Gespräche problemlos möglich.
Eingehende Gespräche sind sowohl ohne als auch mit SBC vollkommen problemlos möglich. Die Invite-Pakete sind um die 1000 Bytes groß.
So meine Fragen dazu sind folgende:
1. Die Konvertierung von einem TCP- zu UDP-Paket ändert die Größe, das ist mir bewusst. Jedoch würde ich gerne wissen, ob man verallgemeinert sagen kann, dass diese Konvertierung von TCP zu UDP, das Paket um 10% größer werden lässt?
2. Wenn es nicht generell so gesagt werden kann, würde mich interessieren, welche Faktoren dazu reinspielen? (Denkanstöße genügen)
3. Die Konvertierung von UDP- zu TCP-Pakete würde die Paketgröße dann verkleinern?
Die Fragen kann man mit einem gewissen Netzwerkwissen sicherlich sich selber auch schon beantworten, aber ich möchte mich hier Meinungen und Erfahrungen aus der Praxis von euch holen. Da die Theorie und Praxis nicht immer übereinstimmt. ;)
Vielen Dank schon mal, LiN
Ich wünsche allen ein schönes Wochenende.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 249119
Url: https://administrator.de/contentid/249119
Ausgedruckt am: 26.11.2024 um 10:11 Uhr
2 Kommentare
Neuester Kommentar
Bei ausgehenden Anrufen wird das Paket leider rund 1620 Bytes groß
Eigentlich technisch absolut unmöglich, denn damit verstößt das Endgerät klar gegen elementare Ethernet Standards ! Das kann ja dann nur ein Firmware Bug sein !Oder meintest du das jetzt so das dort Pakete mit maximale Größe erzeugt werden die dann durch die externe Encapsulation wie PPPoE den MTU Wert übersteigen ?
Letzteres kann man sehr einfach verhindern indem man den den mtu bzw. mss Wert auf dem LAN entsprechend anpasst um das zu verhindern.
Abgesehen davon trägt SIP nur minimalste Daten, sprich nur die Wähldaten zum Verbindungsaufbau. Es ist also höchst zweifelhaft das popelige SIP Pakete wirklich solche MTU Werte haben. Snifferst du das mal mit dem Wireshark mit sieht man das auch.
Aber auch wenn das Endgerät fragmentiert warum bitte sollte das 120 Byte Paket den Empfänger denn nicht erreichen ?? Es ist doch immer ein und dieselbe Session. Wenn das erste durchgeht muss auch das zweite durchgehen. Alles andere würde unlogisch sein ?!
Sicherheitsgünde greifen hier niemals. Eher das Systeme ein Dont Fragment Bit setzen was das Fragmentieren generell verbietet. Dann kommt eine Verbindung aber gar nicht erst zustande !
Hast du mal einen Wireshark genommen und dir das mal in der Realität angesehen ?? Das sollte doch alle Spekulationen deinerseits sicher klären !
Was die Größe der Pakte anbetrifft ist die Rechnug nicht schwer.
TCP: Max ist 1500 Byte möglich. 20 Byte Headerdaten braucht IP und 20 Byte TCP bleibt 1460 Byte für Nutzdaten
UDP: UDP Header ist 8 Bytes lang. 4 Felder je 2 Bytes: 1) Source Port, 2) Destination Port, 3) Länge Datenfeld, und 4) UDP Checksumme.
Hier stimmt mal Theorie und Praxis
Zitat von @aqui:
Oder meintest du das jetzt so das dort Pakete mit maximale Größe erzeugt werden die dann durch die externe Encapsulation wie PPPoE den MTU Wert übersteigen ?
Ich denke, so meine ich das. Ich habe mal Screenshot von dem Wireshark-Auszug gemacht. IP-Adressen und Rufnummern sind geschwärzt. Es geht wie gesagt nur um die Invite-Meldung. Die Sprachpakete sind nicht so groß.Oder meintest du das jetzt so das dort Pakete mit maximale Größe erzeugt werden die dann durch die externe Encapsulation wie PPPoE den MTU Wert übersteigen ?
Ich muss dazu sagen, es ist sogar nur eine MTU von 1480, wie man auch auf den Screenshots sehen wird.
Zitat von @aqui:
Aber auch wenn das Endgerät fragmentiert warum bitte sollte das 120 Byte Paket den Empfänger denn nicht erreichen ?? Es ist doch immer ein und dieselbe Session. Wenn das erste durchgeht muss auch das zweite durchgehen. Alles andere würde unlogisch sein ?!
Aber auch wenn das Endgerät fragmentiert warum bitte sollte das 120 Byte Paket den Empfänger denn nicht erreichen ?? Es ist doch immer ein und dieselbe Session. Wenn das erste durchgeht muss auch das zweite durchgehen. Alles andere würde unlogisch sein ?!
Aus meinen Augen ist das auch unlogisch. Es ist aber eine Tatsache. Ich kenne nur folgenden Teil der physikalischen Strecke zum SIP-Provider:
SBC <--> Switch <--> Medienkonverter (Kupfer-LWL) <--> SIP-Gateway <--> SIP-Proxy
Es ist somit eigentlich nicht ersichtlich, wieso dort etwas verloren gehen kann. Es ist auf Seiten den SIP-Providers auch ein SBC, aber welcher das ist, kann ich nicht sagen.
So der erste Screenshot zeit die ersten Meldungen vom Softgate zum SBC (Nr.54) und dann vom SBC zum SIP-Provider. (66). Die Nummern dazwischen sind alles Schritte auf dem SBC selber. Man sieht, dass das "Don't Fragment"-Bit nicht gesetzt ist. Des Weiteren sieht man, dass die 1622 Bytes in 1480 und 142 Bytes zerlegt werden.
Screenshot 1
Im zweiten Screenshot kann man den Message Header und Body sehen vom Invite-Paket. Der Header ist normal aufgebaut in meienn Augen. Der Body enthält Daten zur Aushandlung, wie z.B. die Codecs. Dies sind aber soweit ich erfahren habe auch normale Daten, welche nicht unüblich sind.
Screenshot 2
Der Body ist aber der einzige Teil der somit die entscheidene "Übergröße" verursachen kann, würde ich sagen. Oder ist das falsch?
Zitat von @aqui:
Hast du mal einen Wireshark genommen und dir das mal in der Realität angesehen ?? Das sollte doch alle Spekulationen deinerseits sicher klären !
Hast du mal einen Wireshark genommen und dir das mal in der Realität angesehen ?? Das sollte doch alle Spekulationen deinerseits sicher klären !
Die Spekulationen klären sich für mich leider nicht. Da ich immer noch versuche den Aufbau zu verstehen von SIP-Paketen. Ich habe mir zwar schon korrekte SIP-Aushandlungen in Wireshark angeschaut, aber die Unterschiede, die ich dort festgestellt habe, lassen sich nicht auf dem SBC abbilden bzw. übertragen. Dass es ein Firmware-Bug ist habe ich auch vermuten und habe auch eine neue Software eingespielt. Die Release Notes der neuen Version besagte auch, dass ein Bug behoben wurde, der doppelte Daten im Message Body enthielt. Somit müsste die Größe nach dem Update kleiner geworden sein. Dem ist allerdings nicht so. Einen genauen Vergleich der Traces habe ich bislang nicht durchgeführt. Da es keinen Paketgrößenunterschied gab. Ich stehe schon mit dem Hersteller in Kontakt und versuche eine Lösung zu erarbeiten.
Der einzige Anhaltspunkt ist aus einem Forum über einen Acme SBC, der das selbe Problem zu haben scheint.
SIP UDP too long
Die Lösung dort heißt:
Of course the proper way to resolve this issue is to use TCP.
Über die Umstellung von UDP zu TCP verhandel ich gerade mit dem SIP-Provider.Ich kann leider kein Trace an einem Mirror-Port fahren, weil ich das alles aus der Ferne einrichten muss. An dem Standort gibt es auch keine IT-Abteilung vom Kunden.
Gruß LiN
