QoS - Quality of Service
Wer schon etwas älter ist, kann sich noch an die frühen transatlantischen Telefonate erinnern. Es dauerte etwas Zeit, bis mein Wort auch "drüben" angekommen ist und die Antwort mein Ohr erreicht hat. Entsprechend mussten die Teilnehmer schon eine gewisse Sprachdisziplin an den Tag legen, wie dies früher in den ersten Chatfenstern und CB-Funk üblich war. Nach dem eigenen Satz oder Nachricht sollte man etwas Zeit vergehen lassen, damit der Gesprächspartner antworten kann. Wer zu früh weiter redet, provoziert eine Überlappung, bei der beide erst mal innehalten.
Arbeitspapier: Bandbreitenmanagement in
Kommunikationsnetzen
http://www.vaf-ev.de/global/dbbin/260510_135925_technik_info_bandbreite_v2010-2.pdf
Ein verständlich geschriebenes Dokument zum Thema, welches auch gut die
Vorteile von OCS mit beschreibt.
Controlling and Limiting Traffic Profiles in your
Network
http://www.hp.com/rnd/pdf_html/traffic_profiles.htm
Kurze Abhandlung von HP zum Einsatz mit Switches
Was ist Sprachqualität ?
Was macht nun aber ein gutes Telefonat in technischer Hinsicht aus ? Es sind zwei wesentliche Faktoren
- Audioqualität
Eine Komponente ist der Klang selbst, welcher durch die Aussteuerung bei der Aufnahme (Mikrofonleistung), die verwendeten Codecs (Kompressionen) und der Qualität der Wiedergabe. Es gibt wirklich qualitative deutliche Unterschiede von Headsets und Mikrofonen. Günstige Geräte müssen nicht schlecht sein, aber sind es leider doch allzu oft. Darunter leidet dann die Verständlichkeit. Es macht durchaus Sinn, Wideband und echokompensierte Mikrofone und hochauflösende Webcams einzusetzen, da gutes Ausgangsmaterial eine wichtige Basis für ein gutes Ergebnis nach der Kompression und Übertragung sind. - Laufzeit, Kontinuität, Verzögerung
Der zweite Faktor ist durch den Anwender weniger zu beeinflussen, sondern Bestandteil des Übertragungsweg. Für die Sprach und Bildkomprimierung muss der Codec einen Buffer betreiben, der natürlich etwas Zeitverzögerung mit sich bringt. Und dann gibt es natürlich die Laufzeit der Paket über ein paketvermitteltes Netzwerk. Abhängig von Belastung, Weitverkehrsverbindungen und verschiedenen Leitwege können Pakete unterschiedliche Wege und Laufzeiten haben. Am Ziel müssen die Pakete als wieder in die Reihenfolge gebracht werden. Auch dazu muss der Codec auf das langsamste Paket warten oder welche weg lassen. Das kann zu Aussetzern und Fremdgeräuschen führen..
Beide Faktoren beeinflussen maßgeblich die Akzeptanz dieser neuen Art zu kommunizieren. Wenn Sie sich überlegen, wie viel Geld einige Tischtelefone kosten, sollte es also kein Problem sein, ein paar gute OC-kompatible Endgeräte zu organisieren.
QoS mit Windows
Gehen wir davon aus, dass es NICHT das Audio/Video-Equipment am PC ist, was sich durch ein Telefonat im unbelasteten lokalen LAN zur Abendzeit gut ausschließen lassen kann. Dann könnte es die Übertragung sein. Schon lange gibt es bei TCP/IP, dem bei VoIP genutzten Protokoll, Verfahren zum Priorisieren von Paketen. dazu müssen aber auch wieder zwei Dinge mitspielen
- QoS-Parametrisierung auf dem Client
Schon auf dem PC ist es über Richtlinien und Einstellungen möglich, bestimmte Pakete zu priorisieren. Speziell wenn mehrere CPU-Kerne und Multitasking parallele Netzwerkübertragungen verursachen, ist ein Vorziehen der Audioverbindung eine nützliche Funktion - QoS-Steuerung auf dem LAN/WAN
Basierend auf den durch den Client gesetzten Prioritätsbits kann dann natürlich auch ein Router die Pakete "vorziehen". Wenn die Bits auf dem Client gesetzt werden, kann natürlich ein Anwender mit entsprechenden rechten sich einen Vorteil verschaffen. Daher nutzen viele Firmen lieber den Weg, auf dem Router anhand der verwendeten Ports die Pakete richtig einzuordnen
Leider ist QoS auf Clients und Routern ein sehr umfangreiches Thema, welches ich hier nicht behandeln kann. Ein paar Startpunkte möchte ich aber geben:
Auf einem Vista-PC muss man natürlich erst mal den QoS-Paketplaner auf der Netzwerkkarte binden.

