Sicherheit in SIP-basierten VoIP-Netzen E-Book

Michael Sauer

• Herausgeber: GRIN Verlag
• Sprache: Deutsch

Veröffentlichungsjahr: 2013

Beschreibung

Masterarbeit aus dem Jahr 2013 im Fachbereich Informatik - IT-Security, Note: 2, Fachhochschule Technikum Wien, Sprache: Deutsch, Abstract: Die Telefonie über das Medium Internet bietet gegenüber der herkömmlichen Telefonie zwei Vorteile: einerseits ist man nicht mehr an einen bestimmten Telefon-Provider gebunden und andererseits ergibt sich durch diesen Umstand in der Regel auch eine Kostenersparnis. Die Benutzung des Internets für die Sprachtelefonie ist aber auch mit Nachteilen bezüglich der Sicherheit verbunden, die in einer eigens dafür geschaffenen Infrastruktur eines Telefon-Providers so nicht vorhanden sind. Diese Master-Thesis versucht herauszufinden, ob eine vergleichbare Sicherheit auch in Voice over Internet Protocol-Netzwerken zu realisieren ist. Für diesen Zweck wird eine zuerst ungeschützte Testumgebung realisiert. Das Herzstück dieser Testumgebung sind zwei Vermittlungsstellen in Form der Open Source Software Asterisk. Diese Umgebung dient als Basis für verschiedene Angriffe, welche die Verwundbarkeit eines solchen Systems aufzeigen sollen. Um die primären Schutzziele der Authentizität, Integrität, Vertraulichkeit und Verfügbarkeit in solch einer Umgebung erfüllen zu können, bedarf es einer systematischen Vorgehensweise. In dieser Arbeit wird nach dem vom Bundesamt für Sicherheit in der Informationstechnik veröffentlichten IT-Grundschutz vorgegangen, in dem im ersten Schritt die vorhandenen Bedrohungen erkannt werden. Darauf folgend gilt es, den erforderlichen Schutzbedarf festzustellen und diesen im letzten Schritt durch geeignete Maßnahmen umzusetzen. Nach der Implementierung unterschiedlicher Sicherheitsprotokolle werden die zuvor durchgeführten Angriffe wiederholt, um festzustellen, ob durch die getroffenen Maßnahmensetzungen die erforderlichen Schutzziele erfüllt werden. Am Ende der Arbeit wird abschließend eine Beurteilung getroffen, ob eine sichere Telefonie über das Internet möglich ist.

Leseprobe

Impressum:

Copyright (c) 2015 GRIN Verlag / Open Publishing GmbH, alle Inhalte urheberrechtlich geschützt. Kopieren und verbreiten nur mit Genehmigung des Verlags.

Bei GRIN macht sich Ihr Wissen bezahlt! Wir veröffentlichen kostenlos Ihre Haus-, Bachelor- und Masterarbeiten.

Jetzt bei www.grin.com

Kurzfassung

Die Telefonie über das Medium Internet bietet gegenüber der herkömmlichen Telefonie zwei Vorteile: einerseits ist man nicht mehr an einen bestimmten Telefon-Provider gebunden und andererseits ergibt sich durch diesen Umstand in der Regel auch eine Kostenersparnis. Die Benutzung des Internets für die Sprachtelefonie ist aber auch mit Nachteilen bezüglich der Sicherheit verbunden, die in einer eigens dafür geschaffenen Infrastruktur eines Telefon-Providers so nicht vorhanden sind. Diese Master-Thesis versucht herauszufinden, ob eine vergleichbare Sicherheit auch in Voice over Internet Protocol-Netzwerken zu realisieren ist.

Für diesen Zweck wird eine zuerst ungeschützte Testumgebung realisiert. Das Herzstück dieser Testumgebung sind zwei Vermittlungsstellen in Form der Open Source Software Asterisk. Diese Umgebung dient als Basis für verschiedene Angriffe, welche die Verwundbarkeit eines solchen Systems aufzeigen sollen.

Um die primären Schutzziele der Authentizität, Integrität, Vertraulichkeit und Verfügbarkeit in solch einer Umgebung erfüllen zu können, bedarf es einer systematischen Vorgehensweise. In dieser Arbeit wird nach dem vom Bundesamt für Sicherheit in der Informationstechnik veröffentlichten IT-Grundschutz vorgegangen, in dem im ersten Schritt die vorhandenen Bedrohungen erkannt werden. Darauffolgend gilt es, den erforderlichen Schutzbedarf festzustellen und diesen im letzten Schritt durch geeignete Maßnahmen umzusetzen.

