vasquez.service.akademie.voip

(letzte Änderung: Montag, 20 Juni 2005)

Kein Internet-Dienst funktioniert ohne Protokoll: Dem Browser sein HTTP, dem Server sein FTP, dem Mailer sein POP und SMPT – und auch VoIP folgt mehreren Protokollen, also nicht nur dem IP. Die aktuellen VoIP-Geräte und -Programme setzen dabei auf SIP, was oft stellvertretend für VoIP genannt wird.

 Voice Over IP

Die Diskussion um das Thema VoIP hält schon einige Jahre an, wird oft sehr kontrovers diskutiert und leider auch oft fehlinterpretiert. Dabei treten neben Begriffen wie Call Center- und Konferenz-Lösungen aktuell auch Begriffe wie „Internet-Telefonie" in den Vordergrund. Alle diese Begriffe haben in diesem Diskussionsumfeld eine Gemeinsamkeit: Die Sprachinformation wird in IP-Paketen durch ein IP-Netzwerk übertragen. Spätestens wenn sich die Diskussionen auf die beiden Protokolle H.323 oder SIP (Session Intiation Protocol -RFC3261) fokussieren, gehen die Diskussionen in eine heftige Pro-und-Kontrarunde über. Dennoch: VolP wird in immer breiterem Maße von Anwendern akzeptiert. Durch die seitens der Provider angebotenen Dienste wird der Einsatz von VoIP auch für kleine Büros und Privatkunden interessant. Als Service haben wir Ihnen einige spannende Neuprodukte aus diesem Bereich zusammengestellt. Auf den folgenden Seiten geben Ihnen die hervorgehobenen Herstellerkästen einen Überblick über aktuelle Produktneuerungen.

Wichtig für den Anwender ist, dass er unabhängig vom System eine breite Palette von Anwendungen angeboten bekommt. Diese sollten nicht gerätespezifisch oder von einer speziellen Betriebssystemimplementierung abhängig sein, die schlimmstenfalls - je nach Ausbaustufe - noch gewechselt werden muss, sondern so beschaffen, dass er nach seinen Anforderungen auf einer einheitlichen Basis skalierbar arbeiten kann. Je nach Unternehmensgröße wird auf eine exzellente Sprachqualität Wert gelegt oder aber darauf, keine größeren Investitionen in neue Netzwerk-Hardware zu tätigen, da man die Sprachqualität mit der vorhandenen Hardware als ausreichend empfindet, und eine Lösung auf der Basis der vorhandenen Infrastruktur sucht. Betrachten wir nun einige der technologischen Parameter.

Sprachqualität über Komprimierungs­verfahren: Codec

In Abhängigkeit von der Bandbreite, die zur Verfügung steht, und der gewünschten Sprachqualität kann es wünschenswert sein, Sprachdaten zu komprimieren. Die ITU entwickelte ein Verfahren, um die Sprachqualität der Codecs (Codieren, Decodieren) mit einer Maßzahl zu versehen und sie somit vergleichbar zu machen. Da sich Delays addieren und die Sprachqualität wesentlich beeinflussen, muss auch der Packetization Delay einkalkuliert werden. G.711 bekam dabei einen MOS (Mean Opinion Score) von 4.1, was ungefähr der Qualität von ISDN entspricht. Im Vergleich dazu ist die Sprachqualität bei G.729 geringfügig schlechter bei einem MOS von 3.92, allerdings bei nur ca. 1/3 der benötigten Ethernet-Bandbreite.
 

 

Codec       

Information

 

 

 

Bandwidth

Calculations

 

Codec & Bit Rate (Kbps)

Codec Sample Size (Bytes)

Codec Sample Interval (ms)

Mean Opinion Score (MOS)

Voice Payload Size (Bytes)

Voice Payload Size (ms)

Packets Per Second (PPS)

Bandwidth

MPorFRF.12 (Kbps)

Bandwidth w/cRTP MP or FRF.12 (Kbps)

Bandwidth Ethernet (Kbps)

G.711 (64 Kbps)

80 Bytes

10 ms

4.1

160 Bytes

20 ms

50

82.8 Kbps

67.6 Kbps

87.2 Kbps

G.729 (8 Kbps)

10 Bytes

10 ms

3.92

20 Bytes

20 ms

50

26.8 Kbps

11.6 Kbps

31.2 Kbps

