Voice over IP unter Linux: Nebenstellenanlage mit Asterisk

Inhaltsverzeichnis

1 Einleitung

2 Voice over IP
2.1 Traditionelle Telefonie
2.2 VoIP als neuer Ansatz
2.3 Qualitätsanforderungen an VoIP
2.4 Sicherheitsaspekte

3 Die Digitalisierung der Sprache
3.1 Sprachcodierungen in VoIP

4 VoIP-relevante Protokolle
4.1 Protokolle für die Sprachdatenübertragung
4.1.1 Das Real-time Transport Protocol (RTP)
4.1.1.1 Die Architektur
4.1.1.2 Der RTP-Header
4.1.2 Das Real-time Transport Control Protocol (RTCP)
4.2 Signalisierungsprotokolle
4.2.1 H.323-SIG
4.2.1.1 H.323-Systemkomponenten
4.2.1.2 H.323-Protokolle und deren Aufgaben
4.2.1.3 Ablauf einer Kommunikation nach H.323-SIG
4.2.2 Session Initiation Protocol (SIP)
4.2.2.1 Hauptaufgaben von SIP
4.2.2.2 SIP-Netzelemente
4.2.2.3 Das SIP-Trapezoid
4.2.2.4 Session Description Protocol (SDP)
4.2.2.5 SIP-Erweiterungen
4.2.2.6 Probleme mit NAT
4.2.3 Inter-Asterisk eXchange Protocol Version 2 (IAX2)

5 Asterisk
5.1 Funktionen von Asterisk
5.2 Das Konzept des Wählplans bei Asterisk

6 Aufbau und Bewertung einer VoIP-Testumgebung
6.1 Die Testumgebung
6.2 Anforderungen an das Testszenario
6.2.1 Anforderungen an die Firewall
6.2.2 Anforderungen in Bezug auf QoS
6.2.3 Anforderungen in Bezug auf die Nebenstellenfunktionalität
6.3 Vorbereitungsmaßnahmen
6.3.1 Konfiguration der Netzwerk-Schnittstellen
6.3.2 Installation von SSH
6.3.3 Installation von Asterisk und optionalen Zusatzpaketen
6.4 Die Umsetzung der Anforderungen
6.4.1 Die Implementierung der Firewall
6.4.2 Die Bereitstellung von QoS
6.4.3 Die Integration der Nebenstellen in das VoIP-System
6.4.3.1 Die Konfiguration der SIP-Teilnehmer
6.4.3.2 Die Konfiguration der IAX2-Teilnehmer
6.4.3.3 Der Wählplan
6.4.3.4 Die Konfiguration der Voice-Mailbox
6.4.3.5 Überlegungen in Bezug auf die Mediadaten-Übertragung
6.4.3.6 Länderspezifische Signaltöne
6.5 Die Bewertung der Gesprächsqualität

7 Fazit

Literaturverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Herkömmliche Telefonie benötigt als Grundlage eine Netzinfrastruktur, die es ermöglicht, leitungsorientierte Verbindungen zwischen zwei beliebigen Teilnehmern innerhalb dieser Infrastruktur herzustellen. Diese Infrastruktur wird in der Regel von einem Telekommunikationsanbieter zur Verfügung gestellt und hat sich über Jahrzehnte bewährt.

Die physikalische Leitung, die im Falle einer Vermittlung über eine oder mehrere Vermittlungsstellen geschalten wird, steht ausschließlich den beteiligten Gesprächsteilnehmern mit der vollen Bandbreite zur Verfügung. Diese funktionierende und qualitativ hochwertige Netzinfrastruktur hat jedoch einen entscheidenden Nachteil: Der Telekommunikationsanbieter möchte für die Bereitstellung dieser Infrastruktur bezahlt werden.

Voice over IP (VoIP) ist ein neuerer Ansatz, der diesen Nachteil umgehen will. Unter VoIP versteht man die Übermittlung der digitalisierten Sprache, eingebettet in eine entsprechende Anzahl an Paketen, über ein IP-Netzwerk. Da es sich beim Internet um ein solches Netzwerk handelt, ist die Möglichkeit einer weltweiten Sprachkommunikation gegeben.

Diese neu gewonnene Möglichkeit birgt jedoch auch eine Vielzahl an Herausforderungen in sich, die bewältigt werden müssen, um den bisher gewohnten Qualitätsstandards gerecht zu werden. Kapitel ² gibt einen kurzen Überblick auf die elementarsten Herausforderungen an ein VoIP-System: die Erfüllung von Quality of Service (QoS)-Anforderungen sowie sicherheitsbezogene Aspekte, die auf keinen Fall vernachlässigt werden dürfen.

Eine der zu bewältigenden Hürden ist die Umwandlung eines analogen Sprachsignals in eine digitale Form. Hier soll versucht werden, die Größe der generierten Pakete möglichst klein zu halten, damit die Sprachdatenübertragung auch in Umgebungen mit geringer Bandbreite zufriedenstellend funktioniert. Auf der anderen Seite soll die Umwandlung derart geschehen, dass möglichst wenig Informationen des ursprünglichen (analogen) Sprachsignals verloren gehen. Dies ist notwendig, damit bei der Rekonstruktion des digitalen in ein analoges Signal möglichst keine Unterschiede zum Original feststellbar sind. Der Algorithmus, der diese Codierung bzw. Decodierung vornimmt, wird als Codec bezeichnet. Das Grundprinzip der Digitalisierung der Sprache sowie die Funktionsweise und Eigenschaften der gebräuchlichsten Codecs wird in Kapitel ³ beschrieben.

Die nach der Codierung entstandenen Pakete müssen nach einem erfolgreichen Verbindungsaufbau übertragen werden. Sowohl für den Vorgang des Verbindungsaufbaus, man spricht hier von Signalisierung, als auch für die anschließende Übertragung der Sprachdatenpakete sind spezielle Protokolle notwendig. Kapitel ⁴ verrät, um welche Protokolle es sich dabei handelt.

Die beiden anschließenden Kapitel ⁵ und ⁶ beschäftigen sich mit einer Nebenstellenanlage auf Softwarebasis, die primär für das Betriebssystem GNU/Linux entwickelt wird. Konkret handelt es sich hierbei um die Software „Asterisk“, mit deren Hilfe nicht nur eine Telefonieumgebung mit einer Vielzahl an Teilnehmern realisiert werden kann. Vielmehr bietet diese Applikation derart viele Funktionen, die in ihrer Gesamtheit in einer käuflich erwerbbaren, Hardware-basierten Nebenstellenanlage schwer zu finden sind.

Ebenfalls in Kapitel 6 enthalten ist die Behandlung der QoS-Anforderungen, die in einer VoIP-Umgebung zu erfüllen sind. Auch hier ist GNU/Linux wieder das Betriebssystem erster Wahl, da es die erforderlichen Mittel zur Realisierung von QoS anhand des Programms „tc“ zur Verfügung stellt.

