Codec

Sprache ist eigentlich ein analoges Signal. Auch Bilder haben eigentlich "unendlich" viele Farben. Aber der Mensch ist zum einen sehr tolerant bzw. "unempfindlich" was Töne und Bilder betrifft und zum anderen denken Computer nun mal binär. Es gibt auch analoge Computer aber das ist ein anderes Thema. Fakt ist aber, dass die meisten Menschen höhere Töne nicht mehr hören, wenn Sie von lauteren und tieferen Tönen überlagert sind. Auch bei Bildern sind durchaus kompromissbereit.

Die Auswirkungen können wir täglich erleben. Das Alpenpanorma ist schon beeindruckender, wenn man auf der Aussichtsplattform steht. Trotzdem werden viele Bilder mit x Megapixel "geschossen" und dann auf dem heimischen Monitor oder "Pictureframe" mit 800x600 Pixel angeschaut. Und bei Musik geben sich die meisten Menschen mit MP3-Dateien und 128kbit Auflösung zufrieden, weil sie mehr doch nicht unterscheiden können. Und beim telefonieren über Mobilfunk (GSM) sind es sogar nur 13,7kbit. Und damit sind wir in der Welt der Codec

Abtastung und Kompression

Ein Codec ist letztlich nichts anderes als eine Beschreibung, wie Informationen zu erfassen und gegebenenfalls zu komprimieren sind und später wieder zurückverwandelt werden können. Diese "Anleitung" wird von Programmierern in entsprechenden Code umgesetzt, der dann aus Signalen entsprechende Bits macht. Im Laufe der Entwicklung wurden verschiedene Codecs entworfen, von denen einige auch durch Patente geschützt sind, andere nicht. Auch die Qualität und die Anforderungen unterscheiden sich erheblich.

Sie sehen also, das schon ohne eine detaillierte Auseinandersetzung mit den mathematischen Besonderheiten die Thematik sehr umfangreich werden kann.

Beispiel G.711

Die Thematik der Abtastung lässt sich an einem nicht komprimierenden Verfahren wie dem G.711-Codec sehr einfach aufzeigen. Bei einer Abtastrate von 8000 Messpunkten pro Sekunde mit einer Auflösung von 8 Bit ( also -127 bis 128) kommen damit 64kbit (8000x8) zusammen.

Damit die Zeitverzögerung der Sprache nicht zu groß wird, werden immer 20 Millisekunden in einem Block versendet. Aus der Sekunde werden als 50 Pakete mit den Daten von 20ms.

Zieht man so einen Abschnitt noch etwas größer, dann erkennt man sogar die einzelnen digitalisierten diskreten Punkte

 

Bei 8000 Messpunkten /50 Pakete sind dies also 160 einzelne Werte, oder eben 160 Byte, die im Ethernet Paket übertragen werden. Schaut man sich ein solches Paket dann aber mal im Ethernet an (Hier WiFi) dann sieht man den Overhead

Es werden hier 171 Bytes "Nutzlast" übertragen. Darauf kommt aber noch der UDP-Header (+20 Byte), der IP-Anteil (+20 Byte) und dann noch der Ethernet (bzw. hier WiFi), so dass am Ende 275 Byte übertragen werden. Der Overhead würde prozentual weniger, wenn man mehr Daten pro Paket versenden würde. Wer aber z.B. 40ms einpackt verzögert auch die Übertragung noch mehr. Zudem würde dann ein Paketverlust gleich einen deutlicher hörbaren "Aussetzer" verursachen. Einige Codecs sind daher flexibel und messen die Laufzeiten, Verluste etc. und passen dynamisch die Abtastintervalle an.

Audio-Codecs im Detail

In Verbindung mit Lync, OCS, VoIP und Video kommen einige Codecs zum Einsatz. Lync wechselt sogar Codecs im laufenden Gespräch, z.B. wenn die Bandbreite zu knapp wird, die Fehlerrate ansteigt. Auch ist es ein Unterschied, ob ein Lync Client mit einem anderen Lync-Client verbunden ist, oder ob mittels "Media Bypass" der Client direkt mit dem Gateway spricht. Bei Konferenzen hingegen muss man die Arbeit der zentralen Mixerstelle (MCU) optimieren und verzichtet vielleicht auf den "besten" Codec zugunsten eines Codecs mit weniger Rechenbedarf.