G.723.1 (6.3 Kbps)

24 Bytes

30 ms

3.9

24 Bytes

30 ms

34

18.9 Kbps

8.8 Kbps

21.9 Kbps

G.723.1 (5.3 Kbps)

20 Bytes

30 ms

3.8

20 Bytes

30 ms

34

17.9 Kbps

7.7 Kbps

20.8 Kbps

G.726 (32 Kbps)

20 Bytes

5 ms

3.85

80 Bytes

20 ms

50

50.8 Kbps

35.6 Kbps

55.2 Kbps

G.726 (24 Kbps)

15 Bytes

5 ms

 

60 Bytes

20 ms

50

42.8 Kbps

27.6 Kbps

47.2 Kbps

G.728 (16 Kbps)

10 Bytes

5 ms

3.61

60 Bytes

30 ms

34

28.5 Kbps

18.4 Kbps

31.5 Kbps

SIP - das Protokoll*


SIP (Session Initiation Protokoll - RFC 3261) verkörpert eine Schlüsselkomponente der Internet Multimedia Architecture. Andere Protokolle wie SDP (Session Description Protocol), RTP
(Realtime Transport Protocol) usw. sind zur Implementierung kompletter Dienste erforderlich. SIP wurde prinzipiell auf dem am meisten skalierbaren und entwickelten Internet-Protokoll HTTP (Hyper Text Transport Protocol) entwickelt, dem World Wide Web zugrunde liegenden Protokoll. SIP verkörpert weit mehr als nur ein Sprachprotokoll. Es unterstützt alle Medien, die auf einer Kommunikationsverbindung realisiert werden können. Allerdings sollte auch klar definiert werden, dass SIP lediglich ein Protokoll zum Aufbau einer Sitzung darstellt und mit den möglichen Anwendungen wie z.B. VolP (Voice over IP; Video over IP etc.) nicht gleichgesetzt werden kann.

Doch SIP ist nur eines von mehreren Protokollen, die bei VoIP eingesetzt werden. SIP steht für Session Initiation Protokoll, was soviel heißt wie Sitzungs-Einleitungs-Protokoll. SIP sorgt aber nur dafür, dass das Gespräch zu Stande kommt. Mit den eigentlichen Telefondaten hat SIP nichts zu tun.

Denn SIP signalisiert nur das Gespräch. Dann komm das Session Description Protocol (SDP) ins Spiel. Das "Sitzungs-Beschreibungs-Protokoll" handelt dann die Gesprächsmodalitäten aus: Sprachcodec, eventuell Video und Übertragungsprotokoll. Letzteres ist für den wirklichen Datenaustausch verantwortlich.

*Quelle: Rolf-Dieter Köhler, weitere Info unter: www.kommunikationsnetze.de unter der Rubrik "Publikationen"

Durchlaufzeit - Delay

Delay bezeichnet die Zeit, die ein Paket benötigt, um das Netzwerk zu durchqueren. Firewalls, Jitter-Buffer, Router und Switches - im Grunde jedes Element im Netzwerk - sorgt dafür, dass diese Verzögerungen immer etwas größer werden. Router Delay beispielsweise ist auch von der Konfiguration abhängig, von Access Listen, Queuing Methoden und Übertragungsarten. Delay hat einen erkennbaren Effekt auf die VoIP-Telefonie, kann aber innerhalb des firmen­eigenen Netzes (LAN und WAN) kontrolliert und beeinflusst werden, im Gegensatz zu einem öffentlichen Netz wie dem Internet. Sprache als Echtzeit-Kommunikation duldet in Netzen nur minimale Verzögerungen (Delay). Die ITU empfiehlt für exzellente Sprachqualität, den Delay der Sprachpakete unter 150 ms zu halten. G.711 hat den niedrigsten Packetization Delay. Die Tabelle zeigt, dass gute Kompression in Abhängigkeit vom Codec nicht nur mit schlechterer Sprachqualität, sondern auch mit erhöhtem Packetization Delay bezahlt werden muss.

Unterbrechnungsfreier Sprachfluss: Jitter Buffer