Nach der Implementierung unterschiedlicher Sicherheitsprotokolle werden die zuvor durchgeführten Angriffe wiederholt, um festzustellen, ob durch die getroffenen Maßnahmensetzungen die erforderlichen Schutzziele erfüllt werden. Am Ende der Arbeit wird abschließend eine Beurteilung getroffen, ob eine sichere Telefonie über das Internet möglich ist.

Abstract

The telephony via the medium Internet offers two main advantages compared to the traditional telephony: On the one hand one is not longer bounded on a certain phone provider and on the other hand one is able to achieve cost savings. But the usage of the Internet for voice telephony has also some disadvantages concerning security, which is not present in a specifically created infrastructure of a phone provider. This master thesis tries to find out if a comparable security can be realized in Voice over Internet Protocol networks.

For this purpose an unprotected test environment will be realized at first. The core of this test environment consists of two exchanges in terms of the open source software Asterisk. This environment is the basis for various attacks, which demonstrates the vulnerability of such a system.

In order to accomplish the primary protection goals of the authenticity, integrity, confidentiality and availability in this environment, a systematic approach is required. This thesis follows the approach of the published IT-Grundschutz from the Bundesamt für Sicherheit in der Informationstechnik , where existing threats are detected at first. Subsequently, it is essential to determine the required protection and to implement it by applicable measures in the last step.

After the implementation of different security protocols the previous attacks will be repeated in order to assess if the taken measures are able to fulfill the required protection targets. At the end of this thesis an assessment is made in order to find out if a secure telephony via the Internet is possible or not.

Keywords: SIP, TLS, VoIP, Asterisk, SRTP

Danksagung

Ich möchte mich an dieser Stelle bei jenen Personen bedanken, die mir bei der Erstellung meiner Diplomarbeit wertvolle Hilfestellung geleistet haben.

Hier möchte ich in erster Linie meinen Erstbetreuer Dipl.-Ing.(FH) Mag. Alexander-Philipp Lintenhofer danken, der mir bei zahlreichen Treffen Ratschläge und Tipps bezüglich der Struktur und des Inhalts dieser Arbeit gab. An dieser Stelle möchte ich mich bei ihm aber nicht nur für die Hilfe bei der Erstellung der Diplomarbeit bedanken, sondern auch für die Art und Weise, wie er seinen Unterricht gestaltet. Er gehört zu jener „Sorte“ von Lektoren, denen es von hoher Wichtigkeit ist, dass seine Studenten das Vorgetragene auch verstehen. Sein Enthusiasmus in Bezug auf das Thema IT-Sicherheit war in jeder Vorlesung zu spüren und auch ansteckend.

Ebenso möchte ich mich bei meinen Zweitbetreuer Dipl.-Ing. Thomas Zeitlhofer bedanken, der mir schon zuvor bei der Erstellung meiner beiden Bachelor-Arbeiten eine große Hilfe war. Auch jetzt hatte er jederzeit ein offenes Ohr für meine Fragen und nahm sich auch die Zeit für persönliche Treffen.

Inhaltsverzeichnis

1. Einleitung

2. Der VoIP-Protokollstack

2.1. Das ISO/OSI-Referenzmodell

2.1.1. Einordnung der VoIP-Protokolle im ISO/OSI-Referenzmodell

2.2. Protokolle für die Mediadatenübertragung

2.2.1. Das Realtime Transport Protocol

2.2.2. Das Realtime Transport Control Protocol

2.3. Signalisierungsprotokolle

2.3.1. Das Session Initiation Protocol

2.3.2. Das Inter-Asterisk eXchange Protocol

2.4. Weitere VoIP-Protokolle

3.Sicherheitsbezogene Protokolle und Mechanismen

3.1. Internet Protocol Security Protocol (IPsec)

3.1.1. Implementierung der Sicherheitsdienste und Betriebsarten von IPsec

3.1.2.Umsetzung einer Sicherheitsstrategie bei IPsec

3.1.3. Kritikpunkte

3.2. Transport Layer Security (TLS)

3.2.1. TLS Handshake Protocol