Den Abschluss dieser Arbeit bildet der Aufbau sowie die Beurteilung einer VoIP-Umgebung auf Basis der Nebenstellenanlage „Asterisk“.

2 Voice over IP

Dieses Kapitel vergleicht die beiden unterschiedlichen Ansätze der bisherigen leitungsvermittelten Telefonie und der neuartigen VoIP-Telefonie auf Basis der Paketvermittlung. Neben der Auflistung der Vor- und Nachteile der Sprachkommunikation über ein IP-Netzwerk wird auch auf das ENUM-Konzept eingegangen, welches notwendig ist, um auch für Gesprächspartner aus fremden Netzen erreichbar zu sein.

Qualitäts- und Sicherheitsanforderungen an ein VoIP-System im Produktiveinsatz sind ebenfalls zu erfüllen. Welche Kriterien dabei zu beachten sind, wird in den letzten beiden Unterkapiteln 2.3 und 2.4 erläutert.

2.1 Traditionelle Telefonie

Schon ein Jahr nach der Erfindung des Telefons durch Alexander Graham Bell im Jahr 18761 wurde die Firma „Bell Telephone Association“ (heute AT&T) mit der Absicht gegründet, eine Telefonnetz-Infrastruktur in den USA aufzubauen. Der Beginn der Errichtung von Telefonnetzen in anderen Staaten folgte unmittelbar später.

Anfangs erfolgte die Vermittlung noch manuell, ab Beginn des 20. Jahrhunderts wurden jedoch schon die ersten Versuche unternommen, diesen Vorgang zu automatisieren. Dabei sendete der Teilnehmer durch das Drehen der Wählscheibe eine je nach gewählter Ziffer unterschiedliche Anzahl an Spannungsimpulsen mit einem definierten Puls/Pausen-Verhältnis an die Vermittlungsstelle. Diese Spannungsimpulse wurden von mechanischen Elementen wie

z. B. Drehwähler, Hebdrehwähler oder Motorwähler für die Verbindungsherstellung benutzt. Sowohl für die Signalisierung als auch für die Übertragung der Sprache wurde ein einziger analoger Kanal verwendet.

Ende der 80er Jahre des vergangenen Jahrhunderts wurde mit der Einführung von ISDN (Integrated Services Digital Network) begonnen. Das analoge Konzept wurde dabei durch ein digitales ersetzt, sowohl die Signalisierung als auch die Sprachdatenübertragung betreffend. Weiters wurden die Kanäle für diese beiden Aufgaben nun gesplittet, sodass für die Übertragung der Nutzdaten (Sprache, Fax oder Daten) zwei B-Kanäle mit je 64 kbit/s und für die Signalisierung ein D-Kanal mit 16 kbit/s zur Verfügung standen.

Egal, ob es sich um eine manuelle Vermittlung durch das „Fräulein vom Amt“, eine automatisierte analoge Vermittlung durch mechanische Komponenten oder um einen

Verbindungsaufbau auf digitale Art und Weise, wie ihn ISDN benutzt, eines haben alle drei Verfahren gemein: Die Vermittlung erfolgt leitungsorientiert, das heißt, bevor ein Gespräch zustande kommen kann, wird eine Verbindung hergestellt, die exklusiv für diese Kommunikation zur Verfügung steht.

2.2 VoIP als neuer Ansatz

Mit VoIP ist es möglich geworden, für eine Sprachkommunikation nicht mehr auf die (in der Regel mit Kosten behaftete) Benutzung einer Infrastruktur eines Telekommunikation- Anbieters angewiesen zu sein. Stattdessen wird hier ein Computernetzwerk (hierbei kann es sich sowohl um ein Intranet oder auch das Internet handeln) für diesen Zweck verwendet. VoIP ist dabei jedoch keine weitere Applikation, die die Struktur des Internets nutzt. Vielmehr mussten neue Protokolle entwickelt werden, um bestimmte Anforderung erfüllen zu können, die eine Sprachtelefonie verlangt. Diese Anforderungen werden in Kapitel 2.3 kurz beschrieben.

Abgesehen vom Aspekt der Netzbetreiberunabhängigkeit und der damit auch verbundenen Kostenersparnis existieren noch weitere Vorteile, die für VoIP sprechen. Vor der Existenz von VoIP benötigte ein Unternehmen etwa zwei verschiedenartige Infrastrukturen, eine für deren Intranet und eine zweite für deren Sprachkommunikation. Dabei handelte es sich in der Regel um eine Nebenstellenanlage, an der sämtliche Telefone der Firma angeschlossen waren. Die Hauptaufgabe der Nebenstellenanlage bestand darin, die Konnektivität dieser Telefone untereinander und mit dem öffentlichen Fernsprechnetz zu verwalten. Mittels VoIP kann nun eine einzige Infrastruktur für beide Aufgaben verwendet werden, das im Endeffekt zu Kostenersparnissen führt.

Ein weiterer Vorteil liegt in der Flexibilität. Herkömmliche Telefonanschlüsse sind ortsgebunden, VoIP hingegen beinhaltet Mechanismen, in der ein Teilnehmer zwar eine einzigartige Adresse besitzt, unter der er erreichbar ist, jedoch kann sich der Teilnehmer an jedem Ort der Welt befinden (sofern er dort einen Anschluss an das Internet vorfindet!).

Ein nicht zu unterschätzender Vorteil ist auch, dass ein VoIP-System in Koexistenz mit herkömmlichen Telefonnetzen existieren kann. Durch den Einsatz entsprechender Gateways ist es nun auch Firmen möglich, eine Umstellung des bisherigen Systems auf VoIP nicht auf einen Schlag durchführen zu müssen. Vielmehr können die entsprechenden Komponenten nach und nach ausgetauscht werden. Man spricht hierbei von einer sanften Migration.

Im Zuge einer Migration stellt sich jedoch folgende Frage: Wie erreiche ich aus meinem gegenwärtigen Netz einen Teilnehmer des anderen Netzes oder wie werde ich erreicht? Das Problem liegt hier also in der Adressierung. An herkömmliche Telefonnetze angeschlossene Endgeräte werden mit sogenannten E.164-Rufnummern adressiert [1]. Die Struktur dieser Adressierung kann aus Abb. 1 entnommen werden.

Die Adressierung der VoIP-Endsysteme erfolgt auf eine andere, inkompatible Art, bestehend aus Benutzer- und Domainnamen, ähnlich dem Aufbau einer E-Mail-Adresse. Im Falle von SIP (Session Initiation Protocol) erfolgt die Adressierung etwa anhand einer SIP URI mit folgendem Format:

sip:michael.sauer@technikum-wien.at

