Der Begriff Voice over IP (VoIP) subsummiert eine ganze Reihe von Verfahren zur Echtzeitübertragung von Sprache über IP-basierte Netze. Dazu zählen sowohl firmeninterne Anwendungen (Enterprise-Telefonie) als auch die IP-Telefonie im öffentlichen Internet (Internet-Telefonie). Insgesamt lässt sich VoIP jedoch nur als Teil einer Gesamtentwicklung von getrennten Daten- und Telefonie-Netzen hin zu einer einheitlichen Netzstruktur verstehen. Das Zusammenfließen der Technologien für den Transport von Sprache, Multimedia und Daten umschreibt man mit dem Ausdruck "converging networks" oder kurz Konvergenz.
Im ersten Teil unseres Artikels haben wir die herkömmlichen Transportverfahren in sprachbasierten Netzen kennen gelernt, mit denen VoIP sich stellen muss. Daneben kamen auch die technischen Rahmenparameter zur Sprache, die Telefonie-Anwendungen qualitativ kennzeichnen. Im vorliegenden zweiten Teil unseres Backgrounders beschäftigen wir uns mit den Kodierungsverfahren, die der Sprachkommunikation zu Grunde liegen und ihre subjektive Qualität entscheidend beeinflussen. Davon ausgehend beschreiben wir die Transportprotokolle und Steuerungsverfahren in VoIP-Netzen sowie deren konkreter Implementation im LAN.
Sprachkodierung
Die Transmission von Sprache über digitale Netzwerke erfordert die Umwandlung der zeit- und wertekontinuierlichen analogen Sprachsignale in zeit- und wertediskrete digitale Signale. Während Art und Parameter der Umsetzung bei herkömmlichen Telefonnetzen fest definiert sind, kann der Anwender sie bei paketvermittelnden Netzen frei wählen.
Dies setzt ein grundlegendes Verständnis der Verfahren voraus, da die Auswahl in erheblichem Maß die benötigte Bandbreite sowie die erreichbare Sprachqualität beeinflusst. Grundsätzlich unterscheidet man hier zwischen Signalformkodierung (PCM und ADPCM) und Vocoder-Verfahren (wie etwa CELP). Erstere signalisieren den zeitlichen Verlauf der Sprache im vorgegebenen Frequenz- und Amplitudenbereich, letztere kodieren und rekonstruieren auf Basis eines Sprachmodells.
PCM
Die Pulse Code Modulation stellt das gegenwärtig am weitesten verbreitete Verfahren zur Analog/Digital-Wandlung von Sprachsignalen dar. Sie umfasst die Abtastung, Quantisierung und Kodierung der Signale.
Die ITU-T-Empfehlung G.711 definiert für den Einsatz von PCM zur Sprachkodierung folgende Merkmale:
Bandbegrenzung der Sprachsignale auf 300 Hz bis 3,4 kHz
eine nichtlineare Quantisierung nach der A- oder der µ-Law-Kennlinie. Die Verwendung einer nichtlinearen Quantisierungskurve verringert das sogenannte Quantisierungsrauschen, da sie im Vergleich zu einer linearen Quantisierungskurve den relativen Fehler bei kleinen Abtastwerten reduziert
Abtastfrequenz 8 kHz
8-Bit-Kodierung der Abtastwerte
Aus den letzten beiden Punkten ergibt sich eine Bitrate von 64 kbit/s.
ADPCM
Das Kürzel ADPCM steht für Adaptive Differential Pulse Code Modulation. Gegenüber herkömmlicher PCM unterscheidet sich das Verfahren durch zwei Erweiterungen.
Zum einen verändert sich in der Regel das Sprachsignal von Abtastwert zu Abtastwert nur allmählich. Dies nutzt das differenzielle PCM-Verfahren aus, indem sowohl Sender als auch Empfänger einen Prädikator aufweisen, der den nächsten Wert anhand bestimmter Regeln schätzt. Statt der tatsächlichen Abtastwerte wird nun lediglich die Amplitudendifferenz von abgetastetem und geschätztem Wert gespeichert. Da diese Differenz kleiner ausfällt als der eigentliche Abtastwert, reduziert sich auf diese Weise der Bandbreitenbedarf.
Zum anderen passt das adaptive Verfahren die Schrittgrößen des Quantisierers auf Basis der vorangegangenen Abtastwerte an. Auf diese Weise lässt sich ohne gravierenden Qualitätsverlust die Abtastrate senken.
LPC-Verfahren
Sprachkodierverfahren arbeiten mit speziellen, für die Umsetzung von Sprache optimierten Codecs. Diese basieren in der Regel auf Linear-Predictive-Coding-Verfahren (LPC), die den menschlichen Sprachkanal als ein System von Röhren mit unterschiedlichen Durchmessern modellieren.
In diesen werden die akustische Wellen von den Stimmbändern stimmhaft oder stimmlos generiert. Beim Durchlaufen durch das System kommt es an Übergängen von Röhren unterschiedlichen Durchmessers zu Reflexionen und Interferenzen. Die jeweilige Reflektionsrate repräsentieren dabei die Reflektionskoeffizienten refl[0], ..., refl[p-1]. Auf diesem Weg lässt sich mit einer relativ kleinen Zahl von Parametern die sprecherabhängige Erzeugung des Sprachklangs beschreiben.
Zur Analyse wird das Audio-Signal in kleine Rahmen s[i] fester Dauer (typischerweise 20 bis 30 ms) zerlegt. Für jeden Rahmen s[i] berechnet das Verfahren p Gewichte lpc[0], .. , lpc[p-1] so, dass s[i] sich möglichst gut durch die Formel
lpc[0] * s[i-1] + lpc[1] * s[i-2] + ... + lpc[p-1] * s[i-p]
annähern lässt. Übliche Werte für p sind 8 oder 14.
Als Eingabe des Modells dient ein synthetisch generiertes Quellsignal, das sich zwischen den Zuständen "stimmhaft" (Sinus-Schwingung) und "stimmlos" (Rauschen) umgeschalten lässt. Nun ermittelt das Verfahren die Unterschiede zwischen dem generierten und dem tatsächlichen Sprachsignal. Daraus errechnet es die anzuwendenden Prädiktionskoeffizienten lpc[i]. Für jeden Rahmen werden dann die Art der Anregung (stimmhaft oder stimmlos) sowie die aktuellen Parameterwerte lpc[i] kodiert und übertragen.
CELP und MP-MLQ
Im Vergleich zu den einfachen LPC-Verfahren unterscheidet Code Excited Linear Prediction (CELP) neben den Zuständen "stimmhaft" und "stimmlos" auch dazwischen angeordnete Arten der Anregung. Diese bestimmt ein Analysator mittels Vektorquantisierung des minimierten Vorhersagefehlers und hinterlegt sie im sogenannten Codebook.
Für jeden Rahmen kodiert und überträgt CELP dann den Codebook-Index sowie die lpc-Parameter. Man bezeichnet diese Vorgehensweise auch als Analysis-by-Synthesis, wobei das rekonstruierte Signal weitgehend dem Ursprungssignal gleicht. Algebraische CELP-Varianten (ACELP) ergänzen das Verfahren um erweiterten Kompressionsmethoden zur Bandbreitenreduzierung.
Mit einer gegenüber ACELP verbesserten Quantisierung arbeitet die Multipulse Maximum Likelihood Quantization, kurz MP-MLQ. Anstelle einer einzigen Basisfrequenz erstellt MP-MLQ einen Satz von Impulsen, die den ursprünglichen Frequenzinhalt der Sprachanregung deutlich besser nachbilden.
Vergleich der Verfahren
Eine verbreitete subjektive Messgröße zur Bewertung der Sprach-Codec-Qualität ist der mittlere Meinungswert (Mean Opinion Score - MOS). MOS-Tests werden jeweils bei einer Gruppe von Zuhörern durchgeführt, die Sprach- und Klangqualität auf Grund ihrer subjektiven Empfindungen mit Noten von 1 (schlecht) bis exzellent (5) bewerten müssen. Daneben finden auch rechnergestützte Analyseverfahren Einsatz.
Die untenstehende Tabelle zeigt den MOS für verschiedene ITU-standardisierte Telefonieverfahren. Es lässt sich klar ersehen, dass ausgefeilte LPC-Verfahren den Bandbreitenbedarf deutlich reduzieren, ohne einen subjektive Qualitätsverlust zu verursachen. So erreicht ein algebraisches CELP-Verfahren (Conjugate Structure ACELP) nahezu den gleichen Akzeptanzwert beim Benutzer wie PCM. Dabei reduziert es jedoch die Transferrate auf ein Achtel.
ITU-T-Standard | Kodierung | Datenrate (kbit/s) | Aufnahmedauer (ms) | MOS |
|---|---|---|---|---|
(Quelle: Davidson, Peters) | ||||
G.711 | PCM | 64 | 0,125 | 4,10 |
G.726 | ADPCM | 16 | 0,125 | 3,85 |
G.728 | LD-CELP | 16 | 0,625 | 3,61 |
G.729 | CS-ACELP | 8 | 10 | 3,92 |
G.732.1 | CELP | 5,3 | 30 | 3,65 |
G.732.1 | MP-MLQ | 6,3 | 30 | 3,9 |
Transportprotokolle
Den Eckpfeiler für die Übertragung von Echtzeitverkehr über IP-Netzwerke bildet derzeit das Real Time Transport Protocol (RTP). Es wurde bereits im November 1996 als RFC 1889 der IETF vorgeschlagen. Auf RTP basieren Produkte wie LiveMedia von Netscape oder NetMeeting von Microsoft, aber auch komplette Anwendungsprotokolle wie H.323 und SIP.
Zum Transport der auftretenden Paketflüsse ("RTP-Ströme") greift das Protokoll auf das unzuverlässige, verbindungslose UDP zurück. Hier steht die schnelle und effiziente Übertragung der Daten im Vordergrund. Gehen UDP-Daten im Netz verloren, werden sie nicht - wie beim verbindungsorientierten TCP - erneut angefordert, da dies eine zu große Verzögerungszeit zur Folge hätte.
RTP
Die untenstehende Abbildung zeigt den RTP-Header in Kombination mit den ebenfalls benötigten Kopfdaten der darunter liegenden Protokolle UDP und IP.
Die Bedeutung der einzelnen Datenfelder im RTP-Header entnehmen Sie bitte der folgenden Tabelle.
Bits | Bezeichnung | Bedeutung | |
|---|---|---|---|
| |||
V | 2 | version | RTP-Versionsnummer |
P | 1 | padding | Gibt an, ob der Frame mit Padding-Bytes aufgefüllt werden soll. |
X | 1 | extension | Gibt an, ob eine Header-Erweiterung vorliegt |
CC | 4 | CSRC count | Anzahl der CSRC-Identifier |
M | 1 | marker | Markiert ein bestimmtes Profil |
PT | 7 | payload type | Legt das Format des RTP-Pakets fest und ordnet es einer Anwendung zu |
SN | 16 | sequence number | Dient der Sortierung der empfangenen Pakete |
- | 32 | timestamp | Absendezeit (in Relation zum RTP-Strom) |
SSRC | 32 | Sync source | Zufallszahl zur Unterscheidung von verschiedenen RTP-Quellen |
CSRC | 32 | contributing source | Identifikation der beitragenden Quelle (nur bei gemischten RTP-Strömen) |
Zur Transportsteuerung nutzt RTP das RTP Control Protocol (RTCP, RFC 1889). Es basiert auf der periodischen Übertragung von Steuerpaketen an alle Teilnehmer einer Session. Via RTCP erhält der Sender Feedback zu den Eigenschaften des Transportkanals, wie etwa über Paketlaufzeiten, Jitter oder Paketverluste.
Verbesserte Varianten
Die Headerdaten für IP, UDP sowie RTP-Header belegen 20, 8 und 12 Bytes. Der resultierende 40 Byte lange Datenkopf bedeutet für gewisse Applikationen - etwa bei der Übertragung von zwei G.729-Sprachaufnahmen mit insgesamt 20 Byte - einen gewaltigen Overhead. Für solche Anwendungen reduziert man den Header auf eine Länge von 2 oder 4 Byte (cRTP - Compressed RTP). Hierzu kombiniert der Sender IP-Quell- und Zieladresse, UDP-Quell- und Zielport sowie das SSRC-Feld zu einer Session Context ID (CID). Anhand der CID können die beteiligten Vermittlungsknoten und Empfänger die Pakete korrekt zuordnen.
Das Reliable User Datagram Protocol (RUDP) macht das verbindungslose UDP-Protokoll etwas zuverlässiger. Dabei bleiben die wesentlichen Eigenschaften des verbindungslosen und unzuverlässigen UDP zwar erhalten. Allerdings versieht RUDP die Pakete mit redundanter Information und versendet sie mehrfach. Auf diese Weise sinkt die Wahrscheinlichkeit von unerkannten Übertragungsfehlern oder nicht übertragenen Paketen. Als bekanntestes Verfahren setzt Q.931-over-IP Reliable UDP zur Übertragung ein.
Gesprächssteuerung
Wie bei der leitungsorientierten Sprachtelephonie transportieren auch paketorientierte Verfahren Signalisierung und Nutzdaten getrennt. In der Welt der Datenkommunikation bezeichnet man die Signalisierung auch als Gesprächssteuerung (Call Control), die Nutzsignale dagegen als Träger oder Bearer. Beide laufen auf getrennten Kanälen über das gleiche IP-Netz. Von den zahlreichen mittlerweile entwickelten VoIP-Call-Control-Protokollen kommt zweien eine besondere Bedeutung zu:
Die ITU-T-Empfehlung H.323 beschreibt die Übertragung von Multimediaverkehr über paketvermittelnde Netzwerke. Bereits seit 1996 definiert, handelt es sich bei H.323 um das älteste und konsequenterweise am weitesten verbreitete Protokoll zur Gesprächssteuerung. Die aktuelle Implementation ist H.323 Version 4 vom November 2000.
Das Session Initiation Protocol (SIP) wurde 1999 von der IETF vorgestellt. Das medienbasierte Protokoll soll Endgeräten mehr Intelligenz verleihen und damit weitergehende Dienste ermöglichen.
H.323
Der H.323-Standard der ITU-T fasst eine ganze Reihe von Komponenten und Protokollen zu einer Infrastruktur zusammen. Die folgende Tabelle bietet eine entsprechende Übersicht:
Feature | Protokoll |
|---|---|
| |
Anrufsignalisierung | H.225 |
Medienkontrolle | H.245 |
Audio-Codecs | G.711, G.722, G.723, G.728, G.729 |
Video-Codecs | H.261, H.263 |
Daten-Sharing | T.120 |
Transportprotokoll | RTP / RTCP |
Wie das obige Bild verdeutlicht, setzt H.323 für den schnellen Datentransport auf UDP, während die Signalisierung weitgehend über das verbindungsorientierte und damit zuverlässigere TCP erfolgt.
H.323-Elemente
Die Endgeräte eines H.323-basierten Netzes werden als Terminals bezeichnet. Sie müssen folgende Elemente besitzen:
eine System-Steuer-Einheit, die die Anruf-Steuerung nach H.225 und H.245 sowie weitere Signalisierungsaufgaben übernimmt,
eine Medien-Übertragung, die die Datenströme formatiert,
einen Audio-Codec, der das zu übertragende Signal kodiert und das empfangene Signal dekodiert,
sowie eine paketbasierte Netzwerkschnittstelle zur Unterstützung von TCP oder UDP.
Darüber hinaus kann des H.323-Terminal einen Video-Codec sowie weitere Elemente zur Unterstützung zusätzlicher Applikationen (wie Konferenzen) umfassen.
H.323-Gateways übernehmen die Anbindung an leitungsvermittelnde Netze. Sie besitzt gleichzeitig die Eigenschaften eines leitungs- und eines paketvermittelnden Endgerätes. Ein optionale H.323-Gatekeeper bietet den H.323-Terminals zusätzliche Dienste, wie z.B. Adressübersetzung, Zugangskontrolle, Bandbreitenmanagement und Zonenmanagement. Multipoint Controller Units (MCU) schließlich unterstützten Konferenzen zwischen drei oder mehr Endpunkten. Sie können auch in ein Terminal, ein Gateway oder einen Gatekeeper integriert sein.
H.323-Kommunikation
Der Gesprächsaufbau von zwei Teilnehmern TE-A und TE-B unter Verwendung einer VoIP-Applikation setzt folgende Punkte voraus:
Beide Teilnehmer haben ihre Telefonie-Applikation bereits gestartet.
Beide Endpunkte haben sich beim zugehörigen Gatekeeper registriert.
Die Anrufsignalisierung wird durch den gemeinsamen Gatekeeper geroutet.
Sind diese Präliminarien abgeschlossen, lauft der Verbindungsaufbau in vier Schritten ab:
TE-A sendet gemäß H.225 eine SETUP-Meldung an die IP-Adresse von TE-B. Ist statt der IP-Adresse nur der Domain-Name bekannt, wird zunächst eine Anfrage an einen DNS-Server gestellt.
TE-B beantwortet die SETUP-Meldung mit einem ALERT und einer Portnummer, um eine H.245-Verhandlung zu beginnen. Gleichzeitig signalisiert die VoIP-Applikation auf TE-B, dass ein Gesprächswunsch gemeldet wurde. Es "klingelt".
Nun verhandeln beide Stationen die Übertragungsparameter. Dazu zählen insbesondere die Art der Sprachkodierung und die Portnummern für die RTP-Ströme.
Zu guter Letzt werden logische RTP-Kanäle in beide Richtungen geöffnet, die Übertragung beginnt.
SIP
Das im Rahmen der Multiparty Multimedia Session Control (MMUSIC) erarbeitete und im März 1999 als RFC 2543 dem IETF vorgeschlagene Session Initiation Protocol (SIP) ist ein textbasiertes Protokoll auf der Anwendungsebene (Layer 7). Es beschreibt den Aufbau, die Veränderung und den Abbau von Multimedia-Verbindungen. Die Teilnehmer an einer Sitzung (Session) kommunizieren dabei über Multicast-Nachrichten oder durch verbundene Unicast-Nachrichten miteinander.
SIP operiert unabhängig von den darunter liegenden Protokollen der niedrigeren Ebenen. Es kann also sowohl auf TCP als auch auf RTP/UDP aufsetzen. Mit dem nachrichtenorientierte Stream Control Transmission Protocol (SCTP, RFC 2960) steht zudem ein eigenes Transportprotokoll zur Verfügung.
Zu den Stärken des Protokolls zählt nicht zuletzt, dass es über ein Gateway mit H.323 zusammenarbeiten kann. Darüber hinaus bietet SIP eine offene und erweiterbare Struktur. So lassen sich etwa die SIP-Meldungs-Header anwendungsspezifisch gestalten und gegebenenfalls bei IANA anmelden.
SIP-Verbindungsaufbau
Ein SIP-basierter Telefonie-Server operiert üblicherweise im Proxy-Modus. Dabei integriert er sowohl Client- als auch Server-Funktionen. Auf diese Weise dient er beiden Kommunikationspartner sozusagen als Stellvertreter der jeweiligen Gegenstelle. Ein Verbindungsaufbau läuft folgendermaßen ab:
Der Proxy-Server akzeptiert die INVITE-Anfrage eines Teilnehmers A (beispielsweise cz@cs-tu-berlin.de), der mit Teilnehmer B (etwa henning@cs.columbia.edu) telefonieren möchte.
Der Proxy-Server stellt zwecks Adressauflösung eine Anfrage an einen Location Service. RFC 2543 sieht hier mehrere Möglichkeiten zur Verwaltung der Adressinformationen vor.
Der Location Service gibt die benötigten Adressinformationen zurück.
Der Proxy-Server stellt nun eine INVITE-Anfrage an den (oder gegebenenfalls die) Adressaten.
Teilnehmer B signalisiert dem Benutzer die ankommende Anfrage: Es "klingelt".
Teilnehmer B teilt dem Proxy-Server mit, dass die Verbindung aufgebaut werden kann (SIP-Message 200 - OK).
Der Proxy-Server leitet diese Nachricht an Teilnehmer A weiter
Teilnehmer A sendet eine ACK-Anfrage an den Proxy-Server.
Der Proxy-Server leitet diese ACK-Anfrage wiederum an Teilnehmer B weiter.
Der Proxy-Server wirkt hier gleichsam als Mediator zwischen den Kommunikationspartnern. Bei einem Redirect-Server verläuft der Verkehr statt dessen unmittelbar zwischen den Gegenstellen, der Server dient quasi nur als Relais.
MGCP und MEGACO
Das 1998 entwickelte Simple Gateway Control Protocol (SGCP) soll die Kosten für jene Endgeräte verringern, die in der VoIP-Terminologie als Gateways bezeichnet werden. Dazu verlagert es die intelligente Gesprächssteuerung auf eine zentralen Plattform im Netz.
Das Internet-Protocol-Device-Control-Protokoll (IPDC) ähnelt dem SGCP weitgehend, stellt aber zusätzliche Mechanismen für Betrieb, Administration, Management und Bereitstellung (Operation, Administration, Management & Provisioning - OAM&P) zur Verfügung.
Beide Protokolle verknüpfte die IETF 1998 zum Media Gateway Control Protocol (MGCP, RFC 2705/2805). Im August 2000 verabschiedeten IETF und ITU-T gemeinsam das sogenannte MEGACO-Protokoll (RFC 2885 / H.248), den Nachfolger von MGCP.
Einstellungen im Netzwerk
Die im ersten Teil unseres VoIP-Backgrounders für die Telefonie geforderten Qualitätseigenschaften lassen sich nur dann erreichen, wenn im Netzwerk entsprechend angepasste Übertragungseinstellungen vorliegen. Diese lassen sich in einem kleinen LAN wesentlich einfacher treffen und überwachen, als in einer weitschweifigen Infrastruktur mit verschiedenen Teilnetzen.
Im folgenden stellen wir eine Reihe von Parametern und Funktionen vor, mit denen sich die Übertragungsqualität beeinflussen lässt. Einige davon lassen sich fest implementieren. Die Einsatzmöglichkeit und Wirksamkeit vieler anderer hängt jedoch von der konkreten Auslastung des Netzwerks ab. Hier hilft nur die Taktik des "best effort" weiter, eine definierte Übertragungsqualität kann nicht für jeden Betriebsfall garantiert werden.
Queuing
Mit Hilfe von Queueing-Regeln lassen sich wichtige Anwendungen bei der Zuordnung auf die FIFO-Ausgangswarteschlangen priorisieren. Dazu stehen verschiedene Verfahren zur Auswahl.
Weighted Fair Queuing (WFQ) verwendet den Fast-Switching-Pfad des Cisco IOS. Es verteilt die freie Bandbreite dynamisch auf Datenflüsse, die es anhand von Quell- und Zieladressen, Protokolltyp, Socket- oder Portnummern und CoS/ToS-Werten identifiziert. Die Gewichtung erfolgt derzeit in Abhängigkeit Parametern wie IP-Precedence, RSVP, IP-RTP-Priorität und -Reservierung sowie Forward respektive Backward Explicit Congestion Notification (FECN/BECN) bei der Verwendung von Frame Relay.
Per Custom Queuing (CQ) kann ein bestimmter Anteil der verfügbaren Bandbreite einem bestimmten Protokoll zugewiesen werden. Auf diese Weise erreicht man zwar eine gute Kontrolle der Verkehrsströme, jedoch geht dies zu Lasten einer vergleichsweise aufwändigen manuellen Verwaltung.
Das Priority Queuing (PQ) weist den eingehenden Verkehr vier Ausgabe-Queues mit unterschiedlichen Prioritäten zu. Dabei wird der Verkehr in einer Queue vorrangig bedient, bis der Puffer leer ist. Laufzeitkritische Pakete transportiert PQ also sehr schnell, die Verzögerungszeiten niedrig priorisierter Daten können sich jedoch wesentlich erhöhen.
IP-ToS
Der Header von IPv4-Paketen umfasst ein Feld namens Type of Service (ToS), das zur Priorisierung der Pakete dienen kann. Dabei sind allerdings einige Einschränkungen zu berücksichtigen. So ignorieren beispielsweise viele IPv4-Netzknoten den ToS vollständig - QoS muss aber Ende-zu-Ende gewährleistet sein.
Daneben erlaubt das ToS-Feld nur sechs verschiedene Prioritätsstufen für Netzwerkverkehr auf der Anwendungsebene: Die beiden höchsten Stufen (6 und 7) bleiben für Netzwerkinformation reserviert.
Last not least belegt inital die Applikation auf dem Endgerät das ToS-Feld. Dessen Einstellung entzieht sich damit zunächst dem Einfluss des Netzwerkadministrators. Zwar besteht zwar die Möglichkeit, die Felder auf Grund von bestimmten Regeln neu zu bewerten. Eine solche Policy-basierte Regelung wäre aber eigentlich auch ohne ToS möglich.
Erst IPv6 erlaubt eine genauere Einstellung der Priorität mit Hilfe eines 8 Bit langen Feldes, sowie die Aufnahme von speziellen Steuerinformation durch einen Extension Header. Während die Nutzung von IPv6 in geschlossenen Umgebungen durchaus schon in naher Zukunft realistisch erscheint, dürfte die lückenlose Unterstützung über das Internet noch beträchtliche Zeit auf sich warten lassen.
RSVP
Über das von Cisco entwickelte und als RFC 2205 standardisierte Resource Reservation Protocol (RSVP) können Applikationen dem Netzwerk signalisieren, welche Art von QoS sie benötigen. RSVP arbeitet als Ende-zu-Ende-Signalisierungsprotokoll, das bei jedem RSVP-fähigen Netzknoten eine bestimmte Bandbreite und Latenz anfordert. Die Applikationen enthalten dann eine Rückmeldung, ob die nachgefragte QoS akzeptiert oder abgelehnt wurde.
RSVP stellt einen Paradigmenwechsel innerhalb der IP-Architektur dar. IP operiert als verbindungsloses Protokoll, RSVP dagegen arbeitet bis zu einem gewissen Grad verbindungsorientiert: Vor der Übertragung der eigentlichen Nutzdaten nimmt es eine Ende-zu-Ende-Signalisierung vor. Dies lässt sich durchaus mit einem Verbindungsaufbau beispielsweise unter ATM vergleichen.
Einige grundlegende Einschränkungen kann auch RSVP nicht umgehen:
RSVP macht nur dann Sinn, wenn allen beteiligten Router eines Pfades es unterstützen. Bei verschalteten Netzwerken kann man gerade dies aber nicht grundsätzlich garantieren.
RSVP skaliert nicht. Die Reservierung tausender RSVP-Pfade in einem globalen Netz erscheint kaum attraktiv.
RSVP ist kein Routing-Protokoll. Es kann also nicht IP-Routing-Tabellen auf der Basis von Verkehrsflüssen modifizieren oder Datenstaus umgehen. RSVP bleibt an die vom IP-Routing identifizierte Pfade gebunden.
Produkte
Mittlerweile stehen eine Vielzahl von VoIP-Endgeräten zur Auswahl. Meist stellen sie einen Tribut an die Gewohnheiten der Benutzer dar, die weiterhin über ein "Telefon" telefonieren und an einem Rechner arbeiten wollen.
Design und Bedienung der IP-Terminals orientieren sich daher weitgehend an Telefonapparaten. Dies stellt andererseits die Produktentwickler vor knifflige Probleme, was die Benutzerschnittstellen zur Bedienung komplexer Mehrwertdienste angeht.
Bei den VoIP-Geräten zeigt sich zunehmend die Konvergenz von PC- und Embedded-Systemen - Schlagwort: Appliances. So finden neben Mainstream- Betriebssystemen zunehmend auch dezidierte Embedded-OS wie Windows CE oder VxWorks Eingang in VoIP-Endgeräte.
Interessant ist in diesem Zusammenhang auch die Einbindung von Wireless-Technologien. Während die meisten WPAN-Protokolle dezidierte leitungsorientierte Sprachkanäle mitbringen, ist dies bei den WLAN-Technologien und speziell dem Platzhirsch IEEE 802.11b nicht der Fall.
Integrierte Systeme
Aus technischer Sicht erscheint die künstliche Trennung der Telefonie- und Netzwerk-Endgeräte wenig erstrebenswert. Gegen das unmittelbare Telefonieren über Desktop, Notebook oder Embedded Computer spricht gegenwärtig nur die Boot-Zeit und bis zu einem gewissen Grad auch die Ausfallsicherheit.
Die Integration von Telefonie-Anwendungen in den Rechner setzt - neben der entsprechenden Hardware, wie Netzwerk- und Soundkarte, die aber bei den meisten Rechnern ohnehin vorhanden sind - vor allem die benötigte Software voraus.
Bei diesen Software-Clients bewahrheitet sich bereits heute die Aussage "Das Telefon der Zukunft ist eine CD". Microsoft setzt in seinem Server-Betriebssystem auf das seit längerem eingeführte Telephone Application Programming Interface (TAPI), das mittlerweile in der Version 3.0 vorliegt.
Call-Center-Lösungen
Call Center erfreuen sich einer steigenden Verbreitung und stellen genau die Rahmenanforderungen, die gerade VoIP in besonderer Weise erfüllen kann:
Die Sprachdaten werden in einem meist relativ überschaubaren lokalen Netzwerk (LAN) transportiert.
Es handelt sich im Moment noch in vielen Fällen um komplette Neuinstallationen.
Es besteht ein besonderer Bedarf an Mehrwertdiensten, insbesondere nach leistungsfähiger Rufweiterleitung und der Ankopplung an datenbankgestützte Informationssysteme.
Entsprechend finden VoIP-Lösungen in diesem Bereich bereits weite Verbreitung.
Gateways und Router
Kommt unternehmensintern VoIP zum Einsatz, nach außen aber weiterhin das leitungsvermittelnde TK-Netz, dann spielt die Kopplung eine zentrale Rolle. Hierfür stehen zahlreiche Gateway-Produkte der großen Hersteller zur Verfügung.
Darüber hinaus müssen bei Bedarf aber auch die verschiedenen Übertragungs- und Anwendungsprotokolle gekoppelt werden, so dass sich in diesem Bereich eine große Vielfalt ergibt.
Schließlich müssen die Netzwerke den Transport der Sprachdaten mit der geforderten QoS leisten. Hier sind insbesondere die Vermittlungsknoten der IP-Ebene (Router) gefordert.
Fazit
Voice over IP bildet nur einen Lösungsbaustein für die konvergierenden Multimedia-Netzwerke der Zukunft. Das lässt sich schon an den Gateway-Lösungen ersehen, die die Industrie heute anbietet: Bei der Mehrzahl handelt es sich um sogenannte Media Gateways, die Daten, Sprache und Video auf einer Leitung zusammenfassen.
Im Moment beschränken sich die Einsatzmöglichkeiten solcher Gateways zwar auf lokale Netze oder die Anbindung von Remote Offices ans Mutterhaus. Spätestens mit der flächendeckenden Implementation von IPv6 dürfte die durchgängige Implementation konvergenter Netze inklusive VoIP zur üblichen Praxis werden. (jlu)
Weiterführende Literatur
Davidson, J., Peters, J.: Voice over IP - Konzepte, Technologien, Anwendungen; Markt+Technik Verlag 2000; ISBN 3-8272-5800-6
Foth, E.: Handbuch IP-Telefonie; Fossil Edition Netze 2001; ISBN 3-931959-33-3