3.2.2. TLS Record Protocol

3.2.3. Kritikpunkte

3.3. SIP Digest Authentication

3.4. Session Initiation Protocol Secure (SIPS)

3.5. Secure Realtime Transport Protocol (SRTP)

3.5.1. Multimedia Internet KEYing (MIKEY)

3.5.2. Ablauf der gesicherten Kommunikation bei SRTP

3.5.3. Zfone Realtime Transport Protocol (ZRTP)

4. VoIP und NAT

4.1. Network Address Translation

4.2. Die NAT-Problematik bei SIP

4.3. Lösungsmöglichkeiten im Bezug zur NAT-Problematik

4.3.1. Symmetric Response Routing

4.3.2. Symmetric RTP/RTCP

4.3.3. Weitere Lösungsmöglichkeiten

5.Die ungeschützte Testumgebung

5.1. Verwendete Hard- und Software

5.1.1. Der VoIP-Server Asterisk

5.1.2. Der VoIP-Server Asterisk

5.2. Überblick auf die ungesicherte VoIP-Infrastruktur

5.3. Konfiguration der Komponenten

5.3.1. Konfiguration der NAT-Gateways

5.3.2. Konfiguration des DNS-Servers

5.3.3. Konfiguration der Asterisk-Server

5.3.4. Konfiguration der VoIP-Clients

5.4. Testen der ungesicherten VoIP-Infrastruktur

6.Feststellen der Bedrohungen

6.1 Klassifikation von Angriffen

6.2. Netzwerkspezifische Bedrohungen

6.2.1. Bedrohungen auf der Sicherungsschicht

6.2.2. Bedrohungen auf der Vermittlungsschicht

6.2.3. Bedrohungen auf der Transportschicht

6.2.4. Bedrohungen auf der Anwendungsebene

6.3. Strukturanalyse der VoIP-Testumgebung

6.4. Angriffe auf die primären Schutzziele

6.4.1. Angriffe auf das Schutzziel der Verfügbarkeit

6.4.2. Angriff auf das Schutzziel der Vertraulichkeit

6.4.3. Angriff auf das Schutzziel der Integrität und Authentizität

7. Schutzbedarfsfeststellung

7.1. Schutzbedarfsfeststellung für die VoIP-Testumgebung

7.1.1. Schutzbedarfsfeststellung für Anwendungen

7.1.2. Schutzbedarfsfeststellung für IT-Systeme

7.1.3. Schutzbedarfsfeststellung für Räume

8. Auswahl und Umsetzung geeigneter Sicherheitsmaßnahmen

8.1. Schutz der Signalisierungsdaten mittels TLS

8.1.1. Zertifikate

8.1.2. Konfiguration der Asterisk-Server

8.1.3. Konfiguration der VoIP-Clients

8.1.4. Konfiguration des DNS-Servers

8.2. Schutz der Mediadaten mittels SRTP

8.2.1. Konfiguration der Asterisk-Server

8.2.2. Konfiguration der VoIP-Clients

8.3. Die Konfiguration der Firewall

8.4. Testen der geschützten Umgebung

8.5. Wiederholung der Angriffe auf die primären Schutzziele

8.5.1. Angriff auf das Schutzziel der Verfügbarkeit

8.5.2. Angriff auf das Schutzziel der Vertraulichkeit

8.5.3. Angriff auf das Schutzziel der Integrität und Authentizität

9. Fazit

9.1. Erkannte Schwachstellen

9.1.1. Schwachstellen in Bezug auf die Vertraulichkeit

9.1.2. Schwachstellen in Bezug auf die Authentizität und Integrität

9.1.3. Schwachstellen in Bezug auf die Verfügbarkeit

9.2. Vergleich mit IPsec

9.3. Schlusswort

Literaturverzeichnis

Abbildungsverzeichnis

Listings

Tabellenverzeichnis

Abkürzungsverzeichnis

A. Konfigurationsdateien der ungeschützten VoIP-Testumgebung

A.1. NAT-Gateway

A.2. DNS-Server

A.3. Asterisk-Server

B. Konfigurationsdateien der geschützten VoIP-Testumgebung

B.1. NAT-Gateway

B.2. DNS-Server

B.3. Asterisk-Server

1. Einleitung