Jitter ist die durchschnittliche zeitliche Varianz in der Auslieferungszeit von Paketen. Um den Netzwerk-Jitter zu begrenzen, implementieren die Hersteller Jitter Buffer in ihre Endpunkte. Der Sinn des Jitter Buffers ist es, Pakete für eine gewisse Zeit zurückzuhalten, bevor sie dem Entkomprimierungsprozess zugeführt werden. Jitter Buffer sind auch in der Lage, die Pakete zu sortieren, falls sie in der falschen Reihenfolge eintreffen. Je nach der Größe des Jitter Buffers kann durch das Zurückhalten der Pakete Delay entstehen. Der Jitter Buffer sollte möglichst dynamisch angelegt sein.
 


 


Bitte kein Echo...

Echo entsteht durch nicht abgestimmte Impedanzen beim Übergang von der vieradrigen Vermittlungsstelle auf die zweiadrige lokale Schleife, oder wenn ein IP-Gespräch das LAN über eine schlecht administrierte, analoge Amtsleitung verlässt. Normalerweise hört nur der Sprecher sein Echo. Um es zu unterdrücken, setzt man Echo Entferner (Echo Canceler) ein, die die erhaltenen Sprachdaten mit den aktuellen Sprachmustern vergleichen. Sind diese identisch, wird das Echo entfernt.

Analog spricht mit digital: Transcoding

Transcoding nennt man die Konvertierung von Sprachsignalen, zum Beispiel von analog nach digital oder umgekehrt, sei es nun mit oder ohne Kompression. Jede Transcoding Episode führt zu einem Verlust an Sprachqualität. Deutlich hörbar ist es zum Beispiel, wenn ein Anruf über verschiedene Voice-Codecs geroutet wird. Wenn beispielsweise ein Mitarbeiter der Hauptgeschäftsstelle in der Zweigstelle anruft, wo dann eine Anrufweiterieitung zum zentralisierten Voice-Mail-System in der Hauptgeschäftsstelle erfolgt, also verschiedene Transcoding Sequenzen durchlaufen werden, verschlechtert sich die Sprachqualität hörbar. Intelligente Kommunikationsserver sind in der Lage, solche Situationen zu erkennen und - den Anforderungen entsprechend - den Pfad direkt zu setzen (Rerouting). In unserem Beispiel würde das Gespräch von der Hauptgeschäftstelle direkt zum Voice-Mail-System weitergeleitet werden, damit Transcoding-Sequenzen minimiert werden.

Jede Menge Warteschleifen

Weighted Fair Queuing (WFQ) ähnelt dem First-in/First-out Queuing (FiFo), außer dass es kleinen Flows und Paketen mit einem höheren Diffserv-Wert bzw. IP-TOS-Wert bevorzugte Behandlung gewährt. Diese Queuing-Strategie ermöglicht es, kompaktere Protokolle - zum Beispiel Telnet - oder höher priorisierte wie die IP-Telefonie zu bevorzugen. Dennoch werden deshalb natürlich keine Pakete verworfen. Aus diesem Grunde kann es trotzdem bei der IP-Telefonie zu Jitter und Delay kommen, weil beispielsweise auch niedrig priorisierte FTP-Daten irgendwann durch die Queues geschleust werden müssen.
 

Reden ist Bandbreite, schweigen nicht: Silent Suppression / VAD

Voice Activity Detection (VAD) - auch Silent Suppression genannt - ist ein Feature, um Bandbreite einzusparen. Während eines Gespräches spricht oft nur eine Person, so dass während der Übertragung 50% Stille herrscht. Voice Activity Detection überwacht das erhaltene Signal nach Sprachaktivität und verhindert, dass diese Stille übertragen wird. VAD kann auch benutzt werden, um während der Zeit, in der ein Gesprächsteilnehmer nicht spricht, sogenannte „Comfort Noise"- oder „Ambient Noise"-Pakete zu versenden, die durch den erheblich kleineren Payload Bandbreite einsparen. Ohne diese Illusion der konstanten Transmission würde der Gesprächspartner denken, die Leitung wäre tot. Der Haken an VAD ist der Algorithmus, der entdeckt, dass ein Teilnehmer nicht spricht. Wenn der Algorithmus zu aggressiv eingestellt ist, könnte es sein, dass der Anfang eines Wortes abgeschnitten wird. Anderseits verschwendet man viel Bandbreite, falls der Algorithmus nicht scharf genug greift. VAD bzw. Silent Sup-pression ist normalerweise in den IP-End-punkten eingebaut und wurde auch in den Sprachcodec G.729B implementiert.

Prioritäten: TOS Byte