Einstellen kann man hier aber erst mal nichts. Das erfolgt über Gruppenrichtlinien:
- QoS Tools and Settings - QoS Group Policy Settings
and Registry Entries
http://technet.microsoft.com/de-de/library/cc737728(WS.10).aspx#w2k3tr_qos_tools_lmmu - Policy-based Quality of Service (QoS)
http://technet.microsoft.com/en-us/library/cc771283(WS.10).aspx

Speziell für den Communicator Client und das Microsoft RTC-Protokoll muss man aber noch zusätzlich beachten, dass man hier den Schlüssel "QoSEnabled" noch auf 1 setzen kann.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RTC\Transport]
"QoSEnabled"=dword:00000001
Danach werden nach einem Reboot Audiodaten mit einem DSCP=40 und Videodaten mit DSCP=24 gekennzeichnet.
- Vista SP1 (or SP2) DSCP settings for QoS OC 2007 R2
http://communicationsserverteam.com/archive/2009/06/04/458.aspx - Enabling DSCP Marking
http://technet.microsoft.com/en-us/library/dd441192(office.13).aspx - RegistryHack für "non-domain joined vista/win7
machines"
http://winadmin.blogspot.com/2010/11/windows-vista7-qos-policy-and-non.html
QoS in Lync Policies
In Verbindung mit Lync sollten Sie natürlich entsprechende Ports festzurren, damit ein Router auch anhand der Ports priorisieren kann. Hier ein Beispiel der CSConferencingConfiguration. Hier ist wichtig, dass der Wert "ClientMediaPortRangeEnabled" auf "$true" steht und die Ports für Audio (Hier 5350-5389) vorgegeben sind.
PS C:\> Get-CsConferencingConfiguration Identity : Global MaxContentStorageMb : 500 MaxBandwidthPerAppSharingServiceMb : 375 ContentGracePeriod : 15.00:00:00 ClientMediaPortRangeEnabled : False ClientMediaPort : 5350 ClientMediaPortRange : 40 ClientAudioPort : 5350 ClientAudioPortRange : 40 ClientVideoPort : 5350 ClientVideoPortRange : 40 ClientAppSharingPort : 5350 ClientAppSharingPortRange : 40 ClientFileTransferPort : 5350 ClientFileTransferPortRange : 40 ClientSipDynamicPort : 7100 ClientSipDynamicPortRange : 3 Organization : HelpdeskInternalUrl : HelpdeskExternalUrl : ConsoleDownloadInternalUrl : ConsoleDownloadExternalUrl :
Hier ist natürlich im Default gut zu sehen, dass Audio, Video, Media per Default die gleichen Ports verwenden. Wenn Sie diese verschiedenen Lasten im Netzwerk unterscheiden wollen, dann sollten Sie die Ports auf verschiedene Bereiche anpassen. Dann können Sie auch diese Ports in der Gruppenrichtlinie und auf Routern verwenden. Zudem sollten Sie auf CSMediaConfiguration sicherstellen, dass hier auch QoS aktiviert ist.
PS C:\> Get-CsMediaConfiguration Identity : Global EnableQoS : False EncryptionLevel : SupportEncryption EnableSiren : False MaxVideoRateAllowed : Hd720p15M
Leider ist hier ein "False" per Default aktiv.
QoS auf Gateways
Die Einstellungen auf Routern sind sehr produktspezifisch und kann ich hier daher nicht beschreiben. Hier mal ein Bild eines Audiocodes Mediant 1000:

