IT CONSULTING WOLFINGER

Professional Training and Coaching

Announcements and Offers

Use our Forum

Issues with IT, Routing, Switching or Security. Tell us your question!

Link to Forum

CCNA Inhouse Qualification in 5 Days

You want to improve your team knowledge for Cisco CCNA certification? You want to teach your team at the own Campus and with your own equipment? You are searching for an experienced coach? You want an individual training?

Just a call, a mail, a smoke signal.... I stand for the quality of my work.

 

Voice over IP ( VoIP )
Auszug aus Kursunterlage 2006

Author /Referent:

Klaus Dieter Wolfinger
IT CONSULTING WOLFINGER

© Alle Rechte vorbehalten

 

Abstract

Unter Voice over IP (VoIP) versteht man Ethernet- bzw. Internet-Telefonie. Diese Technologie ermöglicht die Verbindung von verbindungsorientierten Telefonie-Sprachnetzen über die paketorientierten Datennetze. Dazu werden zusätzliche Mechanismen, Endgeräte und Netzkomponenten benötigt, um den Übergang zwischen beiden Welten zu ermöglichen.

 

Einleitung

 

Sprache über Datennetzwerke - Kommunikation mittels VoIP

Unter VoIP (Voice over IP) wird IP-Telefonie verstanden, die es ermöglicht, ein normales Telefongespräch über ein paketvermittelndes Datennetz auf Basis eines IP-Protokolls zu übertragen. Das bedeutet den Übergang der traditionellen verbindungsorientierten Sprachnetze hin zu paketorientierten Sprach/Datennetze.

Um dies jedoch zu ermöglich, bedarf es den Einsatz von zusätzlichen Mechanismen in den Endgeräten und Komponenten im Netz um die verfügbaren Brandweiten besser ausnützen zu können und Probleme im Netz zu umgehen.

Eingesetzt werden hierbei Sprachkompressions-Algorithmen, die in der Lage sind, Sprache bei gleicher Qualität mit wesentlich geringerer Bandbreite zu übertragen. Die Sprache wird dadurch im Netz als Sonderform der Daten behandelt. Daraus ergeben sich neue Anwendungsgebiete, welche die Merkmale der Sprachkommunikation und der Datenverarbeitung vereinen.

Dazu gehören z.B. :

  • PC-zu-PC-Telefonie: 

  • Hier kann die Verbindung mittels z.B. Software als IP-Telefon hergestellt werden. Die technische Voraussetzung hierzu ist ein Multimedia PC mit Vollduplex-Soundkarte, Mikrofon, Lautsprecher bzw. Headset. Da beide Teilnehmer aktiv in der Applikation sein müssen, schließt diese Tatsache die Unabhängigkeit für einen Verbindungsaufbau aus. Es gibt für diese Art der Verbindung spezielle Applikationen (z.B. Teamspeak, Microsoft NetMeeting, Phoner, Xlite), die allerdings nicht alle als VoIP-Applikationen verstanden werden.

  • Telefon-zu-Telefon-Verbindungen über die Datennetze:
    Diese können (indirekt) über IP kommunizieren, indem sie selbst an herkömmlichen PBX- Anlagen angeschlossen sind, die miteinander über ein IP-Netzwerk gekoppelt sind.

  • PC oder IP-Phone-zu-Telefon-Verbindungen:

  • Hierbei werden die IP-Pakete des IP-Telefons zu einem Telephony Server weiter geleitet, der diese in entsprechende digitale (ISDN) oder analoge Sprachdaten umwandelt und zu einer Telefonanlage oder Vermittlungssystem weiterleitet. Dabei werden so genannte Gateways oder Gatekeeper verwendet um die Konvertierung der Sprachpakete zwischen den leitungs- und paketvermittelnden Netzwerken zu gewährleisten. Sie sollten den H.323.Standard unterstützen um interoperabel zu Systemen unterschiedlicher Hersteller zu sein. Die letztgenannte Möglichkeit entspricht dem, was als VoIP bezeichnet wird.

Aus diesen wiederum ergeben sich u.a. folgende Anwendungsgebiete:

 

Sprachübermittlung über das Internet/Intranet,

Messaging via Web,

Web-basierte Call Center,

Remote Teleworking.

 

Den Übergang zwischen der bisherigen verbindungsorientierten Telekommunikationsinfrastruktur und der IP-Telefonie sorgen so genannte Gateways. Sie sorgen für die Anpassung der Telefonnetze mit den paketorientierten Datennetzen.

Ein Gateway bietet folgende Funktionen:

  • Interfaces zum Anschluss von Telefon-Nebenstellenanlagen bzw. dem öffentlichen Telefonnetz,

  • Signalisierungsfunktionen (Verbindungsauf- bzw. abbau),

  • Sprach-Kompression/Dekompression in Echtzeit,

  • Verpackung bzw. Entpackung der komprimierten Sprache,

  • Interfaces zum IP-Netz.

Innerhalb der paketorientierten Netze werden die Informationen in diskrete digitale Pakete zerlegt und mittels zusätzlicher Übertragungsprotokolle über die Netzinfrastruktur (Switches, Router) übertragen. Durch die in den Protokollinformationen eingebetteten Adressinformationen können die Switches/Router die Datenpakete über das Netz transferieren. Dabei wird für jedes Paket die optimale Route zwischen Sender und Empfänger ermittelt. Dadurch wiederum ist es möglich Störfaktoren wie verfügbare Bandbreite und Fehlerrate zu berücksichtigen. Durch die unterschiedlichen Wege der im Netz geschalteten Koppelelemente treten unterschiedliche Laufzeiten bzw. Verzögerungszeiten zwischen Sender und Empfänger auf. Die Datenströme müssen am Ende wieder zu einem kontinuierlichen Datenstrom zusammengesetzt werden, nachdem sie nicht mehr sequenziell über eine bestimmte Verbindung übertragen werden. Hierfür werden spezielle Vorsorgen getroffen, dass die einzelnen Datenpakete nicht verloren gehen bzw. im Fehlerfall nicht übertragen werden.

Zusammenfassend bietet VoIP in der Entwicklung der Vernetzung eine Möglichkeit die Daten- und Sprachkommunikation auf einem einheitlichen Übertragungsmedium zu vereinen. Es können die Daten in den klassischen Netzwerken als auch die Sprache über ein gemeinsames Medium bis zum Endnutzer übertragen werden. Das IP ist das am weitest verbreitete Protokoll für die Endgerätadressierung und auch die Kernkomponente des Internets.

 

Es können mittels VoIP zwei Ideen realisiert werden:

  • Telefonie wird auf technisch höherem Niveau mit der vernetzten Datenkommunikation auf den gleichen Übertragungsmedien übertragbar.

  • Es werden Schnittstellen geschaffen, um eine direkte Beziehung zwischen den Telefonteilnehmern (der Sprache) und den verfügbaren Informationen (den Daten) über ihn herstellen zu können. Dadurch sind völlig neue Anwendungen auf Basis von CTI-Lösungen (Computer Telephony Integration) die in der herkömmlichen Telefonie nicht existierten oder zu im Kosten-Nutzen-Verhältnis inakzeptabel sind. IP stellt eine wichtige Transporttechnologie für Übertragungen von Telefongesprächen über große Entfernung dar (Long Distance Telephon Toll Services).

Immer neuere Technologien, DSPs (Digital Signal Processor) und Komprimierungsmechanismen ermöglichen die Sprachübertragung über IP und das Internet mit fortschreitender Qualität.

Signifikante Beispiele für Vorteile von Voice over IP :

  • es sind keine zusätzlichen (getrennten) Verkabelungen mehr erforderlich

  • es wird nur noch ein standardisiertes Kabel für alle Kommunikationsverbindungen benötigt - die Kommunikation kommt aus einem RJ-45-Netzwerkanschluss

  • die IP-Telefonie nutzt die gleichen Identifizierungsprotokolle wie die am Netzwerk angeschlossenen PCs; über DHCP können den IP-Telefonen Adressen zugewiesen werden

  • in der Regel kann für den Administrator und den Einzelnutzer ein einheitliches webbasierendes Netzwerkmanagementtool angeboten werden

  • Systeme können relativ einfach erweitert werden

  • Es werden deutliche Telefonkosteneinsparungen bei firmeninternen Gesprächen zwischen einzelnen Endpunkten möglich, etc. .....

Voraussetzung für eine VoIP/LAN-Telefonie

Es werden sehr hohe Qualitätsanforderungen bei Zuverlässigkeit und Verfügbarkeit der Kommunikationsnetzwerke erwartet (z.B. permanente Verfügbarkeit, muss stabil laufen). Weiter muss die Multimedia-Fähigkeit der Endsysteme und Zwischensysteme garantiert sein, d.h. die Sprachpakete müssen gegenüber Datenpakten priorisiert werden und mittels standardisierten Schnittstellen erfolgen. Wenn die Sprach-Daten-Informationen über öffentliche IP-Netzwerke (z.B. Internet) übertragen, so ist auch der Aspekt der Datensicherheit sehr wichtig. Es muss sichergestellt werden, dass die Sprach abhörsicher über WAN-Strecken übertragen werden kann (mittels Verschlüsselung der Sprachdaten möglich). Weiter spielen hier auch gesetzliche Aspekte eine wesentliche Rolle. Um Verzögerungen entgegen zu wirken, müssen WAN-Switches mittels Verschlüsselungschips und Priorisierungsmechanismen ausgestattet sein. Für die IP-Telefonie existieren spezielle Standards um Telefongespräche oder IP-Konferenzen mit unterschiedlicher Software überall im IP-Netzwerk zu ermöglichen. Diese wurden bereits 1997 von der ITU (International Telecommunications Union) beschlossen.

Technische Grundlagen

Voraussetzung für eine Überführung der Sprachkommunikation in die Daten-Netzwerke ist die Digitalisierung und Kodierung bzw. Dekodierung der Sprache zwischen den Gesprächsteilnehmern. Ebenso muss auf die Anforderungen und Übertragungsmechanismen für die Zusammenführung beachtet werden. Im Folgenden werden einige Aspekte behandelt.

Sprachkodierung (Voice Encoding)

Um ein analoges Sprachsignal durch ein digitales Netzwerk zu übertragen ist es notwendig, das Signal in einen binären Datenstrom umzuwandeln (durch Sprachkodierung), und am Ende der Übertragung wieder in die ursprüngliche Form zurück zu wandeln.

Die Analog/Digital-Konvertierung (Voice Encoding Process) ist der Schlüssel zur Sprachintegration in Paketorientierten Netzwerken. Als weitest verbreitete Sprachkodierungsverfahren zählt das PCM (Pulse Code Modulation) und ist in der G.711-Spezifikation als Standard definiert.

Wichtige Standards zur Sprachkomprimierung:

Standard

Info

Netto-Bandbreite

SpeexNarrow-15k

Hervorragend

15 Kbps

SpeexNarrow-8k

Gute Qualität

8 Kbps

MS-GSM

Gute Qualität

13 Kbps

GSM-06.10

Gute Qualität

16.5 Kbps

G.726-32k

Gute Qualität

32 Kbps

G.711-µLaw-64k

Hervorragend

64 Kbps

G.711-ALaw-64k

Hervorragend

64 Kbps

LPC-10

Zufriedenstellend

3.64 kbits

G.723.1

Hervorragende Qualität

6.3 Kbps

Microsoft ADPCM 8k

Zufriedenstellende Qualität

32 Kbps

CCITT-Norm 64k

Hervorragend

64 Kbps

Bandbreitenanforderung

Es gibt unterschiedliche Angaben über erforderliche Bandbreiten um eine vernünftige Sprachqualität zu ermöglichen. Um die vorhandene Bandbreite der Datennetze möglichst wenig zu belasten, werden die Sprachdaten komprimiert. Der G.711-Standard (ISDN) benötigt eine Bandbreite von 64 kbit/s. Verschiedene Codierungsverfahren erreichen sogar eine Datenrate von 8 kbit/s.

Anzahl der gleichzeitigen Bandbreite aller Gespräche bei Nutzbandbreite aller Gespräche bei

Gespräche

Verwendung von 64 Kbit/s je Gespräch

von 8 Kbit/s je Gespräch
(ISDN-Qualität) Gespräch (G.729; CS-ACELP)

100

6,4 Mbit/s

0,8 Mbit/s

250

16,0 Mbit/s

2,0 Mbit/s

500

32 Mbit/s

4,0 Mbit/s

Tabelle 1: Gesprächs- und Gesamtbandbreite

Bei der VoIP-Telefonie besteht die Möglichkeit einer „Silence Suppression“. Man versteht darunter die Unterdrückung von Sprachpaketen während Gesprächspausen. D.h. das System erkennt eine Gesprächspause und erzeugt dann keine bzw. leere Sprachpakete. Somit wird der Verbindungskanal nicht belastet. Einige Lösungen erstellen auf der Übertragungsstrecke so genante „Silence Indicators“. Dabei werden über die Verbindungsstrecken solange keine Pakete geschickt bis wieder gesprochen wird. Es wird so während des Gesprächs wieder Bandbreite freigegeben. Bei der herkömmlichen Telefonie bleibt der Übertragungskanal während der gesamten Verbindungszeit blockiert. Da in dieser Zeit keine Daten übertragen werden, kann die reale Übertragungsbandbreite drastisch auf ca. 40 bis 60 % des theoretischen Wertes gesenkt werden.

Verzögerung, Laufzeiten, Jitter auf dem Übertragungsweg

Verzögerungen hinsichtlich der Signallaufzeit (Delays) sind auf jeder Übertragungsstrecke anzutreffen. Die Ursachen sind verschieden und daher unterschiedlich in der Auswirkung auf die Anwendung. Die Gesamtverzögerung je Sprachabtastwert sollte 200 ms je Übertragungsrichtung für eine gute Netzwerkdimensionierung nicht überschreiten. Gemäß G.114 ist für VoIP als Realtime-Applikation eine Ende-zu-Ende-Signallaufzeit von maximal 300 ms erlaubt. Laufzeitschwankungen (sogenante Jitter) sind empfangsseitig auszugleichen, z.B. durch intelligente Puffermechanismen. Kommt es dazu, dass Pakete, aufgrund unterschiedlicher Übertragungswege in komplexen Netzwerken, nicht in korrekter Reihenfolge beim Empfänger eintreffen, spricht man von einem Sequence Error. Auch die Auswahl der jeweiligen Komponenten hat Einfluss auf die Gesamtdauer einer Paketübertragung. Mögliche Gründe für die Entstehung zusätzlicher Verzögerungen u.a.:

  • Verarbeitungszeiten im Endsystem,

  • Übertragungsgeschwindigkeit zur ersten aktiven Komponente,

  • Anzahl der aktiven Komponenten im (Sende-)LAN,

  • Anzahl der Router auf dem Verbindungsweg (Hops ),

  • Übertragungsgeschwindigkeit zur ersten aktiven Komponente,

  • Anzahl der aktiven Komponenten im (Empfangs-)LAN,

  • Verarbeitungszeit im Endsystem

