RTP – Real-Time Transport Protocol

Abkürzung: RTP

RTP überträgt den eigentlichen Sprach- oder Videostrom. Es läuft über UDP und verzichtet bewusst auf Wiederholungen von fehlenden oder fehlerhaften Daten.

Definition RTP

Das Real-Time Transport Protocol ist in RFC 3550 festgelegt und dient der Übertragung zeitkritischer Medien. Bei der IP-Telefonie ist es der Kanal, über den die Sprache tatsächlich fließt, nachdem SIP das Gespräch aufgebaut hat.

RTP arbeitet über UDP. Das ist eine bewusste Entscheidung. Ein verlorenes Sprachpaket später nachzuliefern bringt nichts, weil der Moment vorbei ist. Eine Wiederholung würde die Übertragung nur weiter verzögern.

Folgerichtig garantiert RTP weder Zustellung noch Reihenfolge. Es liefert dem Empfänger lediglich die Mittel, beides zu erkennen: eine fortlaufende Nummer je Paket und einen Zeitstempel.

Was im Paket steht

Der Header ist klein, üblicherweise zwölf Byte. Wesentlich sind vier Angaben.

• Nutzlasttyp. Welcher Codec verwendet wird. Die Zuordnung stammt aus der Aushandlung per SDP.
• Folgenummer. Steigt mit jedem Paket um eins. Daran erkennt der Empfänger Verluste und vertauschte Reihenfolge.
• Zeitstempel. Gibt an, zu welchem Zeitpunkt die enthaltene Sprache gehört. Grundlage für die Wiedergabe im richtigen Takt.
• Quellkennung. Identifiziert den Sender innerhalb der Sitzung.

Ports und Bandbreite

RTP nutzt keinen festen Port. Die Ports werden je Gespräch ausgehandelt und in der Beschreibung per SDP mitgeteilt, üblicherweise aus einem hohen Bereich. Für die Steuerung wird der jeweils nächsthöhere Port verwendet.

Dass die Ports wechseln, ist der Grund, warum sich RTP durch feste Portfreigaben nicht sinnvoll durchreichen lässt.

Zur Bandbreite ein Rechenbeispiel mit G.711, dem in Deutschland üblichen Codec. Bei 20 Millisekunden Sprache je Paket ergeben sich 50 Pakete je Sekunde mit je 160 Byte Nutzlast. Dazu kommen zwölf Byte RTP, acht Byte UDP und zwanzig Byte IP. Das sind 200 Byte je Paket und damit rund 80 kbit/s je Richtung, auf Ethernet-Ebene etwa 87 kbit/s.

Der Kopfanteil beträgt also ein Ffünftel. Bei stärker komprimierenden Codecs verschiebt sich das Verhältnis deutlich zuungunsten der Nutzlast, weil der Kopf gleich groß bleibt.

Was die Qualität bestimmt

Paketverlust. Bis etwa ein Prozent bleibt es unauffällig, weil Endgeräte fehlende Abschnitte rechnerisch überbrücken. Darüber wird es hörbar, zunächst als metallischer Klang, dann als Aussetzer.

Laufzeitschwankung. Pakete kommen in ungleichmäßigen Abständen an. Der Jitterpuffer im Endgerät sammelt sie und gibt sie gleichmäßig aus. Er kostet dabei Verzögerung, weshalb er nicht beliebig groß gewählt werden kann.

Verzögerung. Bis etwa 150 Millisekunden in eine Richtung wird ein Gespräch als natürlich empfunden. Darüber beginnen sich die Sprecher ins Wort zu fallen.

Diese drei Größen hängen zusammen. Ein großer Puffer gleicht Schwankungen aus, erhöht aber die Verzögerung. Endgeräte passen ihn deshalb während des Gesprächs an.

Steuerkanal

Parallel läuft ein Steuerprotokoll, das Berichte über die Qualität austauscht: Zahl der verlorenen Pakete, gemessene Schwankung, Laufzeit. Es überträgt keine Nutzdaten.

Diese Berichte sind die Grundlage der Qualitätsanzeigen in Telefonanlagen. Wer eine Störung eingrenzen will, findet dort belastbarere Werte als im Eindruck der Beteiligten.

RTP und NAT

Der Sprachstrom geht an die Adresse, die per SDP mitgeteilt wurde. Ist das eine private Adresse, kommt er nicht an.

Die verbreitete Lösung besteht darin, an die Adresse zu senden, von der die Pakete tatsächlich kommen, statt an die angekündigte. Das Verfahren heißt symmetrisches RTP und setzt voraus, dass eine Seite zuerst sendet, damit im Router ein Eintrag entsteht.

Daraus erklärt sich, warum Einweg-Audio häufiger auftritt als vollständige Stille. Die Seite hinter NAT sendet, ihre Pakete kommen an, und der Router lässt die Antwort durch. Umgekehrt fehlt der Eintrag.

Abgrenzung

SIP baut das Gespräch auf, SDP beschreibt den Kanal, RTP überträgt ihn. Alle drei können unabhängig voneinander scheitern.

SRTP ist die verschlüsselte Variante nach RFC 3711. Verschlüsselte Signalisierung allein schützt die Sprache nicht.

Für Fax ist RTP ungeeignet, weil verlustbehaftete Codecs die Signale zerstören. Dafür gibt es ein eigenes Verfahren nach T.38.

Quellen

• RFC 3550: RTP, A Transport Protocol for Real-Time Applications
• RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control
• RFC 3711: The Secure Real-time Transport Protocol (SRTP)
• RFC 4961: Symmetric RTP / RTP Control Protocol
• ITU-T G.114: One-way transmission time