Der Anruf aus einem VoIP-Netz, im beschriebenen Fall von einem SIP-Telefon, zu einem Teilnehmer in einem PSTN- oder ähnlichem Fremdnetz ist relativ unproblematisch. Die anzurufende Telefonnummer ist Bestandteil der SIP URI (anstelle des Benutzernamens), welche vor dem Passieren des Gateways extrahiert wird.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: E.164-Rufnummernadressierung nach ITU-T [1]

Ein weitaus größeres Problem stellt der umgekehrte Fall - ein Anruf aus dem Fremdnetz in ein VoIP-Netz - dar. Der Zeichensatz einer E.164-Rufnummer besteht lediglich aus numerischen Zeichen, Adressen mit alphanumerischen Zeichen können also nicht angewählt werden.

Die Lösung für dieses Problem bietet das ENUM-Konzept (E.164 Number Mapping) an. Dabei werden den Teilnehmern im VoIP-Netz auch Telefonnummern im E.164-Format zugewiesen. ENUM wandelt diese Nummer in eine im Internet gültige URL um, damit diese dann per DNS auffindbar ist. Bei der Umwandlung werden dabei im ersten Schritt die in der Nummer enthaltenen Ziffern so positioniert, dass am Schluss die erste Ziffer an letzter Stelle, die zweite Ziffer an vorletzter Stelle usw. steht. Anschließend werden zwischen den Ziffern Punkte eingefügt und im letzten Schritt die Top Level Domain hintangefügt [2]:

E.164-Rufnummer: +43 780 1234567

ENUM-URL: 7.6.5.4.3.2.1.0.8.7.3.4.e164.arpa

Im DNS-Eintrag einer ENUM-URL können unterschiedliche, auch mehrere, Kontaktadressen hinterlegt werden. Sinnvoll in diesem Fall ist die zur E.164-Nummer äquivalente SIP URI- Information.

Jetzt kann nun ein Anruf aus dem Fremdnetz absolviert werden. Dabei wählt der Anrufer die E.164-Nummer des VoIP-Teilnehmers. Die Vermittlungsstelle des Anrufers initiiert anhand der gewählten Rufnummer eine DNS-Abfrage und bekommt als Resultat die SIP URI des anzurufenden Teilnehmers. Mittels dieser nun gewonnenen Information kann die Signalisierung in das VoIP-Netz über ein entsprechendes Gateway weitergeleitet werden.

Als Abschluss dieses Kapitels stellt sich die Frage nach den Nachteilen von VoIP. Bisherige Telefoniedienste, die von einem Netzbetreiber zur Verfügung gestellt werden, sind nicht unfehlbar in Bezug auf die Sicherheit2. Die Bedrohungen im Internet und somit auch jene für die IP-Telefonie sind jedoch um einiges höher und erfordern dementsprechenden Aufwand, um sowohl die Funktionalität der VoIP-Infrastruktur als auch die Erfüllung diverser

Schutzziele zu gewährleisten.

2.3 Qualitätsanforderungen an VoIP

Die Anforderungen an eine Übertragung von Sprachdaten sind üblicherweise höhere als an eine von „normalen“ Daten. So ist es beispielsweise unerheblich, ob eine abgesendete E-Mail deren Empfänger Sekundenbruchteile oder eine Minute später erreicht. Bei der Telefonie ist es offensichtlich, dass Sprachpakete, die Sekunden später eintreffen, keine vernünftige Konversation ermöglichen. Dies ist aber nur eine der speziellen Anforderungen, die - bezogen auf die Qualität - an VoIP gestellt wird. In Summe beeinflussen vier Merkmale die Qualität einer Sprachkommunikation [3]:

- Bandbreite von virtuellen Verbindungen zwischen den Endgeräten
- Delay
- Jitter
- Packet Loss Rate

Der erste Punkt beschreibt die Tatsache, dass für die Übertragung der codierten Sprachsignale die entsprechende Bandbreite zur Verfügung stehen muss. Die Wahl des Codierungsverfahrens (siehe Kapitel 3) ist somit auch von der zur Verfügung stehenden Bandbreite abhängig.

Unter einem Delay versteht man die Verzögerungszeit, die ein Sprachsignal vom Absender zum Empfänger braucht. Verschiedene Faktoren beeinflussen die Laufzeit eines solchen Signals (bzw. des Pakets, welches das Signal beinhaltet), wie etwa die Zeiten, die für die Codierung und Decodierung des Signals notwendig sind oder die Zeiten, in denen das Paket bei zwischenliegenden Routern verweilt, da auch diese Zeit benötigen, um den Header des Paketes auszuwerten und Routing-Entscheidungen zu treffen. Eine weitere Stelle, an der Pakete „ausgebremst“ werden können, ist das Modem des Senders, welches im Normalfall eine einzige Warteschlange für die zu sendenden Daten besitzt. Hier kann man insofern gegensteuern, indem man davor ein Queue Management betreibt, welches zu sendende Daten in der Geschwindigkeit an das Modem weiterleitet, in der es Daten in das Internet weiterzuleiten fähig ist. Damit bleibt die Warteschlange des Modems leer und kann Sprachdatenpakete, die das davorliegende Queue Management System mit höchster Priorität an das Modem schickt, sofort versenden.

Beim Queue Management System, dass die Sprachdatenpakete vorrangig weiterleiten soll, handelt es sich typischerweise entweder um eine klassenlose pfifo_fast-Queueing Discipline (QDisc) oder um eine klassenbehaftete PRIO QDisc. Das Grundprinzip ist bei beiden ähnlich: Insgesamt stehen mindestens drei Bänder zur Verfügung. Das TOS-Feld (Type of Service) im

Header einlangender IP-Pakete wird untersucht und abhängig von dessen Wert wird das Paket in eines der vorhandenen Bänder eingereiht. Sprachdatenpakete werden im Normalfall dem Band 0 zugeordnet, welches das höchstpriore Band darstellt. Solange sich Pakete in Band 0 befinden, sind etwaig vorhandene Pakete in anderen Bändern blockiert. Jedes einzelne Band leitet die Pakete nach dem FIFO-Prinzip (First-In-First-Out) weiter [4].

Den Jitter, also die Varianz der Verzögerungszeit), möglichst gering zu halten, kennzeichnet die dritte Anforderung an ein VoIP-System. Entstehen kann Jitter durch unterschiedliches Routing der einzelnen Pakete. Eine wirkungsvolle Maßnahme zur Jitter-Reduktion ist die Verwendung eines Jitter-Ausgleichspuffer auf Empfängerseite [3].

Die letzte Anforderung betrifft die Anzahl der verloren gegangenen Pakete. Bis zu einem gewissen Grad ist VoIP dagegen unempfindlich, steigt jedoch die Paketverlustrate, so sind merkbare Unterbrechungen in der Sprachkommunikation die Folge [3].

2.4 Sicherheitsaspekte