Das Type of Service Feld (TOS) im IP-Paket, enthält drei so genannte Precederice-Bits, die eine Priorität bestimmen, sowie Flags, die generelle Anforderungen an die Güte der Übertragung stellen. Der Differentiated Service Standard, kurz Diffserv, veränderte die Bedeutung des TOS-Feldes und ist heutzutage die gängigere Methode, um Pakete auf Layer 3 zu priorisieren. Das TOS-Feld wird durch den Absender gesetzt und kann von den vermittelnden Komponenten sowie vom Zielsystem genutzt werden, um die Priorität dieses Paketes gegenüber anderen zu ermitteln. Die Precedence-Bits, Bits 0 bis 2, bilden ähnlich wie bei IEEE 802.1p bis zu 8 Prioritätsklassen ab.


Priority, Custom und Class Based Queuing: Gesteuertes Warten

Das Strict Priority Queuing unterteilt den Verkehr in mehrere Warteschlangen, die nach verschiedenen Prioritäten aufgeteilt werden. Dabei wird darauf geachtet, dass die Warteschlangen mit der höchsten Priorität immer vor den Warteschlangen mit niedrigerer Priorität bedient werden. Mit dieser Queuing-Methode kann es aber dazu kommen, dass normale Datenpakete komplett verworfen werden, wenn nur genügend telefoniert wird. Das landläufig als Custom Queuing bezeichnete Round Robin sortiert den IP-Verkehr in Queues, die zuvor konfiguriert werden. Round Robin ist nicht ohne Vorbehalte für die IP-Telefonie geeignet, da es nicht strikt genug Sprachpakete priorisiert. Das Class-Based Weighted Fair Queuing (CB-WFQ) mit Low Latency Queuing (LLQ), welches auch Class Based Queuing genannt wird, kombiniert alle oben genannten Queuing-Methoden.

Resource Reservation

Das Resource Reservation Protocol (RSVP) gehört zur Integrated Services Architecture (RFC 1633), auch IntServ genannt. Hiermit sollen über das Internet oder andere IP-basierende Netze hinweg Ressourcen reserviert werden, um ein „End-to-End"-QoS zu erreichen. Endgeräte stellen Bandbreitenanforderungen an das Netz. Jede Layer 3 Netzwerk-Komponente muss IntServ unterstützen. RSVP ist in zwei Stufen gegliedert (s. Abb. 1).


Abb. 1

Mit den Path-Messages wird ein Pfad zu dem Ziel gesucht. Jeder Router trägt sich als Hop in die Path-Message ein, so dass der Empfänger eine Liste von Routern erhält, über die der Pfad nun rückwärts aufgebaut und Bandbreite reserviert werden soll.

QoS

Quality of Service (QoS) priorisiert die Daten, die mit Class of Service markiert und in verschiedene Klassen eingeteilt wurden.

Überlastungsschutz: Random Early Detection

Wichtige Queue-Management-Techniken sind Random Early Detection (RED) und Weighted Random Early Detection. Sie verwerten Pakete zufällig aus der Queue, bevor es zu einem Engpass kommt. Wenn RED nicht konfiguriert ist, füllen sich die Buffer bei einem Engpass und alle nachfolgenden Pakete werden fallengelassen. Weil alle Pakete zur gleichen Zeit fallengelassen werden, fangen die TCP Hosts an, ihre Transmissionen zu reduzieren. Ist der Engpass überwunden, erhöhen alle TCP Hosts ihre Transmissionen wieder, was erneut einen Engpass verursacht. Dies führt zu Wellen von Engpässen und Perioden, die die Übertragungsverbindung häufig nicht voll ausnutzen und manchmal extrem überlasten. RED ermöglicht es also, die Übertragungsbandbreite besser auszunutzen, indem rechtzeitig vor einer Überlastung Pakete verworfen werden. WRED ermöglicht es, zwischen verschieden priorisierten Daten zu unterscheiden, und dass Standard IP-Pakete häufiger gedropt werden als Premium IP-Pakete. Trotzdem sollte man diese Techniken für Sprachdaten meiden, da Sprachpakete das Real Time-Protokoll verwenden und verlorene Pakete nicht erneut gesendet werden. Eine Implementierung von RED oder WRED kann also durch Paketverluste zu einer Reduzierung der Sprachqualität führen und bedarf einer sorgfältigen Erwägung und Analyse des Netzwerks.

 

 