Der heutzutage anzutreffende Trend, Telefonate statt über das klassische leitungsgebundene Telefonnetz über das Internet zu führen, bietet neben den monetären noch weitere Vorteile. Ein Aspekt betrifft beispielsweise die Ortsungebundenheit. Einem Teilnehmer wird eine Adresse, ähnlich einer E-Mail-Adresse, zugewiesen. Das Telefon des Teilnehmers, dem die Adresse durch entsprechende Konfiguration bekannt gegeben wird, kann an jedem Ort der Welt mit dem Internet verbunden werden und garantiert somit die Erreichbarkeit des Teilnehmers.

Doch wie steht es um die Sicherheit? Können Gespräche über das Internet genauso „sicher“ wie über das klassische Telefonnetz oder das GSM-Netz abgewickelt werden? Um diese Frage zu klären, soll an dieser Stelle darauf hingewiesen werden, dass auch jene Netze, die an einen Telefonprovider gebunden sind, nicht hundertprozentige Sicherheit bieten. Zum einen lässt das heute allgegenwärtige Thema „Vorratsdatenspeicherung“ erkennen, dass zumindest die Verkehrsdaten aufgezeichnet werden, unabhängig davon, ob es sich um Festnetz- oder GSM-Telefonie handelt. Auf der anderen Seite ist es auch versierten Privatpersonen möglich, dank der Open Source-Software OpenBTS und relativ kostengünstiger Hardware einen IMSI-Catcher (International Mobile Subscriber Identity) zu bauen und damit illegalerweise Telefongespräche abzuhören.

Nichtsdestotrotz soll diese Diplomarbeit lediglich klären, ob ein sicheres Telefonieren über das Medium Internet möglich ist. Dazu wird nachfolgend aufgeführte Gliederung verwendet.

Dass der Einleitung folgende Kapitel 2 beleuchtet im ersten Schritt die wichtigsten Protokolle im Bezug auf die Telefonie über das Internet. Neben den „klassischen“ Protokollen wie beispielsweise das Internet Protocol auf der Vermittlungsschicht und dem Transmission Control Protocol und dem User Datagram Protocol auf der Transportebene liegt der Fokus dieses Kapitels auf jenen Protokollen, welche für die Durchführung eines Telefonats über ein Netzwerk von Relevanz sind. Hier handelt es sich auf der einen Seite um das Session Initiation Protocol, das für die Signalisierung und somit in weiterer Folge für die Etablierung eines Mediakanals, in dem die Sprachdaten ausgetauscht werden, zuständig ist. Auf der anderen Seite wird auf das Realtime Transport Protocol eingegangen, dass dermaßen konzipiert ist, dass es auch echtzeitkritische Daten, wie den Mediaverkehr in Form von Sprachdatenpaketen, über ein Netzwerk transportieren kann.

Besteht der Bedarf, die Signalisierungs- und Mediadaten bezüglich der Vertraulichkeit, Authentizität und Integrität zu schützen, so bedarf es gesonderter Protokolle, die solche Schutzziele erfüllen. Einen Teil solcher Protokolle behandelt Kapitel 3. Neben dem auf der Netzwerkschicht arbeitenden Internet Protocol Security Protocol, kurz IPsec, liegt das Hauptaugenmerk in diesem Kapitel auf dem Transport Layer Security (TLS)-Protokoll. Während das erstgenannte Protokoll in der Lage ist, sowohl die Signalisierungs- als auch die Sprachdaten zu schützen, wird TLS nur herangezogen, um die Signalisierungsdaten abzusichern. Um dennoch den Schutz der Mediadaten zu gewährleisten, kann auf das ebenfalls beschriebene Secure Realtime Transport Protocol (SRTP) zurückgegriffen werden.

In Kapitel 4 wird darauf folgend erkannt, dass bei der Signalisierung und dem Transport der Mediadaten Probleme auftreten können, wenn sich zwischen den beteiligten Komponenten ein Network Address Translation (NAT)-Gateway befindet. Beleuchtet werden in diesem Kapitel nicht nur die möglicherweise auftretenden Probleme, sondern auch unterschiedliche Lösungsansätze.