Telefonie über ein Netzwerk, und im Besonderen über das Internet, ist sämtlichen Bedrohungen ausgesetzt, mit denen auch klassische Internetanwendungen konfrontiert sind. Bei der Planung und Umsetzung einer VoIP-Infrastruktur muss darauf Bedacht genommen und im Sinne eines PDCA-Zyklus mögliche Sicherheitslücken geschlossen werden, welche die Schutzziele der Vertraulichkeit, Integrität, Authentizität und Verfügbarkeit verletzen. Im Sinne des PDCA-Zyklus bedeutet hier, dass Sicherheit nicht mit einer einmaligen Analyse möglicher Schwachstellen und einer darauf folgenden Umsetzung von Sicherheitsmaßnahmen realisiert ist. Vielmehr müssen die Ergebnisse der getroffenen Maßnahmen laufend überprüft und verbessert werden.

Eine Vielzahl unterschiedlicher Bedrohungen lauern auf allen vier Ebenen des TCP/IP- Referenzmodells. Exemplarisch werden an dieser Stelle drei davon näher beschrieben, die Anthony Plewes als am gefährlichsten einstuft [5]:

Businesses of all sizes adopting IP telephony need to seriously consider its security implications. But while a number of threats exist, three stand out as the most dangerous, particularly to smaller organizations: denial of service, spit and fraud.

Denial of Service-Attacken (DoS) können durch permanente Anfragen an einen Rechner diesen lahmlegen. Effektiver versehen diese Angriffe ihren Dienst, wenn sie von mehreren Stellen gleichzeitig einen Rechner attackieren. Man spricht in so einem Fall von Distributed Denial of Service (DDoS). DoS-Attacken können sowohl auf der Netzwerk-, der Transport- aber auch auf der Anwendungsebene erfolgen. DoS-Angriffe auf der IP-Ebene werden etwa in der Regel mit speziellen ICMP-Nachrichten vollzogen, während auf der Transportebene ein Senden unzähliger SYN-Pakete (SYN-Flooding) zum Erfolg führt. Auf Applikationsebene ist im Falle von SIP ein sich ständig wiederholender INVITE-Request auch als DoS-Attacke zu verstehen. Dadurch wird eine ständige Rufsignalisierung beim „Opfer“ provoziert, der schlussendlich das Telefon deaktivieren wird und somit nicht mehr erreichbar ist. Der Angreifer hat somit sein Ziel - das Lahmlegen dieser Komponente - erreicht [3].

SPIT (Spam over Internet-Telephony) ist das VoIP-bezogene Pendant zu Spam. Anstatt den E-Mail-Benutzer zu belästigen, werden bei SPIT dem Sprachkommunikationsteilnehmer

unerwünschte Werbebotschaften in akustischer Form übermittelt, entweder durch direkten Anruf oder durch Hinterlegen dieser „Angebote“ in seiner Voice-Mailbox.

Gebührenbetrug (Call Fraud) entsteht, wenn eine unberechtigte Person das VoIP-System nutzt und dadurch anderen Personen finanziellen Schaden zufügt. Auch hier sind die Möglichkeiten, wie ein Betrug vonstattengeht, unterschiedlich. In der unkompliziertesten Form benutzt der Betrüger ein fremdes Telefon, um Anrufe auf fremde Kosten durchzuführen. Eine andere Variante ist, einen Trojaner in das VoIP-System einzuschleusen, um Informationen gewinnen zu können, die für das weitere Vorhaben notwendig sind.

3 Die Digitalisierung der Sprache

Sprachinformationen, die über ein IP-Netzwerk übertragen werden sollen, liegen ursprünglich in analoger Form vor und müssen daher dementsprechend digital abgebildet werden. Diese Transformation setzt sich aus folgenden Schritten zusammen [3]:

- Glättung durch Tiefpassfilterung des analogen Sprachsignals (Anti-Aliasing-Filter)
- Abtastung des geglätteten Signals
- Quantisierung
- Repräsentation der einzelnen, quantisierten Werte durch binäre Codewörter

Unter Quantisierung versteht man in diesem Zusammenhang das Auf- oder Abrunden eines analogen Spannungswertes auf einen diskreten Wert. Diese Maßnahme ist notwendig, da ein (analoger) Spannungsbereich unendlich viele Werte annehmen kann, die digitale Darstellung jedoch auf einen endlichen Zahlenraum beschränkt ist.

Die so erzeugten Codewörter bilden in Summe den Sprachbitstrom, der anschließend paketiert und versendet werden kann.

Der Empfänger muss nun aus den erhaltenen Paketen die Sprachinformationen herausfiltern und sie in ein analoges Signal umwandeln, welches in verstärkter Form einem Lautsprecher zugeführt werden kann. Die konkreten Schritte dabei sind:

- Extraktion der Sprachinformation aus dem IP-Paket
- Umwandlung des jeweiligen Codewortes in einen analogen Spannungswert
- Glättung der dabei entstandenen „Treppenkurve“ mithilfe eines Rekonstruktionstiefpasses

Zusammenfassend verdeutlicht Abb. 2 noch einmal den kompletten Ablauf, von der Codierung über den Versand bis hin zur abschließenden Decodierung eines Sprachsignals.

Grundsätzlich kann die Sprachcodierung auf zwei Arten erfolgen: Entweder man wendet ein Abtastwert-orientiertes (Sample-based) oder ein Segment-orientiertes (Frame-based) Verfahren an.

Bei der ersten Variante wird das Sprachsignal (üblicherweise) 8000-mal pro Sekunde abgetastet und die entsprechenden Werte codiert. Die Wahl dieses Wertes ergibt sich aus der Tatsache, dass bei einer Sprachübertragung der Frequenzbereich von 300 bis 3400 Hz übertragen wird. Das entspricht einem Frequenzband von 3,1 kHz. Nach dem Shannon’schen Abtasttheorem muss die Abtasthäufigkeit mindestens doppelt so hoch sein wie die im

analogen Signal enthaltene höchste Frequenz, in diesem Fall also mindestens 6,8 kHz. International einigte man sich letztendlich auf eine Abtasthäufigkeit von 8 kHz [3]. Jeder Abtastwert wird - im Falle des Pulse Code Modulation-Verfahrens (PCM) - mit 8 Bits codiert, dass letztendlich zu einer Datenrate von 64 kbit/s führt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Prinzip der digitalen Sprachübermittlung [3]

Ein anderes Verfahren, welches auch auf Sample-Based-Codierung basiert, ist das Differential PCM (DPCM). Die Theorie dahinter ist, dass aufeinander folgende Sprachsignale bestimmte statistische Abhängigkeiten aufweisen. Dank dieser Eigenschaft können zukünftige Amplitudenwerte mit einer bestimmten Wahrscheinlichkeit vorausgesagt werden. Codiert und übertragen werden in weiterer Folge nicht mehr die absoluten, diskreten Spannungswerte, sondern die Differenz zwischen dem prädiktierten und dem tatsächlichen Wert. Da diese beiden Werte in der Regel nahe beieinanderliegen, sind kürzere Codewörter und somit eine geringere Bitrate bei gleichbleibender Qualität möglich [3].