Paketoptimierung

Einer der großen Verursacher für Delay und Jitter über WAN-Verbindungen ist der sogenannte Serialization Delay. Damit wird diejenige Zeit umschrieben, die benötigt wird, um ein Paket auf eine Leitung zu packen. Für eine optimale Sprachperformance sollte der Serialization Delay nicht mehr als 10 ms betragen. Es kann problematisch werden, wenn ein Sprachpaket auf ein größeres Datenpaket warten muss, welches über eine langsame Strecke soll. Die Lösung besteht darin, größere Datenpakete vor der Übertragung in kleinere Pakete aufzuteilen. So können Sprachpakete zwischen den aufgeteilten Datenpaketen übertragen werden. Für die Fragmentierung gibt es verschiedene Methoden:

   Maximum Transmission Unit (MTU)

   Link Fragmentation und Interleaving (LFI) als Erweiterung zu Multilink PPP (MLP)

   FRF.12, ein Frame Relay Standard für Fragmentierung

   cRTP, eine RTP Header Kompression von Sprachpaketen.

Die Maximum Transmission Unit (MTU) bestimmt die maximale Byte-Größe eines Paketes, das über ein Interface übertragen werden darf. Wenn nun die MTU eines Interfaces heruntergesetzt wird, ist der Router dazu gezwungen, die Pakete auf Layer 3 zu fragmentieren, was jedoch zusätzliche Prozessorzeit an beiden Enden benötigt.

Sprachqualität durch Fragmentierung

Link Fragmentation und Interleaving (LFI) ist eine Erweiterung zu Multilink PPP (MLP) und fragmentiert Pakete auf Layer 2 (PPP). Im Gegensatz zur Fragmentierung auf dem IP-Layer wird bei der Fragmentierung auf Layer 2 nur ein 8 Byte großer PPP-Header erzeugt. Daher ist diese Methode der MTU-Manipulation vorzuziehen, wenn über eine PPP-Verbindung übertragen wird. Pakete sollten dabei so fragmentiert werden (MTU und LFI), dass der Serialization Delay unter 10 ms liegt. Damit wird eine gute Sprachqualität gewährleistet. FRF.12 ist ein Frame Relay Standard für Fragmentierung und arbeitet auf ähnliche Weise wie LFI. Wie auch LFI ist FR.12 effizienter und sollte bei Frame Relay-Verbindungen bevorzugt werden.


 

Die Auswahl der Routing-Protokolle

Weil Sprache andere Anforderungen an das Netz stellt als Daten, sind speziell im WAN geeignete QoS-Mechanismen unverzichtbar, ohne die die Bandbreite radikal reduziert würde. Aber auch Routing-Protokolle müssen sorgfältig überdacht und ausgewählt werden, da auch sie verschiedene Konvergenz-Zeiten haben. Denn während einer Phase, in der ein Protokoll beispielsweise einen Fehler entdeckt und eine andere Route sucht, können keine Gespräche stattfinden. Die Auswahl der Protokolle hängt vom Routing ab. Wenn ein Netz nur einen einzigen Pfad zu anderen Netzwerken hat, sind statische Routen ausreichend. Wenn aber mehrere Pfade existieren und Konvergenz-Zeiten bedeutsam werden, sollte man zwischen EiGRP (Cisco) oder OSPF wählen.

Load- oder Flow-Balancing

Viele Routing-Protokolle - zum Beispiel OSPF - installieren mehrere Routen für ein bestimmtes Ziel in eine Routing-Tabelle. Einige Router versuchen auch ein Load-Balancing zwischen zwei Pfaden. Es gibt dafür zwei Methoden. Die erste ist Per-Packet Load BaSancing, wobei Pakete nach Round Robin Manier zwischen den beiden Routen bedient werden. Die zweite Methode ist Per-Flow Load Balancing, wobei alle Pakete, die zusammengehören, in einem Flow den gleichen Pfad nehmen. (Quell-, Zieladresse und Ports gleichen sich), Per-Packet Load Balancing kann zu abgehackter Sprachqualität führen, weshalb Per-Flow Load Balancing bevorzugt werden sollte.


Verschlüsselung über Virtual Private Network

