RTP (Real-time Transport Protocol, RFC 3550) trägt die eigentliche Sprache oder das Video, nachdem SIP die Sitzung ausgehandelt hat, und läuft über UDP mit einem kompakten Header (Sequenznummer, Timestamp, SSRC). RTCP berichtet daneben die Qualität. SRTP (RFC 3711) ergänzt RTP um Verschlüsselung und Authentifizierung, mit Schlüsselaustausch über SDES im SDP oder DTLS-SRTP.
RTP: die Medien tragen
Sobald SIP und SDP die Sitzung vereinbart haben, fließen die Medien selbst über RTP — fast immer über UDP, weil Echtzeit-Audio rechtzeitige Zustellung der garantierten vorzieht. Jedes RTP-Paket trägt hinter einem 12-Byte-Header ein Stück codiertes Audio (einen Codec-Frame wie 20 ms G.711). RTP ist ein von der SIP-Signalisierung separater Strom auf den vom SDP ausgehandelten Ports und fließt typischerweise direkt zwischen den Endpunkten oder über ein Media-Relay, statt dem Signalisierungspfad zu folgen.
Der RTP-Header
Der 12-Byte-RTP-Header gibt dem Empfänger alles, was er zum Rekonstruieren eines Echtzeitstroms braucht. Die Sequenznummer erkennt Verlust und Umsortierung. Der Timestamp spiegelt den Abtastzeitpunkt, sodass der Empfänger Audio im richtigen Takt wiedergeben und Jitter mit einem Jitter-Buffer entfernen kann. Die SSRC identifiziert die Medienquelle innerhalb der Sitzung eindeutig. Der Payload-Type spiegelt den im SDP vereinbarten Codec. Das Marker-Bit kennzeichnet Ereignisse wie das erste Paket nach einer Stille-Phase.
| Feld | Größe | Zweck |
|---|---|---|
| V / P / X / CC | 1 Byte | Versions-, Padding-, Erweiterungs- und CSRC-Zählflags |
| M (Marker) + PT | 1 Byte | Marker-Bit + Payload-Typ (Codec aus SDP) |
| Sequenznummer | 2 Bytes | Paketverlust und -neuanordnung erkennen |
| Zeitstempel | 4 Bytes | Abtastzeitpunkt; steuert Playout / Jitter-Buffer |
| SSRC | 4 Bytes | Synchronisationsquelle – identifiziert den Datenstrom |
| CSRC (0–15) | 0–60 Bytes | Zugehörige Quellen (von Mixern) |
RTCP: Qualitäts-Feedback
RTP reist mit einem begleitenden Steuerprotokoll, RTCP, auf dem benachbarten (ungeraden) Port. RTCP trägt keine Medien; stattdessen sendet jede Seite periodisch Sender Reports und Receiver Reports, die die Gesundheit des Stroms beschreiben — gesendete und verlorene Pakete, kumulierter Verlust, Interarrival-Jitter und die aus Report-Timestamps abgeleitete Umlaufzeit. Diese Metriken sind das Rohmaterial für MOS-Schätzungen und für die Diagnose von Einwegaudio, Jitter und Verlust bei einem VoIP-Anruf. RTCP trägt zudem Source Description (CNAME) und BYE zum Strom-Abbau.
| Metrik | Was es Ihnen sagt |
|---|---|
| Paketverlust (Anteil + kumulativ) | Wie viel Audio geht verloren |
| Interarrival-Jitter | Abweichungen im Paket-Timing – Wiedergabeschwierigkeiten |
| Round-Trip-Zeit | Pfadlatenz (aus SR/RR-Zeitstempeln) |
| Höchste empfangene Sequenz | Fortschritts- und Verlusterkennung pro Quelle |
SRTP: die Medien verschlüsseln
Reines RTP ist unverschlüsselt, sodass jeder auf dem Pfad das Audio aufzeichnen und wiedergeben kann. SRTP (RFC 3711) sichert es: Es verschlüsselt die RTP-Nutzlast (standardmäßig AES im Counter-Modus) und hängt einen Authentifizierungs-Tag an (standardmäßig HMAC-SHA1), der die Integrität schützt und Replay-Schutz bietet, während der RTP-Header lesbar bleibt, sodass Router und Jitter-Buffer weiter funktionieren. Der Transport erscheint im SDP als RTP/SAVP statt RTP/AVP. SRTP schützt Vertraulichkeit und Integrität, hängt aber vollständig davon ab, wie seine Schlüssel ausgetauscht werden.
SRTP-Keying: SDES vs. DTLS-SRTP
SRTP benötigt an jedem Ende einen Master Key, und die zwei gängigen Wege, ihn zu übermitteln, unterscheiden sich in der Sicherheit stark. SDES (RFC 4568) legt den Schlüssel in eine a=crypto-Zeile im SDP — einfach, aber nur so sicher wie die SIP-Signalisierung, daher muss diese über TLS getragen werden, sonst ist der Schlüssel offengelegt. DTLS-SRTP (RFC 5763/5764) führt stattdessen einen DTLS-Handshake im Medienpfad durch, um Schlüssel abzuleiten, sodass der Schlüssel nie in der Signalisierung erscheint; es ist das Modell, das WebRTC vorschreibt. Wählen Sie DTLS-SRTP, wo Endpunkte es unterstützen, und schützen Sie SDES stets mit SIP über TLS.
| Methode | RFC | Wo der Schlüssel liegt | Hinweis |
|---|---|---|---|
| SDES | RFC 4568 | a=crypto Zeile im SDP | Erfordert SIP über TLS, um sicher zu sein |
| DTLS-SRTP | RFC 5763/5764 | Abgeleitet durch einen DTLS-Handshake im Medienpfad | Schlüssel nie in der Signalisierung; von WebRTC verwendet |
| MIKEY | RFC 3830 | Schlüsselverwaltungsnutzlast | Wird in einigen IMS-Implementierungen verwendet |
Häufig gestellte Fragen
Was ist der Unterschied zwischen SIP und RTP?
SIP ist die Signalisierung, die einen Anruf aufbaut, ändert und beendet; RTP ist der Medientransport, der die eigentliche Sprache oder das Video trägt, sobald der Anruf aufgebaut ist. Sie laufen als separate Ströme auf separaten Ports — SIP handelt die Sitzung aus, RTP stellt sie zu.
Warum läuft RTP über UDP statt TCP?
Echtzeit-Audio schätzt Rechtzeitigkeit über Zuverlässigkeit. Die Neuübertragung und das Head-of-Line-Blocking von TCP würden Latenz und Jitter hinzufügen, die einem Live-Anruf mehr schaden als ein gelegentlich verlorenes Paket. RTP über UDP lässt den Empfänger kleine Verluste kaschieren und den Strom im Takt halten.
Was macht RTCP?
RTCP ist der begleitende Steuerkanal von RTP. Es trägt keine Medien; es berichtet periodisch die Stromqualität — Paketverlust, Jitter und Umlaufzeit über Sender und Receiver Reports —, was zur Schätzung der Anrufqualität (MOS) und zur Diagnose von Problemen wie Einwegaudio genutzt wird.
Was ist SRTP?
SRTP (RFC 3711) ist das sichere Profil von RTP. Es verschlüsselt die Mediennutzlast (typischerweise AES im Counter-Modus) und authentifiziert jedes Paket (typischerweise HMAC-SHA1) mit Replay-Schutz, während der RTP-Header im Klartext bleibt. Im SDP erscheint es als RTP/SAVP-Transport.
Was ist der Unterschied zwischen SDES und DTLS-SRTP?
Beide keyen SRTP. SDES trägt den Schlüssel in einer a=crypto-SDP-Zeile, ist also nur sicher, wenn die SIP-Signalisierung selbst mit TLS geschützt ist. DTLS-SRTP leitet Schlüssel über einen DTLS-Handshake im Medienpfad ab, sodass der Schlüssel die Signalisierung nie berührt — der Ansatz, den WebRTC verlangt.
Quellenspezifikationen
Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)