Einfluss der aktiven Komponenten

Die Datenpakete durchlaufen unter Umständen während des gesamten Übertragungsweges zahlreiche aktive Komponenten. Z.B. in LANs Etagen- und Gebäudeverteiler, bei Verbindungen zu entfernten Standorten ggf. Router und Firewalls. Bei Switches als aktive Komponenten in LANs werden verschiedene Betriebsarten nach ihrem äußeren Erscheinungsbild unterteilt. Dies sind:

  • Store-and-Forward:
    Diese Switches speichern das gesamte Datenpaket zwischen, überprüfen es auf Sinnfälligkeit (Länge, CRC, ...) und leiten es im Anschluss als fehlerfreies Paket weiter. Pakete mit Fehlern werden verworfen. Nachteil ist die relativ große Verarbeitungszeit zwischen dem Eintreffen des letzten Bits und der Weiterleitung des ersten gespeicherten Bits. Vorteil jedoch ist die Filterfunktion die nur fehlerfreie Pakete durch lässt. Somit wird das Netzwerk von fehlerhaften Paketen entlastet.

  • Cut-through:
    Hierbei wird als Weiterleitungszeit die Zeitspanne zwischen dem Eintreffen des ersten Bits eines Pakets und der Weiterleitung dieses ersten Bits am Ausgangsort angegeben. Nachteil ist dabei, dass eine Konsistenzprüfung der einzelnen Datenpakete nicht erfolgt und daher fehlerhafte bzw. zu kurze Frames (Tinny Frames) im Netzwerk weiter geleitet werden. Vorteil ist aber die relativ kurze Switching-Zeit.

  • Adaptive Switching oder Intelligent Switching:
    Dabei wird von Modifikationen der oben erwähnten Switching-Techniken gesprochen. Z.B. solange ein bestimmter Schwellwert für fehlerhafte Pakete nicht erreicht wird, wird in der Betriebsart Cut-through gearbeitet. Ist der Schwellwert erreicht, wird in Store-and-Forward weiter gearbeitet. Sinkt der Wert der Fehlerhaften Pakete wieder unter den Schwellwert, wird wieder auf Cut-through umgeschaltet. In all den genannten Methoden entstehen Verarbeitungszeiten von wenigen µs bis hin zu mehreren zehn ms. Werden von VoIP-Paketen Firewalls und Proxy Server durchlaufen, dann können sich diese Verzögerungen auf ca. 500 ms erhöhen; dann sind allerdings VoIP-Implementationen für den Anwender nicht mehr zumutbar.

Einfluss von VoIP auf WAN-Konzepte

Der folgenden Erörterung liegt die Ausgangslage zugrunde, dass in den meisten Netzwerkkonzepten die Verbindungen zwischen den Standorten mit Breitband WAN-Verbindungen hergestellt werden.
Wird die Verbindung durch Kommunikationsfehler unbrauchbar, wird häufig eine Lowband Reserveleitung aktiv. Das bedeutet bei normaler Datenkommunikation u.U. Wartezeiten und schlechtere Reaktionszeiten bei bestimmten Anwendungen. Nun wird im Weiteren davon ausgegangen, dass hierbei auch VoIP-Datenströme übertragen werden. Um unliebsame Wartezeiträumen bei der Sprachübertragung durch zeitgleiche Übertragungswünsche von anderen Applikationen zu verhindern gibt es bereits Lösungen der VoIP- Geräte-Hersteller. Wenn nötig werden lange Ethernet-Pakete auf der Senderseite in zahlreiche kleinere Pakete zerlegt. In diesen Datenstrom werden die Sprachpakete so eingereiht, dass sie in definierten Zeitabständen übertragen werden. Zusätzlich können sie mittels Priorisierung bevorzugt angeordnet werden. Auf der Empfängerseite werden die einzelnen Sprachpakte dann herausgefiltert, zu ihrem Empfänger weiter geleitet und der fragmentierte Datenstrom wird wieder in seine ursprüngliche Form zurück versetzt. Da diese Lösung allerdings keinen Standard darstellt, ist es von Nöten auf beiden Seiten der Übertragung die Komponenten des gleichen Herstellers einzusetzen.

Einfluss des Internets auf die Sprachübertragung

Werden Sprachpakete mittels Internet übertragen, kann es neben den Verzögerungen durch die unterschiedlichen Übertragungswege auch zu einer Änderung der Paketreihenfolge auf der Empfangseite kommen. Durch den Einsatz geeigneter Software für Internet-Telefonie lässt sich dies aber wieder korrigieren. Es wird somit ein Zwischenspeicher erforderlich, welcher zwar die Korrektheit der Sprachsequenzen gewährleistet, aber auch zu zusätzlichen Verzögerungen führt. Diverse Sprachbeeinträchtigungen, wie z.B. Wartezeiten, überlagerte Gesprächsteile, werden oft als störender gewertet als Rauschen oder andere kurzzeitige Störungen im Kommunikationsweg.

Verzögerungen mit mehr als 100 ms machen ein akzeptables Telefongespräch bereits unmöglich. Für eine definierte Sprachqualität gilt, dass nur bis zu 10 ms Verzögerung für jeweils 1000 Meilen (terrestrische Verbindung) nicht überschritten werden sollte. Digitale Verschlüsselungsprinzipien erzeugen ebenfalls zusätzliche Verzögerungen im gesamten Übertragungskanal.

Die am weitest verbreiteten Komprimierungsstandards für VoIP und ihre Verzögerungen:

  • G.729A oder CS-ACELP:
    sie verursachen 25 bis 30 ms Verzögerung auf einem Übertragungsweg

  • G.723.1 oder MultiRate CELP:
    verursachen mehr als 100 ms Verzögerung auf einem Übertragungsweg. Werden die Pakete durch Router, Firewalls und Proxy-Server übertragen, kommen hierbei weitere Verzögerungen hinzu. Typische Werte sind hierbei für Router ca. 10 ms und Proxy-Server ca. 500 ms, dann wird jedoch ein VoIP-Einsatz bei ungünstigem Netzwerkdesign unakzeptabel (siehe auch oben). Bei der Übertragung der Pakete über Internet ist weiterhin zu beachten, dass das IP eine verbindungslose Technologie darstellt, bei der Daten über verschiedene Pfade weitergeleitet werden können. Das bedeutet, dass die Intervalle zwischen zwei ankommenden Datagrammen einer Sprachübertragung unterschiedlich groß sein können. Das Verfahren des Elastic Buffering wird eingesetzt, um die anfallenden Unterschiede während des IP-Datenverkehrs abzugleichen. Jedoch verursacht diese Zwischenspeicherung ebenfalls eine Verzögerung von ca. 40 bis 60 ms. Die einzelnen Datenpakete werden in Paketorientierten Netzwerken nicht zeitsynchron übertragen, was zu stochastischen Verzögerungen führt. Meist ist dann der zeitliche Abstand zwischen den einzelnen Datenpaketen unregelmäßig. Werden nun zeitsensitive Daten (wie etwa bei der Telefonie) übertragen, ist die Synchronisation allerdings sehr wichtig für die Qualität der Verständigung. Treffen dann die einzelnen Pakete auch noch nicht in der richtigen Reihenfolge ein, dann müssen sie beim Empfänger zwischengespeichert und ggf. wieder richtig angeordnet werden. Dieser Puffer ist möglichst gering zu halten, um die Gesamtverzögerung möglichst gering zu belassen. Bei ATM-Netzwerken werden die benötigten Puffergrößen während der Übertragung anhand des tatsächlichen Jitters ermittelt und angepasst. Bei schnellen Netzwerken und geringen Jitter reicht ein kleiner Puffer. Hauptsächlich in IP-Netzwerken, wo einzelne Pakete zu sehr unterschiedliche Zeiten ankommen, werden die Pakete gezählt die zu spät ankommen und dann in Relation zu den insgesamt angekommenen Paketen gesetzt. Daraus resultiert dann die notwendige Größe des Puffers. Bei VoIP wird die Sprache in Frames einer definierten Länge (z.B. 20ms) kodiert. Anschließend wird immer nur ein vollständiger Frame kodiert bzw. dekodiert, was zur Folge hat, dass diese Pakete sowohl auf der Empfänger - also auch auf Entstehungsseite u.U. zwischengespeichert werden müssen.

  • Die IP-Telefonie ist eine Echtzeit-Applikation. Der Standard G.114 definiert hierfür als Ende-zu-Ende-Signallaufzeiten maximal 300ms (400ms ohne Echo). Laufzeitschwankungen können z.B. durch intelligente Pufferungsverfahren empfangsseitig ausgeglichen werden. Wird ein IP-Netzwerk also als Trägermedium für IP-Telefonie gewählt, erfordert es bei mangelnder Bandbreite geeignete Mechanismen zur Steuerung des Paketstroms um definierte Qualitäten sicherzustellen.

Dienstgüteklassen: Class of Service (CoS) und Quality of Service (QoS)

Wichtiges Kriterium für die Akzeptanz der VoIP ist die realisierbare Qualität der Sprachübertragung. In Netzwerken wird diese Qualität/Güte durch QoS bzw. CoS definiert. Diese akzeptable Qualität ist von vielen technischen Faktoren abhängig und wird oft subjektiv beurteilt (etwa mit Beurteilungen wie 'zu leise', 'verzerrt', ...). Durch u.a. unzulängliche Bandbreite ist das Internet nur bedingt den Anforderungen hinsichtlich der Übertragungsqualität hinreichend. Bei hohem Verkehrsaufkommen kann es in einzelnen Switches zu Stausituationen kommen, was wiederum zu zusätzlichen Verzögerungen und dadurch zur stotternden Sprachdaten führen kann. Hierbei ist es möglich mit geeigneten Cache-Mechanismen in definierten Umgebungen noch einzugreifen.
Ein weiterer Faktor der Verbindungsqualität, ist der Verlust einzelner Datenpakete. Dieser sollte den Wert von 5% der zu übertragenden Pakete nicht überschreiten. Gemäß G.114 gelten für Verbindungen hinsichtlich der Paketverzögerung bis max. 200 ms als gute Qualität und bis zu 400 ms als gerade noch akzeptabel. Allerdings Verbindungen mit mehr als 400 ms Verzögerungen und mehr als 5% Paketverlust werden als nicht zu akzeptierende Qualität bezeichnet und sollten daher nicht eingesetzt werden.

Neben dem Versuch Übertragungsstrecken mit ausreichend hoher Bandbreite zur Verfügung zu stellen, kann man zur Gewährleistung von entsprechenden Qualitätskriterien in Netzwerken zwei Verkehrsflussteuerungen unterscheiden:

  • dynamische Ressourcenzuweisung (Integrated Services):
    Hierbei werden durch das RSVP unterschiedliche Mechanismen bereit gestellt, die es ermöglichen, einzelne Verbindungen entsprechend den jeweiligen QoS-Anforderungen der Applikationen definierte Netzwerkressourcen zuzuweisen. Ist es nicht möglich diese Ressourcen zuzuweisen, sollte diese Anforderung abgelehnt werden und die Verbindung kommt u.U. nicht zustande.

  • Prioritätszuweisung (Differentiated Services):
    Hierbei soll es möglich sein, bei begrenzten Übertragungskapazitäten ausgewählten Anwendungen eine spezielle Priorisierung zuzuweisen. Dadurch sollen so markierte Datenströme bevorzugt übertragen werden. Es ist hier notwendig, dass die aktiven Netzwerkknoten über entsprechend viele und große Warteschleifen verfügen, damit die niedrig priorisierten Pakete nicht verworfen werden. Für lokale Netzwerke kann durch die Verwendung spezieller Priorisierungstechniken eine Beeinflussung der Datenweiterleitung realisiert werden:

  • IEEE 802.1p-Priosierung:
    Das IEEE 802.1p Frame Extension dient zur Übertragung von Daten als Sprachpakete mit der Priorität in Ethernet-Netzwerken. Es können bis zu 8 Prioritäten definiert werden.

  • IEEE 802.1Q-VLAN-Steuerung:
    Es ist möglich ein erweitertes Frame-Format spezielle VLAN zu definieren. Dadurch können Datenstreuung in einem Netzwerk verringert werden. Jedoch ist die Priorisierung der Daten nicht möglich. Durch die Definition eines speziellen VLAN für die Sprachkommunikation in einem Netzwerk ist keine Übertragungsqualität garantiert.

  • Priorisierung mittels ToS-Field im IP Header:
    Diese Art der Priorisierung findet ihren Einsatz, wenn Daten auch über WAN-Verbindungen übertragen werden müssen. Die markierten Datenpakete werden dann über beliebige Hubs, Router und Switches uneingeschränkt übertragen und sind an jeder Stelle des Netzwerks verfügbar. Jedoch benötigt die Auswertung an jedem Verteilerpunkt des Netzwerks einen Router oder Layer3-Switch. Protokolle für die Übermittlung der Datagramme vom Sender zum Empfänger legen bestimmte Verarbeitungsfunktionen fest. Die Verarbeitungs­anweisungen werden dann mit den Typ-of-Service-Parametern (ToS) übergeben und von Routern zwischen Netzwerken verstanden und ausgeführt. (ToS definiert mit drei Precedence Bits insgesamt acht ToS-Klassen.)

  • Layer-3-Funktionalität:
    Hierbei ist es möglich mittels geeigneter Software von 3Com die IP-Precedence-Bits auf eine IEEE 802.1p-Priority-bit zu mappen. Dadurch wird es ermöglicht, dass Router den Datenverkehr durch Auswertung der Layer-3-Information priorisieren können. Ebenfalls lässt sich mit der Software ein weiteres Problem lösen. Und zwar, wie einzelne Applikationen in Abhängigkeit von vordefinierten Regeln innerhalb des Netzwerks den Datenverkehr dynamisch modifizieren können.

  • Ressourcenreservierung mittels RSVP (Ressource Reservation Protocol):
    Ursprünglich von Fa. Cisco entwickelt, wurde es später in den RFCs 2205 und 2750 standardisiert. Es ist Bestandteil des Integrated Services-Modells und stellt hohe Anforderungen an Router. Es werden mit diesem Protokoll keine Anwendungsdaten übertragen, sondern nur Steuerfunktionen ausgeführt.

  • MPLS (Multiprotocol-Label-Switching):
    Als Standard in RFC 3031 für MPLS-Architektur, RFCs 2507 und 2508 für Komprimierungsverfahren der IP-Header (die über MPLS-Netzwerke übertragen), verwirklicht. Dabei erhält das erste Paket einer Verbindung ein Label mittels dem alle nachfolgenden Pakete ohne aufwendige Headeranalyse weitergeleitet werden können. Eine Priorisierung zu QoS-Unterstützung ist möglich.

  • DiffServ (Differentiated Services):
    Ist eine wichtige Methode zur Paketpriorisierung basierend auf Serviceklassen, die von Netzwerken bereitgestellt werden und ist im RFC 2475 definiert. Die unterschiedlichen Serviceklassen können den Paketen durch Markierungen zugeordnet werden. Dieses erfolgt im Host oder im Netzwerkknoten am Rand des Netzwerks. Die Markierung erfolgt durch Benutzung einen DS-Feldes (Definition of the Differentiated Service Field). Während im ToS-Feld durch die Precendence-Bits nur acht Prioritätsstufen unterschieden werden, bietet das DS-Feld bis zu 64 Möglichkeiten. Die Pakete werden entsprechend ihrer Markierungen beim Durchlaufen der Netzwerkknoten behandelt.

  • Layer-4-Switching:
    So genannte Layer-4-Switches bzw. Router erlauben Daten auf der Applikationsebene zu vollziehen (im Gegensatz zu Layer-3 auf IP-Ebene). Dabei werten die Layer-4-Geräte die TCP/UDP-Portnummer der Applikation aus und entscheiden durch vorkonfigurierte Mechanismen wie die Daten weitergeleitet werden.