VPN bezieht sich auf verschlüsselte Tunnel zwischen Remote Standorten und kann private Standleitungen oder das Internet über ein oder mehrere Internet Service Provider nutzen. Der Verschlüsselungsprozess kann von einer Millisekunde bis zu einer Sekunde oder mehr betragen, was in vielen Fällen für Sprachdaten nicht akzeptabel ist. VPN wird besonders für Verbindungen über das Internet benutzt, wo man kaum Möglichkeiten hat, QoS-Parameter zu kontrollieren. Eventuell können einige Firmen mit ihren Service-Providern einen Service-Level Vertrag abschließen, um einen akzeptablen Service-Level zu erhalten. Einige Hersteller bieten zudem die Möglichkeit an, dass Sprachdaten schon an den Endpunkten verschlüsselt werden. So können sie verschlüsselt über eine separate Standleitung übertragen werden. In allen Fällen ist eine genaue Planung und regelmäßige Überprüfung notwendig (s. Abb. 2).

Abb. 2


 

Testgeräte für VolP

Beim zunehmenden Einsatz von IP-Telefonen ist ein Testgerät, welches inline zwischen das IP-Telefon (oder PC) und das Netzwerk angeschlossen wird; sehr hilfreich. Eine Inline-Funktionalität, wie beispielsweise beim Nettool von Fluke Networks, erfordert, dass die PoE Funktionalität berücksichtig wird. Ein Inline-Tester muss die Energie für das Endgerät mit übertragen (durchschleifen), da ansonsten keine Netzwerkverbindung aufgebaut werden kann. Für die VolP Applikation ist es wichtig, den gesamten „Gesprächsverlauf" zu diagnostizieren. Ein VolP Log sollte folgende Informationen enthalten: Call-Controll-Events, QoS Konfiguration, Parameter der Anrufqualität, Anruf-Aufbau und Konfiguration, Anrufsunterbrechungen (Abbruch). Für die Gesprächsdurchführung sollten die RTP-Konfiguration inkl. IP-Adresse, Port und VLAN gezeigt werden. Ein Monitor für Jitter und verlorene Pakete ist unerlässlich. Der Tester sollte diese Funktionen beinhalten, jedoch einfach in der Bedingung sein. Da VolP eine End 2 End Applikation ist, sollte sich auch die Messung auf beide Enden der Kommunikation konzentrieren.

Address Translation

IP-Telefonie arbeitet nicht sehr gut über Network Address Translation (NAT). Viele NAT-Implementationen unterstützen das H.323-Protokoll nicht. Die Zieladresse bei Sprachpaketen wird in mehr als einem Header verkapselt, zum Beispiel in Q.931, H.225 und den lP-Headern. NAT verändert aber nur die Adresse in den IP-Headern, was die Kontrolle der Anrufe verhindert. Wenn keine Q.931-freundliche NAT-Implementationen vorhanden sind, muss das Netzwerk neu geplant werden, so dass Sprachdaten NAT umgehen können.

Broadcast Domänen

IP-Telefonie reagiert sehr sensibel auf Delay und Jitter, des­halb sollte grundsätzlich der Broadcast-Traffic im Netzwerk minimiert werden. Hubs sollten durch Switches ausgetauscht wer­den. Empfehlenswert ist es, auch für die IP-Telefonie ein eigenes VLAN oder Subnetz zu verwenden. Diese Trennung sorgt für ein sauberes Design, ist hilfreich für Troubleshooting und schützt Sprachdaten vor Broadcasts von anderen Netzen. Durch VLAN Tagging können Sprachdaten klassifiziert und entsprechend priorisiert werden.

 
 

Fehler durch Messungen beheben

Netzwerkverantwortliche und Administratoren werden heute mit neuen Anforderungen bei der Fehlersuche konfrontiert. Anders als bei dem Standard-Telefon können Fehler bei VoIP-Telefonen vielschichtige Ursachen haben. Kabel, Netzwerkverbindung, IP- und VLAN- Konfiguration, PoE und VoIP-Protokoll sind Punkte, die nun getestet werden müssen. Das Kabel muss frei von Kurzschlüssen, Split Pairs und Unterbrechungen sein. Eine funktionierende Netzwerkverbindung ist Grundlage jedes VoIP Links. Dabei ist die ausgehandelte Geschwindigkeit (10/100MBit/s) und die Übertragungseigenschaft Half-/Full-Duplex die erste wichtige Information. Jedoch können auch Auslastung, Broadcast, Fehler- und Collisions-Rate die Verbindung maßgeblich beeinflussen.