Da viele Codes auch "Stille" erkennen können und dann reduziert senden (und der Empfänger ein "Comfort Noise-Signal" wiedergibt, ist die Bandbreite als "Obere Grenze ohne Fehlerkorrektur" angegeben. Zudem habe ich (außer bei GSM) die Bandbreite auf Ethernet umgesetzt. Zu den 64kbit G.711 kommt ja noch der Ethernet Overhead dazu.

Codec Bandbreite (Max ohne FEC) MOS Einsatzzweck
GSM verschiedene 6,5-13kbps   Im GSM-Netz werden binäre Daten übertragen und das ist "teuer". abgestimmt auf die Slots (TDM)-Verfahren) und die Leistung der Geräte kommen verschiedene Codecs zum Einsatz, die meist nur 3.1 KHz übertragen können und natürlich stark komprimieren.
G.711a
G.711u		 97 kbs 4,4
4,2		 Dieser Codec wird im ISDN-Netz eingesetzt und tastet 64kbit ab. Er wird auch als PCMa aLaw (Europa) und PCM uLaw (USA) bezeichnet. Der Einsatz bei VoIP ist besonders einfach, da ein Gateway die Daten dann nicht umkodieren muss. Die unterschiedliche Qualität kommt daher, dass uLaw mit 56kbit und aLaw mit 64kbit abgetastet wird
http://en.wikipedia.org/wiki/G.711
G.722 101 kbs   Dieser Codec ist ein "Wideband" Codec, d.h. tastet höher (16khz) und mit 14 Bit ab und kommt z.B. in Konferenzen oft zum Einsatz. Auch Lync nutzt den Codec für Audio-Konferenzen
http://en.wikipedia.org/wiki/G.722
Achtung: G722.1 ist eher mit Siren vergleichbar und nicht mit G.722
SIREN 53 kbs   Ursprünglich von Picturetel (Heute Polycom) entwickelter Codec, der von OCS 2007R2 noch für Konferenzen genutzt wird
http://en.wikipedia.org/wiki/Siren_Codec
RTAudio8 45kbs   Dies ist der von Microsoft native genutzte Codec, um Audio zwischen PCs zu übertragen. Dank Kompression, die natürlich auch aufgrund des Computers einfacher ist, kommt der Codec mit relativ wenige Bandbreite aus. Bedenken Sie, dass der Ethernet overhead für alle gleich ist.
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=7515
http://en.wikipedia.org/wiki/Rtaudio
RTAudio16 62kbs   Dies ist die "Wideband" Variante, die höher auslöst
T.38     Dieser Codes ist für FAX optimiert. Beim Übergang aus dem PSTN-Netz sollte das Gateway die "Faxtöne" quasi schon digitalisieren, so dass der Codec schon das binäre Fax überträgt und keine digitalisierten Töne. Damit muss man zum einen nicht 64kbit abtasten, da die meisten Faxgeräte gerate mal 14000 Baud nutzen und T.38 enthält zudem die Funktion, verlorene Pakete erneut zu übertragen (Feherlsicherung). T.38 ist daher sehr ratsam für Fax. Leider erfordert dies leistungsfähigere Gateways und eine Unterstützung bei Endpunkte.
http://en.wikipedia.org/wiki/T.38
G.723.1     Lizenzpflichtiger Codec mit sehr hoher Kompression und schlechter Audioqualität. Kommt aber oft in VoIP-Umgebungen vor und wird von Exchange UM unterstützt.
http://en.wikipedia.org/wiki/G.723.1
G.726-40
G.726-32
G.726-24
G.726-16		   4,2
3,9
3,3
2,5		 Die Angabe 40,32,24 und 16 steht für die Absatzrate
http://en.wikipedia.org/wiki/G.726

