1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

[Dr.Einstein]

Hi,

gerade wenig Zeit darum:

https://www2.lancom.de/kb.nsf/1275/E7E6 ... enDocument

Statt auf BE müsstest du z.B. EF ummarkieren.

Gruß Dr.Einstein

[Koppelfeld]

Guten Morgen!

https://www2.lancom.de/kb.nsf/1275/E7E6 ... enDocument

Puuuuuuh.
Also, die Anwendung setzt neue Flags, die Telekom wertet die aus und berechnet ein Sondervolumen "low latency / low loss"?

Das sind wohl Herrn Oettigers Teleoperationen? Oder Fahrzeug - zu - Fahrzeug - Transfer?

Aber ganz im Ernst: Wir haben regelmäßig Probleme damit, den Gerätezoo "passend" zu konfigurieren. Insbesondere wenn an einem IP-Telephon noch ein weiteres Gerät hängt.

Daher - und weil ich es auch ungünstig finde, IP-Telephone überhaupt ins Internet zu lassen - bekommen die ein eigenes, abgeschlossenes Netz, welches ich auch im VPN leicht priorisieren kann.

Ich würde liebend gern eine Firewallregel haben, die sagt:
"UDP-Pakete von Host xy bitte in die "bevorzugt" - Queue?

"Bandbreiten pro Verbindung reservieren" haut dann daneben, dann zählt der Lancom 2 bis 5 Verbindungen.

Ich will einfach nur in die "bevorzugte" queue.


Geht das?

[Dr.Einstein]

Es war eine Beispielfirewallregel, die DSCP umtaggt. Was anderes hatte ich gerade nicht zur Hand. Natürlich muss das jetzt angepasst werden für die ankommende Richtung, oder was auch immer du/er vorhat.

@Koppelfeld: Ansonsten gibt es in Deutschland eine Vielzahl von Providern, die QoS Profile unterstützen mit Low Latency, Droprate etc. Die Sachen kosten je übertragenen MB. Ich frage mich deswegen eh schon lange, wieso es diesen Aufschrei um Netzneutralität gibt. Faktisch bietet das seit Jahren jeder ernste Provider an.

Gruß Dr.Einstein

[ako77]

Hallo mal wieder,

zu diesem Thema hätte ich nun weitere Erkenntnisse:
inzwischen funktioniert die Markierung von DSCP's auf EF einwandfrei. Zumindest lt. Trace des IP-Routers. Aus der Sicht passt es also.
Dennoch habe ich das Gefühl (durch mögliche fehlerhafte Konfiguration), als würde der Lancom nicht hinterherkommen, wenn er QOS machen soll.
Äußert sich so, dass ich sehr massive Aussetzer / Jitter auf der Leitungsrichtung Upload habe. Im LanMonitor sehe ich, das "Tx bevorzugt" wird.

qos01.jpg

Pro Station habe ich hier großzügig 128kbit/s festgelegt:

qos-ef-out.jpg

Der Ansatz der FW-Regeln oben erhebt keinen Anspruch auf Richtigkeit!

Sollte ich, wenn ich schon Regeln für IN und OUT habe, auch nen Haken bei "für gesendete Pakete"/"für empfangene Pakete" setzen?

Die Regel "Change-DSCP" wirkt sich jetzt natürlich auf "Beliebig" aus - was ich vllt. auch nur auf die Netze VLAN-VOIP und die "SIP-Provider" setzen sollte?
Habt Ihr hierzu Vorschläge, Änderungen, Ideen oder Empfehlungen?

Danke & Grüße....

[GrandDixence]

Dennoch habe ich das Gefühl (durch mögliche fehlerhafte Konfiguration), als würde der Lancom nicht hinterherkommen, wenn er QOS machen soll.
Äußert sich so, dass ich sehr massive Aussetzer / Jitter auf der Leitungsrichtung Upload habe.

Seriöse TechnikerInnen/AdministratorInnen zeichnen die SIP/RTP-Telefongespräche mit der Funktion "Paket-Capturing" des LANCOM-Gerät auf. Und untersuchen diese mit den mächtigen SIP/RTP-Funktionen (Jitter- und Paketverlust-Messungen etc.) des Programms Wireshark:

http://www.unappel.ch/public/100119-wireshark-xlite/

https://www.wireshark.org/

Ich bin der Meinung, dass bei der OUT-Regel (Richtung: von Heimnetzwerk nach Internet) die Option "Erzwungen" aktiviert werden sollte. Siehe auch:

http://www.lancom-forum.de/fragen-zum-t ... 14326.html

