142583
May 04, 2020, updated at 07:32:17 (UTC)
1072
6
0
Voice over WiFi Priorisierung
Hallo FuuBas,
mich würden mal eure Gedanken zur möglichst flachen Priorisierung von Voice over WiFi Traffic interessieren.
Ich habe seit Samstag eine asiatische Delegation im Haus, die wie verrückt telefonieren. Stundenlang sprechen unzählige Leute VoIP über unsere Gäste WiFi Infrastruktur.
Wenn sie jetzt nicht im Beratungsraum sitzen und sich z.b. in der Produktion oder in den Laboren befinden und bewegen, dann gibt es hin und wieder Probleme mit der Sprachqualität.
Roaming habe ich optimiert, bzw gibt es dort keine Probleme.
Auf die schnelle habe den IMS der die Gespräche initiiert, eine QoS Regel verpasst, dass Vorfahrt herrscht. Scheint soweit geklappt zu haben die Jungs Lächeln noch mehr als sie sonst schon Lächeln.
Wie würdet ihr Voice over WiFi priorisieren ohne nach den Destination IMS zu suchen und sie regelmäßig zu pflegen?
Eine möglichst flache Konstruktion würde mich interessieren, ohne jeglichen VoIP Traffic oder alles ESP mitzunehmen.
mich würden mal eure Gedanken zur möglichst flachen Priorisierung von Voice over WiFi Traffic interessieren.
Ich habe seit Samstag eine asiatische Delegation im Haus, die wie verrückt telefonieren. Stundenlang sprechen unzählige Leute VoIP über unsere Gäste WiFi Infrastruktur.
Wenn sie jetzt nicht im Beratungsraum sitzen und sich z.b. in der Produktion oder in den Laboren befinden und bewegen, dann gibt es hin und wieder Probleme mit der Sprachqualität.
Roaming habe ich optimiert, bzw gibt es dort keine Probleme.
Auf die schnelle habe den IMS der die Gespräche initiiert, eine QoS Regel verpasst, dass Vorfahrt herrscht. Scheint soweit geklappt zu haben die Jungs Lächeln noch mehr als sie sonst schon Lächeln.
Wie würdet ihr Voice over WiFi priorisieren ohne nach den Destination IMS zu suchen und sie regelmäßig zu pflegen?
Eine möglichst flache Konstruktion würde mich interessieren, ohne jeglichen VoIP Traffic oder alles ESP mitzunehmen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 569459
Url: https://administrator.de/contentid/569459
Printed on: May 9, 2024 at 07:05 o'clock
6 Comments
Latest comment
Zitat von @142583:
Wie würdet ihr Voice over WiFi priorisieren ohne nach den Destination IMS zu suchen und sie regelmäßig zu pflegen?
Eine möglichst flache Konstruktion würde mich interessieren, ohne jeglichen VoIP Traffic oder alles ESP mitzunehmen.
Wie würdet ihr Voice over WiFi priorisieren ohne nach den Destination IMS zu suchen und sie regelmäßig zu pflegen?
Eine möglichst flache Konstruktion würde mich interessieren, ohne jeglichen VoIP Traffic oder alles ESP mitzunehmen.
Was denn jetzt? Erst willst du es nicht adressbasiert machen und dann aber auch nicht inhaltsbasiert. Dann bleibt dir nur, die Leute aus dem Netz zu werfen oder mit dem vorherigen Ist-Zustand leben zu lassen.
Die übliche Vorgehensweise, die in den meisten Geräten auch schon vordefiniert ist, ist anhand der DSCP-Markierung. Voice Payload hat normal die 46. Also danach priorisieren.
Viel mehr kannst du auch nicht machen, weil Wifi Calling oder was für Namen es noch hat, halt SIP in IPSec ist.
Auf die schnelle habe den IMS der die Gespräche initiiert, eine QoS Regel verpasst, dass Vorfahrt herrscht.
Das ist ja nur die halbe Miete bzw. bringt gar nichts. Kollege @tikayevent hat es oben schon gesagt.Essentiell ist erstmal ob du Layer 2 Priorisierung machst (802.1p) oder Layer 3 über DiffServ und vor allem WIE deine Netzwerk Infrastruktur damit umgeht. Priorisierung muss auf jedem einzelnen Device gesetzt sein wenn es durchgängig sein soll. Am Internet Router ist so oder so Schluss, denn die Provider kappen jegliche QoS Infos von Paketen weg.
Alle Netzwerk Infrastruktur Hardware MUSS diese prioriserten Pakete lesen und erkennen können um sie bevorzugt zu behandeln und zwar auf dem gesamten Pfad zwischen Client und Zielserver !
Ohne das igniriert die komplette Infrastruktur jegliche Priorisierung. In einem WLAN Netz sollte man zusätzlich noch den WMM Support auf allen APs aktivieren.
Diese Threads beschreiben grob die QoS Grundlagen im Netz:
Kaufberatung - Switches mit VoIP-Priorisierung
Redundante Core Switches
Es ist ein Samstagvormittagnotbehelf.
Grundsätzlich gibt es im Gäste WiFi keine Besonderheiten, außer dass der gesamte Traffic aus diesen Netzen die vorletzte Priorität genießt am Exchange ins WAN. Der Internetzugang für diesen Traffic unterstützt sogar Priorisierung, mindestens bis zum Exchange zum nächsten Tier1. Da liegt nicht das Problem.
Das Problem lässt sich auch lösen, wenn ich von 10 auf 20 MBit gehe, habe ich festgestellt. Das ist allerdings nicht möglich und 10 Mbit sind schon sehr viel.
Die jetzige Regel ist vermutlich nicht Mal rechtlich in Ordnung. Aber der Vorstand möchte, dass jeder Zucker in diese ** geblasen wird. ;)
Ich möchte z. B. nicht jeden VoIP Traffic von Facebook und Konsorten mitnehmen und auch nicht mit der Betriebsvereinbarung kollidieren.
DSCP 46 auf any:any scheint die selbe positive Wirkung zu haben. Seit 12:00 Uhr läuft das mit 8 MBit und nun warte ich auf Feedback.
Unsere drei Provider machen mit 8 und weniger MBit übrigens keine Probleme.
Erfahrungsgemäß sind diese Art von Probleme immer mit China verbunden. Selbst die Schrottleitung nach Marokko kennt solche Sperenzien nicht.
Grundsätzlich gibt es im Gäste WiFi keine Besonderheiten, außer dass der gesamte Traffic aus diesen Netzen die vorletzte Priorität genießt am Exchange ins WAN. Der Internetzugang für diesen Traffic unterstützt sogar Priorisierung, mindestens bis zum Exchange zum nächsten Tier1. Da liegt nicht das Problem.
Das Problem lässt sich auch lösen, wenn ich von 10 auf 20 MBit gehe, habe ich festgestellt. Das ist allerdings nicht möglich und 10 Mbit sind schon sehr viel.
Die jetzige Regel ist vermutlich nicht Mal rechtlich in Ordnung. Aber der Vorstand möchte, dass jeder Zucker in diese ** geblasen wird. ;)
Ich möchte z. B. nicht jeden VoIP Traffic von Facebook und Konsorten mitnehmen und auch nicht mit der Betriebsvereinbarung kollidieren.
DSCP 46 auf any:any scheint die selbe positive Wirkung zu haben. Seit 12:00 Uhr läuft das mit 8 MBit und nun warte ich auf Feedback.
Unsere drei Provider machen mit 8 und weniger MBit übrigens keine Probleme.
Erfahrungsgemäß sind diese Art von Probleme immer mit China verbunden. Selbst die Schrottleitung nach Marokko kennt solche Sperenzien nicht.
Das ist allerdings nicht möglich und 10 Mbit sind schon sehr viel.
Ganz besonders wenn man bedenkt das per Voice Call nur popelige 56kBit/s benutzt werden.. 
Ich möchte z. B. nicht jeden VoIP Traffic von Facebook und Konsorten mitnehmen
Was auch Sinn macht. Normal klassifiziert man diesen Traffic mit einer ACL und lässt auf diesen dann so separierten Traffic die 802.1p oder DSCP Settings los. Bei DSCP muss man immer bedenken das reine L2 Devices das nicht auswerten (klar, denn die interessiert rein nur die Mac Adressen und nie der L3 Header). Man muss L3 QoS dort immer explizit aktivieren. L2 QoS natürlich nicht.Das aber wie gesagt auf dem gesamten Pfad oder wenigstens soweit man den Pfad QoS mässig beeinflussen kann.
diese Art von Probleme immer mit China verbunden
Die große Firewall lässt grüßen
Das deaktivieren von U-APSD für das WiFi brachte die "Lösung".
Nun laufen Voice Video Calls auch mit 4Mbit. Nun ist die Bandbreite wieder bei 4/4 für alle Gäste und keine Extrakonfig mehr nötig.
Warum diese Herren mit Video Calls rumlaufen dürfen, die Frage schenke ich mir. Dafür klebe ich weiter unseren Spitzenpolitikern die Notebook Cam zu und gebe Aufkleber für die Familie mit nach Hause.
Nun laufen Voice Video Calls auch mit 4Mbit. Nun ist die Bandbreite wieder bei 4/4 für alle Gäste und keine Extrakonfig mehr nötig.
Warum diese Herren mit Video Calls rumlaufen dürfen, die Frage schenke ich mir. Dafür klebe ich weiter unseren Spitzenpolitikern die Notebook Cam zu und gebe Aufkleber für die Familie mit nach Hause.
Wenn man die vereinbarte Grundlage für die Nutzung des Gäste WiFi liest, dann steht da, dass der Betreiber lediglich einen Forward für den Traffic macht und nichts anderes. Kein Firewalling, Logging und was auch immer.
Der Nutzer des Vouchers unterschreibt dafür und ist dann anonym.
Der Traffic wird auch von der Telekom unter separaten IPs ins Internet gebracht, getrennt von unseren Angestellten.
Daran rumzuspielen ist nicht unbedingt die beste Idee, auch nicht wenn du Geschäftsführung das telefonisch zu ...kannst Du Mal gleich beauftragt... Kannst du Mal gleich ist der kleine Bruder von Ärger mit den übermächtigen Betriebsrat.
Die ganze Sache hat ja auch einen Interessenkonflikt eingebaut, es gibt ein paar Multi-Device Voucher den BR-Mitglieder und hohes Management nutzen um ihre (private) Kommunikation unterm Radar abzuwickeln.
Der Nutzer des Vouchers unterschreibt dafür und ist dann anonym.
Der Traffic wird auch von der Telekom unter separaten IPs ins Internet gebracht, getrennt von unseren Angestellten.
Daran rumzuspielen ist nicht unbedingt die beste Idee, auch nicht wenn du Geschäftsführung das telefonisch zu ...kannst Du Mal gleich beauftragt... Kannst du Mal gleich ist der kleine Bruder von Ärger mit den übermächtigen Betriebsrat.
Die ganze Sache hat ja auch einen Interessenkonflikt eingebaut, es gibt ein paar Multi-Device Voucher den BR-Mitglieder und hohes Management nutzen um ihre (private) Kommunikation unterm Radar abzuwickeln.