Es gibt noch eine ganze Menge weiterer Codecs, aber diese sind üblich im Bereich VoIP.

Bei Audio-Konferenzen ist es üblich, die verschiedenen einkommenden Tonsignale zu "mixen", d.h. hier ist es dann wichtig, dass der Codec die MCU nicht überfordert. Sie muss ja zumindest die wenige Audioströme decodieren und zusammenfügen, die dann wieder an alle Teilnehmer verteilt werden. Hoffen wir mal, dass die meisten Teilnehmer "schweigen und auch keine Hintergrundgeräusch die "Erkennung der Stille" verhindern.

MOS-Wert (Mean Opinion Score)

MOS ist die Abkürzung für "Mean Opinion Score". Die Qualität einer Sprachverbindung wird in der Telekommunikation anhand des MOS-Werts angegeben. Die Scala von MOS reicht dabei von 1 (schlecht) bis 5 (sehr gut). Der MOS-Wert beruht auf einer Testreihe mit einer Gruppe von Versuchspersonen und stellt daher einen subjektiven Wert zur Beurteilung der Qualität der Sprachübertragung dar. Im ISDN wird ein MOS-Wert von knapp über 4 erreicht. Die Qualität hängt von der Übertragungsleitung aber auch vom verwendeten Codec ab.

Video-Codecs

Für Video kommen dann noch ein paar weitere Codec hinzu, da Video ganz andere Anforderungen an die Übertragung stellt. Die meisten Codec übertragen zu bestimmten Zeiten, z.B. alle 10 Sekunden (H.264) oder 3 bzw 4 Sekunden (RTVideo) ein komplettes Bild und füllen die Zwischenräume mit unterschiedlichen "Differenzbildern" auf. Kommen diese "I-Frames" nicht an, dann bemerken Sie dies an einem "Rucken" des Bilds. Auch das Vor-und Zurück-Spulen eines solchen Films (DVDs und HDTV codieren ähnlich) kann dann immer erst wieder an so einem I-Frame aufsetzen.

Diese I-Frames sind natürlich "Groß", so dass Sie nicht in ein einzelnes Ethernet-Paket (151kbyte) passen. Ein normales VGA Bild mit 640x480 Pixel hat schon mal ein paar KB, so dass daraus meist um die 10 Ethernet-Pakete werden. Wer also nur 1% der Pakete auf der Leitung verliert, verliert im Schnitt 10% dieser "Vollbilder". Ohne Fehlersicherung würde das Video also immer mal wieder "hängen" bleiben. Daher sendet z.B. RTVIDEO zusätzliche Pakete, um den Verlust zu kompensieren. Wenn jemand 10 Pakete sendet und ein 11tes Paket die Prüfsummer (wie bei einem RAID) enthält, dann kann ein Verlust eines Pakets heraus gerechnet werden.

Auch der Endpunkt ist zu betrachten. Selbst die Komprimierung von 640x480 Videobildern mit 30 fps erfordert schon einen Dual-Core, wenn man daneben noch etwas anderes machen will. Bei HD, was bei Videokonferenzen meist nur 720p (1280x720) anstelle von 1080 (1920x1080) bedeutet, kann auch einen Quad-Core schon gut auslasten.

Die erforderliche Bitrate ist auch hier wieder Abhängig von den "Änderungen" auf dem Bild und wie der Codec damit umgeht, z.B. indem er Informationen weglässt (unscharf) oder die Bitrate erhöht. Auch ist die Auflösung nicht an einen Codec gebunden./p>