QoS in der IN-Regel ist aus meiner Sicht überflüssig wenn die VoIP-Telefone direkt am LANCOM-Gerät angeschlossen sind. In Richtung "von Internet nach Heimnetzwerk" kommt es zu keinem Warteschlangestau im LANCOM-Gerät und somit macht hier QoS kein Sinn.

Vermutlich fehlt auch die "künstliche" Drosselung des Upload/Upstream:

Code: Alles auswählen

/Setup/Schnittstellen/DSL/Upstream-Rate

damit der Warteschlangestau der ausgehenden Datenpakete im LANCOM-Gerät überhaupt entstehen kann (Richtung: von Heimnetzwerk nach Internet). Oder habe ich dies in den (zahlreichen) Beiträge übersehen?

[Koppelfeld]

Seriöse TechnikerInnen/AdministratorInnen zeichnen die SIP/RTP-Telefongespräche mit der Funktion "Paket-Capturing" des LANCOM-Gerät auf. Und untersuchen diese mit den mächtigen SIP/RTP-Funktionen (Jitter- und Paketverlust-Messungen etc.) des Programms Wireshark:

2% der mir bekannten Admins können ein Ethreal-Ausgabe lesen. Und jetzt bringst Du auch noch Damen ins Spiel? Da kenne ich jetzt eine einzige, und die war bis vor kurzem ein Mann.
Ernsthaft: Du brauchst dann auch noch Protokollkenntnisse.
Und was nützt es Dir, wenn Du etwas über den Jitter weißt, welcher auf der Strecke erzeugt wird ?
Ohne Kenntnis der Dejitterbuffereinstellung der beteiligten Geräte: garnix.

Nix gegen Wireshark, nix gegen den (vorbildlichen) "dynamischen" Capture - Download.


Pragmatisch bleiche ich bei der Empfehlung "Voice Call Manager".

QoS in der IN-Regel ist aus meiner Sicht überflüssig wenn die VoIP-Telefone direkt am LANCOM-Gerät angeschlossen sind. In Richtung "von Internet nach Heimnetzwerk" kommt es zu keinem Warteschlangestau im LANCOM-Gerät und somit macht hier QoS kein Sinn.

Stimmt. Das Dumme ist nur: Das glaubt keiner.

[ako77]

QoS in der IN-Regel ist aus meiner Sicht überflüssig wenn die VoIP-Telefone direkt am LANCOM-Gerät angeschlossen sind.

Ok, die VoIP-Telefone sind am Switch (in einem VLAN) angeschlossen. Ich meine, ich habe hier auch durchaus schon gelesen, dass QOS auch Eingangs sinnvoll ist.
Wenn ich also die "IN-Regel" deaktiviere und im QOS "Erzwungen" aktiviere, wäre das also Dein Vorschlag? Ich werde es testen...

Mit dem Lancom-Tracer habe ich hier bereits mehrfach mitgeschnitten - jedoch noch nie im Wireshark analysiert (...). Da war mir erstmal wichtig, das die DSCP-Markierungen "richtig" sind.

Vermutlich fehlt auch die "künstliche" Drosselung des Upload/Upstream:

Vermutlich ja. Also auch noch ein Punkt, mit dem man testen könnte!?

Pragmatisch bleiche ich bei der Empfehlung "Voice Call Manager".

VCM habe ich nicht vergessen, jedoch scheint mir die Einrichtung nicht trivial zu sein und ich habe bisher keine Zeit aufgewendet, das Ding zu verstehen, was es von mir eingerichtet haben möchte.

[Koppelfeld]

VCM habe ich nicht vergessen, jedoch scheint mir die Einrichtung nicht trivial zu sein und ich habe bisher keine Zeit aufgewendet, das Ding zu verstehen, was es von mir eingerichtet haben möchte.

Bezogen auf das, was Du bisher alles gemacht hast, ist der VCM sogar ausgesprochen trivial.

Bloß hat ein Marketing"profi" offenbar dem Entwickler eingebrockt:
- "Du mußt einen "Wizard" bauen"
- "Es darf keine verständliche Bezeichnung in den Menüs vorhanden sein. Auf keinen Fall gängige Fachtermini, sondern 'modern Esperanto' aus Deutsch und Englisch !"

So heißt dann ein SIP-Endgerät "SIP Benutzer".

Ich kann Dir ggfs. ein Angebot machen: Mittwoch bis Freitag liege ich im Krankenhaus und habe speziell am Donnerstag, zwischen zwei Bagatelloperationen, vieeeeel Zeit. Da kann ich Dich gerne telephonisch unterstützen. Schicke Dir meine Mobilnummer gern auf Anforderung per p.n..