Bei DPCM werden die Prädiktions-Parameter zu Beginn bestimmt und bis zum Ende der Sprachcodierung verwendet. Tatsache ist jedoch, dass sich die statistischen Eigenschaften eines Sprachsignals im Laufe der Zeit verändern und infolgedessen eine kontinuierliche Anpassung dieser Parameter wünschenswert wäre. Diesem Wunsch geht die Adaptive DPCM (ADPCM) nach, welche das Sprachsignal in kleine Zeitsegmente zerlegt (üblicherweise 10 bis 20 ms) und für jedes dieser Segmente die entsprechenden Parameter festlegt. Mittels ADPCM sind je nach Länge des Codewortes Datenratenreduktionen auf 16 kbit/s bis 40 kbit/s möglich.

Bei allen drei oben genannten Verfahren (PCM, DPCM und ADPCM) erfolgt die Quantisierung nichtlinear. Der Unterschied zwischen linearer und nichtlinearer Quantisierung liegt im Quantisierungsintervall, also dem Abstand zwischen zwei benachbarten Quantisierungsstufen.

Bei einer linearen Quantisierung ist dieser Abstand stets gleich groß. Bei Anwendung dieses Verfahrens ergibt sich jedoch der Nachteil der Quantisierungsgeräusche, die beim Auf- oder Abrunden eines kontinuierlichen Signalwerts zu einem diskreten Wert entstehen. Diese sind umso deutlicher hörbar, je höher das Quantisierungsintervall ist.

Man könnte zwar die Quantisierungsintervalle verkürzen, was aber insofern nicht zielführend ist, da eine damit verbundene Erhöhung der Quantisierungsstufen auch zu einer Vergrößerung der Codewörter und schlussendlich zu einer höheren Bitrate führt. Eine bessere Alternative

stellt die nichtlineare Quantisierung dar. Dabei werden unterschiedlichen Amplitudenwertbereichen verschiedene Quantisierungsintervalle zugewiesen. So erhalten

„leisere“ Geräusche geringere Intervalle, da diese bei der Sprachkommunikation statistisch gesehen häufiger auftreten. Ein weiteres Kriterium, die Quantisierungsintervalle in diesem Bereich zu verkürzen, ist die Tatsache, dass die Empfindlichkeit des menschlichen Gehörs proportional zum Logarithmus der Lautstärke ist [3].

Demzufolge werden die Quantisierungsintervalle logarithmisch aufgeteilt. Kleine Amplitudenwerte werden also gröber quantisiert als große. Ein Kompander, dessen Funktionsweise durch eine sogenannte Kompandierungskennlinie beschrieben ist, führt diese logarithmische Verstärkung durch. Die Kompandierungskennlinie wird dabei in eine Anzahl von Segmenten unterteilt, wobei die Kennlinie in jedem Segment linear dargestellt wird.

Wie eingangs erwähnt, wird jeder Abtastwert mit acht Bits codiert. Diese Bits a0… a7haben bei der nichtlinearen Quantisierung nun folgende Bedeutung: Das erste Bit a0repräsentiert, ob der Amplitudenwert positiv oder negativ ist. Die nächsten drei Bits a1 bis a3kennzeichnen die Nummer des Segments der Kompandierungskennlinie und die letzten vier Bits a4bis a7stellen die Quantisierungsstufe innerhalb des Segments dar [3]. Endresultat sind insgesamt

256 Quantisierungsstufen, welche innerhalb des Segments linear und global betrachtet logarithmisch sind.

Grundsätzlich verwendet man zwei unterschiedliche Kennlinien, die untereinander nicht kompatibel sind. Die vorwiegend in Europa verwendete A-Kennlinie (A-Law), welche mit 13 Segmenten beschrieben wird und die in Amerika und Japan gebräuchliche µ-Kennlinie (µ- Law), welche eine Unterteilung in 15 Segmente vornimmt.

Die andere Möglichkeit, Sprache zu codieren, ist das Frame-Based- bzw. das Segment- orientierte Verfahren. Dieses Verfahren macht sich die Möglichkeit zunutze, dass der Vokaltrakt des Menschen, der die Sprache erzeugt, künstlich nachgebildet werden kann. Die statistische Eigenschaft der Sprache bleibt in entsprechend kleinen Zeitintervallen bis etwa 30 ms nahezu unverändert (stationär) und kann mittels weniger Parameter beschrieben werden [3]:

- Stimmhafter/stimmloser Laut als Parameter V/UV
- Pitch-Periode T (die Periode der Stimmbandvibration; dieser Wert entspricht dem Kehrwert der Sprachgrundfrequenz)
- Lautstärke G (Gain)
- Mehrere Parameter a1, …, aK, welche die Artikulation mithilfe eines linearen Filters beschreibt

Den Begriff „Sprachgrundfrequenz“ beschreibt ein Zitat aus [6] folgendermaßen:

Sprache wird durch Veränderung des von der Lunge kommenden Luftstroms erzeugt. Zunächst passiert der Luftstrom am Eingang der Luftröhre den Kehlkopf (medizinisch Larynx) mit den Stimmbändern. Stehen die Stimmbänder dicht beieinander, dann werden sie durch den Luftstrom zu periodischen Schwingungen angeregt. Es entsteht ein stimmhafter Laut. Die Frequenz der Schwingungen (Sprachgrundfrequenz, fundamental frequency) liegt im Mittel bei Männern um 100 Hz und bei Frauen um 180 Hz. Die Variation der Sprachgrundfrequenz ist zusammen mit Lautstärkeänderungen wesentlich für die Sprachmelodie einer Äußerung. Ist der Abstand zwischen den Stimmbändern groß, so kommt

es zu keinen Schwingungen sondern nur zu Turbulenzen. Dann spricht man von stimmlosen Lauten.

Mithilfe der Nachbildung der Sprachgrundfrequenz und den Formant-Frequenzen lässt sich Sprache auch künstlich erzeugen. Dieser Ansatz ist für Text-to-Speech-Systeme interessant. Unter Formanten versteht man jene Frequenzbereiche, die - je nach Anatomie des Rachenraums, Zungenstellung, Lippenrundung und ähnliche Parameter - bei einer Artikulierung eines Lauts verstärkt wiedergegeben werden. Diese Frequenzen liegen abhängig vom Laut in unterschiedlichen Bereichen.

Bei der Codierung wird nun ein Segment in der Größe von z. B. 20 ms herangezogen, die 160 Abtastwerte (bei einer Abtastfrequenz von 8 kHz) in einen Buffer abgelegt und anschließend analysiert. Das Endergebnis der Analyse ist ein Vektor, der die oben genannten Parameter enthält. Auf der Gegenseite wird aus diesem Vektor wieder eine menschliche Sprache synthetisiert.