Codec Format
xx/y/fps		 Bandbreite (Max ohne FEC) Einsatzzweck
RTVideo QCIF 176x144   Es gibt Konferenzsysteme, die die Bilder mehrerer Teilnehmer in ein neues Bild zusammensetzen. Da das resultierende Bild dann mehrere Kacheln mit weniger Auflösung je Bild hat. Dann reicht es vielleicht, wenn die Teilnehmer alle nur ein "Viertel-CIF" senden. Das Format ist interessanterweise auch auf die Auflösung früherer kleiner Handy-Displays. Aber ich habe schon lange nicht mehr gesehen, dass es eingesetzt wurde.
RTVideo CIF 352x288 260kbs Der Standardcodec für Videos im CIFS-Format. Auch wenn die Anzahl der Pixel lächerlich wenige erscheint, so reicht dies für einfache Meetings schon aus.
RTVvdeo VGA 640x480/30fps 600kbs Wer mehr braucht, kann einfach zu VGA schalten. Dies machen die Clients aber nur, wenn Sie das Fenster auch entsprechend "groß" ziehen und in einer Konferenz genug Personen dies anfordern.
Beachten Sie, dass aber auch ein DSL6000-Anschluss nur 576kByte Upstream bereit stellt.
RTVideo HD 1280x720/30fps 1500kbs Die 720p-Auflösung erfolgt nur, wenn der sendende Client einen Quadcore hat und der Empfänger auch das Fenster entsprechend "groß" gemacht hat. Der Bandbreitenbedarf ist aber zumindest beim Sender nicht zu unterschätzen und oft immer noch mehr als DSL-Anschlüsse hergeben.
Erst DSL 16000 kann wohl bis zu 3,5 MBit als Upload liefern.
PANO 1056x144 (22:3) 15fps 350kbit Besonderes Format, welches beim Einsatz der Roundtable zum Einsatz kommt und dann als zusätzlicher Datenstrom gesendet und verteilt wird
H.263     Diesen Codec hat der Lync Client noch mit an Bord. Primär als Rückwärtskompatibilität zu anderen Clients.
http://en.wikipedia.org/wiki/H.263
H.264     Lizenzpflichtig und nicht von Lync genutzt

Bei Konferenzen beschränkt sich OCS und Lync aber darauf, die Daten des aktiven Sprechers (anhand der Audioinformation) anzufordern und an alle Teilnehmer zu verteilen. Die MCU ist hierbei also kein Mixer sondern ein Switch. Über das Steuerprotokoll RTCP werden die Clients angewiesen, ihr Bild zu senden oder eben auch nicht. Kleine Information am Rande: OCS/Lync bekommt auch das Bild des "vorherigen" Sprechers und sendet dieses an den aktiven Sprecher. Das ist nicht jedem Teilnehmer bekannt aber so hat der aktive Sprecher nicht sich selbst im Bild bekommt zumindest ein einer Person ein Feedback.

Zu dem Thema Codec könne man noch viel mehr schreiben und erläutern und auf all die Feinheiten und Kniffe, die z.B. Microsoft in seinen RTVideo eingebaut hat, kann ich hier nicht eingehen.

Alle Konferenzen beginnen übrigens erst mal mit "CIFS. Über das RTCP-Protokoll melden die Clients auch, welches Videoformat sie gerne hätten. Anhand einer Formel entscheidet dann die MCU, ob z.B. VGA angefordert und dann auch verteilt werden soll.

Wer mit wem und wann

Über SIP werden Verbindungwünsche ausgetauscht, die in einem SDP-Nutzlastl neben den IP-Adresse auch die verschiedenen Codes enthalten, die die Teilnehmer sprechen können. Je nach Umgebung kommt dann der passende Codec zum Einsatz, wobei sich die Wahl auch im Betrieb ändern kann. Ein Codec-Wechsel ist nichts ungewöhnliches. Ich habe mal versucht hier eine Übersicht zu erstellen, welcher Client mit welchem Server welchen Codec einsetzt.

Hinweis: Das sind die "normalen" Codec. Ein Wechsel aufgrund von schlechten Bandbreiten es ist ein einigen Fällen möglich.

Wer mit Wem Lync
Client		 OCS
Cient		 Mediation Media
Bypass		 Konferenz ExUM
Unterstützte Codes RTAudio RTAudio CU3:G711
CU4:RTAudio		 G711 G722
Siren		 G.711 µ-law
G.711 A-law
G.723.1
Lync Client RTAudio RTAudio CU3:G711
CU4:RTAudio		 G711 G722
Siren		 RTAudio16
OCS Client   RTAudio G711 n/a Siren ?
Mediation Server     RTAudio (?)(1) G711 (2) ?
Konferenz            

