QoS Einstellungen bei reiner Softphonenutzung

  • Hallo zusammen,


    folgendes Szenario:


    Wir haben 2 VLANs, einmal für die Telefone, TK-Anlage, etc. hier funktioniert das Telefonieren problemlos. Voice-TAG ist gesetzt.
    Im zweite VLAN sind die PCs der Benutzer. Hier tritt das Problem auf, dass Benutzer welche nur das Softphone haben nichts mehr hören bzw.
    den Gegenüber total verzerrt hören, wenn auf dem PC gleichzeitig Anwendungen wie Youtube, Teamviewer o.ä. laufen.
    Hier fehlt es vermutlich an entsprechenden QoS Einträgen auf dem Switch. Kann mir hier jemand sagen, was ich hier auf
    Paketbasis einstellen muss, damit das reibungslos funktioniert?


    Viele Grüße
    RH_BK

    Viele Grüße
    Rouven

  • @RH_BK:


    Um welche Softphones geht es denn? Um die vom UCC-Client oder externe Lösungen?


    Wenn es um das integrierte Softphone des UCC-Client geht, der über Port 5222 arbeitet, wird es mit QoS leider nichts, das ist für verschlüsselte Kommunikation nicht einsetzbar. Ausweg wäre dann nur, einen anderen SoftphoneClient einzusetzen, der über die "normalen" SIP-Ports ansprechbar ist und nicht verschlüsselt ...


    Sollte ich mich irren, lasse ich mich wie immer gerne korrigieren.


    Natürlich würde ein funktionierendes QoS (bei unverschlüsselten Telefonaten) in den meisten Fällen sehr effektiv weiterhelfen. Das steht außer Frage ...

  • Beobachte mal die CPU last. Bei Youtube videos kann diese bei zu klein dimensionierter Rechenleistung durchaus mal in die höheren prozente steigen. Vorallem bei FullHD ohne dedizierte Grafikkarte, was dann wiederum das Stottern verursacht


    Was habt ihr denn für Hardware?

  • An der Hardware sollte es nicht scheitern. Dieses Verhalten tritt auch bei Teamviewerverbindungen und Down-/Uploads auf und die brauchen nun wahrlich bei weitem nicht die Ressourcen die zur Verfügung stehen

    Viele Grüße
    Rouven

  • ... tatsächlich könnte die Belastung des jeweiligen Computers zwar eine Rolle spielen - eher aber im Bereich von Virenscannern die im Hintergrund aktiv sind oder natürlich bei sonstigen (sehr starken) Auslastungen des Systems, oder auch Belastungen der Netzwerkkarte, die sich im "ungewöhnlichen" Bereich abspielen würden.


    ABER:


    Erfahrungsgemäß macht das modernen Systemen nicht mehr ernsthaft viel aus und sollte - wenn überhaupt - nur sehr selten eine Rolle spielen. Der Hinweis auf die Datennutzung z.B. bei Teamviewerbetrieb ist insofern schon absolut richtig, hier würde QoS (wenn es denn im Zusammenhang mit dem UCC-SoftphoneClient ginge) schon etwas bewirken / Probleme komplett beseitigen. Der Flaschenhals wäre typischerweise die Internet-Anbindung - hier hatte ich ganz vergessen zu fragen, um welche Anbindung es sich denn handelt (ADSL, SDSL, VDSL ... Kabel? Geschwindigkeit, wieviele gleichzeitige Internet-Nutzer .... usw.)?

  • Es ist eine 100 Mbit SDSL Leitung auf die ~20 User kommen. Da das Verhalten aber auch bei internen Gesprächen auftritt würde ich selbst den Punkt schon ausschließen wollen. Und es tritt wie gesagt auch nur bei den Personen auf, welche rein mit dem UCC Client telefonieren. Andere User mit Telefonen (welche im VoiP VLAN sind) haben keine Probleme.

    Viele Grüße
    Rouven

  • was für ein Gerät routet denn euren verkehr?
    Was für eine Firewall und was für Switche habt ihr? Vielleicht kennt man es ja


    Bei 20 Usern sollte jeder normale Gigabit Switch keine Probleme haben. Auch nicht bei QOS.


    Vielleicht sind hier IDS / IPS auf der Firewall aktiv.
    Das sollte für den VoIP traffic tunlichst vermieden werden

  • Der Hinweis auf die inerne Telefonie und auch nicht UCC-Telefonie ist schon mal sehr interessant und aussagekräftig. Tatsächlich würde ich damit auch sagen, dass grundsätzliche LAN- oder Anbindungsprobleme halbwegs ausgeschlossen werden können. Ein 100 MBit SDSL ist überdies bei 20 Benutzern, die sicher nicht mal alle gleichzeitig telefonieren ausreichend (auch mit sonstigem (büroüblichen) Datenverkehr).


    Tipp dazu:


    Es gab in unserem Kundenumfeld mehrfach das Szenario, das verwendete Switche selbst automatisch / per Default den "Versuch eines QoS" anboten und eben leider aktiv hatten. Genau in diesen Fällen gab es dann absolut vergleichbare Effekte - insbesondere bei den UCC-Clients. Bitte nach Möglichkeit mal schauen, ob bei verwendeten Switchen irgendwelche "Helferlein" aktiv sind, diese mal abschalten und dann nochmal testen.


    Zudem bleibt die Frage: wenn QoS für die Telefonie aktiv ist und es auch Benutzer mit "normalen" Telefonen über die üblichen, nicht verschlüsselten Kommunikationswege gibt, würde ich durchaus davon ausgehen, dass exakt die UCC-Softphones bei Greifen des QoS für alle andere Telefone zusammen mit dem sonstigen Datenverkehr "abgeregelt" werden, man also genau dafür exakt das Gegenteil dessen erzeugt, was man erreichen wiill. Wie ist das denn ... wenn nachweislich im LAN überhaupt oder kaum Datenverkehr feststellbar ist - tritt das Problem dann bei den UCC-Softphones in gleicher Intensität auf oder eher schon weniger?


    Leider, leider kann es aber eben am mir so bekannten grundsätzlichen Problem hängen bleiben, dass die Softphones des UCC-Clients am nicht möglichen QoS "kranken".


    Noch eine Frage am Rande:


    Die Arbeitsplätze sind per LAN-Kabel oder WLAN angebunden?

  • Das muss dann aber auch brutal sein ;)


    Unsere Gateprotect lässt bei IPS /IDS von ursprünglich 400 mbit internet anbindung gerade mal 60 - 80 mbit übrig.
    Kann man sich ja dann ausmalen was bei 100 mbit passiert.


    Und wenn die Firewall dann am besten noch jedes VoiP paket durch den Virenscanner schickt wäre es kein Wunder warum alles abgehackt ankommt.


    Testszenario wäre hier wie sich der PC verhält, wenn er im VoIP Vlan ist


  • und was bleibt bei Dir dann übrig, wenn neben dem Virenscanner auf den Clients noch eine Endpoint-Protection läuft ?


    Habt Ihr ggf. auf den Clients eine Endpoint-Protection-Lösung im Einsatz die auch noch einmal auf Viren- und Ransomware prüft, unabhängig von der Firewall ? Falls ja, hier dann das Softphone als Ausnahme eintragen.

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • ...also meiner Erfahrung nach taggt der UCC Client sehr wohl die ToS Header.
    Weiß gar nicht, wieso immer wieder irgendwo die Vermutung auftaucht, dass das nicht ginge :p


    Somit sollte imho einer Priorisierung auf aktiven Netzwerk-Komponenten (die DiffServ unterstützen) eigentlich nichts im Wege stehen.


    Hier mal ein paar ermittelte Werte:


    System SIP RTP
    Starface-PBX CS3 EF
    Starface UCC-Client CS0 CS7
    Yealink Telefon AF31 EF


    Grüße
    Martin



  • Hallo Martin
    weisst du auch ob bei W10 Clients noch eine QoS Policy auf Windowsseite erforderlich ist, damit die Diffservwerte von Starface weitergegeben werden?
    Oder gibts dazu einen Link zu einem guten Beitrag?
    Bei Lync hatten wir früher auch das Problem mit der schlechte Sprache und Abbrüchen bis wir auf den W7 Rechnern eine QoS Policy eingerichtet hatten. Leider fehlt mir heute der Mitarbeiter ;-((


    Gruß
    Josef

  • Vielleicht hilft Dir dieser Link von Microsoft weiter ?


    Alternativ könnte auch dieser Beitrag auf msxfaq.de helfen.

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!