Das Modell, das den Vokaltrakt künstlich nachbildet, wird als Linear Predictive Coding- Decoder (LPC-Vocoder) bezeichnet. Im Einsatz ist unter anderem ein LPC-Vocoder, dessen linearer Filter aus lediglich zehn Parametern besteht (daraus leitet sich der Name dieses Filters, LPC-10, ab), somit wird hier die Sprache aus insgesamt dreizehn Parametern (inklusive Lautstärke, Pitch-Periode und Lautart) beschrieben.

Der Vorteil dieses Verfahrens liegt auf der Hand: Beim Einsatz eines LPC-10-Filters benötigt man lediglich 48 Bits, in denen sämtliche Parameter untergebracht sind. Beim unkomprimierten PCM-Segment von 20 ms benötigt man jedoch 1280 Bits, das in einer beinahe 27-fachen Datenrate resultiert. Verschwiegen werden soll jedoch nicht die Tatsache, dass die Sprachqualität bei Anwendung eines solchen Algorithmus geringer ausfällt als bei einem abtastwert-orientierten Verfahren.

3.1 Sprachcodierungen in VoIP

Es gibt eine Vielzahl von Sprachcodecs, die in VoIP-Umgebungen Verwendung finden. Tabelle 1 (modifiziert übernommen aus [2]) listet einige davon auf und beschreibt, welches Sprachcodierungsverfahren für den jeweiligen Codec verwendet wird. Schon aus der Blockgröße der in der Tabelle enthaltenen Codecs lässt sich erkennen, dass es sich bei den ersten beiden um ein abtastwert-orientiertes Verfahren und bei den letzten beiden um ein Segment-orientiertes Verfahren handelt, das beim jeweiligen Codec angewendet wird. Der R- Faktor macht eine Aussage über die Qualität der Sprache. Er soll ein Verhältnis zwischen dem ursprünglichen analogen Signal und dem erzeugten digitalen Signal darstellen, d. h., bei einem Wert von 100 sind beide Signale ident. Je niedriger der R-Faktor ist, umso schlechter ist die Qualität des digitalen Signals.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Sprachcodecs

Letztendlich muss der Benutzer anhand der gewünschten Qualität und der zur Verfügung stehenden Bandbreite abwägen, welcher Codec am geeignetsten ist.

4 VoIP-relevante Protokolle

Die gesamte Kommunikation in Rechnernetzen verläuft nach bestimmten Protokollen. Werden zu sendende Daten von einer Anwendung des Rechners A generiert, durchlaufen diese Daten eine je nach betrachtetem Referenzmodell unterschiedliche Anzahl an Protokollschichten, überqueren anschließend ein physikalisches Medium (Kupferleitung, Glasfaser, Luft, …) und gelangen letztendlich nach dem Durchlauf der Protokollschichten in umgekehrter Reihenfolge zur Anwendung des Rechners B. Jede Protokollschicht ist für unterschiedliche Aufgaben zuständig und kann verschiedenste Protokolle beinhalten.

In Bezug auf die VoIP-Kommunikation werden mehrere Klassen der Protokolle benötigt. Unterschieden werden muss hier nach [3]:

- Protokolle für die Übermittlung der Sprache
- Signalisierungsprotokolle für den Auf- und Abbau von Verbindungen
- Protokolle für die Steuerung von VoIP-Gateways

Betrachtet aus der Sicht des vierschichtigen TCP/IP-Referenzmodells lassen sich nun folgende Protokolle erkennen, die für eine VoIP-Kommunikation bedeutsam sind.

Die unterste Schicht, der Network Interface Layer, kann unter anderem folgende Protokoll- Stacks beinhalten [2]:

- POTS/PPP
- ISDN/PPP
- ADSL/ATM+PPP
- SDH/ATM
- SDH/PPP
- 10BaseT/MAC
- 100BaseTX/MAC

Eine Schicht oberhalb, dem Internetwork Layer, kommt das IP-Protokoll in den Versionen 4 und 6 zum Tragen.

Jedes der bis jetzt genannten Protokolle kann von jeder Protokollklasse verwendet werden. Eine Unterscheidung erfolgt jedoch im Layer 3, dem Transport Layer. Das verbindungsorientierte TCP-Protokoll inkludiert unter anderem Fehlererkennungs- und Fehlerkorrekturmechanismen, falls Pakete verloren gehen. Dieser Vorteil wird aber mit einem größeren Overhead der Pakete, einer höheren Latenzzeit sowie einem höheren Jitter erkauft. Für die Übertragung von Sprachinformationen sind diese Nachteile untragbar, verloren gegangene Pakete wirken sich hingegen auf die Gesprächsqualität nicht so dramatisch aus. Aus diesem Grund wird für die Übermittlung der Sprache auf der Transportebene das verbindungslose UDP-Protokoll verwendet.

Signalisierungsprotokolle können sowohl auf TCP als auch auf UDP aufbauen. So verwenden die beiden Protokolle H.225.0 und H.245 aus der H.323-Protokollfamilie das

Transportprotokoll TCP, während SIP in der Regel UDP benutzt. Um die sichere Zustellung der Signalisierungsdaten trotz UDP als Transportprotokoll zu gewährleisten, verfügt das SIP- Protokoll eigene Mechanismen zur Fehlerkontrolle. Nichtsdestotrotz hat man bei SIP die Option, für den Versand von Signalisierungsdaten TCP zu verwenden.

Die Protokolle für die Steuerung von VoIP-Gateways (MGCP, Megaco) stützen sich wiederum auf UDP als Transportprotokoll.

Für die Übertragung von Audio- und Videodaten ist das RTP-Protokoll samt dem dazugehörigen Kontrollprotokoll RTCP zuständig. Eine eindeutige Zuordnung zu Layer 3 oder Layer 4 ist nicht möglich. Da es ein Protokoll für den Transport von Nachrichten ist, würde es einem Layer 3-Protokoll entsprechen. Andererseits nutzt es dabei (üblicherweise) UDP und ist außerdem eng mit der Applikation verknüpft, dass wiederum einem Layer 4- Protokoll entspricht. Korrekter wäre es, RTP in Schicht 3b und UPD in Schicht 3a einzuordnen [2]. Eine genauere Beschreibung des RTP-Protokolls erfolgt in Kapitel 4.1.

Eindeutig dem Application Layer zuzuordnen sind jedoch die Signalisierungsprotokolle, die für den Aufbau und Abbau einer Verbindung sowie für die Steuerung von VoIP-Gateways zuständig sind. Einige bekannte Signalisierungsprotokolle sind:

