Herr Lose, Sie stottern!
Wer mit generell kleinem Bandbreitenbudget auskommen muss, oder (Beispiel:) Kollegen hat, die bei Youtube-Verbot mosern, der muss sich schon was einfallen lassen. Üblicherweise kommt es nur bei IP-Telefonie, also technisch bei „UDP-Traffic“ auf hohe Zuverlässigkeit und Geschwindigkeit an.
Anmerkung: Dieser Beitrag ist veraltet. Mit Sicherheit gibt es schon gegenteilige Meinungen oder bessere Ansätze. Bitte sieh Dich im Lancom-Forum dazu um.
Naja, wir wissen ja, was wir von dem Versprechen von vor EXAKT 5 Jahren zu halten haben – das ist 2014 ja immer noch „Neuland“. Inzwischen halten die Holländer ihren Fix-IP-200M-Kabelanschluss für zu langsam und wir zahlen für einen 5M Anschluss stattlich vergoldete EUR500 an die Rosa-Jungs. ¥€$! Wir wissen ja, wo wir uns zu bedanken haben – Das hat bestimmt nix mit Lobby oder Schlandnet zu tun – Nein, nicht das ich das für ein Wirtschaftshemmnis halten würde… Ups, ich rutsche wieder in Politik ab, Sorry ;-) Das war der andere Joe.
Oft kommen kleine Router in unserem Schmalbandnetzen beim Paketjonglieren an die Grenzen des technisch machbaren. Das äußert sich bei VoIP in Jittern oder abgerissenen Gesprächen bzw. nur noch in Fetzen übertragenem Audio, also in oben gewählter Überschrift. Durch geringe Bandbreiten an einigen Lokationen führt das zu extrem schwierige Bedingungen für IP-Telefonie. Je nachdem, an welchem Standort ich mich befinde tritt das beim „Hören“ oder „Sprechen“ auf.
Gute Firmware hilft allerdings, dem Problem ein bisschen beizukommen. Nachdem sich meine Gesprächspartner vermehrt beschwert hatten, musste ich dem jetzt mal nachdenken, nachlesen und durchkonfigurieren. In meinem Beispiel kommen folgende Hardwarekomponenten zum Einsatz: Starface, Snom, Lancom und Sophos.
Die Ausführungen sind (noch) Beta, ich erhebe also in keiner Form Anspruch auf Korrektheit. Dieser Beitrag ist noch im „Bastelstatus“. Ich hoffe auf zahlreiche Rückmeldungen für Optimierungen. Die Theorie ist hier erst einmal in meinem Kopf aus dem Netz zusammengefügt. Irgendwann werde ich berichten, und diesen Satz entfernen. Bis jetzt (Freitag Abend) funktioniert es so jedoch ganz gut. inzwischen an vielen Standorten präsent und verrichten dort tagtäglich ihre Arbeit einwandfrei. Ich erhebe dennoch keinen Anspruch auf Korrektheit, Konfiguration auf eigene Gefahr.
Update 01.03.2014: Inzwischen habe ich schon die ersten Rückmeldungen. @Jirka verweist auf ein paar wirklich gute Beiträge im LC-Forum und auch @Dr.Einstein meldet zu meinem Beitrag, „Nach meinen Erfahrungen wirkt sich diese ab einem bestimmten Punkt negativ aus, auch auf VoIP Verbindungen, wenn der Upload zu hoch ist und Fragmentierung erzwungen wird. Aber jede Konstellation ist anders, es gibt kein globales Kochrezept für QoS -> VoIP“.
In meinem Szenario setze ich rein Starfaces im vermaschten Anlagenverbund, sowie überall SNOM Endgeräte ein. Letztere sind des Anwenders Liebling, da sie einfach zu bedienen sind. Hier sind einige der „Starfaces“ zu finden, die ich schonmal irgendwann gebaut habe, die also real existieren. Die Starface Appliance an sich ist hier aber nur symbolhaft zu sehen. Sie ist zwar meine Lieblingsanlage, Du wirst aber mit Sicherheit etwas anderes einsetzen. Die meisten Hersteller von IP Anlagen und IP Telefonen bietet eine Angabe für das QoS „Tagging“ an, d.h. wie sie ihren versendeten Verkehr kennzeichnen.
Das QoS bedeutet, die Datenpakete bekommen eine spezielle Briefmarke oben drauf, die es als „besonders wichtig“ markieren. Die meisten Geräte, die viel UDP sprechen, machen das bereits von haus aus. Die dürfen also – sofern der Router oder der Switch das entsprechend richtig umsetzt – am Flughafen Fast Lane / VIP Checkin machen. Das ist bei Deinen IP-Telefonie-Geräten genauso. Du müsstest das Verkehrskennzeichen dann jeweils für Deine Geräte adaptieren.
Du kannst Dir hier einen Überblick über das Szenario machen, welches ich in dieser HowTo abbilden möchte. Prinzipiell sind die Firewall Appliances an durchgehend gegeneinander auszutauschen, jedoch hat in diesem Fall „Lancom“ die Nase vorn was Fragmentierung der Pakete betrifft (Dazu später mehr):
Zum einen muss man sich ein wenig mit der Materie auseinandersetzen. SNOM hat dazu eine relativ simple Tabelle online gestellt, die das Nachrechnen einfach macht, ebenso schreibt neuerdings Starface genau auf, wie sie ihre Pakete markieren. Und jetzt heißt es, genau nachdenken. Wir wollen ja SIP Audio, also den RTP Datenstrom. Also das problematische UDP-Ding, was zu Jittern oder aussetzern neigt. Wir wollen definitiv nicht das Session Initiating Protokoll (TCP 5060, Gesprächskontrollsignal) priorisieren. An’s Herz legen mag ich Euch noch die Tabelle von Jirka im Lancom Forum, der hat das alles nochmal genau aufgemalt und gibt auch noch ein paar wichtige Tipps, die man für dieses Thema anwenden kann.
Hinweis: Das ganze funktioniert nicht für Endgeräte, welche direkt eine VPN-Verbindung aufbauen, wie z.B. SNOM Endgeräte mit direkt konfiguriertem SSL-VPN zu einer Sophos UTM, die viele im Homeoffice einsetzen (Im Szenario als Piktogramm „Mobiles SNOM“ dargestellt).
RTP Audio für SIP wird bei SNOM mit TOS 160 markiert, also DSCP Klasse CS5. Bei Starface ist es die DSCP Klasse EF. Jetzt gilt es also, für CS5 und EF jeweils eine Priorisierung herzustellen und bei MTU Fragmenten möglichst zu unterstützen. MTU ist eine Wissenschaft für sich, welche – so wie ich nachlesen konnte – entscheidende Auswirkungen auch auf die Gesprächsverzögerung hat, d.h. wann die Audiodaten auf der Gegenseite ankommen. Dr. Einstein sagt im Lancom Forum allerdings, dass meine MTU Konfiguration gerade bei hohen Upload-Bandbreiten problematisch sein können. Was es mit der MTU generell auf sich hat, könnt Ihr hier nachlesen.
Adaptiert heist das, eine Lancom und eine Sophos UTM können beide für die Priorisierung einen Bandbreitenpool bereitstellen, doch MTU-Reduktionsanpassung funktioniert nur mit Lancom. Gesetz dem Fall, wir sprechen über eine Lancom-Sophos VPN Strecke ist es bei der MTU-Reduktion unerheblich, welche Seite die MTU-Reduktion macht, die Pakete passen sich dem jeweils kleinsten Nadelör an.
Wichtig ist, dass wir grundsätzlich pro Sitzung eine Bereitstellung der Bandbreite von mindestens 128K für das bei SNOM so beliebte HD-Audio haben.
Feststellung:
Starface RTP Audio: DSCP Klasse EF
SNOM RTP Audio: DSCP Klasse CS5
Hinweis:
Mit dem Switching kann man eine Menge kaputt machen, und so rate ich von der Konfiguration der Paketbehandlung im Switch selbst ab. Zwar können die selbst alles irgendwie, allerdings sind die Pakete bereits von haus aus korrekt markiert, wie wir ja oben lesen und die das Nadelör ist das Gateway. Netgear macht z.B. alles mögliche mit den Paketen, nur das nicht, was wir wollen, wie ich am Standort WES bitter erfahren musste. Bei HP gelingt das schon deutlich besser, allerdings erst in den großen Switchserien (z.B. 2920 oder meinem absoluten Liebling, dem 5406zl – gerade dieser im 10G Verbund mit vielen 2920) – und da macht das auch Sinn. Das aber hat nichts mehr mit diesem Szenario hier zu tun, denn hier spreche ich über kleine, eng vermaschte Umgebungen. Wenn man nicht völlig auf dem Schlauch stehen möchte, und sich wundert, warum aus dem SNOM kein CS5 mehr herauskommt, dann solltet Ihr das hier so konfigurieren:
Konfiguration Astaro/Sophos UTM an den jeweiligen Standorten HRO und NOH
Hierzu können müssen wir zunächst die Bandbreitenpools an den Interfaces definieren. Dazu definieren wir die jeweils maximal zur Verfügung stehende Bandbreite an den jeweiligen Interfaces. In meinem Fall habe ich eine recht luxuriöse Ausstattung an der Seite der Sophos UTM. Das ist mit Sicherheit bei Euch nicht so schick wie in meinem Beispiel, ihr solltet Eure Bandbreite zuvor z.B. auch mal mit einem Speedtest – z.B. mit den relativ guten von OOKLA testen. Dann habt Ihr einen recht zuverlässigen Wert. Anschließend wechselt Ihr in //Schnittstellen & Routing/Dienstqualität (QoS)/Status und aktiviert die Bandbreiten für das externe Interface und für das interne, an dem entweder Euer SNOM oder Eure Starface hängt:
Anschließend definiere ich die Verkehrskennzeichner für die DSCP Klassen. Für CS5 und EF lege ich jeweils in //Schnittstellen und Routing/Dienstqualität QoS/Verkehrskennzeichner einen jeweiligen wie folgt an:
Anschließend lege ich mir auf der Sophos Seite einen Bandbreiten-Pool an. Das mache ich für SNOM und Starface unter //Schnittstellen & Routing/Dienstqualität (QoS)/Bandbreiten-Pools wie folgt:
Damit beides auch auf VPN-Strecken läuft, definiere ich in der Einstellung //Schnittstellen & Routing/Erweitert auch noch beide Funktionen wie folgt:
Damit ist die Konfiguration auf der Sophos Seite abgeschlossen. Es ist nicht mehr zu tun.
Konfiguration Lancom LCOS ab Version 7.8 an den jeweiligen Standorten KR und WES
Ihr definiert zunächst den auf der WAN-Seite zur Verfügung stehenden Bandbreitenpool, sofern Ihr – wie die meisten – nicht das integrierte Modem verwendet. Dazu wechselt Ihr im Lanconfig auf //Schnittstellen/WAN/Interfaces und konfiguriert Eure Bandbreite:
Jetzt baue ich einen Tipp von @Jirka im Lancom Forum ein. Er sagt, dass ich – sofern ich Fehler im Regelaufbau meiner Firewall gemacht habe – mit der Option „Diffserv-Feld beachten“ unter //IP-Router/Allgemein/“Diffserv-Feld beachten“ schon die halbe Miete hätte:
Anschließend müsst Ihr für Diffserv-EF und Diffserv CS5 jeweils eine neue Filter-Regel anlegen. Sie sollte als allererstes abgearbeitet werden, also die höchste Priorität haben. Bei mir sind die VOIP-Klassenregeln auf Priorität 30, das kann bei Euch sicherlich anders aussehen. Dazu wechselt Ihr in //Firewall QoS/IPv4 Regeln und legt eine neue Filter Regel an:
Unter ./Aktionen wählt Ihr „Hinzufügen“ aus und betitelt wie folgt:
Unter ./Aktionen definiert Ihr die Aktion wie folgt. Ihr müsst über den Weg Eurer Strecke achten. Sollte die Strecke über VPN oder über die Default Route (z.B. Internet) oder wie bei mir über alle Wege laufen, solltet Ihr wie hier definieren:
Wählt also definitiv aus -> „bei DiffServ-CP“ den Wert „EF“ und Übertragen.
Im QoS Eintrag der Filter-Regel kommen nun insgesamt 3 Einstellungen zum Tragen, da wir hier nicht nur die Reservierung, sondern auch die MTU-Reduktion konfigurieren möchten. Definiert dazu ein neues QOS-Objekt in Eurer ./Filter-Regel/QoS via „Hinzufügen“:
Fügt anschließend folgende QoS Obekte hinzu (MTU steht hier generell noch zur Diskussion für hohe Upload-Bandbreiten, sprich Du kannst damit spielen und variieren):
So dass Ihr anschließend diese 3 Objekte in QoS wie folgt hinterlegt habt:
Stationen und Dienste können jeweils wie folgt konfiguriert werden – nämlich gar nicht:
Damit habt Ihr Euer QOS-Objekt für Starface / Asterisk fertig definiert. Anschließend Ihr die eine neue Firewall-Regel identisch wie oben, jedoch mit dem Diffserv-CP Tag „CS5“ wie hier gezeigt:
So dass Ihr in Eurer Firewall-Regeltabelle zwei Firewallobjekte habt, die wie folgt überschlägig angezeigt werden:
Das war’s. Am LanMonitor lässt sich die Funktion relativ gut überprüfen. Wie ihr bei mir – in der schwächsten Lokation in KR – seht, ist recht viel Dampf auf der Leitung, doch findet kein Telefongespräch statt:
Bei Nutzung der Starface an einem Knoten in meiner Vermaschung oder eines SNOM-Endgerät über eine der VPN-Strecken verändert sich das Bild beim Gesprächsaufbau wie folgt:
Ich bin mit der Gesprächsqualität erst einmal sehr zufrieden. Es findet kein Jittern mehr statt, die Verzögerung ist auch in erträglichem Rahmen, selbst wenn die Leitung so wie hier (16M Anschluss) bis an die Grenzen gequält wird.