Im nächsten Schritt, beschrieben in Kapitel 5, erfolgt der Aufbau einer Testumgebung zum Zwecke der Internet-Telefonie. Beim Herzstück dieser Umgebung handelt es sich um zwei AsteriskServer in unterschiedlichen Domänen. Daneben finden sich noch fünf VoIP-Clients in Form der Software Blink sowie ein Domain Name System (DNS)-Server. Nach der Konfiguration sämtlicher genannter Komponenten wird in diesem Kapitel abschließend noch ein Funktionstest hinsichtlich einer ungeschützten Kommunikation durchgeführt.

Diese Testumgebung dient in weiterer Folge als Grundlage für das Kapitel 6, in dem jene Bedrohungen festgestellt werden, denen die ungeschützte Testumgebung ausgeliefert ist. Um sämtliche Bedrohungen erkennen zu können, bedarf es einer systematischen Vorgehensweise. In dieser Arbeit wurde der IT-Grundschutz, ein vom Bundesamt für Sicherheit in der Informationstechnik (BSI) veröffentlichter Standard, als Vorgehensweise herangezogen. Abgeschlossen wird dieses Kapitel mit einer Auswahl von Angriffen auf die Testumgebung, um die Existenz der erkannten Bedrohungen offensichtlich zu machen.

Der nächste logische Schritt nach der Bedrohungsfeststellung ist zu erkennen, welcher Schutzbedarf notwendig ist, um den Bedrohungen entgegenwirken zu können. Kapitel 7 befasst sich mit dieser Thematik. Auch hier wird wieder nach dem IT-Grundschutz des BSI vorgegangen.

Nachdem die Bedrohungen und der benötigte Schutz festgestellt wurden, gilt es nun, geeignete Sicherheitsmaßnahmen auszuwählen und umzusetzen, damit der Schutzbedarf auch tatsächlich befriedigt wird. Kapitel 8 stellt sich im ersten Teil dieser Problematik, anschließend wird die zu betrachtende Umgebung wieder auf deren Funktion im Hinblick auf die implementierten Sicherheitsmaßnahmen getestet. Abschließend werden nochmals jene Angriffe durchgeführt, die schon zuvor in der ungesicherten Testumgebung zum Erfolg führten.

2. Der VoIP-Protokollstack

Die Kommunikation in einem Netzwerk verläuft nach bestimmten Protokollen. Dies gilt auch für Voice over IP (VoIP), einer in IP-Netzen durchgeführten Sprachkommunikation. Die von einer Applikation auf Senderseite erzeugten Daten durchlaufen mehrere Protokollschichten, bevor sie anschließend über ein physikalisches Medium zum Rechner des Empfängers übertragen werden. Dort werden die selben Schichten nochmals, diesmal aber in inverser Reihenfolge, passiert. Die Aufgaben jeder einzelnen Schicht sind dabei unterschiedliche. Grundsätzlich gibt es zwei Modelle, mit denen eine Kommunikation beschrieben werden kann. Zum einen handelt es sich um das ISO/OSI-Referenzmodell, welches eher einen theoretischen Ansatz verfolgt, und zum anderen um das in der Praxis tatsächlich verwendete TCP/IP-Referenzmodell. Details zum erstgenannten Modell finden sich im anschließenden Kapitel 2.1 wieder.

Bei einer VoIP-Kommunikation muss eine Unterscheidung zwischen der Signalisierung und der eigentlichen Übermittlung der Sprachdaten getroffen werden. Die Signalisierung ist für die Herstellung und den Abbau einer Verbindung zwischen den Kommunikationspartnern zuständig. Eine Beschreibung der bekanntesten Signalisierungsprotokolle erfolgt in Kapitel 2.3, wobei hier das Hauptaugenmerk auf das Session Initiation Protocol SIP gelegt wird. Nach einem erfolgreichen Verbindungsaufbau kann die Übertragung der Sprachdaten erfolgen. Ein dafür zuständiges Protokoll ist das in Kapitel 2.2 beleuchtete Realtime Transport Protocol RTP sowie dessen zugehöriges Kontrollprotokoll RTCP (Realtime Transport Control Protocol).

2.1. Das ISO/OSI-Referenzmodell