- H.323-SIG (bestehend aus den Unterprotokollen H.225.0 und H.245)
- SIP … Session Initiation Protocol
- IAX3
… Inter-Asterisk eXchange Protocol
- MGCP … Media Gateway Control Protocol
- Megaco … MEdia GAteway COntrol

Auf die drei erstgenannten Protokolle wird im Kapitel 4.2 näher eingegangen.

Jene Protokolle, die für die VoIP-Kommunikation von Bedeutung sind, sowie deren Platz im TCP/IP-Referenzmodell, werden in der Abb. 3 noch einmal zusammenfassend verdeutlicht.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Relevante Protokolle in Bezug auf die VoIP-Telefonie

Abbildung in dieser Leseprobe nicht enthalten

Neben diesen offenen Protokollen existieren auch noch proprietäre Ansätze wie z. B. das Skinny Client Control Protocol (SCCP) von Cisco oder UNISTIM von Nortel.

4.1 Protokolle für die Sprachdatenübertragung

Das Real-time Transport Protocol (RTP) wurde entwickelt, um Audio- und Videodaten in Echtzeit übertragen zu können. Es stellt ein verbindungsloses und ungesichertes, ein in der Regel4auf UDP aufbauendes Transportprotokoll dar, dessen aktuelle Spezifikation im RFC 3550 [7] beschrieben ist. RTP ist nicht für den Auf- oder Abbau einer Verbindung zuständig. Dafür sind Signalisierungsprotokolle wie z. B. SIP oder H.323-SIG verantwortlich (siehe

Kapitel

4.2). Eine nähere Beschreibung von RTP wird im folgenden Unterkapitel 4.1.1

vorgenommen.

Ebenfalls im RFC 3550 spezifiziert ist das Real-time Transport Control Protocol (RTCP), das als Kontrollprotokoll eine Überwachung der RTP-Echtzeitkommunikation und in weiterer Folge eine Sicherstellung der Übertragungsqualität als Aufgabe innehat. Mit welchen Mechanismen dies geschieht, wird in Kapitel 4.1.2 erläutert.

4.1.1 Das Real-time Transport Protocol (RTP)

4.1.1.1 Die Architektur

Ein RTP-System setzt sich aus folgenden Elementen zusammen:

- RTP-Sender
- RTP-Empfänger
- Sessions
- Translator (optional)
- Mixer (optional)
- Monitor (optional)

Die Aufgabe des Senders in Bezug auf VoIP besteht darin, die Sprachdaten zu erfassen, zu komprimieren und RTP-Pakete für den Weitertransport zu generieren. Diese Pakete enthalten sowohl die Nutzdaten als auch den RTP-Header. Dem RTP-Paket wird ein UDP- und IP- Header hinzugefügt, bevor es versandt wird (siehe Abb. 4).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: RTP-Nutzdaten im IP-Paket

Abbildung in dieser Leseprobe nicht enthalten

4 Ein neuerer Ansatz verwendet das Datagram Congestion Control Protocol (DCCP) anstelle von UDP als Basis für RTP. DCCP verbindet die Vorteile von UDP mit der zusätzlichen Möglichkeit einer Staukontrolle. Eine ausführliche Beschreibung und die Spezifikation von DCCP findet man im RFC 4340 [33].

Der Empfänger erhält die Pakete aus dem Netzwerk, führt im Bedarfsfall Fehlerkorrekturen durch, dekomprimiert die Sprachdaten und präsentiert das Ergebnis, also die Sprachinformation der Gegenseite, dem Benutzer.

Eine RTP-Session besteht aus einer Gruppe von Teilnehmern, die mittels RTP miteinander kommunizieren. Besteht die Gruppe aus zwei Teilnehmern, so handelt es sich um eine Unicast-Session, bei mehr als zwei Teilnehmern um eine Multicast-Session. Jeder Teilnehmer wird durch seine Netzwerkadresse und einem Port-Paar identifiziert. Ein Port-Paar besteht aus einer geradzahligen Portnummer für die RTP-Sprachdaten und der darauffolgenden, ungeraden Portnummer für die RTCP-Pakete.

Ein Translator befindet sich zwischen Sender und Empfänger. Er empfängt RTP-Pakete, konvertiert dessen Nutzdaten in ein anderes Format und sendet diese Pakete weiter. So wird in [3] etwa die Möglichkeit aufgeführt, ein bestimmtes Sprachformat in ein proprietäres (für außenstehende nutzloses) Format überzuführen, um so die Vertraulichkeit der Sprachkommunikation über ein öffentliches Netz zu garantieren. Auf der Gegenstelle wird wiederum ein Translator benötigt, der dieses Sprachformat rückwandelt. Das SSRC-Feld im RTP-Header (siehe Kapitel 4.1.1.2) wird beim Einsatz eines Translators nicht verändert.

Der Einsatz eines Mixers ist dann sinnvoll, wenn Kommunikationsströme von mehreren Quellen zusammengefasst und das Resultat weitergesendet werden soll. Im Gegensatz zum Translator fungiert ein Mixer als neue Quelle, dementsprechend wird auch das SSRC-Feld manipuliert.

Unter einem Monitor versteht man eine Applikation, welche RTCP-Pakete empfängt. Aus diesen kann er Rückschlüsse über den QoS-Status der momentanen Sprachverbindungen schließen, welche für Fehlerdiagnosen oder statistische Zwecke weiter verwendet werden können.

4.1.1.2 Der RTP-Header

Abb. 5 stellt die Struktur eines RTP-Headers dar. Im Anschluss daran folgt eine kurze Erläuterung der darin enthaltenen Felder.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: RTP-Header

- V (Version): Dieses 2 Bit große Feld stellt die RTP-Version dar.
- P (Padding): Ist dieses Flag gesetzt, dann enthält das RTP-Paket am Ende eine Menge von Füllbits, die nicht zur Nutzlast gehören.
- X (Extension): Wenn dieses Flag gesetzt ist, befindet sich im RTP-Header eine Header Extension.
- CC (CSRC Count): Dieses 4 Bit große Feld stellt die Anzahl der CSRC-Identifier dar, die sich im gleichnamigen Feld des Headers befinden.
- M (Marker): Die Bedeutung dieses Flags wird durch ein Profil definiert.
- PT (Payload Type): Hier wird mittels 7 Bits beschrieben, wie die Sprachdaten codiert wurden. Die verschiedenen Sprachcodierungsverfahren sind im RFC 3551 [8] beschrieben.
- Sequence Number: Dieses 16 Bit breite Feld wird bei jedem RTP-Paket inkrementiert, damit der Empfänger einerseits die Möglichkeit hat, den Verlust von Paketen festzustellen und andererseits die korrekte Reihenfolge einlangender Pakete wieder herzustellen. Die Sequence Number des ersten Pakets ist dabei eine zufällige Zahl, um Known-Plaintext-Angriffe zu erschweren.