Die Einstellungen bei anderen Routern und Switches sehen sicher anders aus.
QoS und Wifi
Lync Clients werden immer "mobiler". Irgendwann wird es sicher auch Lync-Clients für Smartphones geben, die auch Audio oder gar Video übermitteln. Bandbreiten dazu sind natürlich über Funktechnologien bereit zu stellen. Auch wenn UMTS/GPRS noch etwas dauert, so ist WiFi in den meisten Firmen schon etabliert und schon heute können Sie mit ihrem Notebook natürlich per WiFi auch mit dem Lync Communicator Audio und Video machen.
Allerdings funktioniert das nur auf einem wenig belasteten WiFi-Funkraum gut, weil Video und erst Recht Audio besondere Ansprüche an die Übertragung stellt. Es sind zum einen sehr viele sehr kleine Pakete die möglichst kontinuierlich übertragen werden sollen. Und das ist nicht immer zu gewährleisten, wenn mehrere Clients vielleicht auch punktuell eine Spitzenlast produzieren oder wenige APs eine größere Fläche mit vielen Clients abdecken müssen. Eine wichtige Voraussetzung sind also viele kleine Zellen und das System dies unterstützt auch entsprechende Priorisierungen. QoS gibt es auch auf WiFi.
- Lync Server Network
Infrastructure Roadmap
http://technet.microsoft.com/en-us/lync/gg131923 - IEEE 802.11e
http://de.wikipedia.org/wiki/IEEE_802.11e - Wireless Multimedia
Extensions
http://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions -
http://www.arubanetworks.com/lync
http://www.arubanetworks.com/solutions/by-application/wireless-conferencing/
VoIP und Verbindungsaufbau
An ein "neuartiges" Vorhalten beim Verbindungsaufbau werden Sie Anwender auch gewöhnen müssen. Da bei VoIP die Signalisierung per SIP erfolgt, aber die Nutzdaten über eine separate Verbindung aufgebaut wird, kann das Wähl und Freizeichen ab und an ändern und erst wenn die Gegenseite abhebt, wird auch die angeforderte Datenverbindung aufgebaut. Und das kann auch mal ein bisschen dauern oder an Firewalls komplett scheitern. Es ist also durchaus möglich, dass bei einem zu frühen Gesprächsstart beim gegenüber die Sprache noch gar nicht ankommt.
Wer z B-. mit dem OCS-Server einen Anruf tätigt, kann manchmal drei verschiedene Töne hören.
- Freizeichen beim SNOM-Telefon u.a.
Bei einem klassischen Telefon erwarten die Menschen, dass beim Abheben des Hörers auch ein "Freizeichen" (Langer Ton) zu hören ist. Früher war das dass Zeichen, dass die Vermittlungsstelle gemerkt hat, dass Sie abgehoben haben und ein Hebdrehwähler zugeordnet worden ist.
Bei VoIP gibt es sowas nicht aber viele Telefone simulieren ein "Freizeichen", ohne überhaupt ein SIP-Paket versendet zu haben. Wenn ein VoIP-Telefon also angemeldet ist und sie abheben, dann gaukelt ihnen das Telefon ein Freizeichen vor. - OCS wählt an
Sehr kurz kann man hören, wenn der OCS-Server die SIP-Verbindung startet und solange kein Feedback eines "TRYING" kommt, ist ein Tonzeichen zu hören - Zwischenfreizeichen
Wenn dann z.B. der Mediation Server die Verbindung zur nächten Station (dem Gateway) aufgebaut hat, erhält er von dort ein "Trying". Der OCS ändert dann seinen Ton in das OCS Freizeichen - Zielfreizeichen
Das Gateway baut über die TDM-Strecke eine Verbindung zur angerufenen Nummer her. Wenn dies z.B. ein Mobiltelefon ist, dann hört der Anwender am Ende das "Freizeichen" des Mobilfunkanbieters.
All diese Freizeichen sind natürlich nur durch "Software" abgebildet. Bislang ist noch keine "Sprachverbindung" über einen Codec hergestellt worden. Das ist übrigens im ISDN-Netz auch so. Der B-Kanal zur Sprache wird erst aufgebaut, wenn die Verbindung von der Gegenseite angenommen wurde. Auf bei VoIP wird das Annehmen der Gegenstelle über die jeweilige Protokollverbindung gemeldet und die Sprachverbindung aufgebaut.
Qualität überprüfen
Aber selbst wenn alles theoretisch gut aussieht, können Anwender über Probleme klagen, die sie irgendwie auflösen müssen. Dazu gibt es tatsächlich auch gleich mehrere Wege, die sie einschlagen können-
- OCS Monitoring-Server
Der Office Communications Server kennt eine QoS-Rolle, welche installiert und konfiguriert werden muss. Am Ende einer Verbindung überträgt der Client als auch der Mediation Server einen Qualitätsreport im SIP-Paket mit an den OCS-Server, welcher diese Daten dann ablegen kann. - OCS-Deployment Validation Tool
Mit dem DVT gibt es Werkzeuge, mit der die reibungsloste Funktion von OCS geprüft werden kann - Netzwerktrace mit Wireshark (www.wireshark.org)
Leider verschlüsselt OCS intern alle Pakete per TLS aber die meisten Firmen verbinden den Mediation Server mit dem Gateway ohne Einsatz von TLS. Das ist auch nicht unbedingt erforderlich, wenn es sich um ein gesondertes LAN handelt. Hier können Sie dann per Netzwerktrace auch die SIP und Audiopakete mitschneiden und sogar "abhören. - Netzwerktrace mit Cain&Abel (www.oxid.it)
Auch das Programm Cain&Abel bietet die Möglichkeit, IP-Pakete auf dem Netzwerk abzulauschen und als Audiodate zu extrahieren - Netzwerktrace mit SIP-Recorder (http://www.pcbest.net/siprecorder.htm)
Diese Software vereinfacht das Mitschneiden als Spezialist für VoIP. Allerdings zeichnet es nur die ersten 30 Sekunden auf.
Sie wissen natürlich, dass solche Mitschnitte, auch wenn Sie als Fehlersuche gemeint sind, nicht ohne vorheriges Einverständnis der Nutzer erfolgen dürfen. Hier mal ein Mitschnitt es PCMU Audiopakets von einem Mediant 1000 an meinen Desktop.

Sie können gut erkennen, dass hier "DifferentiatedServicesField" auf 46 gesetzt ist, wie weiter oben auf dem Bild zur Konfiguration zu sehen ist. Auch bei IPV6 gibt es dieses Feld.

- Differentiated services
http://en.wikipedia.org/wiki/Differentiated_services - Implementing Quality of
Service Policies with DSCP
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949f2.shtml
Best Practice
Auch wenn heutige Netzwerke "schnell" (z.B. Gigabit to the Desktop) sind, so ist eine hohe "Brutto-"Datendurchsatzrate noch kein Garant für einen störungsfreien VoIP-Betrieb selbst wenn die für die Telefonie benötigte Bandbreite eher im Bereich von Kilobyte/Sek liegt. Die Priorität, Kontinuität und Verlustfreiheit sind wichtige Themen.
- Räumliche Nähe
WAN-Verbindungen sind immer ein "Risiko" und Fehler oft nur sporadisch und damit sehr schwer zu erkennen. Leider lassen sich WAN-Verbindungen nicht immer vermeiden. Wichtig ist dann QoS und eine Überwachung. - Keine "ungepflegten" VPNs zwischen Standorten
Wo direkte WAN-Verbindungen nicht zur Verfügung stehen, werden oft VPN-Verbindungen über das günstigere Internet konfiguriert. Allerdings sind hier Laufzeiten und Bandbreiten überhaupt nicht garantiert. Ein schneller Download von Dateien ist kein Zeichen, dass "genug Bandbreite da wäre. VoIP ist kein Bandbreitenfresser (meist <200kbit) aber benötigt konstante und kurze Laufzeiten.
Und wenn die gleiche Leitung zum "Surfen" genutzt wird, kann genau so ein schneller Download die Latenzzeit "hörbar" vergrößern. - VPN von extern
Das Einpacken von VoIP-Paketen in VPNs ist aber auch bei Anbindungen von Einzelpersonen(z.B. unterwegs oder zuhause) ein gerne eingesetztes Mittel. Auch hier sind Laufzeiten eventuell ein Problem. Gerade private DSL-Anschlüsse haben zwar eine relativ hohe Bandbreite für den Download von Dateien, (DSL768 und höher) aber die Gegenrichtung beträgt meist nur ein Bruchteil der Datenrate, so dass es hier zu Engpässen kommen kann. werden dann die Pakete noch durch ein VPN und die entsprechenden Accesspunkten mit einer Verschlüsselung geleitet, kann recht schnell kostbare Laufzeit verloren gehen. - Überwachung von Netzwerkfehlern
Viele Fehler liegen im Netzwerk darunter und sind von oben gar nicht sichtbar. Moderne Netzwerkkarten errechnen selbst CRC-Prüfsummen und fordern verlorene Pakete neu an, so dass diese Fehler in keiner Statistik auf dem Server oder Client erscheinen. Es kann helfen die CRC-offload-Funktion (TCPChimney etc.) temporär abzuschalten. Zwar wird VoIP damit nicht schneller, aber Netzwerkfehler können damit entdeckt werden, die ansonsten für das Betriebssystem verborgen bleibt.
Wie so oft ist der Fehler aber im Details und kann nur durch eine zielgerichtete Suche mit Analyse der Daten gefunden werden.
Unterstützung durch
Net at Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach unter
0800-NETATWORK (0800-638 28 96) an.
Weitere Links
- VoIP
Telefonieren über IP - Exchange 2007 UM nutzt auch VoIP -
VoIP Sniffer
VoIP Sprachdaten mit Wireshark analysieren. - SIP im Detail
-
PCD Pre-Call Diagnostics
Hilfsprogramm für jeden Desktop zur Überwachung der Netzwerkqualität für VoIP mit OCS -
Microsoft Office Communications Server 2007 R2 Requirements for a
QoS Environment
http://technet.microsoft.com/en-us/library/dd441262(office.13).aspx -
Microsoft Office Communications Server 2007 QoE Summary Reports
http://technet.microsoft.com/en-us/library/bb964094.aspx - Office Communications Server 2007 Deployment Validation Tool
http://www.microsoft.com/downloads/details.aspx?FamilyId=3596A10D-65CC-4CCA-8470-3F23D5EA55B2&displaylang=en - Office Communications Server 2007 Quality of
Experience (QoE) Monitoring Server Guide
http://www.microsoft.com/downloads/details.aspx?FamilyID=9ed29d74-3391-4902-bf2c-6757410f3335&displaylang=en - Office Communications Server 2007 VoIP Test Set
http://www.microsoft.com/downloads/details.aspx?familyid=7B6AB4F3-2949-4E97-856E-9C4AE323C75A&displaylang=en - http://blogs.msdn.com/byrons/archive/2008/03/19/deployment-validation-tool-part-1-of-2.aspx
- Deployment Validation Tool Webcast
http://blogs.msdn.com/byrons/archive/2008/04/02/deployment-validation-tool-webcast.aspx
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032372044&Culture=en-US - TechNet Webcast: Identifying Audio Quality Issues Pre-Deployment with
the Communications Server 2007 Deployment Validation Tool (Level 200)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032372044&EventCategory=4&culture=en-US&CountryCode=US - Which Server(s) to deploy the (DVT) Deployment Validation Tool
http://blogs.msdn.com/byrons/archive/2009/04/21/where-to-deploy-the-dvt-deployment-validation-tool.aspx - Vista SP1 ( SP2) DSCP settings for QoS OC 2007 R2
http://communicationsserverteam.com/archive/2009/06/04/458.aspx - Microsoft to Cisco, "Our QoE is better than your QoS
"! as a result of another Independent Study
http://voip-buzz.com/2007/11/09/microsoft-to-cisco-our-qoe-is-better-than-your-qos-as-a-result-of-another-independent-study/ - OCS Quality of Experience (QoE) - Quick Facts
http://blog.insideocs.com/2009/04/27/ocs-quality-of-experience-qoe-quick-facts/ - OCS 2007 R2 – Archiving and Monitoring
http://blogs.technet.com/toml/archive/2009/01/02/ocs-2007-r2-archiving-and-monitoring.aspx - Controlling and Limiting Traffic Profiles in your Network
http://www.hp.com/rnd/pdf_html/traffic_profiles.htm - Overview of the Microsoft RTAudio Speech codec
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=7515