Allgemeine Probleme

  • Paketverluste:
    Bei der Übertragung von Sprachpaketen kann es wie bei normaler Datenübertragung zu Verlusten von Paketen kommen. Dies kann hier jedoch zu erheblichen Beeinträchtigungen der Sprachqualität führen. Daher ist eine wesentlich höhere Übertragungsqualität über den gesamten Kommunikationsweg erforderlich. Das User Datagramm Protocol (UDP) regelt bei der Sprachkommunikation, dass fehlende Pakete übergangen werden. Dieser Verlust kann mittels Software in geringen Umfang umgangen werden. Sind diese Verluste größer bzw. betreffen nacheinander folgende Pakete, kann es zu hörbaren Aussetzern kommen (Drop Outs).

  • Adressierung und Erreichbarkeit:
    Es ist wichtig als Voraussetzung für die Erreichbarkeit der Teilnehmer ein geeignetes Adressierungsschema inklusive Verzeichnisdienst und eine Lokalisierungsfunktion zu haben. Es muss geregelt werden an welche Adresse die Pakete geroutet werden, ob der Adressat zur Zeit erreichbar ist, welche Fähigkeiten das benutzte Endgerät besitzt. Die Telefonverbindung im Internet lässt sich auf zwei grundsätzliche Arten herstellen:

  1. der Anrufer kennt die IP-Adresse des Adressat und wählt diese an, oder er wählt die Person aus einer Liste aller erreichbaren Personen im IP-Netzwerk aus. Anruflisten werden auf so­genannten Connection Servern geführt. Nach Start einer Telefon-Software meldet sich das Programm an einem Server an und liefert die aktuellen IP-Adressen.

  2. Dynamische IP-Adressen:
    Hierbei kann die IP-Adresse mittels Verwendung von DNS-Strukturen und E-Mail-Aliase, Registrierung der H.323 URL, der Verzeichnisdienst bzw. Protokolle wie das LDAP, oder die Lokalisierung der Endgeräte mittels TRIP (Telephony Routing Information Protocol) ermittelt werden.

  • Echos:
    Werden in der paketvermittelten Netzwerken Werte für Echos (bestehen aus Stärke des reflektierten Signals und der gesamten Laufzeit, bis zur Wahrnehmung des Signals) erreicht, die größer als 50ms sind, so werden diese als Störungen wahrgenommen. Der Einsatz von zusätzlichen Echo-Filter ist dann ratsam. Das Echo wird dabei durch den Vergleich der schon gesendeten Pakete mit den empfangenen gefiltert. In der digitalen Signalverarbeitung werden Echounterdrückung (G.164) und Echoverhinderung (G.165, G.168) zur Beseitigung dieser Störungen eingesetzt.

  • Qualitätsüberwachung/Messung von VoIP-Netzwerken:
    Um die einzelnen Dienstgütemerkmale von IP-Netzwerken erfassen zu können, bieten verschiedene Firmen Hard- und Softwarelösungen an u.a.
    Acterna (http://www.acterna.de)
    Agilent Technologies (http://www.agilent.com)
    Avaya (http://connectivity.avaya.com/systimax/products/ipatch)
    Empirix Inc. (http://www.empirix.com)
    Netscout (http://www.netscout.com)
    Radcom (http://www.radcom-inc.com)
    Shunra Software Ltd. (http://www.shunra.com)
    Spirent Communications Inc. (http://www.netcomsystems.com)

VoIP – Die Hersteller

Im Folgenden werden einige Hersteller und Anbieter VoIP-Technologie angeführt und erläutert.

Alcatel

Der französische Telekommunikationsanbieter Alcatel verfügt über ein komplettes Produktportfolio an VoIP-Lösungen, für große, mittlere und kleine Unternehmen. Mit der neuen Generation der OmniCore-Switches bietet Alcatel gleich die für den Aufbau eines leistungsfähigen Netzwerks nötigen Komponenten an. Für Kleinunternehmer bietet Alcatel an: die für mittlere Unternehmen konzipierte »Omni PCX 4400« um IP-Funktionen für kleinere Filialen erweitert; weiters stellt die neue, modular aufgebaute »Omni PCX Office« alle Kommunikationsfunktionen in einer einzigen Box zur Verfügung. Die Omni PCX 4400 basiert auf einer Unix-Implementation inklusive ACT-Integration (Alcatel Crytal Technology). Darunter ist eine Switching-Struktur zu verstehen, die den Wechsel von Circuit- und Paket-Switching gestattet. Selbst bei hohen Datenaufkommen ist der Transfer durch eine Non-Blocking-Funktion sichergestellt. Bei hohem Verkehrsaufkommen und mangelnder Übertragungsqualität leitet die Anlage die Verbindung automatisch über ein qualitativ höherwertiges Netzwerk um, ohne das dies der Anwender bemerkt. Die Anlage kann bis zu 5.000 Teilnehmer aufnehmen und im Anlagenverbund bis zu 50.000 miteinander verbinden.
Alcatel OmniPCX 4400 ist ein fortschrittliches IP-basierendes Sprachkommunikationssystem. Basierend auf eine Client/Server UNIX Architektur ist er von 50 bis zu 50.000 Benutzer skalierbar, innovative Reflexes-Handsets bieten fast 100% Zuverlässigkeit, One-Number Mobilität, Unified Messaging, VoIP Netzwerk mit QoS-Management, und umfassende Netzwerkverwaltung. Alcatel 4645 VMS ist eine vollständige Software-basierende Lösung, völlig eingebaut ist in Alcatel OmniPCX Enterprise, bietet sie einen einfachen Zugang zu den weiterentwickelten Features für Benutzer die mit Alcatel ReflexesTM-Telefonsets ausgerüstet sind.
Alcatel OmniDesktop 4980 ist eine Generation von PC Telefonie-Applikation, die Kommunikationen und Informationen durch Verknüpfen vom Desktop-PC und das Telefon vereint. Es reiht sich nahtlos in populäre Workgroup-Anwendungen ein und ist vollständig bereit für andere Geschäftsapplikationen.

Snom105

Link: http://www.snomag.de/snom105_en.php#

 

Eine interessante Linux Implementierung bietet dieses VoIP-Phone. Es unterstützt SIP und H.323, wobei der Focus der Entwicklungen auf Interoperabilität und Preis lag.

Snom105 Features:

  • 128 x 64 pixels graphical backlit display

  • 2 Ethernet port switch. One port with PoE support

  • Asian Language Support (ALS): Japanese

  • call hold, call wait

  • transfer

  • STUN client (NAT traversal)

  • Plug and Play support (UPnP)

  • HTTP Server

  • phone book

  • conference call

  • call divert

  • redialling

  • caller waiting list

  • 27 ring tones

  • DTMF

Cisco

Zu den Vorreitern in Sachen Voice-over-IP zählt der Netzwerkspezialist Cisco. Um auch mit der IP-Telefonie einen großen Umfang an Leistungsmerkmalen zu erreichen, hat Cisco für seine VoIP-Lösungen das Skinny-Protokoll entwickelt, die Telefone unterstützen XML. Die umfassende Produktpalette deckt sowohl den Bedarf kleiner bis mittlerer als auch großer Unternehmen ab. Mit AVVID (Architecture for Voice, Video and Integrated Data) hat Cisco zudem einen übergreifenden Rahmen für die Übertragung von Sprache, Daten und Video über ein unternehmensweites Netzwerk geschaffen. AVVID umfasst neben den VoIP-Lösungen auch sämtliche Netzkomponenten und Applikationen, die für den Aufbau eines schnellen und leistungsfähigen konvergenten Netzes nötig sind. Es besteht aus Switches und Routern, VoIP-Applikationen, Clients (IP-Telefone und Lösungen für Desktop-PCs) und Videoconferencing-Einheiten.

Einige Produkte:

  • CallManger
    Diese Vermittlungssoftware ist das Kernstück der IP-Telefonie, eine Geprächs­verarbeitungssoftware die auf einem Windows 2000 Server installiert wird - dem Media Convergence Server.
    Der CallManger verwaltet bis zu 2.500 IP-Geräte pro Server und bis zu 10.000 IP-Geräte pro Cluster aus 5 Servern. Die Cisco IP-Telefone 7910 / 7960 werden an einen geswitchten Ethernet-Port angeschaltet. Für den Anschluss einer Arbeitsstation wird kein zusätzlicher Ethernet-Port benötigt, ein 100 Mbit-Ethernet-Switch ist in dem IP-Telefon integriert. Mit dem großen grafischen Display des 7960 werden XML Seiten dargestellt und Zugriffe auf Datenbanken möglich, ohne einen PC zu benutzen.

  • Cisco Media Convergence Server 7822/7830/7835
    Server Hardware: Cisco VG200/DE-30+ Sprachgateways
    Zugangsgateways erlauben den IP-PBX-Systemen mit existierenden PSN oder PBX Systemen zu kommunizieren. Sie bestehen aus analogen Station-Gateways, analogen und digitalen Trunk-Gateways, und einem Konvergenz-Sprach-Gateway.

  • Cisco Switches
    Die IP-Telefonie benötigt ein durchgängig geswitchtes Ethernet-LAN um Quality of Service garantieren zu können. Cisco bietet entsprechende Switches die den Anforderungen eines modernen Netzwerkes gerecht werden. Immer mehr Cisco Switches z.B. der Catalyst 4000 unterstützen jetzt eine Energieversorgung der Telefone über das vorhandene Ethernet Kabel, das sonst notwendige Netzteil kann also wegfallen. Bei vorhandener Netzwerkhardware besteht die Möglichkeit, über ein vor den Switch geschaltetes 'Patchpanel', Strom ins Netz einzuspeisen.

  • Cisco Access Server / Router
    Cisco Systems bietet eine Vielzahl von Komponenten um die interne IP-Telefonie mit der traditionellen Telefonie (ISDN/Analog) zu verbinden. Außerdem können bestehende Standleitungen für die Sprachübermittlung genutzt werden. Cisco drahtloses IP-Telefon - Cisco Systems erweitert sein IP-Telefonie-Portfolio um drei neue Produkte:

  1. Darüber hinaus stellt das Unternehmen IP-basierende Hard- und Software-Erweiterungen vor. Die neuen Produkte machen die Vorteile der IP-basierenden Kommunikation - eine einzige Infrastruktur für Daten und Sprache, höhere Produktivität, größere Mobilität am Arbeitsplatz und verbesserte Ausfallsicherheit - für eine höhere Zahl von Anwendern in Unternehmen aller Größen zugänglich. Die Geräte arbeiten über eine intelligente IP- Netzwerkinfrastruktur nahtlos mit den Access Points der Cisco Aironet Serie nach IEEE-Standard 802.11b zusammen. Der Vorteil des Cisco IP-Telefons 7920 gegenüber einem herkömmlichen DECT- Telefon (Digital Enhanced Cordless Telecommunications) besteht in der Möglichkeit der Integration einer Vielzahl von Datenapplikationen. Die Cisco IP-Telefone 7912G und 7902G sind zusammen mit dem bereits verfügbaren Cisco IP-Telefon 7905G die Einstiegsmodelle in das Cisco-Portfolio für Konzerne, mittelgroße und kleinere Unternehmen. Wie alle IP-Telefone von Cisco sind das 7912G und das 7902G mit Inline-Power sowie automatischen Konfigurationsfunktionen ausgestattet.

Net IQ

Der auf Tools für das Netzwerk-, Performance- und Applikationsmanagement spezialisierte Anbieter Net IQ hat eine neue Software entwickelt, mit der sich prüfen lässt, ob eine Netzwerkinfrastruktur VoIP-tauglich ist.

Der Chariot VoIP Assessor kann VoIP-Calls generieren, um herauszufinden, an welchen Stellen im Netz Änderungen vorgenommen werden müssen. Zu den kritischen Faktoren für die Sprachqualität von VoIP-Übertragungen zählen unter anderem Verzögerungen der Datenpakete, unterschiedliche Laufzeiten und der Komprimierungs-Codec.

Vivinet Assessor legt schnell und leicht fest wie gut VoIP in einem Netzwerk arbeitet. Zusätzlich um den Bedarf in Upfront-Training zu verhindern und teuren Arbeitseinsätzen, kalkuliert der VoIP Assessor auch eine Gesamt-Call-Qualität die erwartet werden kann und generiert einen Bericht der Netzwerkbereitschaft für VoIP.

Nortel Networks

Das Unternehmen zählt zu einem der wichtigsten Anbieter für VoIP-Lösungen. Das umfassende Portfolio reicht von Carrier-Grade-Produkten über VoIP-Einschubkarten für die hauseigene Tk-Anlage Meridian bis zum Business Communications Manager (BCM) für kleinere Unternehmen. Der BCM ist eine gelungene Komplettlösung mit umfangreicher Zusatzsoftware. Hinzu kommt ein reichhaltiges Softwareangebot wie der „Call Pilot“ für Unified Messaging und weitere Kommunikationsanwendungen für Call Center oder Web-Contact-Center.

Auszug aus der Produktpalette:

  • Meridian Home Office II,

  • I2004 Internet-Telefon,

  • I2005 Software Phone,

  • Meridian Desktop Solution,

  • Remote Office 9150,

  • Optera Metro 5000,

  • Communication Server 2000/3000

Siemens

Zu den Pionieren im Voice-over-IP-Markt zählt auch die Siemens AG mit dem Konzernbereich Information and Communication Networks. Zentrales Produkt für die VoIP-Kommunikation in Unternehmensnetzen ist die Hipath-Familie. Damit bietet Siemens eine umfassende Lösung für VoIP an.

Zu den wichtigsten Komponenten gehören hierbei:

  • Kommunikationssysteme OpenScape Voice Serie,

  • Kommunikationssysteme der HighPath 4000 Serie

  • IP-Telefone,

  • IP-Telefon-Anwendungen.

Das Portfolio für Hipath umfasst zahlreiche Applikationen, darunter Mobile Office, Call Center und CRM. Die HiPath basieren auf den Standards H.323 und G.711 und liefen auf Windows NT EmbeddedPlattformen. Der HiPath-5500-Server war für bis zu 300 Benutzer ausgelegt und konnte als Hicom-300E-Kommunikationsserver angeschlossen werden. Der HiPath-5500-Server wurde für mittelständische bis Großunternehmen entwickelt und war für Windows NT mit bis zu 800 Benutzer konzipiert. Als Übergang zu Betreibernetzen oder anderen Kommunikationssystemen kann HiPath RG 2500 (IP- Gateway) herangezogen werden.

Die Produktfamilie OpenScape bietet alles was man heute als “Unified Communications” bezeichnet.

Zu speziellen Anwendungen zählen:

  • ein Unified Messaging System,

  • die Call Center Produktfamilie ProCenter (für innovatives Customer Relationship Management),

  • Voice Mail-Systeme PhoneMail (dient zum Speichern, Abrufen und Verteilen von Sprachnachrichten. Die eingetragenen Benutzer erhalten hierfür eine Mailbox (Sprachbriefkasten).

Weitere VoIP-Anbieter

Wichtige VoIP Protokolle und Spezifikationen

Überblick

Folgende Organisationen haben bis jetzt vor allem Einfluss auf die VoIP-Standardisierung gehabt:

  • IETF Internet Engineering Task Force

  • Tiphon Telecommunications and Internet Protocol Harmonization Over Network, das ist die VoIP-Arbeitsgruppe des ETSI European Telecommunications Standards Institute

  • IMTC International Multimedia Teleconferencing Consortium, Vorschläge der IMTC sind in die ITU H.320-Standards eingeflossen

  • ITU International Telecommunication Union, eine Organisation in der UNO, die sich um die weltweite Standardisierung der Telekommunikation und Radiowellenverwendung (TV, Radar, FM) kümmert

Standard

Beschreibung

Org.

H.323

Paket-basierte Multimedia Kommunikations-Dienste

ITU

H.225.0

Anrufersignalisierung und Paketisierung - inkludiert:

ITU

H.225.0 - Q.931:

ISDN (Integrated Services Digital Network)

ITU

H.225.0 - RAS:

Registration, Admission and Status Protocol

ITU

H.225.0 Annex G

Paketsynchronisation, Gatekeeper zu Gatekeeper Kommunikation

ITU

H.245

Kontrollfunktionen für die Multimedia-Kommunikation

ITU

H.235

Sicherheit und Verschlüsselung für H-Serie Multimedia Terminals

ITU

H.450.x

Ergänzende Multimedia Dienste:
Generic functional protocol for the support of supplementary services in H.323, Call transfer, Diversion, Hold, Park & pickup, Call waiting, Message waiting indication

ITU

H.323 Annex D

Echtzeit Fax, das T.38 verwendet

ITU

H.323 Annex E

Anruf-Verbindung über UDP

ITU

H.323 Annex F

Single-use device

ITU

T.38

Procedures for real-time group 3 facsimile communications over IP networks

ITU

T.120 series

Datenprotokolle für Multimediakonferenzen

ITU

SIP (RFC 3261)

Session Initiation Protocol, Aufbau und Beenden von Verbindungen

IETF

SDP (RFC 2327)

Session Description Protocol, Beschreibung von Multimedia-Sessions

IETF

Tabelle 2: Signalling Protokolle

Standard

Beschreibung

Org.

H.GCP

Beabsichtigte Vorschläge für das Gateway Control Protocol

ITU

MGCP (RFC 2805 und RFC 3435)

Media Gateway Control Protocol

IETF

MEGACO/H.248

MEGACO protocol, Nachfolger von MGCP (RFC 3015)

IETF

SGCP (Draft)

Simple Gateway Control Protocol

IETF

IPDC (Draft)

IP Device Control

IETF

RSVP (RFC 2208)

Resource ReSerVation Protocol

IETF

Tabelle 3: Gateway Control Protokolle

Standard

Beschreibung

Org

RTP (RFC 1889)

Real-time Transport Protocol

IETF

RTCP (RFC 1889)

Real-time Transport Control Protocol

IETF

RTSP (RFC 2326)

Real-time Streaming Protocol

IETF

Tabelle 4: Media Transport Protokolle

Standard

Algorithmus

Bitrate (Kbit/s) End-to-End

Delay (ms)

Sprachqualität

Org.

G.711

PCM

48, 56, 64

<1

Hervorragend

ITU

G.723.1

MPE/ACELP

5.3, 6.3

67-97

Gut - Ok

ITU

H.728

LD-CELP

16

<2

Gut

ITU

G.729

CS-ACELP

8

25-35

Gut

ITU

G.729 Annex A

CS-ACELP

25-35

8

Gut

ITU

G.722 ADPCM

Sub-band

48, 56, 64

<2

Gut

ITU

G.726

ADPCM

16, 24, 32, 40

60

Gut - Ok

ITU

G.727

AEDPCM

16, 24, 32, 40

60

Gut - Ok

ITU

Tabelle 5: Media Encoding - Audio Codecs (bzw. Vocoder)

Standard

Algorithmus

Bitrate (Kbit/s)

Videoqualität

Org.

H.261 (DCT) mit Bewegungs-Kompensation

Discrete cosine transform

px64

niedrig

ITU

H.263

Weiterentwicklung von H.261

(p= # der ISDN B Kanäle)

mittel

ITU

Tabelle 6: Media Encoding - Video Codecs

VoIP Netzstrukturen

Zentralisierter Netzaufbau

Hierbei wird vor allem das MGCP oder das H.248/Megaco Protokoll verwendet. Der zentrale Knoten wird Call Agent oder Media Gateway Controller genannt, der die Vermittlung der Anrufe übernimmt. Er verbindet sich dann zu einem Media Gateway weiter, das dann die eigentlichen Anrufe routet und übermittelt. In zentralisierten Netzen (ähnlich den klassischen Telefonnetzen) gibt es intelligente zentrale Vermittlungsknoten und Endgeräte, die in Bezug auf den Telefonaufbau und die Audioübermittlung nur sehr einfache Aufgaben übernehmen. Es ist auch möglich eine zentralisierte Struktur über SIP oder H.323 zu betreiben, was allerdings eher unüblich ist. Der Vorteil bei zentralisierten Netzen ist die zentrale Administration, das Gesprächsmanagement, das leichtere Belauschen (aus Sicht des Betreibers bzw. Gesetzgebers) und die einfachere Netzstruktur.

Dezentralisierter Netzaufbau

In diesem Zusammenhang werden die Protokolle SIP und H.323 genannt. Die Intelligenz (Verbindungsaufbau, Routing, etc.) wird dabei auf die Endgeräte verteilt, die zu VoIP-Telefonaten fähig sind. In einem H.323-Netzwerk werden diese Endpunkte Gatekeeper genannt, in einem SIP-Netzwerk Proxy- oder Redirect-Server. Die Vorteile bestehen in der größeren Flexibilität der Netze, in einem Aufbau, der eher dem Internet entspricht (dezentral) und in der besseren Verständlichkeit für Techniker, die mit IP Netzen arbeiten.

VoIP-Protokolle

H.323

Oftmals wird H.323 als Signalisierungsprotokoll bezeichnet. Jedoch umfasst die Empfehlung weit mehr, als ein reines Signalisierungsprotokoll. Vielmehr spricht man von einer Protokollfamilie oder einer Protokoll-Suite, da sie eine Vielzahl von Spezifikationen von Endgeräten, Codecs oder (Unter-)Protokollen enthält.

Mit H.323 sollten ursprünglich Multimedia-Applikationen über LANs transportiert werden. H.323 wird auch ein sogenanntes „umbrella protocol“ genannt, da es eine Reihe von anderen Standards wie das H.225 oder das H.245 Protokoll beinhaltet. Ziel ist es, ein vollwertiges Multimedia-Protokoll zu sein, um etwa die Arbeit an Online-Dokumenten bei gleichzeitiger Vermittlung von Sprache und Bild zu ermöglichen. Trotz dieser vordefinierten Standards ist es für Software-Anbieter möglich eigene Erweiterungen in das Protokoll einzubauen. Wegen der frühen Verfügbarkeit des H.323-Protokolls (1996) wird es derzeit im Internet am meisten verwendet. H.323 verwendet das Q.931-Protokoll (ISDN), wodurch Verbindungen in das klassische Telefonnetz relativ einfach ermöglicht werden. Die aktuelle Version ist H.323v4 (Version 4), die im November 2000 veröffentlicht worden ist.

Weiters werden folgende Netzkomponenten spezifiziert:

  • H.323-MCUs (Multipoint Control Units)
    MCUs ermöglichen Konferenzschaltungen zwischen Konferenzteilnehmern, da dadurch der Datenverkehr entsprechend geregelt wird.

  • H.323-Gateways
    Gateways stellen die Brücke zwischen IP-Netz und analogem Telefonnetz dar. Hier findet die Paketierung bzw. Depaketierung der Datenpakete statt.

  • H.323-Gatekeeper
    Gatekeeper managen einerseits die vielfältigen Management-Aufgaben der Terminals (Breitbandmanagement, Ruf-Autorisierung, etc.), andererseits dienen sie etwa dazu um die IP Adressen der Empfänger ausfindig zu machen.

  • SET (Simple Endpoint Type)
    SETs sind einfach strukturierte Endgeräte wie PDAs, die aber auch H.323-kompatibel sind.

#

Aktion

H.323-Protokoll

Transport

1

Das Endgerät fordert eine Erlaubnis und Bandbreite zu Beginn einer H.323-Session vom Gatekeeper an.

RAS (Registrierung, Admission und Status)

UDP

2

Endpunkte: Negotiate und Establish den Call Setup.

Q.931

TCP

3

Endpunkte: Exchange Capabilities und Setup der RTP-Kanäle

H.245

TCP

4

Die Endgeräte tauschen Audiodaten aus

H.225 (RTP/RTCP)

UDP

Tabelle 7: Beispiel für eine typische H.323 Startup-Sequenz

Multi Control Unit (MCU)

Eine MCU ermöglicht eine Konferenz zwischen drei oder mehr Teilnehmern, welche geografisch voneinander getrennt sind.

Die MCU ist dabei eine Art „Sternverteiler“, welche die Endgeräte (sogenannte „Kommerzielle Systeme“) miteinander verbindet.

MCUs sind als eigenständige Hardware oder als Softwarekomponente erhältlich.

  • Hardware MCUs sind sehr leistungsfähig, jedoch relativ teuer.

  • Software MCUs sind relativ günstig, aber weniger leistungsfähig

Es werden MCUs bzw. MPs zunehmend in Endsysteme integriert. Hier ist der Halbleiter-Markt treibende Kraft, da es immer günstigere und höher integrierte Bausteine gibt.

Auf der MCU werden also Konferenzen und Services eingerichtet. Konferenzpartner auf der MCU können sein:

  • H.261 im Modus „Video Switching“

  • H.263 im Modus „Video Switching“

  • Continous Presence

Mit der MCU werden verschiedene Parameter ausgehandelt:

  • Datenanwendungen mittels T.120

  • Bandbreitenreservierungen

  • Anzahl der Teilnehmern

  • Bildrate

  • Bildgrösse

Die Aushandlung der Parameter findet in vordefinierten Schablonen (Services) statt. Diese bilden die Grundlage für benutzerdefinierte Konferenzen. Die Rufnummer setzt sich hier dann immer aus der Servicerufnummer („Service-ID“) und einer Konferenznummer („Konferenz-ID“) zusammen.

Durch Kaskadierung mehrerer MCUs kann die Kapazität einer Konferenz erhöht werden.

Beispiel:

Die MCU-Konferenz 910 habe die Parameter:

  • Darstellung im Continuous Presence Mode

  • Endgeräte senden ihre Videos mit maximal 174 kbps im QCIF1-Format

  • Endgeräte empfangen ihre Videos mit maximal 504 kbps im CIF2-Format

  • es werden 15 Bilder pro Sekunde im Standard H.261 gesendet

  • Konferenznummer generieren unter http://www.myserver.de

  • Generierung einer Konferenz-ID, z.B. 98765

  • Konferenznummer ist dann 19471414

Ablauf einer Konferenz

Dail-In:

  • Einwahl in eine MCU-Konferenz

  • Wahl der Konferenznummer (.z.B. 19471414)

  • möglicherweise ist noch die Gatekeeper-Prefix nötig

Dail-Out:

  • Administrator der Konferenz lädt über die Weboberfläche einen neuen Teilnehmer ein

  • Durchwahl für weitere Teilnehmer mit config**n1**n2
    Voraussetzung für dieses Wählverfahren ist es, dass der Service überhaupt weitere Teilnehmer zulässt.

Multipoint Controller (MC)

  • fester Bestandteil einer MCU

  • für die Verteilung der Medienströme zuständig

  • Vermittlungszentrale für den Aufbau der Konferenz

Multipoint Prozessor (MP)

  • optimale Hilfe für den Multipoint Controller

  • zuständig für die Aufbereitung eines Datenstromes

  • Lippensynchronität herstellen

  • Übersetzung verschiedener Standards ineinander

Wenn jedes Terminal einen eigenen Multipoint Controller besitzt (dezentralized multipoint), kann auf zentrale MCUs verzichtet werden.

Gatekeeper

Ein Gatekeeper ist eine logische Komponente des H.323-Standards, welcher sowohl als Windows- oder UNIX-Software, als Router-Option, als Teil einer MCU oder eines TCP/IP-Gateways implementiert sein kann.

In H.323-Netzen kann es einen oder mehrere Gatekeeper geben. Der Einsatz von Gatekeepern ist optional, jedoch stellen sie innerhalb einer H.323-Umgebung das wichtigste Element dar. Gatekeeper verfolgen vielerlei Aufgaben, die im Folgenden kurz aufgezählt seien.

  • Ein Gatekeeper verwaltet die Kommunikationsbeziehungen (d.h. Rufauf- und Rufabbau) zwischen den H.323-Terminals, er registriert angemeldete Endgeräte mit ihren Rufnummern oder Aliasen und wandelt diese zu IP-Adressen bzw. Domainnamen.

  • Gatekeeper verwalten die Zugriffsrechte der Anwender, sorgen für optimale Verbin- dungsqualität durch Bandbreitenmanagement und sammeln Verbindungsdaten, die z.B. für Abrechnungszwecke genutzt werden können. Kommen in einer VoIP-Infrastruktur mehrere Gatekeeper zum Einsatz, so ist der Verwaltungsbereich eines Gatekeepers als sog. „Zone“ definiert. Auch das Zonenmanagement wird durch die Gatekeeper übernommen.

  • ohne Gatekeeper findet eine direkte Kommunikation zwischen den H.323-Komponenten (Terminals, Gateways, MCUs) statt

  • bei Vorhanden sein eines Gatekeepers müssen sich die Komponenten bei ihm registrieren

  • der Gatekeeper vermittelt den Verbindungsaufbau

  • Adressauflösung ist ein weitere wesentliche Aufgabe

  • Authentifizierung und Zugangssteuerung

  • Bandbreitenverwaltung
    - maximale Bandbreite für alle Rufe der Zone
    - maximale Bandbreite pro Ruf

Zonen und Nummer

Der Zonenbegriff beschreibt:

  • Administrationskonzept auf Gatekeepern

  • Zone:
    logische Zusammenfassung aller Geräte, welche einem Gatekeeper zugeordnet sind

  • zur Kennzeichnung erhalten alle Geräte eine Nummer (E.164-Alias) und über den Gatekeeper eine Prefix

  • innerhalb eines Internets werden alle Prefixe für Gatekeeper von Adminsitrator dieses Intranets vergeben.

  • andere Netze (Provider) haben eigene Nummerierungskonzepte

Gatekeeper Registrierung

  • Registrierung eines Terminals am Gatekeeper muss eindeutig sein

  • Die Anmeldung erfolgt per H.323-Name (z.B. Maschinenname: abcmm20), E.164-Alias (numerische Zahl: z.B. 9876) und Angabe der Gatekeeper IP-Adresse

  • Aliase können theoretisch pro Sitzung geändert werden, deshalb ist ein Nummernplan pro Zone nötig

  • Die Teilnehmer können nach der Registrierung mit dem E.164-Alias gerufen werden (und lokal auch mit dem H.323-Namen)

Gatekeeper Vernetzungsstruktur

  • Gatekeeper können miteinander verbunden werden

  • normalerweise besitzt jeder GK eine Tabelle mit Einträgen, welche andere GK noch existieren

  • Einsatz sogenannter „Country“-Gatekeeper um die Tabelle zu reduzieren

  • der Country-GK ist allen anderen GK als einziger bekannt. (ähnlich Defaultgateway)

  • Prefix = Gatekeeper-Name

Beispiel:

  • Terminal1 einschalten: Registrierung am Gatekeeper1

  • Ruf am Terminal1 mit Nummer 004903012345

  • Gatekeeper1 findet 0049030 Prefix für Country Gatekeeper

  • Gatekeeper fragt Country-GK nach der Nummer 004903012345

  • Country-GK schickt Gatekeeper1 die IP-Adresse der Terminals2

  • Terminal1 sendet an Terminal2 einen Ruf

  • Konferenzparameter werden ausgehandelt

  • Konferenz beginnt

Gatekeeper Beispiele (Auswahl)

Gerät

lokale Konfig per ...

Konfiguration remote per ...

Cisco MCM

serielle Schnittstelle

Telnet

RADVision ECS,
OnLAN 323 integriert

MSIE5 und JAVA

MSIE5 und JAVA

RADVision NGK

Windows Software

VNC

OpenH323 Gatekeeper

Textfile und Telnet auf Port 7000

Telnet auf Port 7000

Tabelle 8: Gatekeeper Beispiele (Auswahl)

RadVision basiert auf Windows NT-Technologie, das Open Gatekeeper Projekt basiert auf Linux und Solaris.

Gateways

Gateways dienen der Verbindung von herkömmlichen Telefonnetzen und VoIP- Infrastrukturen. Damit leisten sie einen wesentlichen Beitrag zur Praktikabilität von VoIP-Technologie. Aufgrund der umfassenden Verbreitung herkömmlicher Telefonnetze ist eine sinnvolle Nutzung von VoIP nur gegeben, wenn über Gateways entsprechende Brücken zwischen VoIP- und Telefoniewelt geschlagen werden können.

Die Hauptfunktionen eines Gateways bestehen also darin, „Übersetzerdienste“ zwischen dem Telefonnetzwerk und dem IP-Netz zu leisten und den Auf- und Abbau der Sprachkanäle zwischen beiden Netzen zu verwalten. Dabei übernimmt ein Gateway sowohl die Umsetzung der Sprachdaten, als auch die der unterschiedlichen Signalisierungen. So kann ein Gateway beispielweise die Signalisierungen des in der Telefonwelt verbreiteten SS7-Standards auf entsprechende Signalisierung im IP-Netz umsetzen.

  • ein Gateway ist über die OSI-Schichten 4-7 implementiert

  • Gateways konvertieren Protokolle ineinander, können aber auch die physikalische Kopplung von zwei Netzwerkkarten übernehmen

  • weitere Aufgaben:
    - Adressinterpretation und Routenwahl
    - Flusssteuerung und Fehlerbehandlung
    - Fragmentierung und Reassemblierung bei ungleichen Framegrössen

MCU (Multi Point Control Unit)

Die Einrichtung einer MCU ist nur dann erforderlich, wenn Konferenzschaltungen erwünscht werden. Die MCU agiert im Netz wie ein H.323-Terminal, welches in der Lage ist, die Gespräche von mehreren Anrufern (Konferenzteilnehmern) entgegenzunehmen und zu halten. Je nach Hersteller können MCUs mehrere Konferenzen parallel realisieren.

Da der Ursprung der H.323 Rahmenempfehlung im Bereich der Videotelefonie/des Videoconferencing zu suchen ist, sind wichtige Zusatzdienste, die aus der herkömmlichen Telefonie bekannt sind, ursprünglich nicht realisiert worden.

Diesem Mangel schafft der optionale Substandard H.450 Abhilfe. Nach und nach werden verschiedene Zusatzdienste implementiert und verabschiedet, so dass bei der Anwendung von VoIP mittels H.323 nicht auf gewohnte Komfortfunktionen verzichtet werden muss, die sich bei der herkömmlichen Telefonie etabliert haben. So sind zwischen 1998 und 2001 zwölf Zusatzdienste wie Makeln, Anrufumleitung, Anklopfen, Namensanzeige und Rückruf mit den Empfehlungsnummern H.450.1 bis H.450.12 implementiert und verabschiedet worden.

Terminal

In einer H.323-Umgebung bezeichnet der Begriff „Terminal“ einen (multimedialen) Endpunkt zur Kommunikation. Ein H.323-Terminal ist also (in der VoIP-Welt) ein H.323-Telefon. Dieses kann hauptsächlich in zwei Ausprägungen erscheinen: Als Software auf einem PC (sog. „Softphones“ oder „Softclients“) oder als eigenständiges Tischgerät, dem sog. IP-Phone.

Als bekannteste Ausprägung eines Softphones findet man heute die Microsoft- Anwendung „NetMeeting“, die für alle Windowsversionen ab Windows95 verfügbar ist.

TCS4

TCS4 ist eine spezielle Methode der Weiterleitung von Rufen am Gateway. Es gestattet direkte ISDN-Rufe über ein Gateway an einem LAN-Endpunkt. Die Rufnummer hat immer den Aufbau:
Trennzeichen + Alias-Nummer des LAN-Endpunktes.

TCS4 wird leider von den einzelnen Herstellern unterschiedlich implementiert.

Beispiele von TCS4 Implementierungen:

Hersteller / Gerät

TCS4-Wahl

manuelle Wahl

Tandberg

003025410800 * 908

... 800/908#

Sony Contact 1600

003025410800 ** 908

... 800/*/908#

Polycom ViewStation

003025410800 ## 908
oder 908 in H.323 – Extension Feld eintragen

... 800/#/908#

PT 680

908 in extra Feld eintragen

... 800/#/908#

VCON

003025410800 ^ 908

 

Tabelle 9: Beispiele von TCS4 Implementierungen

/... entspricht einer Pause in der manuellen Wahl bis zur Bestätigung
# ... entspricht in der manuellen Wahl der Endbestätigung der Wahl

  1. T.120-Anwendungen

Neben Audio- und Video sind teilweise Möglichkeiten der Datenanwendungen realisiert.

T.120 ist die Protokollfamilie, welche die Grundlagen von Datenanwendungen beschreibt. Ein Beispiel ist die Applikation „Netmeeting“. Es exisiteren jedoch auch andere Programme die sich im Aussehen und Funktionalität sehr ähneln. Typische T.120 Anwendungen sind:

  • Chat

  • Filetransfer

  • Whiteboard

  • Application Sharing

Shared Applications sind in T.120 nicht definiert.

T.120 Chat

Es handelt sich um eine einfache Kommunikation mittels Tastatur. Der Teilnehmer tippt Text ein, welcher alle anderen Teilnehmer in einem Fenster angezeigt bekommen. Je nach Netzstruktur und -performance kann diese Kommunikation sehr schnell sein. Chatten ist allerdings für eine flüssige Kommunikation eher ungeeignet.

T.120 Whiteboard

Die Teilnehmer arbeiten auf eine verteilten Arbeitsfläche, auf welcher Dokumente mittels verschiedener Text- und Malwerkzeuge gemeinsam bearbeitet werden können. Es stehen meist mehrere Arbeitsflächen (Seiten) zur Vefügung. Ein ideales Einsatzfeld ist z.B. das gemeinsame Bearbeiten von Zeichnungen und graphischen Darstellungen. Die Anwendung unter Windows heisst „Whiteboard“.

T.120 Application Sharing

Hier wird die Bedienoberfläche eines odere mehrerer Anwendungsprogramme allen Teilnehmern zur Verfügung gestellt. Das Programm läuft also nur als ein Prozess auf nur einem Rechner. Das Programm zur gemeinsamen Nutzung kann entweder nur zur Ansicht oder zur Bearbeitung freigegeben werden. Meist wird dies durch einen zusätzlichen Reiter oberhalt der Titelzeile mit der Aufschrift „freigegeben durch ...“ angezeigt.

MGCP

MGCP und Megaco/H.248 wurden mit dem Hintergedanken entworfen ein zentrales Management der Infrastruktur zu ermöglichen. Der Aufbau ist ganz klar an die klassischen Telefonnetze (PSTN - Public Switched Telephone Network) angelehnt.

Technische Daten:

  • Gateway - UDP-Port 2427,

  • Call Agent - UDP-Port 2727

  • Kodierung: einfacher ASCII Text

    • Kommandos:

      • AuditConnection, AuditEndpoint, CreateConnection, DeleteConnection, EndpointConfiguration, ModifyConnection, NotificationRequest, Notify, RestartInProgress

      • Parameter: BearerInformation, CallId, Capabilities, ConnectionId, ConnectionMode, ConnectionParameters, DetectEvents, DigitMap, EventStates, LocalConnectionOptions, MaxMGCPDatagram, NotifiedEntity, ObservedEvents, PackageList, QuarantineHandling, ReasonCode, RequestedEvents, RequestedInfo, RequestIdentifier, ResponseAck, RestartDelay, RestartMethod, SecondConnectionId, SecondEndpointId, SignalRequests, SpecificEndPointId

Neben diesen einzelnen Befehlen besteht eine MGCP-Anfrage auch aus den folgenden Komponenten:

  • Transaction ID (1 bis 999999999)

  • Name des Endpunktes, für den die Anfrage gedacht ist

  • Protokollversion

  • Parameter-Set

  • optionaler Session Descriptor

Beispiel eines MGCP-Requests

RQNT 1202 aaln/ Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. MGCP 1.0
N: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. :5678
X: 0123456789AC
R: L/hd(A, E(S(L/dl),R(L/oc, L/hu, D/[0-9#*T](D))))
D: (0T|00T|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
S:
Q: process
T: G/ft (Antwort der Gegenseite, dass die Anfrage erfolgreich war:)
200 1202 OK

MEGACO/H.248

Technische Daten:

  • Ports: 2944 (TCP, UDP) Text, 2945 (TCP, UDP) Binär

  • Kodierung: ASN.1 Text

    • Kommandos:
      Add, Modify, Subtract, Move, AuditValue, AuditCapabilities, Notify, ServiceChange
      Parameter: Modem, Mux, Media, TerminationState, Stream, Events, EventBuffer, Signals, Audit, ServiceChange, DigitMap, Statistics, Packages, ObservedEvents, Topology, Error, Local, Local Control, Remote, Service

Beispiel eines MEGACO/H.248-Requests

1. Ein MG registriert bei einem MGC und verwendet das ServiceChange Kommando:

MG1 to MGC:
MEGACO/1 [124.124.124.222]
Transaction = 9998 {
Context = - {
ServiceChange = ROOT {Services {
Method=Restart,
ServiceChangeAddress=55555,
Profile=ResGW/1}
}
}
}

2. Der MGC schickt eine Antwort:)

MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Reply = 9998 {
Context = - {ServiceChange = ROOT {
Services {ServiceChangeAddress=55555, Profile=ResGW/1} } }
}

SIP (Session Initiation Protocol)

Herkunft/Historie

Im Gegensatz zu H.323 kommt SIP aus dem Internet-Umfeld und wurde von der Internet Engineering Task Force (IETF) entwickelt und veröffentlicht. Im März des Jahres 1999 veröffentlichte die IETF den RFC2543 im Status „Proposed Standard“.

Die SIP-Arbeitsgruppe hat seitdem einige Fehler und Unzulänglichkeiten behoben, Unklarheiten beseitigt und kleinere Formmängel ausgebessert. Somit hat der RFC2543 im Jahr 2000 die letzte Entwicklungsstufe des „Draft Standards“ erreicht.

Das SIP-Protokoll

Der Funktionsumfang von SIP beschränkt sich auf die Initialisierung, die Beendigung und die Modifikation von (Multimedia-)Sessions mit einem oder mehreren Teilnehmern. SIP ist somit ein reines Signalisierungsprotokoll, welches im TCP/IP-Protokollstapel auf der Anwendungsschicht angesiedelt ist. Als Transportprotokolle können demzufolge sowohl TCP als auch UDP verwendet werden. In der Regel verwendet SIP das UDP als Transportprotokoll. Jede gewöhnliche SIP-Nachricht (Request- oder Response- Message) passt in ein einziges UDP-Datagramm; für deren Transport ist der im Vergleich zu TCP wesentlich kleinere UDP-Header völlig ausreichend.

SIP ist ein sehr einfach gehaltenes, textbasiertes Client-Server-Protokoll, das keinen festen Satz an Standards beschreibt, sondern eine flexible Erweiterung bestehender Standards bildet. Durch seine Wurzeln in der Internetgemeinde lehnt sich das Protokoll an bereits bestehende Standards und Protokolle an. So sind zum Beispiel deutliche Parallelen zum HTTP-Format erkennbar (z.B. Fehler- oder Statusmeldungen und deren Nummern). Auch die Konventionen bezüglich der Namensvergabe im Stil von Emails sind übernommen worden. Zur Namensauflösung verwendet SIP das Domain Name System (DNS).

Die SIP-Komponenten

Die Grundelemente einer SIP-Infrastruktur setzen sich aus 4 logischen Hauptkomponenten zusammen:

  • User Agents,

  • Registrierungsserver,

  • Proxyserver und

  • Umleitungs- server.

Häufig werden die verschiedenen Ausprägungen der Server in einer multifunktionalen Software zusammengefasst, so dass in der Praxis oftmals nicht die physische Trennung der Server stattfindet.

Im Folgenden werden die Funktionen der einzelnen Komponenten kurz beschrieben.

SIP User-Agent (UA)

Das Pendant zum H.323-Terminal in der SIP-Umwelt ist der sogenannte „User Agent“. User-Agents bilden also Endpunkte von (Multimedia-)Kommunikation, die in der Regel als IP-Telefone in den verschiedensten Ausprägungen auftauchen.

  1. Je nach dem, welche Funktion ein UA gerade hat, wird zwischen zwei Zuständen unterschieden: Wird von einem UA eine Verbindung zu einem Server initiiert, so agiert der UA in diesem Moment als Client. Demzufolge trägt er die Bezeichnung User-Agent-Client (UAC).

  2. Operiert ein UA im Gegenzug dazu bei der Beantwortung einer Anfrage als Server, so wird er in diesem Status als User-Agent-Server (UAS) bezeichnet.

Da auch Gateways oder MCUs diese Funktionen ausführen und diese Zustände innehaben können, übernehmen diese unter anderem auch die Rolle eines oder mehrerer User-Agents.

SIP Registrierungsserver

Der Registrierungsserver verwaltet die angemeldeten Nutzer in einer ihm zugeordneten Netzwerkdomäne. Die User-Agents registrieren sich mittels der SIP-Nachricht „REGISTER“ beim Server. Dieser Vorgang wiederholt sich in periodischen Zeitintervallen. Neben den Informationen über Ort und SIP-Adresse können über diese Registrierung auch Angaben über Fähigkeiten und Präferenzen der Nutzer gemacht werden. Dies wird über variable Felder registriert, die verschiedenste Informationen enthalten können, wie zum Beispiel die gewünschte Erreichbarkeit („frei“, „nur dringend“, „nicht stören“ etc) oder die vom registrierten Teilnehmer gesprochenen Sprachen.

Proxyserver

Der Proxy stellt sicher, dass Verbindungsanfragen und -antworten zum richtigen Empfänger weitergeleitet werden. Er erfüllt in der SIP-Architektur in etwa die Funktion des Gatekeepers in der H.323-Umgebung . Allerdings verfügt ein Proxyserver über keinerlei Fähigkeiten, einen Medien-Strom zu verarbeiten, sondern er beantwortet nur Anfragen von User-Agents.

Umleitungsserver

Der Umleitungsserver stellt im Gegensatz zum Proxserver keine Verbindung her, sondern informiert anfragende User-Agents über die (neue, temporär andere) Erreichbarkeit anderer User. Diese Informationen bezieht er aus einer Datenbank. Anschließend wird durch den anfragenden User-Agent mit den aktualisierten Daten ein Verbindungsaufbau zum anderen User-Agent durchgeführt.

Technische Daten:

  • Ports: 5060 (SCTP, TCP, UDP) server default, 5061 (TLS)

  • Kodierung: Text - ISO 10646 Character Set in UTF-8 Enkodierung, komprimierbar mittels Signalling compression (RFC3320)

Ziel der SIP-Entwicklung war es ein Protokoll zu schaffen, das den Aufbau und die bereits bestehenden Dienste des Internet optimal nutzt und auch zukünftige Internet-Protokolle erfolgreich einbinden kann. Etwa wird die dezentrale Struktur bewusst genutzt, die Adressierung mittels URLs oder das DNS. SIP wird nicht nur für VoIP, sondern auch für Videokonferenzen und Instant Messaging verwendet.

Bei SIP wird ebenfalls das SDP-Protokoll verwendet. Im Prinzip besteht SIP nur darin den Verbindungsaufbau aufzubauen und wieder zu beenden. SIP wird deshalb gerne verwendet, weil VoIP und Standard-Internet-Dienste vergleichsweise einfach kombiniert werden können. Als Client-Server Protokoll ist es HTTP ähnlich. Flexibilität ist etwa dadurch gegeben, dass der Gesprächspartner zwar über SIP lokalisiert wird, dieser aber entscheiden kann, dass das Gespräch in H.323 stattfindet.

Folgende Protokolle werden von SIP verwendet bzw. integriert:

  • RSVP,

  • RTP,

  • RTSP,

  • SAP,

  • SDP.

Sowohl Anrufer als auch Empfänger bekommen eine SIP-URL (Nutzer@Rechner) zur eindeutigen Identifikation.

User
Der User besteht einerseits aus einem UAC User Agent Client und einem UAS User Agent Server. Der UAC startet die Anrufe, der UAS beantwortet eintreffende Anrufe.

  • Server
    SIP-Proxy-Server
    Dieser ist mit einem HTTP-Proxy vergleichbar. Er nimmt Anrufe entgegen und bestimmt, wohin diese weitergeroutet werden sollen.

  • Redirect-Server
    Diese benutzen etwa DNS um den Clients die entsprechenden Zielserver mitzuteilen.

Methode

Beschreibung

RFC

ACK

Datenverkehr wird bestätigt

3261

BYE

Beenden einer Session

3261

CANCEL

Löschen eines bereits verschickten Requests

3261

INFO

Übertragung zusätzlicher Lager-Informationen

2976

INVITE

Einladung an die Gegenseite zu einem Telefonat

3261

MESSAGE

Möglichkeit Instant Messages zu verschicken

3428

NOTIFY

Verständigung, dass ein bestimmtes Ereigniss stattgefunden hat

3265

OPTIONS

Anfrage über die Fähigkeiten der Gegenseite ? z.B. unterstützte Formate

3261

PRACK

Ähnlich wie ACK bestätigt diese Methode getätigte Datenübertragungen

3262

REFER

Der Empfänger soll den Sender zu einer externen Quelle weiterverbinden

3515

REGISTER

SIP-Client informiert den SIP-Server, wo er zu kontaktieren ist.

3261

SUBSCRIBE

Möglichkeit sich bei bestimmten Datenquellen anzumelden, um über Änderungen informiert zu werden.

3265

UPDATE

Übertragung von neuer Session-Information

3311

Tabelle 10: SIP-Methoden

Request Messages bestehen aus:

  • Method,

  • Request URI und

  • SIP Version.

Response Messages sind zusammengesetzt aus

  • SIP Version,

  • Status-Code und

  • Reason-Phrase.

Nach der ersten Header-Zeile können zahlreiche Informationen mitgeschickt werden, wie etwa Accept-Language, Accept-Encoding, Call-ID oder Timestamp.

Beispiel eines SIP-Requests:

INVITE sip: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. >'; document.write( '' ); document.write( addy_text96254 ); document.write( '<\/a>' ); //--> Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. ; From: Alice <sip: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. >'; document.write( '' ); document.write( addy_text84526 ); document.write( '<\/a>' ); //--> Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. ;;tag=1928301774 Call-ID: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. CSeq: 314159 INVITE Contact: <sip: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. >'; document.write( '' ); document.write( addy_text76772 ); document.write( '<\/a>' ); //--> Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. ; Content-Type: application/sdp Content-Length: 142

H.323 und SIP im Vergleich

Gemeinsamkeiten

Gerade eben die Gemeinsamkeiten dieser beiden Protokolle machen diese Gegenüberstellung erst sinnvoll. Beide Protokolle unterstützen die Funktionen der Signalisierung und des Session- Managements und erfüllen auf ihre jeweilige Art die grundlegenden Anforderungen an diese Aufgaben.

Derzeit wird sowohl in unterschiedlicher Literatur als auch im Internet eine intensive Diskussion über die Verwendbarkeit dieser beiden Protokolle geführt. Wesentlicher Inhalt ist es hierbei, festzustellen, ob das wesentlich jüngere Protokoll SIP in der Lage seien könnte, dem etablierten H.323 den Rang abzulaufen.

Obwohl beide Protokolle eigentlich das gleiche machen, gibt es wesentliche Unterschiede, die im Folgenden gegenübergestellt werden.

Strukturelle Unterschiede

Unabhängig von der Qualität oder der Art, wie die beiden Protokoll ihrer Aufgabe gerecht werden, gibt es wesentliche strukturelle Unterschiede zwischen ihnen.

Kodierung:
Das SIP ist ein rein textbasiertes Protokoll, d. h. sämtliche Kommunikation zwischen SIP-Komponenten erfolgt über formatierte Textmeldungen, die, vergleichbar zu (unverschlüsselter) e-mail, zwischen ihnen ausgetauscht werden. Im Gegensatz dazu steht die binärcodierte Ausprägung des H.323-Protokolls. Hier werden lange Signalisierungscodes verschickt, die gemäß „Abstract Syntax Notation One“ (ASN.1) codiert sind.

Herkunft:
Wie bereits erwähnt entstammt das SIP durch seine Entwicklung durch die IETF aus dem Internetumfeld und verwendet demzufolge entsprechende Standards und vorhandene Protokolle (Oder lehnt sich an ihnen an). Es verfolgt eher den „leichtgewichtigen“ Ansatz des HTTP. Die H.323-Protokollfamilie hingegen findet ihren Ursprung in der Signalisierung von leitungsvermittelten Diensten. Entsprechend komplex ist die gesamte H.323 Definition letztendlich geworden, basiert sie doch auf dem Q.931 Protokoll aus der ISDN-Welt und früheren Versionen aus der H.xxx-Serie.

Funktionale Unterschiede

Ein Teil der o.a. strukturellen Unterschiede führt letztendlich auch zu funktionalen Unterschieden und zu Kritikpunkten an dem einen oder dem anderen Protokoll. In der folgenden Tabelle werden schwerpunktartig Vor- und Nachteile der beiden Gegenspieler dargelegt. Der Klarheit halber werden hier nur Schwerpunkte genannt, außerdem wurde versucht, keine Vorteile des einen als Nachteile des anderen anzugeben, so dass Dopplungen vermieden werden, um die Vergleichbarkeit zu erhalten.

 

H.323

SIP

Vorteile

Präzise Spezifikation, inklusive der zu verwendendenAudio- und Video-Codecs Integrierte Lastverteilung (Load-Balancing) zwischen Gatekeepern Weite Verbreitung bei bestehenden Installationen und bei Produkten im Markt

Basiert auf etablierten und erprobten Grundelementen des Internets wie MIME, HTTP und DNS Hervorragende Administrier barkeit durch textbasiertes Protokoll Sog. „forking“ von Anrufen, d.h. die Weiterleitung von Anrufen auf mehrere Endgeräte nach gewissen Vorgabewerten.
Durch die geringe Größe leicht in mobile User-Agents zu implementieren.

Nachteile

ggf. langsamer Verbindungsaufbau (bis zu mehreren Sekunden)
komplexe Struktur als Ursache für Fehler und erhöhte Kosten

Abrechnungsdienste (Billing) schwerer zu implementieren
Anspruchsvollere Installation bei der Verwendung von Network Adress Translation (NAT).
Ohne funktionierende Basisdienste im Netzwerk (DNS, Proxys) nicht lauffähig

Tabelle 11: SIP versus H323

RTP (Real Time Transfer Protocol)

Das RTP ist in RFC1889 und ITU-TH.225 Annex A standardisiert.

Spachpakete bilden keinen isochronen Datenstrom, da Sprechpausen in der Datenubermittlung unterdrückt werden. Der Sender sendet einzelne Pakete mit Sprachdaten aus. Der Empfänger überträgt diese Pakete in einen Speicher, um daraus einen isochronen Datenstrom der Sprachdaten herzustellen. Der Speicher muss jederzeit einen ausreichenden Füllstand aufweisen, damit Laufzeitschwankungen auf der Paketebene ausgeglichen werden können.

Spachdaten werden mit UDP übertragen, weil UDP gegenüber TCP wegen seiner Verbindungslosigkeit für eine schnelle Übermittlung sorgt. Das im TCP vorhandene ARQ-Verfahren ist für eine Sprachdatenübertragung nicht hilfreich, da nachträglich angeforderte Sprachdaten nicht mehr gesendet werden können und verworfen werden müssen. Datenausfälle durch das UDP-Verfahren sind i.a. tolerierbar, da eine Silbenverständlichkeit von 60% bei einem Hörer noch zu einer Silbenverständlichkeit von 95% führt. Ausfälle von 5% der Pakete werden in der Spachverständlichkeit nicht wahrgenomen.

Das RTP stellt den Sprachdaten einen Header voraus, der die Daten durch eine Typbezeichnung (PayloadType), eine Sequenznummer und einen Zeitstempel kennzeichnet.

Im ersten Oktett wird ferner die Versions-Nummer angegeben, mit dem P-Bit(Padding) Füllbits im Datenbereich, mit dem X-Bit (Extension) eine Headererweiterung und mit dem M-bit (Marker) eine Sprechpausenunterdrückung gekennzeichnet.

Die Sprachdaten werden dem Header angefügt und als Profil bezeichnet. Die verwendeten UDP Port-Nummern sind bei RTP immer geradzahlig. Das dazugehörende Steuerprotokoll RTCP verwendet ungeradzahlige Port-Nummern. Die UDP-Ports haben die Defaultwerte 5004 und 5005.

Die digital kodierten Audiosignale werden über RTP-Kanäle zwischen den Geräten übertragen.

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

Ver

P

X

CSCR

M

Payload Type

Sequence Number

Timestamp

SSRC (Synchronisation Source Identifier)

CSRC (Contributing Source Identifier)

Extensions

Tabelle 12: RTP-Header

Abkürzung

Bit

Beschreibung

Ver, Version

2 bit

RTP Versionsnummr, derzeit 2

P, Padding

1 bit

Falls aktiviert, gibt es an, dass am Ende des Pakets weitere Bytes angehängt sind, die nicht Teil des Payloads sind, z.B. für eine eventuelle Verschlüsselung; das letzte Byte gibt an, wie viele Bytes ignoriert werden sollen.

X, Extension

1 bit

Falls aktiviert, folgt dem Header genau eine Erweiterung.

CC, CSRC count

4 bit

Zahl der CSRC Identifier, die vorkommen werden.

M, Marker

1 bit

Ein frier Marker, der vom jeweiligen Protokoll verscheiden verwendet werden kann.

PT, Payload Type

7 bit

Gibt an, welches Format das RTP transportiert. Beispiele:
4 ... G723, 9 ... G722, 26 ... JPEG, 34 ... H263;

Sequence Number

16 bit

Die fortlaufende Nummer des RTP-Pakets, sie erhöht sich jedes Mal um den Wert 1, allerdings fängt sie bei einer zufälligen Ziffer an, um mögliche Attacken zu erschweren. Durch die Nummerierung sind die Pakete sortierbar.

Timestamp

32 bit

Zeitpunkt der Generierung des ersten Bytes

SSRC, Synchronization source

32 bit

Zufällige Zahl und damit eindeutige ID der Synchronisations-Quelle (Eingabegerät wie z.B. Videokamera)

CSRC, Contributing source

32 bit

Array von 0 bis 15 als Liste der Quellen, die an der Synchronisation mitwirken

Tabelle 13: Erklärung zum RTP-Header

Das folgende RTCP-Protokoll wird zusammen mit dem RTP-Protokoll verwendet.

RTCP (Real Time Control Protocol)

Das RTCP ist ein Steuerprotokoll im Zusammenhang mit dem RTP. Es hat die Nachrichtentypen

  • SenderReport: Informationen zur Datenübertragung (RTP-Stream) desSenders.

  • ReceiverReport: Informationen zum Datenempfänger.

  • SourceDescription: Parameter der Quelle (z.B.Adressen).

  • Bye: Deaktivieren einer oder mehrererQuellen.

  • Application-defined RTCP Packet: Transport proprietärer Informationen.

RTCP Verbindungsauf- und -abbau.

DerVerbindungsauf- und -abbau zwischen H.323 Geräten nutzt die ISDN Q.931 Meldungen und führt sie in TCP-Kanälen durch. Die Abbildung XX zeigt die Signalisierung zwischen zwei H.323 Systemen ohne Gatekeeper-Aktivität im Verbindungsaufbau.

Abbildung XX

Aufgaben von RTCP:

  • Messen des QoS (Quality of Service)
    Diese Qualitätsüberwachung wird durch den regelmäßigen Austausch von Kontrollpaketen der Teilnehmer ermöglicht.

  • Identifizierung der Teilnehmer

  • Bandbreitenkontrolle der RTCP-Nutzung, da die Kontrollpakete die Datenpakete nicht behindern dürfen.

  • Session-Kontrolle
    Ein RTCP-Sendebericht besteht neben einem einfachen Header auch aus Sender-Informationen (timestamps, packet counts) und einem Block-Report, der Empfangsberichte beinhaltet.

Segment

Beschreibung

SSRC_x (SSRC of source x)

SSRC des zu analysierenden Geräts

fraction lost
cumulative number of packets lost

Verhältnis verlorene Pakete zu erwarteten Paketen
Absolute Anzahl verlorener Pakete

interarrival jitter

Mittlere Abweichung der Differenz D, des Abstands zweier empfangener RTP-Pakete und der Sender Timestamps

extended highest sequence number received
last SR

höchste erhaltene Sequenznummer
Mittlere 32 Bit der 64 Bits des Zeitstempels des Erzeugen des Empfangsberichts

delay since last SR

Verzögerung des Empfangs des letzten SR-Paketes und dem Absenden des Empfangsberichtes

Tabelle 14: Aufbau eines RTCP Report-Blocks

SGCP (Simple Gateway Control Protocol)

Hiermit steuern Gateway-Controller (auch „Call-Agents“ genannt) Telefon-Gateways, die PSTN- Telefonate in IP-Pakete konvertieren.

  • Port: 153 (UDP)

  • Kommandos:
    CreateConnection, ModifyConnection, DeleteConnection, NotificationRequest, Notify Komponenten des Befehls: Kommandozeile, Transaction ID, Empfängeradresse, Protokollversion, Parameter-Set

Verbindung von Netzen mit verschiedenen VoIP-Protokollen

TDM (Translation through time-division multiplexing)

Hierbei werden entweder TDM-Geräte oder VoIP-Gateways verwendet um ein Protokoll in das andere zu übersetzen. Der Nachteil besteht in einer zeitlichen Verzögerung bei der VoIP Übertragung, die wegen der zweifachen Übersetzung des VoIP-Protokolls nötig ist (VoIP1 zu TDM zu VoIP1). Deshalb wird diese Lösung meist nur kurzfristig verwendet.

  • Single protocol architecture
    Dabei werden alle VoIP-Dienste auf ein einheitliches Protokoll umgestellt, um das Netzwerk als Gesamtes zu vereinfachen. Es ist allerdings möglich, dass sich bestimmte Geräte oder auch Software nicht auf das neue VoIP-Protokoll umstellen lassen. Weiters hat diese Lösung den Nachteil, dass die Verbindung zu anderen VoIP-Netzen mit anderen Protokollen erschwert wird.

  • Protocol translation
    IP-basierte Protokoll-Übersetzer stellen hier die Brücke zwischen den unterschiedlichen VoIP-Netzen dar. Die Vorteile bestehen darin, dass weder Verzögerungen auftreten, noch dass bestehende Anwendungen verändert werden müssen.

Sicherheit

Mit der Übergabe der Kontrolle von Telefonnetzen an Internet-Server werden die neuen IP-Telefonnetze anfällig für übliche Internet-Attacken wie DDoS (Distributed Denial of Service) oder etwa Viren. Ein weiteres Sicherheitsrisiko wäre die Möglichkeit in schlecht abgesicherte VoIP Systeme einzudringen und Telefongespräche auf Kosten der Eigentümer zu führen. Grundsätzlich ist es förderlich die Sicherheitsplanung in zwei Bereiche zu unterteilen ? einerseits im Absichern der Netzwerkinfrastruktur, andererseits im Schutz des Inhalts der VoIP-Übertragungen. Grundsätzlich ist zu sagen, dass das Abhören von VoIP-Übertragungen über das öffentliche Internet jedenfalls abhörsicherer ist, als unverschlüsselte GSM-Telefonate. Mögliche Sicherheitsmaßnahmen, die zusätzlich zu den üblichen Internet-Sicherheitsmaßnahmen zu treffen sind, sind folgende:

  • Trennung der IP Adressbereiche des Standard-LANs und der des IP PBX
    (PBX - Private Branch Exchange - der Netzknotenpunkt für die IP Telefonate)

  • Isolieren der VoIP-Datenübertragungen auf ein eigenes virtuelles LAN

  • Reduktion der Protokolle, die den IP PBX ansprechen können bzw. das VoIP VLAN

  • Verschlüsseln des VoIP Datenverkehrs wenn möglich
    SIP unterstützt VoIP mit SSL, PGP und S/MIME, H.323 nutzt das H.325 eigene Verschlüsselungsprotokoll und unter gewissen Bedingungen auch SSL. [17]

  • Möglichst frühes Einbinden der Sicherheitsplanung beim Ankauf von VoIP Systemen für Unternehmen

  • Die automatische Registrierung von Telefonen für Enduser deaktivieren

  • Öffentlich zugängliche Telefone mit langen Passwörtern und langen Login-Nummern sichern

Ein Beispiel für die Verwundbarkeit von SIP wurde im Februar 2003 von einer finnischen Universität gefunden. Es stellte sich heraus, dass zumindest einige bekannte VoIP Produkte verwundbar für DDoS-Attacken, unbefugten Zugang oder System-Unterbrechungen waren. Mittlerweile sind die Sicherheitslücken bereinigt worden.

Literaturverzeichnis

Ref

Titel

[1]

Alcatel; http://www.alcatel.com; Stand Mai 2003

[2]

Allnet Devices, „Symbol Launches Voice Over Wi-Fi Pocket PC“,
http://www.allnetdevices.com/wireless/news/2003/05/21/symbol_launches.html; Mai 2003

[3]

CERT Coordination Center, „CERT Advisory CA-2003-06 (SIP)“,
http://www.cert.org/advisories/CA-2003-06.html

[4]

Cisco; http://www.cisco.com; Stand Mai 2003

[5]

Cisco, "Understanding Packet Voice Protocols (White Paper)", http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a008009294d.shtml; Jänner 2003

[6]

Cisco, "Understanding Voice over IP Protocols", http://www.cisco.com/application/pdf/en/us/guest/tech/tk587/c1506/ccmigration_09186a008012dd36.pdf; Februar 2003

[7]

Ente Regulador de los Servicios Públicos, "Resolución N°: JD-3576",
http://www.ersp.gob.pa/busqueda/show_resol.asp?id=JD-3576&;idsector=1; Oktober 2002

[8]

Heise Online, "IETF kümmert sich um Abhörstandards",
http://www.heise.de/newsticker/data/uma-21.04.03-003/; April 2003

[9]

eise Online, "Oberster Gerichtshof hebt VoIP-Blockade in Panama auf",
http://www.heise.de/newsticker/data/pmz-27.11.02-000/; November 2002

[10]

Heise Online, "Panama blockiert Internet-Telefonie",
http://www.heise.de/newsticker/data/pmz-04.11.02-000/; November 2002

[11]

Heise Online, "Rückkehr der Phone Phreaker?",
http://www.heise.de/newsticker/data/dab-08.05.03-002/; Mai 2003

[12]

IETF, "Internet Draft (VoIP-Lawful Intercept)",
http://www.rfc-editor.org/internet-drafts/draft-baker-slem-architecture-01.txt; Juni 2003

[13]

IETF, "RFC 2804 (Wiretaping)", ftp://ftp.rfc-editor.org/in-notes/rfc2804.txt; Mai 2000

[14]

IETF, "RFC 3015 (Megaco)", ftp://ftp.rfc-editor.org/in-notes/rfc3015.txt; November 2003

[15]

IETF, "RFC 3261 (SIP)", ftp://ftp.rfc-editor.org/in-notes/rfc3261.txt; Juni 2002

[16]

IETF, "RFC 3435 (MGCP)", ftp://ftp.rfc-editor.org/in-notes/rfc3435.txt; Jänner 2003

[17]

Information Security Magazine, "Is VoIP Secure? You make the call.", http://www.infosecuritymag.com/2003/apr/voipsecure.shtml; April 2003

[18]

Inode, "Inode realisiert als erster ISP Voice over IP für Endkunden", http://www6.inode.at/aktuelles/aktuelles.php?ID=752; Mai 2003

[19]

Inode, "iTALK VoIP private", http://www6.inode.at/produkte/privat/telefonie/telefonie/italk_voip.html; Stand Mai 2003

[20]

Inode, "Telefonier FAQ", http://www6.inode.at/support/telefonie/italk_faq.php?Article_ID=all; Stand Mai 2003

[21]

M. Hein, M. Reisner; "TCP/IP"; mitp-Verlag/Bonn; 2001

[22]

NetIQ; http://www.netiq.com; Stand Mai 2003

[23]

Network Sorcery, "RFC Sourcebook", http://www.networksorcery.com/enp/default0502.htm; April 2003

[24]

NetworkWorldFusion, "Is VoIP vulnerable?", http://www.nwfusion.com/news/2002/0624voip.html; Juni 2002

[25]

Nortel Networks; http://www.nortelnetworks.com; Stand Mai 2003

[26]

Packetizer, "H.323 Information Site", http://www.packetizer.com/iptel/h323/; April 2003

[27]

Palm, "Palm Announces Alliances in Voice Over IP, Wi-Fi and Security For Palm Tungsten C Handheld Users", http://pressroom.palm.com/InvestorRelations/PubNewsStory.aspx?

[28]

Protocols.com, "VoIP Standards", http://www.protocols.com/voip/standards.htm; Jänner 2003

[29]

R.D. Köhler; "Voice over IP"; mitp-Verlag/Bonn; 2002

 

 

[30]

Shirky.com, "Customer-owned Networks: ZapMail and the Telecommunications Industry", http://www.shirky.com/writings/zapmail.html; Jänner 2003

[31]

Siemens; http://www.siemens.com; Stand Mai 2003

[32]

Universität Oulu (Finnland), Protos Test-Suite: c07-sip, http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/; Februar 2003

[33]

What PC, "IP telephony at risk from hack attacks", http://www.whatpc.co.uk/News/1134874; 01.09.02

[34]

Real Time Protocol, RFC 1889

[35]

Cisco AVVID (Architecture for Voive, Video and Integrated Data)
http://www.cisco.com/go/avvid

[36]

Cisco SIP Homepage
http://www.cisco.com/warp/public/cc/techno/tyvdve/sip/

[37]

VoIP Bandwidth Calculator
http://www.packetizer.com/iptel/bandcalc.html

[38]

Open Source Voice Software (SIP Phone)
http://www.vovida.org/

[39]

Ethereal Sniffer mit H.323 und Skinny
http://www.voice2sniff.org/

[40]

Übersicht über IP Phones
http://iptel.org/info/products/allproducts.php

  1. Abkürzungsverzeichnis

A/D

Analog/Digital

ASN.1

Abstract Syntax Notation One

CLIP

Calling Line Identification Presentation

D/A

Digital/Analog

DHCP

Dynamic Host Configuration Protocol

DNS

Domain Name System

FeM

Forschungsgemeinschaft elektronische Medien

GUI

Graphical User Interface

http/HTTP

Hypertext Transfer Protocol

IETF

Internet Engineering Task Force

IP

Internet Protocol

ISDN

Integrated Services Digital Network

ITU

International Telecommunication Union

KHz

Kilohertz

LAN

Local Aerea Network

LCR

Least Cost Router

LIM

Line Interface Module

MAC

Media Acess Control

MCU

Multi Point Control Unit

MIME

Multipurpose Internet Mail Extensions

MSISDN

Mobile Subscriber ISDN

NAT

Network Adress Translation

PBX

Private Branch Exchange

PSTN

Public Switched Telephone Network

RAS

Registration, Admission, Status

RFC

Request For Comments

RTCP

Realtime Transport Control Protocol

RTP

Realtime Transport Protocol

SIP

Session Initiation Protocol

SS7

Signalling System Number 7

TCP

Transmission Control Protocol

tftp

Trivial File Transfer Protocol

TK

Telekommunikation

UA

User Agent

UAC

User Agent Client

UAS

User Agent Server

UDP

User Datagram Protocol

VoIP

Voice over IP

VLAN

Virtual LAN

WAN

Wide Aerea Network

Anlagen

RFC983 / TPKT

5. The Protocol

   It is the goal of this memo to offer a TP interface on top of the
   TCP.  Fortunately, the TCP does just about everything that
   TS-provider offers to the TS-user, so the hard parts of the transport
   layer (e.g., three-way handshakes, choice of ISS, windowing,
   multiplexing, ad infinitum) are all taken care of by the TCP.

   Despite the symmetry of TP, it is useful to consider the protocol
   with the perspective of a client/server model.

   The information exchanged between TSAP-peers is in the form of
   packets termed "TPKT"s.  The format of these packets is described in
   the next section.  For the purposes of the description below, a TPKT
   has a code which is one of:

      CR - request connection
      CC - confirm connection
      DR - request disconnection
      DT - data
      ED - expedited data

   A TSAP server begins by LISTENing on TCP port 102.  When a TSAP
   client successfully connects to this port, the protocol begins.

   A client decides to connect to the port when a TS-user issues a
   T-CONNECT.REQUEST action.  This action specifies the TSAP ID of the
   remote TS-user, whether expedited data is to be supported, and
   (optionally) some initial TS-user data.  The client consults the TSAP
   ID given to ascertain the IP address of the server.  If the expedited
   data option was requested, the client opens a passive TCP port, in
   non-blocking mode, noting the port number.  This TCP port is termed
   the "expedited port".  The client then tries to open a TCP connection
   to the server on port 102.  If not successful, the client fires
   T-DISCONNECT.INDICATION for the TS-user specifying the reason for
   failure (and, closes the expedited port, if any).  If successful, the
   client sends a TPKT with code CR containing:

      - the TSAP ID of the TS-user on the client's host (the "caller")
      - the TSAP ID of the TS-user that the client wants to talk to
        (the "called")
      - if the expedited data option was requested, the TSAP ID of the
        expedited port for the client's host
      - any TS-user data from the T-CONNECT.REQUEST

   The client now awaits a response.

   The server, upon receipt of the TPKT, validates the contents of the
   TPKT (checking the version number, verifying that the code is CR, and
   so forth).  If the packet is invalid, the server sends a TPKT with
   code DR specifying "PROTOCOL ERROR", closes the TCP connection, and
   goes back to the LISTEN state.

   If the packet is valid, the server examines the TSAP ID that the
   remote TS-user wants to communicate with.  If the TS-user specified
   can be located and started (e.g., the appropriate program which
   implements the indicated protocol is present), then the server starts
   this TS-user by firing T-CONNECT.INDICATION.  Otherwise, the server
   sends a TPKT with code DR specifying "SESSION ENTITY NOT ATTACHED TO
   TSAP" or "REMOTE TRANSPORT ENTITY CONGESTED AT CONNECT REQUEST TIME"
   as appropriate, closes the TCP connection, and goes back to the
   LISTEN state.

   The server now waits for a T-CONNECT.RESPONSE or T-DISCONNECT.REQUEST
   from the TS-user it started.  if the latter is given, the server
   sends a TPKT with code DR containing the reason for the disconnect as
   supplied by the TS-user.

   The server then closes the TCP connection and goes back to the LISTEN
   state.

   Instead, if T-CONNECT.RESPONSE is given, the server sees if an
   expedited port was specified in the connection request.  If so, the
   server opens a second TCP connection and connects to the specified
   port.  If the connection fails, the server sends a TPKT with code DR
   specifying "CONNECTION NEGOTIATION FAILED", closes the TCP
   connection, and goes back to the LISTEN state.  If the connection
   succeeded, the server notes the local port number used to connect to
   the expedited port.

   If an expedited port was not specified in the TPKT with code CR, and
   the server's TS-user indicates that it wants to use expedited data,
   then the server sends a TPKT with code DR specifying "CONNECTION
   NEGOTIATION FAILED", fires T-DISCONNECT.INDICATION with this error to
   the TS-user, closes the TCP connection, and goes back to the LISTEN
   state.

   The server now sends a TPKT with code CC containing:

      - the TSAP ID of the TS-user responding to the connection
        (usually the "called")
      - if an expedited port was specified in the TPKT with code CR,
        the TSAP ID of the port number on the server's host that was
        used to connect to the expedited port
      - any TS-user data from the T-CONNECT.RESPONSE

   After sending the TPKT, the server enters the SYMMETRIC PEER state.

   The client, upon receipt of the TPKT, validates the contents of the
   TPKT (checking the version number, verifying that the code is CC or
   DR, and so forth).  If the packet is invalid, the client sends a TPKT
   with code DR specifying "PROTOCOL ERROR", fires
   T-DISCONNECT.INDICATION with this error to the TS-user, and closes
   the TCP connection (and the expedited port, if any).

   If the packet's code is DR, the client fires T-DISCONNECT.INDICATION
   with the reason given in the TPKT to the TS-user, and closes the TCP
   connection (and the expedited port, if any).

   If the packet's code is CC, the client checks if an expedited port
   was specified and that a connection is waiting on the expedited port.
   If not, a protocol error has occurred, a TPKT with code DR is
   returned, T-DISCONNECT.INDICATION is fired, and so on.  Otherwise,
   the client checks the remote address that connected to the expedited
   port.  If it differs from the port listed in the TPKT with code CC, a
   protocol error has occurred.  Otherwise, all is well, two TCP
   connections have been established, one for all TPKTs except expedited
   data, and the second for the exclusive use of expedited data.

   The client now fires T-CONNECT.CONFIRMATION, and enters the SYMMETRIC
   PEER state.

   Once both sides have reached the SYMMETRIC PEER state, the protocol
   is completely symmetric, the notion of client/server is lost.  Both
   TS-peers act in the following fashion:

   If the TCP indicates that data can be read, the TS-peer, upon receipt
   of the TPKT, validates the contents.  If the packet is invalid, the
   TS-peer sends a TPKT with code DR specifying "PROTOCOL ERROR", fires
   T-DISCONNECT.INDICATION with this error to the TS-user, and closes
   the TCP connection (and expedited data connection, if any).  If the
   TS-peer was the server, it goes back to the LISTEN state.

      NOTE:  If the expedited data option was requested, then there are
      two TCP connections that can supply data for reading.  The
      dialogue below assumes that only ED TPKTs are read from the
      expedited data connection. For simplicity's sake, when reading
      from TCP the relation between connections and TPKTs is unimportant
      and this memo URGES all implementations to be very lenient in this
      regard.  When writing to TCP, implementations should use the
      expedited data connection only to send TPKTs with code ED.
      Section 7 of this memo discusses the handling of expedited data in
      greater detail.

   If the packet's code is DR, the TS-peer fires T-DISCONNECT.INDICATION
   with the reason given in the TPKT to the TS-user, and closes the TCP
   connection (and expedited data connection, if any).  If the TS-peer
   was the server, it goes back to the LISTEN state.

   If the packet's code is ED or DT, the TS-peer fires T-DATA.INDICATION
   or T-EXPEDITED DATA.INDICATION as appropriate with the enclosed user
   data for the TS-user.  It then goes back to the SYMMETRIC PEER state.

   If the packet is invalid, the TS-peer sends a TPKT with code DR
   specifying "PROTOCOL ERROR", fires T-DISCONNECT.INDICATION with this
   error to the TS-user, and closes the TCP connection (and expedited
   data connection, if any).  If the TS-peer was the server, it goes
   back to the LISTEN state.

   If the TCP indicates that an error has occurred and the connection
   has closed, then the TS-peer fires T-DISCONNECT.INDICATION to the
   TS-user specifying the reason for the failure.  If the expedited data
   connection, if any, is still open, it is closed.  If the TS-peer was
   the server, it goes back to the LISTEN state.

   If the TS-user issues a T-DATA.REQUEST or T-EXPEDITED DATA.REQUEST
   action, the TS-peer sends a TPKT with code DT or ED containing the
   TS-user data.  It then goes back to the SYMMETRIC PEER state.

   If the TS-user issues a T-DISCONNECT.REQUEST action, the TS-peer
   sends a TPKT with code DR containing the reason for the disconnect as
   supplied by the TS-user.  The TS-peer then closes the TCP connection,
   (and expedited data connection, if any).  If the TS-peer was the
   server, it goes back to the LISTEN state.

   In terms of (augmented) state tables, the protocol can be explained
   as follows.  The server starts in state S0, the client starts in
   state C0.  "TCP:"  refers to an event or action from the TCP service,
   "SS:"  refers to an event or action from the TS-user (e.g., the ISO
   session service [ISO-8327]).

Serverstates

   state        event                   action                      goto
   -----        -----                   ------                      ----
   S0                                   TCP: listen on port 102     S1

   S1           TCP: connected          TCP: read TPKT
                                        parse, on error
                                          TCP: send DR, close       S0
                                        code is CR
                                          start session server
                                          SS: T-CONNECT             S2
                                                .INDICATION
                                        otherwise,
                                          TCP: send DR, close       S0

   S2           SS: T-CONNECT.RESPONSE  if expedited option,
                                          TCP: open port EXPD
                                        TCP: send CC                P0

   S2           SS: T-DISCONNECT        TCP: send DR, close         S0
                        .REQUEST

   Any event occuring for a state not listed above is considered an
   error, and handled thusly:

   state        event                   action                      goto
   -----        -----                   ------                      ----
   S*           TCP: other              if TCP is open, TCP: close  S0
                                        otherwise ignore            S0
   S*           SS: other               SS: T-DISCONNECT
                                              .INDICATION
                                        if TCP is open, close       S0

Clientstates

   state        event                   action                      goto
   -----        -----                   ------                      ----
   C0           SS: T-CONNECT.REQUEST   if expedited option,
                                          TCP: non-blocking
                                               listen on port EXPD
                                        TCP: open port 102          C1

   C1           TCP: connected          TCP: send CR                C2

   C1           TCP: connect fails      TCP: close
                                        SS: T-DISCONNECT            C0
                                                 .INDICATION

   C2           TCP: data ready         TCP: read TPKT
                                        parse, on error
                                          TCP: send DR, close
                                          SS: T-DISCONNECT          C0
                                                .INDICATION
                                        code is CC
                                          if expedited option,
                                             verify port EXPD
                                             connected correctly,
                                             if not, treat as error
                                          SS: T-CONNECT             P0
                                                .CONFIRMATION
                                        code is DR
                                          TCP: close
                                          SS: T-DISCONNECT          C0
                                                .INDICATION
                                        otherwise
                                          TCP: send DR, close
                                          SS: T-DISCONNECT          C0
                                                .INDICATION



   Any event occuring for a state not listed above is considered an
   error, and handled thusly:

   state        event                   action                      goto
   -----        -----                   ------                      ----
   C*           TCP: other              if TCP is open, close       C0
                                        otherwise ignore            C0

   C*           SS: other               SS: T-DISCONNECT
                                              .INDICATION
                                        if TCP is open, close       C0

Peerstates

   state        event                   action                      goto
   -----        -----                   ------                      ----
   P0           TCP: data ready         TCP: read TPKT
                                        parse, on error
                                          TCP: send DR, close
                                          SS: T-DISCONNECT          end
                                                .INDICATION
                                        code is DT
                                          SS: T-DATA.INDICATION      P0
                                        code is ED
                                          SS: T-EXPEDITED DATA       P0
                                                .INDICATION
                                        code is DR
                                          TCP: close
                                          SS: T-DISCONNECT          end
                                                .INDICATION
                                        otherwise
                                          TCP: send DR, close
                                          SS: T-DISCONNECT          end
                                                .INDICATION

   P0           TCP: other              TCP: close
                                        SS: T-DISCONNECT            end
                                                  .INDICATION

   P0           SS: T-DATA.REQUEST      TCP: send DT                 P0

   P0           SS: T-EXPEDITED DATA    TCP: send ED                 P0
                        .REQUEST

   P0           SS: T-DISCONNECT        TCP: send DR, close         end
                        .REQUEST

   P0           SS: other               TCP: send DR, close
                                        SS: T-DISCONNECT            end
                                                .INDICATION

 

© IT CONSULTING WOLFINGER - An Engineering Approach to Voice over IP