Die noch nicht ausgefüllten Felder habe ich noch nicht ermittelt

Lync Clients beachten zusätzliche aber eventuell eingerichtete Bandbreitenbeschränkungen (CAC). dann kann es schon sein, dass der Client vielleicht sogar nur SIREN einsetzt, weil die Bandbreite nicht mehr als 40kbit zulässt.

TCP oder UDP

Da Audio und Video eher "flüchtige" Informationen sind, ist ein Verlust einiger Pakete problemlos zu tolerieren. Daher ist auch keine Transportsicherung über TCP erforderlich. Welches Protokoll genutzt wird, ist aber bezüglich des Codec irrelevant. Diese sind ja nur die Nutzlast und können sowohl über UDP als auch über TCP übertragen werden.

UDP ist aufgrund seiner Funktion natürlich präferiert und es sind keine TCP-Quittungen und erst recht keine "Retransmissions" erforderlich. Was bringt ihnen ein erneut übertragenes Paket, welches Töne enthält, die in der Vergangenheit liege. Trotzdem kann es vorkommen, dass die Daten über TCP übertragen werden, z.B. wenn UDP durch die Firewall geblockt wird.

Auch wer mit VPNs arbeitet, wird gar nicht merken, dass die UDP-Daten wieder in TCP-Pakete eingepackt werden. Dabei werden Sie im schlimmsten Fall noch fragmentiert (MTU-Size). Es ist daher immer zu überlegen, wie z.B. die bei OCS/Lync eh verschlüsselten Audio/Video-Daten am VPN vorbei kommen können, z.B. indem mal die Edge-Server aus dem VPN ausschließt. Das betrifft Routing, Firewallregeln aber auch die DNS-Auflösung.

Latenzzeit

Die Verzögerung von Audiosignalen ist ein weiteres Thema, welche direkt mir der "gehörten Qualität" verbunden ist und oft allein auf den Codec geschoben wird. Natürlich ist auch ein Codec und die Paketgröße für eine gewisse Signalverzögerung verantwortlich. Schließlich muss er die Audiodaten ja erst einsammeln, abtasten und als Paket formatieren. Kommen dann noch "Fehlerkorrektur" und Jitter-Buffer dazu, dann ist auch auf der Empfangsseite eine Verzögerung zu erkennen. Aber das sind bei weitem nicht die einzigen Verzögerungen. Schauen wir uns exemplarisch mal die Schritte an:

 