- Timestamp: Das 32 Bit große Feld beinhaltet den Zeitpunkt, in dem das erste Byte des Payloads generiert wurde. In Kombination mit der Sequence Number kann das Timestamp-Feld dazu verwendet werden, um den Jitter abzuschätzen [3].

- SSRC (Synchronisation Source Identifier): Unterschiedliche Quellen müssen differente SSRC’s besitzen, damit der Empfänger feststellen kann, welches RTP-Paket welcher Quelle entstammt und die Pakete in weiterer Folge richtig zusammenfügen kann.

- CSRC (Contributing Source Identifiers): Werden mehrere Sprachdatenströme durch einen Mixer zusammengeführt, so beinhaltet das SSRC-Feld den Mixer als Quelle. Im CSRC-Feld werden daher beim Einsatz eines Mixers sämtliche Originalquellen in diesem Feld angeführt.

- Extension Header: Mit diesem optionalen Feld variabler Länge kann RTP erweitert werden und somit an neue Anwendungen angepasst werden [3].

Anzumerken ist an dieser Stelle, dass die Größe des Gesamtheaders (IP, UDP und RTP) mindestens 40 Bytes beträgt. Verwendet man für die Sprachcodierung besonders effiziente Verfahren, so übersteigt die Headergröße jene der Nutzlast. Durch die Tatsache, dass sich die meisten Felder dieser drei Header im Laufe der Kommunikation nur geringfügig ändern, ist eine Kompression bis auf 2 Bytes möglich [3].

4.1.2 Das Real-time Transport Control Protocol (RTCP)

Das das RTP ergänzende Protokoll RTCP dient hauptsächlich dazu, QoS-Informationen in periodischen Zeitabständen zwischen den an der Kommunikation partizipierenden Teilnehmer auszutauschen. Mithilfe der dadurch gewonnenen Informationen kann etwa der Sender die Sendedatenrate reduzieren, wenn die Netzqualität sinkt.

Ebenso ist es mit RTCP möglich, eine Senderquelle mittels eines kanonischen Namens (CNAME) eindeutig zu identifizieren. Diese Möglichkeit ist zwar grundsätzlich auch mit dem SSRC-Feld des RTP-Headers gegeben, jedoch wird dieses Feld dort bei Einsatz eines Mixers verändert.

Eine weitere Möglichkeit, die RTCP unterstützt, ist die Überwachung von Konferenzen mit mehreren Teilnehmern. Dadurch können die aktuellen Teilnehmer einer aktuell stattfindenden Konferenz erfasst und angezeigt werden [3].

Man unterscheidet bei RTCP folgende Pakete, die als Nachrichten versendet werden [7], wobei mehrerer dieser RTCP-Pakete in einem IP-Paket enthalten sein können:

- Sender Report (SR)
- Receiver Report (RR)
- Source Description (SDES)
- Abmeldung (BYE)
- Applikationsspezifische Pakete (APP)
Für VoIP finden nur die beiden erstgenannten Paketarten Verwendung [3], auf die nun im Folgenden kurz eingegangen wird.
Ein Sender Report RTCP-Paket besteht aus drei Abschnitten:
- Header
- Sender Info
- Einem oder mehreren Report Blocks

Optional kann der SR auch einen vierten Abschnitt beinhalten (Profile-specific extensions), in dem weitere anwendungsspezifische Felder definiert werden können. Die Struktur eines Sender Report RTCP-Pakets zeigt Abb. 6.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: Sender Report

Die Header-Sektion besteht teilweise aus Feldern, die schon aus dem RTP-Header bekannt sind und hier dieselbe Bedeutung haben. Konkret handelt es sich um das Versions-, das Padding- und das SSRC-Feld. Der Payload Type, hier 8 Bit breit, beschreibt die Art der RTCP-Nachricht. Im Falle eines Sender Reports lautet der Eintrag 0xC8. Das 5 Bit große Feld RC (Reception Report Count) informiert über die Anzahl der Report Blocks, die diese Nachricht enthält. Der Length-Eintrag gibt die Größe des gesamten RTCP-Pakets (inklusive Header) in 32-Bit-Blöcken wieder, bei null beginnend.

Der nächste Abschnitt - Sender Information - beinhaltet einen 64-Bit-NTP-Zeitstempel und einen 32-Bit-RTP-Zeitstempel. Letzterer ist vom Format her ident mit dem Zeitstempel des RTP-Headers. Der Wert beider Zeitstempel (jener des RTP-Headers und der 32-Bit-RTP- Zeitstempel des SR) ist jedoch ein unterschiedlicher, da RTP- und RTCP-Pakete zeitlich

versetzt versendet werden. Mithilfe des NTP-Zeitstempels des SR und dem korrespondierenden RR des Empfängers kann die Round Trip Delay berechnet werden.

Zwei weitere Felder in diesem Abschnitt sind das jeweils 32 Bit breite Sender’s Packet Count- und das Sender’s Octet Count-Feld. Ersteres Feld gibt die Anzahl der versendeten RTP-Pakete seit Beginn der Session an, das zweite Feld spiegelt wider, wie viele Bytes an Nutzdaten seit Sessionbeginn versendet wurden (exklusive Header und Padding).

[...]

---

¹ Diese Tatsache ist jedoch umstritten. In manchen Quellen wird behauptet, dass der Amerikaner Elisha Gray der Erfinder ist, wieder andere Quellen weisen diese Ehre dem US-Italiener Antonio Santi Guiseppe Meucci zu. Tatsächlich wurde in den USA im Jahr 2002 offiziell Meucci als Erfinder anerkannt.

² Legendäres Beispiel ist das „Blue Boxing“, bei dem in den späten 60er Jahren des 20. Jahrhunderts mittels Einspeisung eines 2,6 kHz-Tonsignals während der Signalisierungsphase danach kostenlose Telefonate durchgeführt werden konnten.

³ Das IAX-Protokoll wird nicht nur für die Signalisierung, sondern auch für die Übermittlung der Sprachdaten verwendet. Nähere Informationen dazu sind in Kapitel 4.2.3 nachzulesen.

⁴ Ein neuerer Ansatz verwendet das Datagram Congestion Control Protocol (DCCP) anstelle von UDP als Basis für RTP. DCCP verbindet die Vorteile von UDP mit der zusätzlichen Möglichkeit einer Staukontrolle. Eine ausführliche Beschreibung und die Spezifikation von DCCP findet man im RFC 4340 [33].

⁵ Das Betriebssystem dieses Clients ist Windows Vista „Home Edition“. QoS-Einstellungen sind nur in den teureren Versionen möglich. Wieder einmal zeigen sich die Vorzüge des freien Betriebssystems GNU/Linux.

⁶ Die Callthrough-Funktion wird in älteren Firmware-Versionen der Fritz!Box nicht unterstützt, sodass ein Update erforderlich sein kann. Die aktuelle Firmware-Version 54.04.81 ermöglicht diese Funktionalität.