vasquez.service.akademie.voip |
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 Komprimierungsverfahren: 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.
SIP - das Protokoll *
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 firmeneigenen 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.
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.
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).
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.
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, deshalb sollte grundsätzlich der Broadcast-Traffic im Netzwerk minimiert werden. Hubs sollten durch Switches ausgetauscht werden. 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.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||