Das ISO/OSI-Referenzmodell wurde seit den späten 70er Jahren mit dem Ziel entwickelt, ein offenes System für Kommunikationsverbindungen (OSI - Open Systems Interconnection) zu schaffen. Standardisiert wurde dieses Modell im Jahr 1983 von der International Organization for Standardization (ISO). Das aus sieben Schichten bestehende ISO/OSI-Referenzmodell (kurz: OSI-Modell) stellt selbst keine Netzwerkarchitektur dar, sondern beschreibt lediglich die Aufgaben der einzelnen Schichten. Die Wahl auf ein siebenschichtiges Modell fiel dabei u.a. auf Grund folgender Überlegungen [1]:

 ein neuer Abstraktionsgrad soll die Erstellung einer neuen Schicht bedingen

 jede Schicht hat eine definierte Funktion zu erfüllen

 die Abgrenzung der Schichten sollte so erfolgen, dass der Informationsfluss zwischen benachbarten Schichten so gering wie möglich ist

 die Anzahl der Schichten soll einen Kompromiss zwischen der Überschaubarkeit der Architektur und einer klaren Funktionstrennung darstellen

Betrachtet man das OSI-Modell in Abbildung 2.1, so lässt sich erkennen, dass der Kommunikationsfluss hier auf zwei Ebenen erfolgt. Auf der einen Seite erfolgt die Kommunikation auf vertikale Weise, das bedeutet, dass jede Schicht ein Interface zu den angrenzenden Schichten besitzt (Interlayer-Kommunikation). Ein wesentliches Merkmal dieser Kommunikationsart ist, dass eine Schicht die Dienste der darunterliegenden Ebene nutzt und im Gegenzug seine Dienste der darüberliegenden Schicht anbietet. Auf der anderen Seite erfolgt die Kommunikation horizontal, man spricht hier auch von einer Peer-to-Peer-Kommunikation. Hier kommuniziert jede Schicht des OSI-Modells auf dem System des Absenders mit der gleichrangigen Schicht auf dem Zielsystem.

Abbildung 2.1.: Das ISO/OSI-Referenzmodell [1]

2.1.1. Einordnung der VoIP-Protokolle im ISO/OSI-Referenzmodell

Jene Protokolle, die für eine erfolgreiche VoIP-Kommunikation erforderlich sind, befinden sich in unterschiedlichen Schichten des OSI-Modells. Ein gemeinsames Merkmal sämtlicher für den Verbindungsaufbau zuständigen Signalisierungsprotokolle ist deren Zuordnung zur Anwendungsschicht. Unterschiede ergeben sich aber bei der Wahl des Transportprotokolls. So verwendet das Signalisierungs-Framework H.323-SIG hauptsächlich TCP, während das in Kapitel 2.3.1 beschriebene Session Initiation Protocol Mechanismen zur Fehlerbehebung selbst mitbringt und somit auf das verbindungslose UDP aufsetzen kann. Auch das Inter-Asterisk eXchange Protocol sowie diverse Protokolle zur Steuerung von VoIP-Gateways wie MGCP oder Megaco nutzen das verbindungslose Transportprotokoll.

Schwieriger gestaltet sich die Zuordnung des Realtime Transport Protocols (RTP), das für die Übertragung der Mediadaten zuständig ist (siehe Kapitel 2.2.1). So deklariert der für dieses Protokoll zuständige RFC 3550 [2], dass es sich bei RTP um ein Transportprotokoll, also einem Protokoll der Transportschicht, handelt. Andererseits nutzt es aber UDP und dessen Multiplexingfähigkeiten. Ebenso ist RTP sehr eng mit der Applikation verknüpft und würde somit einer Zuordnung zu Schicht 7 entsprechen. Eine Möglichkeit der Einordnung wäre, UDP als Protokoll der Schicht 4a zu betrachten und darauf aufsetzend RTP dem Layer 4b zuzuordnen [3].

2.2. Protokolle für die Mediadatenübertragung

Protokolle zum Zwecke der Übertragung von Mediadaten müssen vor allem einen Aspekt berücksichtigen: Die Übermittlung der Audio- und Videodaten soll in Echtzeit erfolgen. Ein Protokoll, dass diesen Aspekt zu erfüllen versucht, ist das in Kapitel 2.2.1 betrachtete Realtime Transport Protocol (RTP) sowie das zugehörige Realtime Transport Control Protocol (RTCP), welches eine Überwachung der RTP-Echtzeitkommunikation vornimmt und dadurch eine Sicherstellung der Übertragungsqualität gewährleisten soll. RTCP wird in Kapitel 2.2.2 behandelt. Sowohl RTP als auch RTCP sind im RFC 3550 [2] spezifiziert.