[Jirka]

Hallo zusammen,

QoS in der IN-Regel ist aus meiner Sicht überflüssig wenn die VoIP-Telefone direkt am LANCOM-Gerät angeschlossen sind. In Richtung "von Internet nach Heimnetzwerk" kommt es zu keinem Warteschlangestau im LANCOM-Gerät und somit macht hier QoS kein Sinn.

nein, aber davor kann es zu einem Stau kommen, in Folge dessen auch RTP-Pakete verloren gehen. Um dies zu verhindern, wird der gesamte eingehende Traffic ohne die RTP-Daten auf die Downloadrate abzüglich der reservierten Bandbreite für RTP eingebremst. Das hat zur Folge, dass TCP-Pakete sich im LANCOM in eingehender Richtung (künstlich) aufstauen (bzw. dass diese auch verworfen werden) und sich dadurch der (oder die) TCP-Stream(s) selber auf eine geringere Datenrate einregelt/n, da die Empfangsbestätigungen auf die gesendeten Pakete den Absender später erreichen (oder gar nicht im Falle der verworfenen Pakete, die daraufhin noch mal gesendet werden müssen). Im Endeffekt lässt sich so im Normalfall der Platz für die RTP-Pakete freihalten.
Man kann das ganz einfach ausprobieren. Man nehme einen SIP-Provider, der nicht dem Internet-Provider entspricht. (RTP-Daten einer SIP-Leitung vom Internet-Provider werden meistens sowieso schon bevorzugt behandelt.) Dann startet man ein paar Downloads und telefoniert dabei. Danach macht man das Ganze mit Reservierung. Wem der akustische Beweis nicht reicht, der kann auch noch zu Wireshark greifen und das genauer analysieren...

Mit dem Lancom-Tracer habe ich hier bereits mehrfach mitgeschnitten - jedoch noch nie im Wireshark analysiert (...).

Das geht mit dem LANtracer-Mitschnitt auch nicht (jedenfalls nicht ohne weiteres).

VCM habe ich nicht vergessen, jedoch scheint mir die Einrichtung nicht trivial zu sein und ich habe bisher keine Zeit aufgewendet, das Ding zu verstehen, was es von mir eingerichtet haben möchte.

Du hast die Option also und nutzt sie nicht?! Das Ding ist in 30 Min. eingerichtet! Kann man sich auch machen lassen...

Viele Grüße,
Jirka

[Koppelfeld]

Das hat zur Folge, dass TCP-Pakete sich im LANCOM in eingehender Richtung (künstlich) aufstauen (bzw. dass diese auch verworfen werden) und sich dadurch der (oder die) TCP-Stream(s) selber auf eine geringere Datenrate einregelt/n, da die Empfangsbestätigungen auf die gesendeten Pakete den Absender später erreichen (oder gar nicht im Falle der verworfenen Pakete, die daraufhin noch mal gesendet werden müssen). Im Endeffekt lässt sich so im Normalfall der Platz für die RTP-Pakete freihalten.

Hallo? Wer bist Du und was hast Du mit Jirka gemacht?

Der echte Jirka weiß, daß RTP aus gutem Grund auf UDP aufsetzt...

Gruß Hans

[Jirka]

Hi, lies einfach nochmal was ich geschrieben habe. Es ging um die Daten, die eben nicht zu RTP gehören.
Viele Grüße,
Jirka

[ako77]

Ich kann Dir ggfs. ein Angebot machen: Mittwoch bis Freitag liege ich im Krankenhaus und habe speziell am Donnerstag, zwischen zwei Bagatelloperationen, vieeeeel Zeit.

Dann zunächst dafür mal gutes Gelingen und gute Besserung und Danke für das Angebot. Darauf werde ich wohl mal zurückkommen...

Du hast die Option also und nutzt sie nicht?! Das Ding ist in 30 Min. eingerichtet!

Ja mea culpa, dann habe ich mir eben genau diese 30 Minuten keine Zeit genommen ...nicht immer muss einem alles ersichtlich/verständlich sein auf den ersten Blick.

Danke für Eure Beiträge zunächst

[Koppelfeld]

Hi,

Hi, lies einfach nochmal was ich geschrieben habe. Es ging um die Daten, die eben nicht zu RTP gehören.

Beim zweiten Lesen ist bei mir dann der Groschen gefallen, gaaaaaanz langsam.
Natürlich hast Du recht, und es war eigentlich auch nicht schwierig zu begreifen.
Gruß und Dank.