Position Verzögerung Total
Die Töne verlassen den Mund des Sprechers 0ms 0ms
Übertragung bis zum Mikrofon. (Schallwellen ist kein Licht und viel schneller als 300m/s breiten sich Druckwellen in unserem Lebensraum nicht aus. Bei einem Meter Abstand wären da schon die ersten 3ms, die aber niemand wirklich wahrnimmt. Sie würden auch nur eingehen, wenn Sie quasi "Freisprechen" mit einem weiter entfernten Mikrofon nutzen würden. 0ms 0ms
A/D-Wandlung. Das Mikrofon nimmt die analogen Druckschwankungen auf und setzt diese in elektrische Signale um, was noch relativ schnell geht. Die Umsetzung in ein USB-Bus-Paket und Übertragung zum PC kann aber je nach Soundgerät schon deutliche Verzögerungen haben. Insbesondere wenn das Mikrofon selbst noch "Soundverbesserungen" wie Echounterdrückung und Popp/Knack-Schutz-Filter enthält. "UC-Headsets" achten z.B. darauf, dass hier die Verzögerung nicht allzu groß wird. (Das kann man tatsächlich in Laboren messen und Microsoft macht das auch. 5-15ms  
Der Codec ist nun an der Reihe, die digitalen Signale zu komprimieren, in die entsprechenden Häppchen aufzuteilen und möglichst schnell zu versenden. Das kostet aber in der Regel mindestens die Paketgröße von 20ms als Verzögerung. 20ms +  
Netzwerkkarte 1ter Hop
Heute haben wir alle in der Regel ein "geswitchtes" Netz, so dass Kollisionen oder ein durch andere Stationen "belegtes Medium" nicht mehr vorkommen sollte. Auch das früher bekannte "Backpressing" von Switches sollte kaum noch passieren. Aber FlowControl ist weiter hin da und auch andere Programme auf ihrem PC senden natürlich Daten. ein "XCOPY" oder ein Speichern einer größeren Powerpoint sind durchaus ernstzunehmende Störfaktoren. Auch wenn Audio nur viele kleine Pakete sind, so unterbricht es nicht den Versand von 1514 Byte-Datenbanken durch den PC. Da muss dass RTP Paket dann eben warten. Bei 100 MBit sind das aber dann dennoch weniger als 0,15ms und damit zu vernachlässigen.  		   
Auch die Übertragung zum Switch und die dortige Weiterleitung ist selbst bei 100 egabBit kein Problem, zumindest wenn genug Bandbreite bereit steht. Stören könnte aber die Empfangsrichtung sein, wenn der Switch die Pakete einfach in der Reihenfolge in die Queue stellt und die kleinen RTP-Paket nicht vorlässt. Beim Senden kann ein Windows Client ja noch selbst die Reihenfolge bestimmen. Dies gilt aber nicht für den Empfang oder die weiteren Hops. Trotzdem belasse ich hier die Latenz bei 0ms 0ms  
WAN Latenz
Anders sieht das natürlich aus, wenn eine WAN-Verbindung hier mit involviert ist. Hier sind nicht nur die Bandbreiten geringer, was eine höhere durchschnittliche Belastung und damit ein höheres Risiko einer Blockierung mit sich zieht, sondern die "Schrittgeschwindigkeiten" sind auch geringer, d.h. die Bits sein langsamer und länger auf der Leitung unterwegs. Da ist einfach die Physik am Limit, denn selbst mit Lichtgeschwindigkeit braucht es ein Zeit die Bits über lange Strecken zu übertragen. Und dann kommen noch die elektrischen Wandler und Verstärker dazwischen. Aber selbst das sind immer noch kleine Werte im Vergleich zur Laufzeit. Eine 2 MBit Leitung kann 2 Mio Bit/Sek übertragen. Ein ca. 1,5kByte (vereinfacht 15000bit) Paket blockiert so eine Leitung schon für 7,5ms und wenn der Schedule dann zwischen "großen Daten" und kleinen Audiopaketen einfach numerisch 1:1 tauscht, dann wird es eng für mehrere Audiokanäle. Hier ist also Priorisierung, z.B. nach IP-Ports oder QoS angeraten, wenn sie nicht gleich dedizierte Bandbreite reservieren. Aber selbst ein ca. 200Byte (=2000bit) großes RTP-Paket braucht immer noch 1ms im idealen fall		 1+x ms
  
Die Jitter-Queue beim Empfänger
Wenn wir nun auch den Switch und das LAN beim Empfänger außen vor lassen, dann landet das Paket direkt im IP-Stack und wird hier erst mal nicht direkt wiedergegeben. Der Codec muss ja zum einen die empfangenen Pakete eventuell erst in die richtige Reihenfolge bringen und da er auf unterschiedliche Laufzeiten reagieren muss, "verzögert" er absichtlich die Wiedergabe, um Spätankommer noch "in time" abspielen zu können. Dieser Buffer variiert von Codec zu Codec. Einige haben einen statischen Wert und andere passen den Buffer an die Qualität an. In der Regel werden aber immer mindestens 1-2 Pakete im Vorlauf gehalten und beim Einsatz einer Fehlerkorrektur noch mehr. Wenn wir mal davon ausgehen, dass ein Paket wieder 20ms von 160 Samples enthält, dann ist allein der Empfänger für eine Verzögerung von 40-60ms verantwortlich.		 40-60ms +  
Dekomprimierung und Wiedergaben
Die Umwandlung der Daten in Töne und die Wiedergabe über ein Headset oder Lautsprecher unterliegt den gleichen Bedingungen wie die Aufnahme. Analoge Lautsprecher an einer PCI-Soundkarte haben weniger Latenzzeiten als USB-Geräte aber in der Regel bewegen sich diese auch im kleinen ms-Bereich		 ca 4ms  

Auch wenn nicht alle Zahlen repräsentativ sind und mit einfachen Mitteln gemessen werden können, so sollten Sie für eine gute Sprachqualität die verschiedenen kniffligen Punkte kennen und nicht leichtfertig an der ein oder anderen Stelle einen Kompromiss eingehen.

Das Messen von solchen Latenzen ist zum einen schwer, weil es sehr kurze Zeiten sind und einzeln nicht mit dem menschlichen Gehör ermittelt werden können. Der Aufbau einer Schleife, bei der auf der Empfängerseite das erhaltene Signal einfach wieder zum Sender zurück gesendet wird um dort dann die Summe beider Richtungen zu messen, scheitert meist an der sehr guten Echo Cancellation der RTAudio-Codecs. Über Programme wie "virtual Audiocable" können Sie sowohl solche Schleifen als auch Verbindungen zu Analyseprogrammen "schalten" aber der Messaufbau ist alles andere als Repräsentativ.

Wenn Sie ein "gutes" Headset und einen halbwegs aktuellen PC verwenden und Virenscanner, Firewalls etc. ihnen nicht dazwischen funken, dann können Sie sich fast immer auf das Netzwerk konzentrieren. Und hier liefern zum einen Lync mit dem Monitoring-Service schon sehr viele Werte und wenn QoS nicht die messingen verfälscht, kann auch die Laufzeit eines einfachen PING mit z.B. 200 Bytes als Nutzlast eine erste Abschätzung geben.

Netzwerk simulieren

Nicht jeder hat verschiedene Bandbreiten zur Simulation zur Verfügung. Und es gibt auch immer weniger PCs, die noch einen COM-Port haben, über den sich zwei Systeme mit einem DFÜ-Netzwerk (RAS als Router) mit unterschiedlichen Bandbreiten verbinden lassen. Und selbst dann kann man nur mit einer relativ fixen Bandbreite arbeiten aber unterschiedliche Latenzzeiten oder Paketverluste lassen sich damit kaum simulieren.

Aber es gibt Abhilfe. So enthält Visual Studio 2010 angeblich eine Netzwerkbremse, die ein langsames Netzwerk auf dem PC simuliert:

In verschiedenen Laboren habe ich das Programm NEWT gesehen (Network Emulator for Windows Toolkit), welches leider wohl nicht mehr frei ist. Es ist wohl Teil des Games for Windows LIVE SDK und XBOX XDK, die beide nicht kostenfrei sind. (Quelle: http://blogs.technet.com/b/juanand/archive/2010/03/05/standalone-network-emulator-tool.aspx). Die folgende Seite listet NEWT als ein Produkt auf, welches von MS Research in ein kommerzielles Produkt gewandert ist

ich kann hier zumindest mit ein paar Screenshots dienen. Man baut damit zwischen die Applikation und der Netzwerkkarte eine Drossel auf. Zuerst definiert man Filter für die gewünschten Ziele, die man drosseln oder blockieren will,

Das kann also z.B. der Lync Kommunikationspartner, Konferenzserver oder Mediation Server sein. Beachten Sie hier auch die Karteikarten am unteren Rand, die später eine Analyse der Eingriffe erlauben. Im zweiten Schritt werden dann zur Anwendung hin die verschiedenen "Belastungen" eingestellt:

Anhand der Reiter können Sie schon sehen, dass man Pakete "verlieren" kann, Fehler verursachen, Latenzzeiten beeinflussen, Bandbreite drosseln oder die Reihenfolge verwürfeln kann.

Leider ist diese Programm nicht in einer mir bekannten Quelle enthalten.

Weitere Links

Keywords:td> Codec G711 RTAudio Video Bandbreite