2.2.1. Das Realtime Transport Protocol

Bei RTP handelt es sich um ein verbindungsloses und ungesichertes Transportprotokoll, das in der Regel auf UDP aufsetzt. RTP teilt den von der Anwendungsschicht einlangenden Mediastrom in Pakete auf, die den Payload eines RTP-Pakets darstellen. Diesem Payload wird noch ein Header (siehe Kapitel 2.2.1.2) vorangestellt, bevor das RTP-Paket an das darunterliegende Transportprotokoll weitergereicht wird. Auf dem Weg vom Sender zum Empfänger kann dieses Paket mehrere RTP-spezifische Komponenten durchlaufen, wie im anschließenden Kapitel 2.2.1.1 beschrieben wird.

2.2.1.1. Komponenten eines RTP-Systems

In diesem Abschnitt wird auf die grundlegendsten Elemente eines RTP-Systems eingegangen. Im Konkreten handelt es sich dabei um folgende Komponenten, wobei die drei letztgenannten Punkte optionale Bestandteile sind:

 Sender

 Empfänger

 Session

 Translator

 Mixer

 Monitor

Der RTP-Sender erfasst (im Kontext von VoIP) die Sprache und digitalisiert diese. Anschließend werden die so gewonnenen Daten entweder Abtastwert- oder Segment-orientiert codiert und als Payload eines oder mehrerer RTP-Pakete verwendet. Nach der Erzeugung eines RTP-Headers wird diesen Paketen noch ein UDP- und IP-Header vorangestellt und schlussendlich versandt [4]. Eine weitere Aufgabe des RTP-Senders ist die Generierung von Sender Reports sowie der Empfang und die Auswertung von Receiver Reports, um im Bedarfsfall eine Übertragungsanpassung vornehmen zu können (siehe auch Kapitel 2.2.2).

Der RTP-Empfänger durchläuft diese Prozedur in umgekehrter Reihenfolge. Er empfängt die Pakete, führt eventuelle Fehlerkorrekturen durch, dekodiert die Sprachdaten und transformiert sie mittels eines D/A-Wandlers in ein analoges Signal. Damit der RTP-Sender die zuvor erwähnte Anpassung durchführen kann, muss der Empfänger diesem auch in periodischen Abständen Receiver Reports zukommen lassen.

Unter einer RTP-Session versteht man eine Menge an Teilnehmern, die mittels RTP miteinander kommunizieren, wobei jeder Teilnehmer durch eine Netzwerkadresse und einem Port-Paar identifiziert werden kann. Der erste dieser beiden Ports muss eine geradzahlige Portnummer besitzen und wird für die RTP-Kommunikation verwendet. Der darauffolgende Port (mit ungerader Portnummer) dient der Übermittlung von RTCP-Paketen. Sessions können in zwei Gruppen kategorisiert werden: Zum einen in Unicast-Sessions, bei denen die Kommunikation Punkt-zu-Punkt erfolgt, oder in Multicast-Sessions, in denen mehr als zwei Teilnehmer involviert sind.

Die Verwendung eines Translators zwischen Sender und Empfänger ist dann notwendig, wenn eine Konvertierung der Mediadaten vorzunehmen ist. Ein Translator kann aber auch andere Aufgaben durchführen, wie etwa eine Ver- und Entschlüsselung oder eine Filterung des Mediastreams. Das SSRC-Feld im RTP-Header (siehe Kapitel 2.2.1.2) bleibt bei der Weiterleitung des Pakets durch die Bearbeitung dieser Komponente unberührt.

Ein Mixer empfängt RTP-Datenpakete von einer oder mehreren Quellen und führt diese zusammen, um sie anschließend als eine Abfolge von Paketen weiterzuleiten, die nur aus einer einzigen Quelle, dem Mixer, stammen. Diese Quelle wird auch bei den neu geformten Paketen im SSRC-Feld des RTP-Headers eingetragen.

Als letzte Komponente sei noch der Monitor zu erwähnen, dessen Einsatz dann Sinn macht, wenn statistische Auswertungen oder Fehlerdiagnosen einer Sprachverbindung durchzuführen sind. Ein Monitor empfängt die RTCP-Pakete und kann aus den dort enthaltenen Informationen Rückschlüsse über den aktuellen Dienstgüte-Status der Verbindung ziehen.

2.2.1.2. Der RTP-Header