Die Übermittlung von Sprache über paketvermittelte Netze gewinnt zunehmend an Bedeutung. Das IP-Protokoll eignet sich zur Übertragung von Sprache sowohl in LANs und Intranets, also auch zwischen Endnutzern im Weitverkehrsbereich. Während konventionelle, leitungsvermittelte Telefonie über identische Netzwerkknoten in Verbindung mit konstanten Übermittlungszeiten und einem hohen Grad an Sicherheit erfolgt, sieht sich VoIP mit den charakteristischen Eigenschaften von IP-basierter Kommunikation konfrontiert, wozu insbesondere variable Übermittlungspfade und –zeiten und ein höheres Maß an Angreifbarkeit gehören. Maßnahmen zur Gewährleistung von Quality of Service und Sicherheit sind somit essentiell. Die Funktionalität der an VoIP beteiligten Protokolle RTP, H.323 und SIP mit ihren Substandards, ihr Ineinandergreifen sowie die Integration mit leitungsvermittelten Netzen werden umfassend dargestellt.
Inhaltsverzeichnis
Abkürzungsverzeichnis
Abbildungsverzeichnis
1 Einleitung
1.1 Ziel der Arbeit
1.2 Entstehung und Entwicklung der Telefonie
1.3 Begriffsbestimmung von VoIP
1.4 Entwicklung von VoIP
2 Grundlagen von VoIP
2.1 Signalisierung in konventionellen Telefonnetzen
2.2 Kommunikationsprotokolle in Datennetzen
2.3 DNS und ENUM
3. Sprachcodierung und Echtzeitkommunikation
3.1 Abtastwert-orientierte Sprachcodierung
3.2 Segment-orientierte Sprachcodierung
3.3 Konzept der Protokollfamilie RTP / RTCP
3.4 Headerkomprimierung durch CRTP / ROHC
4 Signalisierungsprotokolle
4.1 H.323-Protokollfamilie
4.1.1 H.225.0
4.1.2 Schritte beim Verbindungsauf- und -abbau unter H.323
4.1.3 H.245
4.1.4 Anrufsignalisierungsformen beim Gatekeeper-Einsatz
4.1.5 Fast Connect Prozedur
4.1.6 Integration von VoIP über H.323 mit ISDN
4.1.7 Supplementary Services in H.323
4.1.8 Roaming unter H.323
4.1.9 H.235
4.2 SIP
4.2.1 Signalisierung und Adressierung
4.2.2 SDP
4.2.3 SIP-Betriebsarten
4.2.4 Besondere SIP-Dienste
4.2.5 Integration von VoIP über SIP mit ISDN
4.3 Protokollumsetzung zwischen H.323 und SIP
4.4 SIP-Sicherheit
5 VoIP-Gateways
5.1 Media Gateway Control Protokoll
5.2 Megaco (H.248)
6 Routing zwischen IP-Zonen
6.1 TRIP
6.2 Vernetzung von VoIP-Zonen bei Verwendung von H.323 und SIP
6.3 NAPT bei VoIP
6.3.1 STUN
6.3.2 TURN
6.3.3 ICE
6.3.4 UPnP
6.3.5 SIP – Symmetric Response Routing
6.3.6 Symmetric RTP
6.3.7 Application Layer Gateways
6.3.8 H.460
7 Qualitätsanforderungen von VoIP
7.1 Delay
7.2 Echos
7.3 Verzerrungen
7.4 Qualitätssicherung in der VoIP-Übermittlung
7.4.1 Layer-2-Priorisierung
7.4.2 Layer-3-Priorisierung
7.4.3 Queue-Management
7.4.4 Resource Reservation Protocol
8 VoIP-Security
8.1 Angriffe auf Hard- und Softwareebene
8.2 Sicherung der Nutzdatenübertragung
8.2.1 SRTP
8.2.2 ZRTP
8.3 VoIP-Sicherheitskonzepte
8.4 Angriffsklassen bei VoIP
8.5 Bedrohungen in VoIP-Umgebungen
8.6 Firewalls
8.7 IDS / IPS
8.8 Sicherheitsanforderungen von VoIP-Infrastrukturen
8.9 Planung der VoIP-Sicherheit
9 VoIP-Migration
9.1 Sanfte Migration
9.2 Harte Migration
9.3 Planung und Realisierung einer Migration zu VoIP
10 Bewertung und Ausblick
Literaturverzeichnis
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildungsverzeichnis
Abb. 1: Essentielle Schicht-3-Nachrichten im D-Kanal-Protokoll
Abb. 2: Essentielle SS7-Nachrichten
Abb. 3: Auf- und Abbau einer ISDN-Verbindung zwischen zwei Telefonen
Abb. 4: ENUM-URI-Verweis auf NAPTR Resource Record
Abb. 5: Grundprinzip der Sprachübermittlung über ein IP-Netz
Abb. 6: Digitalisierung eines analogen Signals bei linearer Quantisierung
Abb. 7: VoIP-relevante Sprachcodierungsverfahren
Abb. 8: Phasen bei der Sprachkommunikation über ein IP-Netz
Abb. 9: RTP und RTCP als Anwendungen oberhalb von UDP
Abb. 10: Isochronität mit Hilfe eines Jitter-Ausgleichpuffers
Abb. 11: Schritte vor der Audio-/Video-Übermittlung unter H.32
Abb. 12: capabilityTable und capabilityDescriptor eines Terminals
Abb. 13: Protokollfamilie TCP/IP und H.323-Komponenten
Abb. 14: H.225.0-Anrufsignalisierung mit Gatekeeper-Beteiligung
Abb. 15: Über Gatekeeper geroutete H.225.0-Anrufsignalisierung
Abb. 16: Ablauf der Fast Connect Prozedur
Abb. 17: H.225.0-Verlauf zwischen IP-Telefon und ISDN-Telefon beim FCP-Einsatz
Abb. 18: Registrierung eines Teilnehmers in einer Fremd-Zone der Heimat-Domain
Abb. 19: Registrierung eines Teilnehmers in einer Fremd-Zone einer Fremd-Domain
Abb. 20: Ankommender Anruf zu einem Gast beim Intra-Domain-Roaming
Abb. 21: Abgehender Anruf von einem Gast-Teilnehmer bei Inter-Domain-Roaming
Abb. 22: Darstellung der Verteilung der Zustände Client und Server am Beispiel einer SIP-Session
Abb. 23: Aufbau einer SIP-Nachricht am Beispiel einer INVITE-Anfrage
Abb. 24: Aufbau eines Request REGISTER
Abb. 25: Beispiel für einen SIP-Verlauf im Proxy-Mode
Abb. 26: SIP-Verlauf beim Request-Routing
Abb. 27: Einsatz eines Redirect-Servers in einer SIP-Umgebung
Abb. 28: Beispiel für einen SIP-Verlauf im Redirect-Mode
Abb. 29: SIP-Verlauf bei einer Anrufverzweigung
Abb. 30: SIP-Verlauf bei einer Anrufweiterleitung bei Besetzt
Abb. 31: SIP-Verlauf bei einer Anrufweiterleitung nach Timeout
Abb. 32: Abbildung von SIP auf das D-Kanal-Protokoll
Abb. 33: Darstellung eines Verbindungsaufbaus zwischen einem SIP- und einem H.323-Endsystem über ein Gateway ohne Fast Connect Procedure
Abb. 34: Bedeutung der MG-Protokolle bei der Integration eines IP-Netzes mit dem ISDN
Abb. 35: Aufbau einer RTP-Session beim Einsatz mehrerer Call Agents
Abb. 36: Media-Gateway als logisches System
Abb. 37: Aufbau einer Verbindung bei der Integration von VoIP und ISDN
Abb. 38: Routing abgehender Anrufe aus einer VoIP-Zone
Abb. 39: Routing eines ankommenden Anrufs aus dem ISDN zu einer H.323-Zone
Abb. 40: Routing eines ankommenden Anrufs aus dem ISDN zu einer VoIP-Zone mit SIP
Abb. 41: Einfluss von Paketverlustrate und Verzögerung auf die VoIP-Sprachqualität
Abb. 42: Jitter-Ausgleichspuffer und Paketverlustrate
Abb. 43: Struktur eines Queue-Management-Systems
Abb. 44: Router mit fünf Paketen, die für eine Ausgangsleitung anstehen
Abb. 45: Aufbau einer Punkt-zu-Punkt-Verbindung mit garantierter Bandbreite
Abb. 46: Phasen beim Verlauf des VoIP-Sicherheitsprozesses
Abb. 47: Logisches Netzwerkmodell aus Sicht der VoIP-Sicherheit
Abb. 48: Vorschlag für eine Grobeinstufung von Risiken
Abb. 49: Hybride Systemarchitektur am Einzelstandort
Abb. 50: Standortübergreifende hybride VoIP-Systemarchitektur mit zentraler
Anrufsteuerung
Abb. 51: Reine VoIP-Systemarchitektur am Einzelstandort
Abb. 52: Verteilte VoIP-Systemarchitektur mit zentraler Steuerung ankommender und abgehender Anrufe
1 Einleitung
1.1 Ziel der Arbeit
Diese Diplomarbeit beschäftigt sich mit der Sprachkommunikation über digitale Netze, welche das Internet-Protokoll (IP) als Grundlage zur Vermittlung von Daten zwischen Sendern und Empfängern verwenden. Ziel ist, die technischen Grundlagen und die Funktionsweise von Voice over IP (VoIP) heraus zu arbeiten und eine Einordnung dieses Dienstes in den Kontext der Internetstruktur und –prozesse darzustellen. Dabei sollen insbesondere die distinktiven Netzwerkanforderungen von VoIP gegenüber herkömmlichen Datendiensten, vor allem hinsichtlich Quality of Service, herausgearbeitet werden. Ein weiteres Gewicht liegt auf der Darstellung der durch VoIP verwendeten Protokolle und deren Interaktion untereinander. Ein besonderer Schwerpunkt wird auf die spezifischen Schwachstellen und Bedrohungen von VoIP und die notwendigen zu implementierenden Sicherheitsmaßnahmen gelegt.
1.2 Entstehung und Entwicklung der Telefonie
Die Anfänge des Telefons gehen etwa 150 Jahre zurück. Im Jahr 1861 veröffentlichte der deutsche Physiker Johann Philipp Reis erstmals ein telefonartiges Gerät, das Töne und Sprache mittels elektrischer Signale übermitteln konnte. Die Aufnahme der Audiosignale erfolgte über einen Platinstreifen und eine Feder, die die Schwingungen von einem Stück Wursthaut, welches über ein hölzernes Ohrmodell gespannt war, abtasteten. Auch wenn die Signalübermittlung nur unidirektional erfolgte, war die Qualität der rückerzeugten Sprache durchaus gut. Reis vollbrachte es jedoch nicht, seine Erfindung für eine allgemeine Anwendbarkeit weiterzuentwickeln.
Im Jahr 1876 meldete der US-Amerikaner Alexander Graham Bell ein Patent für ein Telefongerät an, das sich auch kommerziell nutzen ließ. Die Erkenntnisse der elektromagnetischen Induktion nutzend erzeugte das Gerät durch Schwingungen einer Membram elektrische Schwingungen, die eine bidirektionale Kommunikation zwischen beiden Gesprächspartnern ermöglichte. Das Telefon war jedoch sehr unergonomisch – durch die eng aneinander liegende Anordnung des Mikrofons und des Lautsprechers in einem Handstück musste dieses während des Gesprächs wechselnd an den Mund oder das Ohr gehalten werden. Lediglich um zwei Stunden verspätet gegenüber Bell versuchte der US-Amerikaner Elisha Gray, einen Telefonapparat patentieren zu lassen. Die USA haben im Jahr 2002 offiziell beschlossen, den US-Italiener Antonio Santi Guiseppe Meucci als Erfinder des Telefons anzuerkennen, nachdem dieser im Jahr 1871 ein Patent für ein Telefon beantragt hatte, das bereits 1874 wieder endete, da Meucci nicht in der Lage war, die Patentgebühren aufzubringen.
Das Grundprinzip der analogen Telefonie hat sich seitdem nicht signifikant verändert. Verbesserungen gab es vor allem in ergonomischer Hinsicht durch die schrumpfende Größe der Geräte und durch die Einführung des Tastentelefons in den 1970er Jahren.[1]
Einen wesentlichen Wandel erfuhr das Telefonnetz in Europa mit seiner flächendeckenden Digitalisierung und der Einführung des ISDN (Integrated Services Digital Network). Grundmerkmal von ISDN am einfachen Basis-Anschluss (Basic Rate Interface) ist die Bereitstellung von zwei voneinander unabhängigen logischen Leitungen, die zwischen Netzabschluss (Network Termination) und der Teilnehmervermittlungsstelle über eine Zweidraht-Verkabelung geführt werden. Der hierbei vorliegende als S0-Schnittstelle bezeichnete Anschluss besteht je Übertragungsrichtung aus zwei Nutzkanälen (B-Kanäle) zum Transport von Sprach-, Daten- und Bildkommunikation mit 64 kBit/s und einem Signalisierungskanal (D-Kanal) mit 16 kBit/s. Der Nutzer kann digitale Endgeräte einsetzen oder weiterhin analoge Apparate über nutzdaten- und signalwandelnde Geräte, sog. Terminal- oder a/b-Adapter, verwenden. Zusätzlich zur Sprachübertragung können im ISDN optionale Zusatzfunktionen wahrgenommen werden, wie etwa Rufweiterleitungen, Gerätewechsel (Terminal Portability) oder das Umschalten zwischen mehreren gleichzeitig verbundenen Gesprächsteilnehmern.
Für größere Kommunikationsanforderungen wird der ISDN-Primärmultiplexeranschluss (Primary Rate Interface) eingesetzt. Diese auch als S2M oder E1 bezeichnete Schnittstelle mit einer Gesamtbandbreite von 2.048 kBit/s enthält 30 Sprachkanäle mit jeweils 64 kBit/s sowie einen Signalisierungs- und einen Servicekanal mit je 64 kBit/s. An die Schnittstelle S2M kann allerdings nur ein Endgerät, etwa eine TK-Anlage, angeschlossen werden. Die in Nordamerika und Japan eingesetzte Schnittstelle T1 stellt 1.544 kBit/s Gesamtnutzbandbreite bereit und enthält 24 B-Kanäle zu je 64 kBit/s und einen Steuerkanal von 8 kBit/s. Im Gegensatz zur europäischen Variante teilt sich bei T1 jeder B-Kanal in einen Sprachkanal mit 56 kBit/s und einen Signalisierungskanal mit 8 kBit/s auf.[2]
Weiterhin werden in den heutigen öffentlichen Telefonnetzen (PSTN – Public Switched Telephone Network) Mehrwertdienste angeboten, die über die reine Sprachübermittlung hinausgehen und "intelligente" Funktionen aufweisen. Diese "intelligenten Netze" (IN) entstehen durch Anwendungen auf verbundenen Application Servern, sog. Service Control Points, und basieren auf offenen Plattformen, um eine weitestmögliche und netzübergreifende Entkopplung von der eigentlichen Technik der Telekommunikationsnetze zu erreichen. Der jeweilige Dienst wird über eine entsprechende Vorwahl in der Rufnummer ausgewählt. Beispielsweise kann ein IN-Dienst für ein Versandunternehmen eine automatische Umleitung eingehender Telefonanrufe anhand des Landes, aus dem diese kommen, oder der Vorwahlnummer zu der Filiale vornehmen, welche dem Anrufer am nahesten liegt. Weitere Routing-Arten berücksichtigen beispielsweise die Tageszeit oder die Sequenznummer des eingehenden Anrufs (wenn etwa jeder 1000. Anrufer im Rahmen eines Gewinnspiels berücksichtigt werden soll) oder Überlastsituationen, um Anrufe bei Überschreiten der personellen Kapazitäten an einen anderen Call-Center umzuleiten.
Gemeinsam ist konventionellen Telefonnetzen, ob analog oder digital (ISDN), das Prinzip der Leitungsvermittlung (Circuit Switching). Dabei werden einzelne Leitungen über Vermittlungsstellen so verschaltet, dass praktisch eine direkte und exklusive Verbindung zwischen den Kommunikationspartnern entsteht. Die Latenz (Verzögerung) der über solche Verbindungen übertragenen Informationen kann als konstant betrachtet werden.
1.3 Begriffsbestimmung von VoIP
VoIP (Voice over Internet Protocol) bezeichnet die Übertragung von Sprachinformationen über IP-Netze. Damit stellt es einen Dienst in paketvermittelten Datennetzen dar, die das IP-Protokoll auf der Vermittlungsschicht nutzen. Dieses Verfahren der Sprachübermittlung bedeutet daher einen grundlegenden Unterschied zu der herkömmlichen, leitungsvermittelten Informationsübertragung. Der Einsatz von VoIP kann auf lokale oder organisationsinterne Netze beschränkt bleiben ("Intranet-Telefonie") oder auch über öffentliche Netze wie dem Internet erfolgen ("Internet-Telefonie"). Weitere mögliche Szenarien sind der Einsatz von VoIP über das Internet als Transitnetz zwischen herkömmlichen TK-Systemen bzw. als Backbone für das ISDN/PSTN oder eine Kopplung eines lokalen VoIP-Netzes an das ISDN/ PSTN mittels eines entsprechenden Gateways.
Da VoIP über IP-Netze erfolgt, sieht es sich einerseits mit den spezifischen Unwägbarkeiten dieser Netze konfrontiert, wie etwa durch das Routing bedingte variable Routing-Pfade und Übermittlungszeiten sowie die Angreifbarkeit von Paketen an Leitungen und Netzwerkelementen. Andererseits stellt VoIP als Echtzeitdienst hohe Anforderungen an die verwendeten Netze, um eine Datenübermittlung in der Qualität und in der Sicherheit zu gewährleisten, wie sie für eine Telefonfunktionalität erforderlich sind. Aus diesem Grund sind ergänzende Verfahren und Prozesse zu implementieren, um die notwendigen Qualitätsmerkmale auch für virtuelle Telefonie-Verbindungen bereit zu stellen.
Zur Übertragung von Sprachinformationen nutzt VoIP das Real-time Transport Protocol (RTP) als Protokoll der Anwendungsschicht. Die Übertragung von RTP-Paketen erfolgt aus Gründen der Latenz wie auch aufgrund des Umstands, dass eine wiederholte Sendung fehlender oder fehlerhafter Pakete den Echtzeitanforderungen nicht gerecht werden kann, nicht mit dem zuverlässigen Transportprotokoll TCP, sondern mit seinem verbindungslosen Gegenstück UDP. Daneben beinhaltet VoIP nicht nur in IP-Pakete gekapselte digitalisierte Sprachsegmente, sondern auch die Übermittlung von Signalisierungs- bzw. Steuerinformationen, die für den Auf- und Abbau von Verbindungen sowie die Veränderung und Anpassung von Verbindungsparametern erforderlich sind.
Im Weiteren wird, soweit nicht näher bezeichnet, der Begriff Netz synonym für IP-Netz verwendet.
1.4 Entwicklung von VoIP
Die erste Software-basierte VoIP-Internetanwendung wurde 1995 durch das israelische Unternehmen VocalTec angeboten. Die Anwendung ermöglichte nur Verbindungen im Halbduplex-Betrieb und konnte noch auf keinen einheitlichen technischen Standards aufbauen. Auch verhinderten die zu dieser Zeit zur Verfügungen stehenden Kapazitäten des Internet und erhebliche Verzögerungszeiten VoIP-Gespräche von guter Qualität. Durch den 1996 erschienenen H.323-Protokollrahmen und die Entwicklung des Protokolls RTP wurde eine Norm gebildet, die eine dem Zeitverlauf abbildende (isochrone) Sprachinformationsübertragung und den Verbund von VoIP-Netzen mit den öffentlichen, leitungsvermittelten Telekommunikationsnetzen ermöglichte. Die Erwartungen gegenüber VoIP erreichten Mitte 1997 ihren vorläufigen Höhepunkt. Mangelhafte Verfügbarkeit und Qualität sowie die Deregulierung des Telekommunikationsmarkts im Jahr 1998, welche mit deutlichen Preissenkungen einherging, führten dann zu einer Markternüchterung. Allerdings wurden, allen voran durch die Firma Cisco, VoIP-Lösungen für Unternehmensnetze entwickelt, die gegenüber leitungsvermittelten TK-Systemen einen Mehrwert bieten sollten. Zwar erreichte die Ernüchterung gegenüber VoIP im Jahr 2000 dennoch ihre Talsohle; jedoch konnten so Erfahrungen gesammelt und die lokalen Netze durch Aufbau der erforderlichen Infrastruktur auf VoIP ausgerichtet werden. Lokale VoIP-Szenarien in Unternehmen enthielten in 2001 bis zu 700 Endgeräte und nutzten das noch dominante Signalisierungsprotokoll H.323, welches größere Teilnehmerzahlen nicht zuließ. Das 1999 erschienene konkurriende Signalisierungsprotokoll SIP, welches im Jahr 2002 in einer zweiten Version veröffentlicht wurde, erfuhr eine immer größere Akzeptanz und wurde schließlich in 2004 von allen deutschen VoIP-Providern eingesetzt, da es eine bessere Skalierbarkeit als H.323 ermöglicht. Durch steigende Qualität und mehr Sicherheit vor Gesprächsabbrüchen sowie durch professionellere und ausfallsicherere Hardware kam es in Deutschland 2005 zu einem deutlichen Aufschwung bei der Nutzung von VoIP.[3]
Das Vorhandensein eines breitbandigen Internetanschlusses stellt eine Grundvoraussetzung für VoIP dar, da ISDN-Anschlüsse mit 64 kBit/s die bei VoIP entstehenden Bitraten zwischen etwa 40 kBit/s und 90 kBit/s kaum bewältigen können. Vielmehr bietet die zunehmende Durchdringung der Bevölkerung mit Breitbandanschlüssen die erforderliche Grundlage zur Anwendung von VoIP. Die Penetration von Breitbandanschlüssen in der deutschen Bevölkerung lag im Juni 2004 bei 6,2%, in 2005 bei 10,2% und in 2006 bei 15,5%. Damit liegt die Verbreitung von Breitbandanschlüssen in Deutschland jedoch fast hinter allen Staaten Westeuropas, Nordamerikas und des pazifischen Raums, obgleich in Deutschland im europäischen Vergleich durchschnittlich die geringsten Kosten für einen 2 MBit/s-Flatrate-Internetanschluss anfallen. In Dänemark ist die Breitband-Durchdringung mit 30,3% am höchsten. Jedoch ist nicht in der voranschreitenden technischen Entwicklung selbst der maßgebliche Faktor bei der Verbreitung von breitbandigen Internetanschlüssen zu sehen, sondern in den künftigen Anwendungen, die zur Befriedigung der vier zentralen Nutzungsmotive Kommunikation, E-Commerce, Information und Unterhaltung Internetanschlüsse mit hohen Durchsatzraten erfordern.
Die zunehmende Verbreitung von VoIP kann als Teil eines Prozesses des Umbruchs und der Konvergenz in der Landschaft der Informationstechnologie und Telekommunikation gesehen werden. Dienste wie Fernsehen, Festnetz- und Mobiltelefonie und Internet, die bislang über eigene, dedizierte Netze betrieben wurden, werden zukünftig über ein gemeinsames "globales IP-Netz als Netz der Netze"[4] erbracht. Diese Konvergenz zwischen konventionellen Telekommunikations- und IP-basierten Netzwerken wird unter dem Begriff "New Generation Network" (NGN) zusammengefasst. VoIP stellt einen wichtigen Bestandteil der sich bildenden NGN dar. Das NGN-Konzept zeichnet sich durch ein paketorientiertes (Kern-) IP-Netz in Verbindung mit netzübergreifenden und –unabhängigen Diensten aus. Eine Bereitstellung von Quality of Service (QoS) für Echtzeitdienste, wie etwa VoIP, wird gewährleistet. Weitere signifikante Merkmale von NGN sind die vollständige Trennung der Verbindungs- und Dienstesteuerung vom Nutzdatentransport und die Integration wichtiger technisch unterschiedlicher Telekommunikationsnetze über entsprechende Gateways. Vorhandene Infrastrukturen werden in NGN soweit wie möglich genutzt. NGN unterstützt Multimedia-Dienste mit hohen Bitraten und weisen aufgrund ihrer einheitlichen Technik niedrige System- und Betriebskosten, eine optimale Auslastung des Kernnetzes und ein einheitliches Netzmanagement auf. Die Sicherheit der übertragenen Daten wird über integrierte Sicherheitsfunktionen hergestellt.[5] Offene Programmierschnittstellen sollen neue, in ihren Möglichkeiten nahezu nicht eingeschränkte "intelligente" Dienste (NGS – Next Generation Services) über alle Telekommunikationsnetze hinweg ermöglichen. Basis von NGN sind verteilte Gateway-Plattformen zur Integration aller beteiligten Netze unter zentraler Steuerung einer Softswitch-Funktionskomponente.
Ein bereits bestehender Ansatz im Wege dieser Konvergenz ist die Integration des Internet mit digitalen, Mehrwertdienste erbringenden (intelligenten) TK-Netzen. Das PINT-Konzept etwa ermöglicht Internetnutzern die Inanspruchnahme von Diensten im ISDN/PSTN, wie z.B. das Initiieren von Telefonverbindungen ("Click-to-Dial"). Das Konzept SPIRITS hingegen verfolgt den Ansatz, Ereignisse aus den digitalen TK-Netzen an das Internet zu übermitteln. Hierauf aufbauende Dienste ermöglichen z.B. die Signalisierung eines Anrufs auf dem Bildschirm eines Computers oder die Verfolgung der Funkzellen (GSM oder UMTS), in welchen sich Mobilfunknutzer aktuell befinden. Hierzu werden die Netze über Gateways miteinander verbunden und im ISDN/PSTN bzw. Mobilfunknetz SCP-Server (Service Control Point) zur Ausführung und Steuerung der Dienste eingerichtet.[6]
Insbesondere die Angebote von VoIP-Anschlüssen wie auch von multimedialen Paketangeboten verdeutlichen diese konvergente Entwicklung. Bezeichnete der Begriff Triple Play ursprünglich den Transport von Sprache, Video und Daten über ein Netzwerk, wird er heute im Wesentlichen durch die Werbewirtschaft als Synonym für Paketangebote von (Internet-) Telefonie, Fernsehen (IP-TV) und Internetzugang verwendet. Treibende Faktoren dieser Entwicklung sind vor allem Kostenersparnisse wie auch das Angebot neuer Dienste. Die Digitalisierung der Fernsehübertragung und die zunehmende Verbreitung von HDTV leisten einen weiteren Beitrag zur Ausbildung breitbandiger und konvergenter Netze. Da bestehende Breitband-Technologien den zukünftigen Anforderungen von NGN, z.B. IP-TV, nicht in allen Szenarien gerecht werden können, erfolgt ein Ausbau des VDSL- (Very High Data Rate Digital Subscriber Line) Netzes, bei dem Glasfaserübertragungsverfahren eingesetzt und diese so nahe an die Teilnehmer herangeführt werden, dass keine bzw. sehr kurze Kupferdoppeladerleitungen zur Überbrückung der Reststrecken verbleiben. Über VDSL lassen sich derzeit Übertragungsraten bis zu 52 MBit/s realisieren.
Telekommunikationsunternehmen wachsen zunehmend über ihre klassischen Geschäftsfelder hinaus und richten sich auf die Erbringung von IP-basierten Gesamtangeboten aus. So gibt es einerseits Telekommunikationsunternehmen, die bislang die Dienste Festnetztelefonie und breitbandiger Internetzugang, evtl. auch Mobilfunk, anboten und in das Segment der Fernsehübertragung eintreten wollen. Andererseits verfolgen auch Mobilfunkanbieter das Ziel, Teile der Festnetztelefonie für sich zu gewinnen oder auch – auf Basis der UMTS-Technik – einen breitbandigen mobilen Internetzugang anzubieten. Daneben haben auch Kabelnetzbetreiber ihr Angebot diversifiziert und bieten inzwischen breitbandige Internetzugänge und Telefonie auf Basis ihrer Netze an. Ein weiterer vorantreibender Faktor sind die Erfolg versprechenden Aussichten des Handy-TV. Bislang am weitesten fortgeschritten ist die Bündelung von Internetnutzung und Telefonie.
Den Einschätzungen nach werden vor allem internetbasierte Anbieter von dieser Konvergenz profitieren, wohingegen Telekommunikationsunternehmen zu den Verlierern zählen werden. Die Studie Deutschland Online aus dem Jahr 2006 kam zu dem Ergebnis, dass Telekommunikationsanbieter im Jahr 2015 nur noch 45% des Anteils am Breitbandmarkt halten werden.[7]
2 Grundlagen von VoIP
2.1 Signalisierung in konventionellen Telefonnetzen
Als Signalisierung wird die Steuerung zum Auf- und Abbau von Verbindungen sowie die Übermittlung von Steuerungsinformationen während bestehender Verbindungen bezeichnet. Um eine Kommunikation zwischen zwei Telefonen zu ermöglichen, müssen über die beteiligten Vermittlungsstellen Signalisierungsinformationen übermittelt werden, um eine durchgehende Verbindung für das Gespräch herzustellen. In analogen Telefonnetzen erfolgt die Signalisierung innerhalb des für die Sprachübertragung genutzten Kanals (Inband-Signalisierung).
Im ISDN werden für die Signalisierung von den Nutzkanälen unabhängige Signalisierungskanäle eingesetzt. Im Gegensatz zur Sprachübertragung findet die Signalisierung im ISDN nach dem Prinzip der Paketübermittlung statt. Die Signalisierung zwischen Endgeräten und der Teilnehmervermittlungsstelle oder in privaten ISDN-Netzen, deren Geräte z.B. durch eine ISDN-TK-Anlage verbunden sind, erfolgt nach dem D-Kanal-Protokoll, durch die ITU-T ("Standardization Sector" der "International Telecommuncation Union") als "Digital Subscriber Signalling System No. 1" (DSS1) bezeichnet. Über das Q-SIG-Protokoll, das eine Erweiterung des D-Kanal-Protokolls darstellt, werden ISDN-TK-Anlagen miteinander verbunden. Die Realisierung von ISDN-Dienstmerkmalen wird ebenfalls über den D-Kanal vorgenommen. Die Steuerungsübermittlung im D-Kanal erfolgt in Anlehnung an das OSI-Referenzmodell. Die erste Schicht (Bitübertragungsschicht) ist für die Übertragung von Informationen in den B- und D-Kanälen zuständig. Über die zweite Schicht (Sicherungsschicht) wird der gesicherte Transport der Signalisierung gewährleistet. Die eigentliche Teilnehmersignalisierung wird durch entsprechende im ITU-T-Standard Q.931 definierte D-Kanal-Nachrichten über die Schicht 3 (Vermittlungsschicht) vorgenommen. Dazu gehören insbesondere die Codierung der Nachrichten, die Behandlung des Nachrichtenaustauschs nach festgelegten Verfahren und die Realisierung von ISDN-Dienstmerkmalen. Da mehrere B-Kanäle einem D-Kanal zugeordnet sein können, enthaltenen die Signalisierungsvorgänge über sog. Call References (CR) in den Nachrichten-Headern einen Hinweis darauf, auf welche Verbindung sie sich beziehen. Die Signalisierungskanäle bilden ein von den Nutzkanälen getrenntes logisches Signalisierungsnetz.[8] Nachfolgend werden wichtige Schicht-3-Nachrichten des D-Kanal-Protokolls für den Auf- und Abbau von Verbindungen dargestellt:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1: Essentielle Schicht-3-Nachrichten im D-Kanal-Protokoll
Quelle: Badach, A. (2007), S. 55 f.
Die weltweite Übermittlung der Signalisierung zwischen den Vermittlungsstellen und damit im Kern der digitalen Netze wie ISDN oder des GSM-Mobilfunks erfolgt nach dem Zeichengabesystem Nr. 7 (SS7). Auch die Kopplung des ISDN mit dem GSM-Mobilfunknetz erfolgt über SS7.[9] Daher kommt dem SS7-Protokoll eine maßgebliche Bedeutung an der globalen Telekommunikationsinfrastruktur zu.[10] Ein 64 kBit/s-Signalisierungskanal im SS7-Netz kann Hunderte von Nutzkanälen steuern.
Es können vier verschiedene Signalisierungsformen unterschieden werden:
- Link-by-Link-Signalisierung: Segmentweise Steuerungsübertragung zwischen den Vermittlungsstellen
- Ende-zu-Ende-Signalisierung: Übertragung der Steuerung zwischen Quell- und Zielvermittlungsstelle zur Ausführung von Dienstmerkmalen
- Transaktionsfähigkeit: Übertragung von Informationen zwischen beliebigen Knoten im Signa-Signalisierungsnetz zur Durchführung intelligenter Dienste
- Überwachung und Steuerung des Signalisierungsnetzes: Fehlerlokalisation und Schaltung von Ersatzkanälen bei defekten Signalisierungskanälen
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2: Essentielle SS7-Nachrichten
Quelle: Badach, A. (2007), S. 64 f.
Die folgende Abbildung stellt den Signalisierungsverlauf beim Aufbau- und Abbau einer ISDN-Verbindung zwischen zwei Telefonen dar. Zwischen den Teilnehmervermittlungsstellen (TVSt) wird das SS7-Protokoll zur Signalisierung verwendet.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3: Auf- und Abbau einer ISDN-Verbindung zwischen zwei Telefonen
Quelle: Badach, A. (2007), S. 57
Der Verbindungsaufbau wird durch Teilnehmer A eingeleitet. Durch das Abheben des Hörers wird die Nachricht SETUP an die Teilnehmervermittlungsstelle von Teilnehmer A (TVSt X) gesendet. Diese Nachricht wird Teilnehmer A mit der Nachricht SETUP ACK bestätigt und der Wählton erzeugt. Die anschließende Übermittlung der Rufnummer erfolgt durch Nachrichten des Typs INFO. Sobald die TVSt X alle Ziffern erhalten hat, teilt sie dies dem Teilnehmer A über die Nachricht CALL PROC (Call Proceeding) mit. Daneben übermittelt TVSt X die SS7-Nachricht IAM (Initial Address Message) an die TVSt Y des Teilnehmers B. Soweit eine Verbindung mit Teilnehmer B möglich ist, wird die IAM-Nachricht auf die Nachricht SETUP des D-Kanal-Protokolls umgesetzt. Das Endgerät von Teilnehmer B überprüft bei Eintreffen der Nachricht SETUP, ob der Anruf entgegen genommen werden kann. Fall dies der Fall ist, wird der TVSt Y die D-Kanal-Nachricht ALERT übermittelt und am Telefon von Teilnehmer B der Klingelnton erzeugt. TVSt Y setzt die empfangene Nachricht ALERT wiederum in eine SS7-Nachricht, hier ACM (Address Complete Message), um und übermittelt diese an TVSt X. Diese wird bei Erhalt zurück auf die D-Kanal-Nachricht ALERT abgebildet und an Teilnehmer A übermittelt sowie der Freiton erzeugt.
Sobald Teilnehmer B den Hörer abgenommen hat, sendet dessen Telefon die Nachricht CONN an TVSt Y. Dies erwidert TVSt Y einerseits mit der Bestätigung CONN ACK an Teilnehmer B und andererseits durch Übermittlung der SS7-Nachricht ANS (Answer Message) an TVSt X. Diese setzt die SS7-Nachricht nach Erhalt auf die Nachricht CONN des D-Kanals um und sendet sie an Teilnehmer A, was die Beendigung des Freitons bewirkt. Teilnehmer A bestätigt den Erhalt der Nachricht mit CONN ACK gegenüber TVSt X. Von hier an ist die Verbindung zwischen Teilnehmer A und Teilnehmer B hergestellt, und die Gebührenerfassung beginnt.
Eine Beendigung des Gesprächs kann von jedem Telefon aus bewirkt werden. Nach dem Auflegen des Hörers (hier durch Teilnehmer A) wird die Nachricht DISC (Disconnect) an TVSt X übermittelt. Dies quittert TVSt X gegenüber Teilnehmer A durch die Nachricht REL (Release). Der B-Kanal zu Teilnehmer A wird freigegeben und die Gebührenerfassung eingestellt. TVSt X übermittelt darüber hinaus die gleichnamige SS7-Nachricht REL an TVSt Y. Dort findet eine Umsetzung der Nachricht auf die entsprechende Nachricht DISC des D-Kanals und deren Übermittlung an Teilnehmer B statt. Sobald auch Teilnehmer B den Hörer aufgelegt hat, wird die Nachricht REL an TVSt Y gesendet, welche diese auf die SS7-Nachricht RLC (Release Complete) umsetzt und an TVSt X sendet. Da auch der B-Kanal zwischen Teilnehmer B und TVSt Y wieder freigegeben werden muss, bestätigt TVSt Y den Erhalt der Nachricht REL mit REL COM gegenüber Teilnehmer B.
2.2 Kommunikationsprotokolle in Datennetzen
Die Regeln und Abläufe, nach denen Informationen in Datennetzwerken übertragen werden, sind durch Kommunikationsprotokolle festgelegt. Für die Datenübertragung im Internet werden Protokolle der TCP/IP-Familie verwendet. Je nach ausgeführtem Dienst, wie E-Mail, Web-Dienst oder VoIP, werden Adressierungen verschiedener Formate verwendet. Zum Transport der Daten über das Internet müssen diese Formate auf die Adressierung des Netzwerkprotokolls IP abgebildet werden. Zur Ermittlung der IP-Adresse des Kommunikationspartners werden die Einträge im Domain Name System (DNS) verwendet.
Basis von TCP/IP ist das Protokoll IP. Es ist der Vermittlungsschicht des OSI-Referenzmodells zuzuordnen. Es obliegt IP festzulegen, wie die Daten in Form von eigenständigen IP-Paketen zum Empfänger übertragen werden. IP kapselt die ihm übergebenen Daten von überliegenden Anwendungen in Pakete einer maximalen Länge und versieht sie mit einem Header, der u.a. die IP-Adresse von Quell- und Zielrechner enthält, um eine Weiterleitung bis zum Zielrechner (Routing) zu ermöglichen. Durch das Feld Type of Service / Differentiated Services im IP-Header wird ein Vermerk gesetzt, wie das jeweilige IP-Paket in Routern zu behandeln ist. Dies ist insbesondere aufgrund der für VoIP erforderlichen QoS-Unterstützung notwendig. IP ist ein verbindungsloses Protokoll. Dies bedeutet, dass IP keine Gewährleistung dafür übernimmt, ob die Pakete ihren Empfänger und wenn ja, fehlerfrei und ohne Veränderungen erreichen. Ein Verwerfen von IP-Paketen ist beispielsweise in Überlastsituationen von Routern möglich. Auch besteht die Gefahr, dass der in jedem IP-Header vermerkte Time to Live – Wert (TTL) aufgrund der passierten Hops bereits zu Null dekrementiert wurde, ehe das IP-Paket sein Ziel erreicht hat. Da Router IP-Pakete grundsätzlich unabhängig voneinander weiterleiten, ist es darüber hinaus je nach Verkehrssituation möglich, dass diese zwischen demselben Absender und Empfänger verschiedene Wege nehmen und somit in einer anderen Reihenfolge beim Zielrechner eintreffen, als sie den Quellrechner verlassen haben. IP stellt dem Zielrechner keine Möglichkeit bereit, die Reihenfolge erhaltener IP-Pakete, deren Integrität und Vollständigkeit zu überprüfen. Derartige Sicherungsfunktionen werden von sog. Transportprotokollen erfüllt. Transportprotokolle entsprechen der Schicht 4 (Transportschicht) im OSI-Referenzmodell.
TCP/IP enthält zwei Transportprotokolle. Diese sind das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP).
TCP ist ein verbindungsorientiertes Transportprotokoll, über das virtuelle Verbindungen zwischen kommunizierenden Rechnern hergestellt werden. Das Merkmal der virtuellen Verbindung wird durch die vor der beabsichtigten Nutzdatenübertragung erfolgte Vereinbarung über den Ablauf der Kommunikation zwischen zwei Anwendungen erreicht. TCP eignet sich daher für Datenübertragungen zwischen Rechnern, die nicht direkt miteinander verbunden sind. TCP-Verbindungen sind vollduplex und bestehen aus zwei entgegengerichteten unidirektionalen Verbindungen.
Das Feld Checksum im TCP-Header ermöglicht es, Teile des IP-Headers (insbesondere Quell- und Ziel-IP-Adresse), den TCP-Header und die Nutzdaten auf Bitfehler zu überprüfen. TCP nimmt bei Bedarf eine Segmentierung der Daten vor und stellt diese am Zielrechner wieder zusammen. TCP-Segmente werden vor der Übertragung fortlaufend byteweise nummeriert, was eine Übergabe der Daten an die überliegenden Anwendungen, die im TCP-Header durch Portnummern abgebildet werden, beim Empfänger in der richtigen Reihenfolge ermöglicht. Ports stellen für jede Anwendung Puffer in Sende- und Empfangsrichtung dar. Mit Quittungsnachrichten wird dem Absender bestätigt, bis zu welchem Byte ein korrekter Empfang der Daten erfolgte. Sollten TCP-Datensegmente fehlerhaft oder verloren gegangen sein, wird eine erneute Übertragung der Segmente angefordert.[11] Darüber hinaus wird der Status eines TCP-Segments durch sechs verschiedene Flags angezeigt. Verbindungsauf- bzw. -abbau werden durch die Flags SYN (Synchronization) bzw. FIN (Finish) initialisiert. Das ACK- (Acknowledgement) Flag wird in Verbindung mit dem SYN-Flag zur Realisierung des 3-Wege-Handshakes und ohne dieses zur Empfangbestätigung von TCP-Segmenten verwendet. Kann eine Verbindung nicht hergestellt werden, weil der maßgebliche Port nicht geöffnet ist, wird dies dem Absender des Verbindungswunsches in einer Antwort mit gesetztem RST- (Reset) Flag angezeigt. Bei gesetztem URG- (Urgent) Flag werden die Daten sofort bearbeitet. Das PSH- (Push) Flag soll bewirken, dass die Daten nicht in einem Puffer zwischengespeichert werden, sondern unmittelbar an die nächsthöhere Schicht übergeben werden.
Das in TCP/IP ebenfalls enthaltene Transportprotokoll UDP ist verbindungslos und stellt damit das Gegenstück zu TCP dar. UDP ist ein einfaches Transportprotokoll, welches Daten schnellstmöglichst ohne Verzögerungen, etwa durch Paketwiederholungen, übermittelt. Durch das Merkmal der Verbindungslosigkeit ist es möglich, dass UDP-Datagramme zwar versendet werden, aber nicht ankommen, da weder UDP noch das kapselnde IP entsprechende Sicherheitsmechanismen enthalten. Der UDP-Header besteht aus vier Feldern mit je 16 Bit. Wie bei TCP sind auch hier die Felder Quell- und Zielport enthalten. Daneben enthält es das Feld Length, welches die Länge des UDP-Datagramms in Byte angibt (minimal 8 Byte) und das Feld Checksum, welches eine Fehlererkennung im UDP-Paket und einige Teile der im IP-Header enthaltenen Felder (IP-Adressen, Protocol, Header-Länge und Total Length) miteinbezieht, die auch als Pseudo-Header bezeichnet werden und nur zur Prüfsummenberechnung dienen, erlaubt. UDP eignet sich vor allem für den Transport von solchen Nutzdaten, die empfindlich gegenüber Verzögerungen sind und eine Fehlererkennung und Neusendung erübrigen, wozu insbesondere Echtzeitdaten wie RTP-Sprachpakete gehören.[12]
Das von UDP abgeleitete Protokoll UDP Lite nimmt im Gegensatz zu UDP keine zwingende Verwerfung von fehlerhaften Paketen vor, da es für einige Codierverfahren sinnvoller ist, mit fehlerhaften Paketen zu arbeiten, als Lücken überbrücken zu müssen. Das ursprüngliche UDP-Headerfeld "Length" wird hier durch "Checksum Coverage" ersetzt, was dadurch möglich ist, dass die Layer-4-Paketlänge bereits im IP-Header vermerkt ist. Der Feldwert von Checksum Coverage gibt an, welcher Teil des UDP-Pakets auf Fehler überprüft und ggf. verworfen werden soll. Ein Checksum Coverage – Wert von 0 führt zu einer Überprüfung nur der Felder des UDP Lite – Headers. Werte von 1 bis 7 decken darüber hinaus die obigen als Pseudo-Header bezeichneten IP-Header-Felder ab. Werte zwischen 8 und 65535 bewirken eine Überprüfung bis zur gesamten Länge des Pakets, so dass sich im Extrem keine Veränderung gegenüber dem ursprünglichen UDP-Verfahren ergibt.[13]
Daneben ist seit Oktober 2000 SCTP als weiteres Transportprotokoll verfügbar. SCTP ist wie TCP verbindungsorientiert, enthält jedoch eine erweiterte Funktionalität. Die Datenübermittlung mittels SCTP ist gegenüber TCP effizienter. Über ist SCTP ist es möglich, die Stärken von TCP und UDP miteinander zu ereinen. UDP ermöglicht zwar eine schnelle Übertragung von Daten, enthält jedoch keine Sicherung gegenüber Übertragungsfehlern. TCP nimmt bei Vorliegen fehlender oder fehlerhafter TCP-Segmente eine Neuübertragung der TCP-Segmente ab dem Segment vor, bis zu welchem der Bytestrom fehlerfrei beim Empfänger einging. Dies hat zur Folge, dass nicht nur das fehlende bzw. fehlerhafte TCP-Segment neu gesendet wird, sondern auch alle weiteren inzwischen schon fehlerfrei beim Empfänger eingegangenen. Daneben wartet TCP beim Empfänger ab, bis alle Daten vollständig empfangen wurden, ehe es diese an überliegende Anwendungen weiterreicht. SCTP fügt einerseits dem UDP-Dienst die Funktion der Fehlersicherung hinzu und führt darüber hinaus TCP-Konzepte aus. Daneben werden Anforderungen von Signalisierungsprotokollen wie SS7 in SCTP berücksichtigt. SCTP enthält Maßnahmen zur Abwehr von Denial-of-Service-Angriffen (DoS), die kein Aufzehren von Ressourcen durch halboffene Verbindungen im Wege von SYN-Flooding ermöglichen. Im Gegensatz zu einer TCP-Verbindung kann eine SCTP-Verbindung, die als Assoziation bezeichnet wird und ebenfalls aus IP-Adresse und SCTP-Portnummer besteht, mehrere IP-Adressen besitzen (Multi-Home-IP-Endsystem). SCTP-Assoziationen setzen sich aus Outbound- und Inboundstreams zusammen. Sie sind im Vergleich zu TCP nicht auf jeweils eine undirektionale Verbindung in jede Richtung beschränkt, sondern können in jede Richtung beliebig ausgestaltet werden. Ein SCTP-Paket besteht neben seinem Header aus Chunks, in denen Daten verschiedener Datenströme gleichzeitig transportiert werden können. Bei Bedarf können Datagramme priorisiert vor anderen übermittelt werden.
Für die Übermittlung von IP-Paketen ist darüber hinaus die zweistufige Adressierung von IP-Netzen zu berücksichtigen. Die logischen IP-Adressen sind dabei auf physikalische Adressen der Sicherungsschicht (Schicht 2 im OSI-Referenzmodell) abzubilden, die in lokalen Netzen als MAC-Adressen bezeichnet werden. Soweit sich der Adressat eines IP-Pakets im selben IP-Subnetz befindet, wird dieses an die physikalische, eindeutige Adresse seines Netzwerkinterfaces gesendet. Gegebenenfalls verwendet der sendende Rechner das Address Resolution Protocol (ARP), um mittels einer Broadcast-Nachricht alle Endsysteme nach der MAC-Adresse einer bestimmten IP-Adresse zu befragen und die Antwort in seine ARP-Tabelle einzupflegen. Anschließend kann das IP-Paket in einem entsprechenden MAC-Frame an den Empfänger gesendet werden. Bei weitergehenden Punkt-zu-Punkt-Verbindungen, etwa über Telefonleitungen, werden diese in der Regel stattdessen in Frames des Point-to-Point-Protocols (PPP-Frames) gekapselt. Diese Frames auf Layer 2 werden auch Data-Link-Frames (DL-Frames) genannt.
2.3 DNS und ENUM
Die von Internetnutzern vorgenommene Adressierung eines Kommunikationspartners erfolgt grundsätzlich durch Nennung entweder seiner Internet-Adresse im Format eines Uniform Resource Locator (URL) oder seiner E-Mail-Adresse. Für die Übermittlung von IP-Paketen ist jedoch die Angabe der jedem Host bzw. jeder Domain zugeordneten IP-Adresse erforderlich. Die Zuordnung eines Namens zu seiner aktuellen IP-Adresse wird auch als Namensauflösung bezeichnet. Das Domain Name System (DNS) ermöglicht eine solche Namensauflösung, indem es auf Basis einer verteilten Datenbank nach dem Client/Server-Prinzip Anfragen nach IP-Adressen gesuchter Hosts ausführt und die zugeordneten Daten dem jeweiligen Benutzer mitteilt. Die Datensätze sind in Ressource Records auf Name-Servern gespeichert, wobei alle Rechnernamen, die weltweit auf Name-Servern hinterlegt sind, als DNS-Namensraum bezeichnet werden. Der DNS-Namensraum ist ähnlich einem Dateisystem hierarchisch in Form eines Baums strukturiert. Er beginnt mit der Wurzel (Root) und verzweigt sich entlang der Knoten, welche Domains und Unterdomains darstellen, bis sich unter Zusammensetzung aller im jeweiligen Pfad benutzen Knoten der vollständige Domain-Name (Full Qualified Domain Name) ergibt. Beispielsweise setzt sich der Domainname "informatik.fh-fulda.de" aus der Top Level Domain "de", der ihr untergeordneten Second Level Domain "fh-fulda" und wiederum deren Subdomain "informatik" zusammen. Die Hierarchien werden durch Punkte voneinander abgegrenzt. Um die IP-Adresse der vollständigen Domain zu ermitteln, liefert jeder Nameserver einen Zeiger auf den Nameserver, der für die unmittelbar folgende Subdomain verantwortlich ist. Diese Aufteilung ermöglicht es daneben, die Administration der einzelnen Domains und deren Subdomains dezentral vorzunehmen. Der Teil einer Domain, welcher der Zuständigkeit eines bestimmten Name-Servers unterstellt ist (über diese die "Autorität" besitzt), wird als Zone bezeichnet.[14]
Bei der Integration von leitungsvermittelten Telekommunikationsnetzen mit IP-Netzen ergibt sich im Hinblick auf die gegenseitige Erreichbarkeit das Erfordernis, VoIP-Telefonen klassische Telefonnummern zuzuordnen. Telefonnummern konventioneller Telefonnetze basieren auf dem Standard E.164 der ITU-T, deren Hierarchie sich von der äußersten rechten bis zur äußersten linken Stelle erhöht. Um über die Telefonnummer eines Geräts im IP-Netz seine korrespondierenden IP-Adresse über DNS ermitteln zu können, muss die Telefonnummer zunächst auf einen im Internet gültigen Uniform Resource Identifier (URI) abgebildet werden. Diese Umwandlung auf ein einheitliches Format übernimmt der Dienst ENUM (Telephone Number Mapping). Die entsprechenden ENUM-URIs sind der Domain e164 unter der Top-Level-Domain arpa zugeordnet. Da sich bei URIs die Hierarchieordnung von links nach rechts erhöht, wird die abzubildende E164-Telefonnummer, deren Ländercode immer mit anzugeben ist, zunächst in ihrer Reihenfolge umgekehrt. Über einen zwischen jede Ziffer einzufügenden Punkt wird das Hierarchiesystem von DNS umgesetzt. Anschließend wird der sich daraus gebildete String der Domain e164.arpa hinzugefügt und darüber die vollständige ENUM-Domain gebildet.
Die Abbildung der Rufnummer +49 69 825340 auf eine ENUM-Domain ergibt sich wie folgt:
E.164-Rufnummer ENUM-URI
+49 69 825340 à 0.4.3.5.2.8.9.6.9.4.e164.arpa
Die Interpretation dieser ENUM-URI wird durch die folgende Abbildung dargestellt:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4: ENUM-URI-Verweis auf NAPTR Resource Record
Quelle: Badach, A. (2007), S. 95
Ausgehend vom Root stellen die Subdomains arpa und e164 Knoten im DNS dar. Im vorliegenden Beispiel handelt es sich um eine Rufnummer aus Deutschland. Der Ländercode "49" wurde im Wege der ENUM-URI-Bildung zu "9.4" permutiert und stellt einen weiteren Knoten dar. Alle weitergehenden Ziffern werden ebenfalls als untereinander angeordnete Subdomains behandelt. Da E.164-Rufnummern nur zehn verwendbare Ziffern enthalten, können die entsprechenden ENUM-Subdomains in jeder Hierarchiestufe auch nur maximal zehn Subdomains enthalten. Über die unterste Subdomain erschließt sich der zugehörige NAPTR Resource Record.
Die jeweilige ENUM-URI ist einem Resource Record des DNS zugeordnet, in dem die verfügbaren dienstspezifischen Kontaktformen (z.B. SIP-, E-Mail- oder Internet-Adressen) hinterlegt sind. Durch das Kürzel "e2u" (E.164 Number to URL) werden diese Dienste in den DNS-Einträgen voneinander abgegrenzt. Der vollständige Eintrag lässt sich über den DNS Name Authority Pointer (DNS NAPTR) ermitteln. Eine Abfrage an den DNS-NAPTR-Dienst mittels einer entsprechenden ENUM-URI, die an einen Name-Server verweist, würde durch Mitteilung z.B. einer SIP-URI, etwa sip:fritz.meier@sip.de, beantwortet werden. Nun kann über ein VoIP-Gateway zwischen dem Teilnehmer im PSTN und jenem im IP-Netz eine Verbindung aufgebaut werden. Ein Nachteil von ENUM ist, dass es keine Verschlüsselungs- und Autorisierungstechniken unterstützt. Daneben können die Authentizität und Integrität von DNS-Nachrichten nicht sichergestellt werden. Eine Lösung dieses Problems wird erst durch DNSSEC, welches digitale Signaturen verwendet, möglich.[15],[16]
Neben e164.arpa als Public ENUM Top Level Domain wurden auch andere Domains für den Einsatz eines ENUM-Konzepts eingerichtet. Diese sind jedoch weniger bedeutend.[17]
3. Sprachcodierung und Echtzeitkommunikation
Wenn Menschen miteinander verbal kommunizieren, erfolgt die Erzeugung wie auch die Aufnahme der Informationen in Form akustischer Wellen. Daher handelt es sich bei Sprachkommunikation um die Übermittlung analoger Signale. Erfolgt die Sprachkommunikation über ein digitales Medium wie ISDN oder VoIP, ist diese vor ihrer Übermittlung in ein digitales Format zu überführen (Digitalisierung) und am Endpunkt des Übertragungssystems in analoge Signale rückzubilden. Sprachübermittlung stellt eine Form der Echtzeitkommunikation dar. Die Zeitdifferenz zwischen Absendung und Empfang der Sprachsignale sollte so minimal wie möglich sein. Daher können Verfahren wie das sichere Transportprotokoll TCP, die eine fehlerfreie und vollständige Datenübermittlung sicherstellen sollen, bei Echtzeitmedien nicht eingesetzt werden.
Die folgende Grafik stellt die Grundvorgänge bei der Sprachübermittlung über IP-Netz dar:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 5: Grundprinzip der Sprachübermittlung über ein IP-Netz
Quelle: Badach, A. (2007), S. 132
Der Digitalisierungsprozess erfolgt in mehreren Stufen. Zunächst werden über einen Tiefpassfilter Geräusche entfernt, die in hohen Frequenzen enthalten sind (Glättung). Anschließend erfolgt eine Abtastung des geglätteten analogen Signals in konstanten Intervallen. Die bei der Abtastung entstandenen Abtastwerte, die der Amplitude entsprechen, werden vom Codierer nach erfolgter Messung und Rundung in eine Bitfolge abgebildet. Die Folge der binären Codewörter stellt den Sprachbitstrom dar, welcher in IP-Pakete gekapselt und über ein IP-Netz versendet wird.
Um beim Emfänger die entsprechenden akustischen Signale näherungsweise rückzubilden, werden die in den IP-Paketen enthaltenen Segmente des Sprachbitstroms an den Decodierer übergeben. Die einzelnen Codewörter werden dort auf analoge Spannungswerte abgebildet. In einem Halteglied wird der jeweilige Spannungswert gehalten, bis ein weiterer erzeugt wird. Es entsteht ein treppenartiger Verlauf von Spannungswerten, der wiederum durch einen Tiefpassfilter gerundet und anschließend zur Bildung analoger Signale verwendet wird. Das gebildete analoge Sprachsignal s*(t) soll eine Nachbildung des ursprünglichen Sprachsignals s(t) darstellen.
Um eine Rückbildung des ursprünglichen Sprachsignals ohne Verluste zu ermöglichen, sollte gemäß dem Abtasttheorem nach Shannon das Abtastintervall so gewählt werden, dass es dem Doppelten der im Ausgangssignal enthaltenen höchsten Frequenz entspricht. Da von einem Frequenzbereich der Sprache zwischen 300 und 3400 Hz ausgegangen wird, ergäbe sich damit eine Mindestabtastfrequenz von 6800 Messungen je Sekunde. Für den Anwendungsfall der Sprachcodierung wurde die Abtastfrequenz international auf 8000 Messungen je Sekunde vereinbart.[18]
3.1 Abtastwert-orientierte Sprachcodierung
Bei einer Abtastwert-orientierten Sprachcodierung wird ein Sprachsignal mit einer bestimmten Häufigkeit, in der Regel 8000 Mal je Sekunde, abgetastet und die gebildeten Abtastwerte (Samples) codiert. Voraussetzung für die Codierung ist eine Rundung der Samples, die als Quantisierung bezeichnet wird. Durch das näherungsweise Abbilden des Sprachsignals entstehen zwangsläufig Quantisierungsfehler, die beim Gesprächspartner als Hintergrundrauschen, auch Quantisierungsgeräusch genannt, wahrgenommen werden. Beim meistgebräuchlichen Verfahren PCM (Pulse Code Modulation), das im ITU-T-Standard G.711 spezifiziert ist und auch bei ISDN eingesetzt wird, stehen für die Codierung jedes diskreten Abtastwerts 8 Bit zur Verfügung. Damit kann jedes Sample auf einen von 256 möglichen Amplitudenwerten abgebildet werden. Der dabei entstehende Bitstrom beträgt somit 8000 Samples/s * 8 Bit = 64 kBit/s.
Die Quantisierung kann in konstanten Stufen (Quantisierungsintervallen) vorgenommen werden. Das Prinzip einer solchen linearen Quantisierung ist in der folgenden Abbildung wiedergegeben, wobei Amplitudenwerte im Intervall -4 <= x < 4 betrachtet werden. Im Wege der Quantisierung werden diese den jeweils nächstgelegenen diskreten Quantisierungsstufen -4, -3, …, 3 zugeordnet. Daraus ergeben sich 8 Quantisierungsstufen, für deren Digitalisierung 3 Bits je Sample hinreichend sind (23 = 8 Kombinationen). Das erste Bit wird als Vorzeichenbit verwendet.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 6: Digitalisierung eines analogen Signals bei linearer Quantisierung
Quelle: Badach, A. (2007), S. 137
Ein Grundproblem der Digitalisierung von Sprache besteht in der Approximation des Sprachsignals auf diskrete Quantisierungswerte, die zur Bildung eines Störsignals, des Quantisierungsgeräuschs führt. Diese Begleiterscheinung nimmt mit Verringerung der Quantisierungsintervalle ab. Die damit einhergehende Erhöhung der Quantisierungsstufen führt aber zu einer Erhöhung der notwendigen Bits zur Codierung eines Samples und damit zu einer größeren Bitrate. Da die Amplitudenwerte jedoch nicht über den gesamten betrachteten Bereich mit derselben Wahrscheinlichkeit auftreten, bietet sich als weitere Möglichkeit zur Minimierung des Quantisierungsgeräuschs an, die Quantisierungsstufen unregelmäßig zu verteilen (nichtlineare Quantisierung). Beim Quantisierungsgeräusch ist nicht vorrangig sein absoluter Wert, sondern sein Verhältnis zur Stärke des Nutzsignals maßgeblich. Um den sich daraus ergebenden Signal/Geräusch-Abstand zu vergrößern und darüber eine Qualitätsverbesserung der digitalisierten Sprache zu erreichen, ist der Einsatz einer nichtlinearen Quantisierung sinnvoll, bei der gegenüber kleinen Amplitudenwerten auch kleinere Quantisierungsstufen angewendet werden. Ein solches Vorgehen trägt auch der Tatsache Rechnung, "dass die Empfindlichkeit des menschlichen Gehörs proportional zum Logarithmus der Lautstärke ist".[19] Eine nichtlineare Quantisierung findet beispielsweise beim PCM-Verfahren statt. Hier werden die Quantisierungsintervalle logarithmisch aufgeteilt. Eine logarithmische Skalierung führt damit zu einer besseren Differenzierung leiser Signale.[20]
Es ist eine Eigenschaft von Sprachsignalen, dass sie in messbarer stochastischer Abhängigkeit zueinander stehen. Über eine Analyse der vorausgegangenen Abtastwerte ist es daher möglich, mit einer gewissen Wahrscheinlichkeit eine Vorhersage (Prädiktion) über die unmittelbar folgenden Amplitudenwerte vorzunehmen. Auf einer solchen Schätzung zukünftiger Abtastwerte basiert das Differential PCM (DPCM). Hier wird nicht ein codierter Abtastwert übertragen, sondern die Differenz zwischen dem Abtastwert und seiner Prädiktion. Die sich ergebenden Differenzwerte liegen innerhalb schmalerer Werteintervalle und benötigen daher zu ihrer Codierung weniger Bits, so dass sich hierüber eine Verringung der Bitrate gegenüber reinem PCM erreichen lässt. DPCM setzt voraus, dass auch der Decodierer auf der Empfängerseite nach demselben Algorithmus Schätzungen der zukünftigen Amplitudenwerte auf Basis der durch ihn rekonstruierten Signale vornimmt und diesen die vom Codierer übertragenen Differenzen hinzuaddiert. Das rekonstruierte Signal stellt jedoch überwiegend einen Näherungswert des ursprünglichen Sprachsignals dar. Über DPCM lässt sich eine Reduktion der Bitrate gegenüber PCM bei praktisch gleicher Codierungsqualität realisieren.
Das Adaptive DPCM-Verfahren (ADPCM) berücksichtigt weiterhin, dass sich der statistische Zusammenhang des Sprachsignale immer wieder verändert, so dass zur effizienten Vorhersage des Sprachsignals eine Anpassung der Vorhersageparameter vorgenommen werden muss. Bei ADPCM wird das Sprachsignal in Zeitsegmente von 10 bis zu 20 ms zerlegt. Innerhalb dieser Intervalle werden konstante Vorhersageparameter bei der Schätzwertberechnung zugrunde gelegt. Gegenüber weiteren Segmenten wird ggf. eine Anpassung der Vorhersageparameter vorgenommen. Für die Übertragung der Differenzen zu den Schätzwerten genügen Bitfolgen der Länge 2 bis 5, so dass bei einer Abtastfrequenz von 8000/s Bitströme von 16, 24, 32 oder 40 kBit/s entstehen.[21] Allerdings ist ADPCM wesentlich sensibler gegenüber Paketverlusten, so dass sich diese leicht in einer wahrnehmbar geringeren Sprachqualität niederschlagen.[22]
3.2 Segment-orientierte Sprachcodierung
Einen anderen Ansatz verfolgt die Segment-orientierte Sprachcodierung. Hierbei wird nicht der Verlauf des Sprachsignals selbst digitalisiert, sondern Parameter zu seiner Beschreibung. Die Details des abgetasteten Sprachsignals gehen hierbei verloren.[23] Es werden lediglich Parameter, ähnlich einem "Rezept", zur Erzeugung von Sprachsignalen übertragen. Daher handelt es sich hier um parametrische Verfahren. Diese funktionieren nach dem Analysis-by-Synthesis-Prinzip (AbS), mittels dem sich die größten Komprimierungsgewinne erzielen lassen. Aus einer Folge von Abtastwerten, die einem bestimmten Zeitintervall entsprechen, wird unter Zugrundelegung einer Konstanz der Eigenschaften dieses Sprachsignalsegments mit einem LPC- (Linear Predictive Coding) Filter eine LPC-Analyse vorgenommen. Eine LPC-Analyse ist Ausgangsbasis zur Generierung von Parametern, um beim Empfänger eine künstliche Sprachsynthese zu ermöglichen. Die Parameter beschreiben Zeitintervalle jeweils von 5 bis 30 ms, in denen das menschliche Sprachsignal aus weitgehend konstant angesehen wird. Bei der Analyse werden die Frequenz des Sprachsignals, die Stimmhaftig-/Stimmlosigkeit und die Lautstärke berücksichtigt.
Beim Empfänger wird der sprachbildende menschliche Vokaltrakt durch einen LPC-Vocoder nachempfunden. Zur Bildung von stimmhaften Lauten wird ein Impulsgenerator und zur Erzeugung von stimmlosen Lauten ein Rauschgenerator eingesetzt. Die Artikulation schließlich wird durch einen linearen Filter vorgenommen. Beim LPC-10-Verfahren werden zur Sprachsignalbeschreibung 13 Parameter verwendet, die eine Datenmenge von nur 48 Bits je Frame zu 20 ms Sprachsignal erzeugen. Bei einer Abtastfrequenz von 8000/s würden innerhalb eines Zeitintervalls von 20 ms somit 160 Abtastwerte vorliegen. Diese 160 Abtastwerte werden durch lediglich 48 Bit codiert, so dass sich bei 50 zu übertragenden Frames je Sekunde eine Bitrate von 50 * 48 Bit/s = 2.4 kBit/s ergibt. Der wesentliche Vorteil der LPC-Technik liegt in der deutlichen Reduzierung der Bitraten gegenüber Abtastwertwert-orientierten Sprachübertragungsverfahren, allerdings bei sehr hohem Rechenaufwand. Für VoIP können sowohl Abtastwert- wie auch Segment-orientierte Sprachcodierungsverfahren eingesetzt werden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 7: VoIP-relevante Sprachcodierungsverfahren
Quelle: Badach, A. (2007), S. 145
Aus Abb. 7 wird deutlich, dass Segment-orientierte Sprachcodierungsverfahren bei gleicher oder besserer Sprachqualität erheblich geringere Bitraten erzeugen, als Abtastwert-orientierte. Das Segment-orientierte Verfahren CS-ACELP 8 bietet gegenüber dem Abtastwert-orientierten Verfahren ADPCM 32 eine bessere Qualität, erzeugt mit 8 kBit/s jedoch nur ein Viertel der Bitrate gegenüber dem Abtastwert-orientierten Verfahren. Es ist aber festzustellen, dass eine Reduzierung der Bitrate in beiden Sprachcodierungsverfahren zwangsläufig zu Lasten der Sprachqualität geht.
Es kann weiterhin festgestellt werden, dass die in VoIP eingesetzten Sprachcodierungsverfahren eine mindestens so hohe Sprachqualität ermöglichen, wie der konventionellen analogen Telefonie. Mittel des MOS- (Mean Opinion Score) Verfahrens, das eine objektive Bewertung von Sprachqualität zum Ziel hat und Bewertungen von 1 (schlecht) bis 5 (hervorragend) vornimmt, erhielt die analoge Telefonie Werte von 3,5 bis 4,0, während VoIP-Sprachcodierungsverfahren zu Bewertungen von 3,8 bis 4,4 führten. Die beste Sprachqualität bietet demnach ISDN mit einem MOS-Wert von 4,5. Zur Ermittlung der Sprachqualität ist es jedoch erforderlich, den Test in der jeweiligen VoIP-Umgebung durchzuführen, da auch netzswerkbedingte Parameter die Sprachqualität beeinflussen, wie Delay, Jitter (Übertragungszeitschwankungen) oder Paketverluste. Auch die zur Verringerung der Netzlast teilweise eingesetzten Voice Activity Detection Mechanismen, die Sprechpausen erkennen und eine Unterbrechung der Nutzdatenübertragung vornehmen, können unangenehme Auswirkungen auf die Sprachqualität haben, da sie zur Abschneidung von Satzanfängen nach Sprechpausen führen können. Auch Echos, Hintergrundrauschen oder Veränderungen der Signaldämpfung bzw. –verstärkung können die Qualität der Sprachübertragung negativ beeinflussen.[24]
3.3 Konzept der Protokollfamilie RTP / RTCP
Da Sprache eine Kommunikationsform ist, bei der hohe Anforderungen an eine möglichst verzögerungsfreie Übermittlung gestellt werden, bestehen auch beim Transport der Informationen über ein IP-Netz diese besonderen Echtzeit-Anforderungen. Der Einsatz eines Transportprotokolls wie TCP, das eine vollständige und fehlerfreie Übermittlung aller IP-Pakete gewährleisten soll, kann im Umfeld der Echtzeitkommunikation nicht sinnvoll eingesetzt werden, da mit einer Neuanforderung von Paketen ein so großer Zeitaufwand verbunden wäre, dass die Echtzeiteigenschaft der Kommunikation damit verloren ginge. Um den besonderen Anforderungen von Echtzeitkommunikation wie Audio (Sprache) und Video gerecht zu werden, wurde durch die IETF (Internet Engineering Task Force) das Real-Time Transport Protocol (RTP) entwickelt, welches Medieninformationen bestimmter Zeitsegmente als Payload überträgt. RTP nutzt das verbindungslose Transportprotokoll UDP.
Um RTP-Pakete zwischen den Kommunikationspartnern übermitteln zu können, muss zunächst eine RTP-Sitzung (engl. RTP-Session) aufgebaut werden, die einen logischen Übermittlungskanal darstellt. Jeder logische Übermittlungskanal besteht aus zwei unidirektionalen Kanälen, je einen für jede Richtung. Nach beendeter Kommunikation wird die RTP-Session wieder abgebaut, um die gebundenen Netzressourcen freizugeben. RTP enthält jedoch keinen Mechanismus zum Auf- und Abbau einer RTP-Session. Für die Vereinbarung der Prinzipien der Sprachkommunikation, etwa hinsichtlich des zu verwendenden Sprachcodierungsverfahrens, werden Signalisierungsprotokolle verwendet. Hierbei kommen die Protokolle aus dem H.323-Framework oder das Session Initiation Protocol (SIP) in Frage. Für die Beschreibung einer RTP-Session wird bei SIP das Session Description Protocol (SDP) eingesetzt. Bei H.323 als sehr komplexes Signalisierungsprotokoll wird für die Beschreibung der RTP-Session das Unterprotokoll H.245 verwendet.
Parallel zu RTP wird das Hilfsprotokoll RTP Control Protocol (RTCP) eingesetzt. Es dient dazu, während einer RTP-Session Kontroll- und Statusinformationen zwischen den kommunizierenden Endgeräten zu übermitteln, z.B. periodische Berichte (Reports) über den Zustand des Empfängers und die Qualität der Nutzdatenübertragung. RTCP erlaubt eine Bewertung der Kommunikationsparameter, welche Relevanz für QoS haben. Eine RTP-Session enthält daher zwei logische Kanäle – einen Media Channel (MC) zur Übertragung der Nutzdaten und einen Media Control Channel (MCC) zur Übermittlung der RTCP-Pakete. Die Portnummern von RTP sind zwischen den Kommunikationspartnern nicht festgelegt, sondern werden bei jedem Aufbau einer RTP-Session ausgehandelt. Für die Portbestimmung des MCC wird jedoch grundsätzlich der dynamische RTP-Port um eins inkrementiert. RTCP verwendet ebenfalls das unsichere Transportprotokoll UDP. Zur Übertragung der RTP- und RTCP-Pakete werden diese in IP-Pakete gekapselt. Die nachfolgende Grafik bildet die grundlegenden Phasen bei der Sprachkommunikation über ein IP-Netz mittels RTP ab:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 8: Phasen bei der Sprachkommunikation über ein IP-Netz
Quelle: Badach, A. (2007), S. 149
Wie in Abb. 9 dargestellt, verwendet H.323 das zuverlässige Transportprotokoll TCP zur Signalisierungsübermittlung, während SIP (SDP) das unzuverlässige Transportprotokoll UDP nutzt:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 9: RTP und RTCP als Anwendungen oberhalb von UDP
Quelle: Badach, A. (2007), S. 151
Ein wichtiges Merkmal von RTP ist, dass RTP aufgrund des Fehlens entsprechender Mechanismen bei UDP in seinem Header eine Nummerierung der Pakete vornimmt, um ihre korrekte Zusammensetzung beim Empfänger sowie die Feststellung von Verlusten zu ermöglichen. Ferner wird in den RTP-Headern ein Zeitstempel eingetragen, so dass die VoIP-Nutzdaten in denselben zeitlichen Abständen wie beim Sender zueinander gefügt werden können, was das Merkmal der Isochronität sicherstellt. Daneben ermöglichen Sequenznummern und Timestamps die Berechnung des Jitters, um ggf. den Jitter-Puffer anzupassen. Die unterschiedlichen Formate der einzelnen Echtzeitmedien werden durch entsprechende Payload Typen spezifiziert. Der RTP-Header enthält des Weiteren des Feld Synchronization Source Identifier (SSRC), welches eine Identifikation des Senders und eine Gruppierung der den Empfänger erreichenden Pakete nach Quellen erlaubt. Das optionale Feld Contributing Source Identifiers enthält eine Liste aller Quellen, soweit mehrere RTP-Kanäle zusammengefügt wurden. Darüber hinaus beinhaltet RTP die Möglichkeit des Einsatzes eines Translators, der das Medienformat empfangener RTP-Pakete in ein anderes Format konvertiert und die geänderten RTP-Pakete weitersendet. Der Einsatz eines Translators wird z.B. bei der Übertragung von PCM-codierten Echtzeitmedien zwischen Amerika/Japan und Europa aufgrund der verwendeten verschiedenen Versionen des PCM-Codecs (A- und µ-Kennlinien) notwendig.[25] Ein weiteres mögliches Einsatzgebiet einer solchen Formatumsetzung ist die Absicherung der Nutzdaten beim Transport über ein unsicheres, öffentliches Netz. Hier kann ein privates Sprachformat verwendet werden, welches eine Decodierung bei einem Angriff auf die Vertraulichkeit verhindert. Beim Empfänger sind die Nutzdaten vor ihrer Decodierung wiederum auf das ursprüngliche Sprachformat abzubilden. Ein ebenfalls einsetzbarer Mixer ist in der Lage, aus Bitströmen verschiedener Herkunft einen gemeinsamen, gemischten Bitstrom zu bilden. Ein Mixer kann die Funktion eines Multiplexers ausüben, etwa wenn mehrere von IP-Telefonen des LANs eines Unternehmensstandorts hergestellte Verbindungen zu Teilnehmern eines anderen Unternehmensstandorts über ein WAN geführt werden sollen. Hier werden die verschiedenen RTP-Kanäle zu einem gemischten Bitstrom gebündelt. Über das CSRC-Feld im RTP-Header wird dem Empfänger mitgeteilt, von welchen Quellen die ursprünglichen Bitströme ausgingen.[26]
Während RTP zur Übertragung von Echtzeitmedien dient, ermöglicht das dazugehörige Kontrollprotokoll RTCP über einen periodischen Austausch von Kontroll- und Statusinformationen die Steuerung von Verbindungen und die Berechnung notwendiger statistischer Daten, insbesondere des Jitter. Hierzu werden periodische Sender- und Receiver-Reports versendet. Aufgrund des Austauschs der Qualitätsparameter gesendeter und empfangener Echtzeitmedien ist es möglich, die Ursache von Fehlern einzugrenzen und ggf. eine Anpassung der erzeugten Bitrate an die Bedingungen des Übertragungsnetzes vorzunehmen. Über die Mitteilung der Qualität der zu übermittelten Nutzdaten kann sich der Empfänger darüber hinaus auf die ankommende Datenmenge einrichten.
Besonders die Einschätzung des Jitter hat eine hohe Bedeutung für VoIP. Aufgrund etwa verschiedener Wegewahl variiert die Übertragungszeit von RTP-Paketen über das Netz. Da manche Sprachpakete in unrichtiger Reihenfolge oder mit deutlichem zeitlichen Abstand beim Empfänger eintreffen, ist es nicht möglich, die in den RTP-Paketen übertragenen Sprachsignale unmittelbar nach ihrem Empfang auszugeben. Somit ist nicht nur eine Sortierung der Sprachpakete entsprechend ihrer korrekten Reihenfolge, sondern auch eine Rückversetzung der erhaltenen Sprachsignale entsprechend der tatsächlichen Ablaufgeschwindigkeit des digitalisierten Gesprächs erforderlich. Zwischen den RTP-Paketen müssen sich daher bei Ausgabe der enthaltenen Sprachsegmente die gleichen zeitlichen Abstände befinden. Dieses Merkmal wird als Isochronität bezeichnet. Zur Umsetzung dieser Anforderung ist es erforderlich, die empfangenen Daten in einem Jitter-Ausgleichpuffer (JAP), auch als Playout Buffer bezeichnet, über einen definierten Zeitraum, der sich am jeweiligen aktuellen Jitter-Schwankungswert bemisst, zwischenzuspeichern.
Abb. 10 zeigt, dass Jitter zur Übermittlung der RTP-Pakete in variablen Zeitabständen führt. Eine Ausgleichspufferung ermöglicht es, die RTP-Pakete in gleich großen zeitlichen Abständen an die Applikation zu übergeben. Allerdings erhöht der Jitter-Ausgleichspuffer den Gesamtdelay.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 10: Isochronität mit Hilfe eines Jitter-Ausgleichpuffers
Quelle: Badach, A. (2007), S. 166
Mittels RTCP ist es möglich, die Übertragungsdauer von RTP-Paketen und das Ausmaß des Jitter einzustufen. Sender- wie auch Receiver Reports enthalten Blöcke u.a. mit seit Sessionbeginn kumulativen Werten über die Anzahl verlorener RTP-Pakete, die Verlustquote von RTP-Paketen, die höchste empfangene Sequenznummer, eine Jitter-Schätzung und den Zeitstempel des letzten empfangenen Sender-Reports sowie die Verzögerung zwischen dem Empfang des letzten Sender Reports und der Versendung des Report Blocks. Die letzten beiden Werte bilden die Grundlage zur Berechnung des Round-Trip Delay (Verzögerung zwischen dem Senden eines Sender Reports und dem Empfang des folgenden Receiver Reports beim Sender).
Daneben ermöglicht RTCP eine Identifizierung der Quellen von Bitströmen. Somit ist eine Zuordnung mehrerer Quellen (z.B. z.B. Audio- und Videobitströme) zu einem Teilnehmer möglich. Diese Identifikation erfolgt über kanonische Namen, die in Source Description-RTCP-Paketen versendet werden. Dies ist notwendig, da eingetragene Identifikationswerte im Feld SSRC durch Mixer überschrieben werden. RTCP eignet sich darüber hinaus für eine Überwachung von Konferenzen mit mehreren Teilnehmern. Über die periodischen Statusinformationen kann den Teilnehmern einer Konferenz mitgeteilt werden, ob weitere Teilnehmern zu der Konferenz hinzugekommen sind und deren Namen anzeigen bzw. ob Teilnehmer die Konferenz verlassen haben.[27]
[...]
[1] vgl. Badach, A. (2007), S. 2 ff.
[2] vgl. Nölle, J. (2005), S. 17 f.
[3] vgl. Eren, E. et al. (2007), S. 2 ff.
[4] Badach, A. (2007), S. 22
[5] vgl. Trick, U. (2007), S. 29 f.
[6] vgl. Badach, A. (2007), S. 27 ff.
[7] vgl. Graumann, S. et al. (2007), in "Monitoring Informationswirtschaft – 10. Faktenbericht 2007", S. 342 ff.
[8] vgl. Badach, A. (2007), S. 4 ff., S. 48 ff.
[9] vgl. Siegmund, G. (2007), Vortrag im Rahmen des "VoIP-Tags" in Hannover am 18.10.2007
[10] vgl. Trick, U. et al. (2007), S. 207
[11] vgl. Badach, A. (2007), S. 67 ff.
[12] vgl. Trick, U. et al. (2007), S. 86 ff.
[13] vgl. Eren, E. et al. (2007), S. 82 f.
[14] vgl. Badach, A. (2007), S. 82 ff.
[15] vgl. Eren, E. et al. (2007), S. 25 f.
[16] vgl. o.V., http://www.denic.de/de/domains/dnssec/index.html, 21.10.2007
[17] vgl. Trick. U. et al. (2007), S. 266 ff.
[18] vgl. Badach, A. (2007), S. 132 ff.
[19] Badach, A. (2007), S. 138
[20] vgl. Nölle, J. (2005), S. 46
[21] vgl. Badach, A. (2007), S. 135 f.
[22] vgl. Siegmund, G. (2007), Vortrag im Rahmen des "VoIP-Tags" in Hannover am 18.10.2007
[23] vgl. Nölle, J. (2005), S. 47
[24] vgl. Nölle. J. (2005), S. 50 f.
[25] vgl. Badach, A. (2007), S. 141
[26] vgl. Badach, A. (2007), S. 148 ff.
[27] vgl. Badach, A. (2007), S. 148 ff.
- Citation du texte
- Dipl.-Kfm. (FH), Dipl.-Ing. (FH) Christian Jäger (Auteur), 2007, Voice over IP unter besonderer Berücksichtigung sicherheitsrelevanter Aspekte, Munich, GRIN Verlag, https://www.grin.com/document/86406
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X.