RTP: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(Der Seiteninhalt wurde durch einen anderen Text ersetzt: „*RTP Grundlagen“)
Markierung: Ersetzt
Zeile 1: Zeile 1:
−
=Was ist RTP?=
+
*[[RTP Grundlagen]]
−
*Das Real-time Transport Protocol (RTP) ist ein Protokoll, das für die Übertragung von Echtzeitdaten, wie zum Beispiel Sprach- oder Videostreams, über IP-Netzwerke entwickelt wurde.
 
−
*UDP selbst hat keine Funktionen zum Erkennen von Paketverlusten
 
−
*Es bietet Mechanismen zur Verpackung und Übertragung von Mediendaten in Form von Paketen.
 
−
=RTP - Realtime Transport Protocol=
 
−
*RTP (Realtime Transport Protocol) ähnelt TCP und UDP und ist ebenfalls ein Transportprotokoll
 
−
*Entwickelt von der IETF (Internet Engineering Task Force)
 
−
*Sorgt für den kontinuierlichen Datenfluss in Echtzeit, hauptsächlich für Audio- und Video-Daten
 
−
*Je nach Codec sind 1 bis 20% Paketverlust tolerierbar
 
−
*RTP gewährleistet jedoch nicht die Qualität der Übertragung (Quality of Service - QoS)
 
−
 
 
−
=UDP und RTP=
 
−
*RTP hingegen, aufgebaut auf UDP, ermöglicht dem Empfänger zumindest das Erkennen von Paketverlusten
 
−
*Im Kontext von RTP sind Paketverluste bis zu einem bestimmten Grad akzeptabel
 
−
=Zweck=
 
−
Das Real-time Transport Protocol (RTP) wird für die Übertragung von Echtzeitdaten wie Audio- und Videostreams verwendet. Hier ist eine Zusammenfassung des Aufbaus von RTP:
 
−
=Umsetzung=
 
−
*Der RTP-Header und der RTP-Payload werden in IP-Paketen verpackt und über das Internet Protocol (IP) transportiert.
 
−
*RTP ist selbst kein zuverlässiges Protokoll ist.
 
−
*Es stellt keine Mechanismen zur Fehlererkennung oder Fehlerkorrektur bereit.
 
−
*Für eine zuverlässigere Übertragung müssen zusätzliche implementiert werden.
 
−
*Maßnahmen wie z. B. das User Datagram Protocol (UDP) in Kombination mit Fehlerkorrekturverfahren wie Forward Error Correction (FEC) oder das Real-time Transport Control Protocol (RTCP) implementiert werden.
 
−
=RTP-Header=
 
−
*Der RTP-Header ist der erste Teil eines RTP-Pakets und enthält wichtige Informationen zur Steuerung und Verarbeitung des Datenstroms.
 
−
 
 
−
=TCP im Vergleich zu RTP=
 
−
*Im Gegensatz zu TCP, wo jedes verlorene Paket erneut gesendet werden muss, handhabt RTP Paketverluste flexibler
 
−
 
 
−
== RTP-Header ==
 
−
{| class="wikitable"
 
−
|- class="hintergrundfarbe5" style="text-align:left;"
 
−
| colspan="8" | Byte 0
 
−
| colspan="8" | Byte 1
 
−
| colspan="8" | Byte 2
 
−
| colspan="8" | Byte 3
 
−
|- style="background:#E8E8E8"
 
−
| Bit 0
 
−
| 1
 
−
| 2
 
−
| 3
 
−
| 4
 
−
| 5
 
−
| 6
 
−
| 7
 
−
| Bit 0
 
−
| 1
 
−
| 2
 
−
| 3
 
−
| 4
 
−
| 5
 
−
| 6
 
−
| 7
 
−
| Bit 0
 
−
| 1
 
−
| 2
 
−
| 3
 
−
| 4
 
−
| 5
 
−
| 6
 
−
| 7
 
−
| Bit 0
 
−
| 1
 
−
| 2
 
−
| 3
 
−
| 4
 
−
| 5
 
−
| 6
 
−
| 7
 
−
|- style="text-align:center;"
 
−
| colspan="2" | V=2
 
−
| colspan="1" | P
 
−
| colspan="1" | X
 
−
| colspan="4" | CC
 
−
| colspan="1" | M
 
−
| colspan="7" | PT
 
−
| colspan="16" | Sequence Number
 
−
|-
 
−
| colspan="32" style="text-align:center;" | Timestamp (in sample rate units)
 
−
|-
 
−
| colspan="32" style="text-align:center;" | Synchronization Source (SSRC) identifier
 
−
|-
 
−
| colspan="32" style="text-align:center;" |Contributing Source (CSRC) identifiers (optional)
 
−
|-
 
−
| colspan="32" style="text-align:center;" |Header Extension (optional)
 
−
|}
 
−
 
 
−
; Version (V), 2 bit: Versionsstand des RTP-Protokolls
 
−
; Padding (P), 1 bit: Das Füll-Bit ist gesetzt, wenn ein oder mehrere Füll-Bytes am Ende des Pakets angehängt sind, die nicht zum eigentlichen Dateninhalt (Payload) gehören. Das letzte Füll-Byte gibt die Anzahl der hinzugefügten Füll-Byte an. Füll-Byte werden nur dann benötigt, wenn nachfolgende Protokolle eine vorgegebene Blockgröße benötigen, z. B. Verschlüsselungsalgorithmen.
 
−
; Extension (X), 1 bit: Das Erweiterungs-Bit ist gesetzt, wenn der Header um genau einen Erweiterungs-Header ergänzt wird.
 
−
; CSRC Count (CC), 4 bit: Der CSRC-Zähler gibt die Anzahl der CSRC-Identifier an.
 
−
; Marker (M), 1 bit: Das Marker-Bit ist für anwendungsspezifische Verwendungen reserviert. Es wird genutzt zur Kennzeichnung von Ereignissen, z. B. dem Auftreten des Endes eines Einzelbildes einer Videosequenz.
 
−
; Payload Type (PT), 7 bit: Dieses Feld beschreibt das Format des zu transportierenden RTP-Inhalts, also der [[Nutzdaten]] (Payload).
 
−
{| class="wikitable" style="text-align:center"
 
−
|- class="hintergrundfarbe5"
 
−
| Payloadnr.
 
−
| Codec
 
−
| Audio/Video
 
−
| Abtastrate
 
−
| Audiokanäle
 
−
| RFC
 
−
|-
 
−
| 0
 
−
| µ-law
 
−
| A
 
−
| 8 kHz
 
−
| 1
 
−
| [RFC3551]
 
−
|-
 
−
| 3
 
−
| GSM
 
−
| A
 
−
| 8 kHz
 
−
| 1
 
−
| [RFC3551]
 
−
|-
 
−
| 4
 
−
| G723
 
−
| A
 
−
| 8 kHz
 
−
| 1
 
−
| [RFC3551]
 
−
|-
 
−
| 5
 
−
| DVI4
 
−
| A
 
−
| 8 kHz
 
−
| 1
 
−
| [RFC3551]
 
−
|-
 
−
| 6
 
−
| DVI4
 
−
| A
 
−
| 16 kHz
 
−
| 1
 
−
| [RFC3551]
 
−
|-
 
−
| 7
 
−
| Linear Predictive Coding
 
−
| A
 
−
| 8 kHz
 
−
| 1
 
−
| [RFC3551]
 
−
|-
 
−
| 8
 
−
| A-law
 
−
| A
 
−
| 8 kHz
 
−
| 1
 
−
| [RFC3551]
 
−
|-
 
−
| 9
 
−
| G.722
 
−
| A
 
−
| 8 kHz
 
−
| 1
 
−
| [RFC3551]
 
−
|-
 
−
| 10
 
−
| L16
 
−
| A
 
−
| 44,1 kHz
 
−
| 2
 
−
| [RFC3551]
 
−
|-
 
−
| 11
 
−
| L16
 
−
| A
 
−
| 44,1 kHz
 
−
| 1
 
−
| [RFC3551]
 
−
|-
 
−
| 12
 
−
| QCELP
 
−
| A
 
−
| 8 kHz
 
−
| 1
 
−
| [RFC3551]
 
−
|-
 
−
| 13
 
−
| CN
 
−
| A
 
−
| 8 kHz
 
−
| 1
 
−
| [RFC3389]
 
−
|-
 
−
| 14
 
−
| MPA
 
−
| A
 
−
| 90 kHz
 
−
| 1
 
−
| [RFC3551, RFC2250]
 
−
|-
 
−
| 15
 
−
| G.728
 
−
| A
 
−
| 8 kHz
 
−
| 1
 
−
| [RFC3551]
 
−
|-
 
−
| 16
 
−
| DVI4
 
−
| A
 
−
| 11,025 kHz
 
−
| 1
 
−
|
 
−
|-
 
−
| 17
 
−
| DVI4
 
−
| A
 
−
| 22,05 kHz
 
−
| 1
 
−
|
 
−
|-
 
−
| 18
 
−
| G.729
 
−
| A
 
−
| 8 kHz
 
−
| 1
 
−
| [RFC3551]
 
−
|-
 
−
| 25
 
−
| CelB
 
−
| V
 
−
| 90 kHz
 
−
|
 
−
| [RFC3551, RFC2029]
 
−
|-
 
−
| 26
 
−
| JPEG
 
−
| V
 
−
| 90 kHz
 
−
|
 
−
| [RFC3551, RFC2435]
 
−
|-
 
−
| 28
 
−
| nv
 
−
| V
 
−
| 90 kHz
 
−
|
 
−
| [RFC3551]
 
−
|-
 
−
| 31
 
−
| H.261
 
−
| V
 
−
| 90 kHz
 
−
|
 
−
| [RFC3551, RFC2032]
 
−
|-
 
−
| 32
 
−
| MPV
 
−
| V
 
−
| 90 kHz
 
−
|
 
−
| [RFC3551,2250]
 
−
|-
 
−
| 33
 
−
| MP2T
 
−
| AV
 
−
| 90 kHz
 
−
|
 
−
| [RFC3551,2250]
 
−
|-
 
−
| 34
 
−
| H.263
 
−
| V
 
−
| 90 kHz
 
−
|
 
−
| [RFC3551,2250]
 
−
|-
 
−
| 96-127
 
−
| dynamisch
 
−
|
 
−
|
 
−
|
 
−
| [RFC3551]
 
−
|}
 
−
 
 
−
; Sequence Number, 16 bit: Die Sequenznummer wird für jedes weitere RTP-Datenpaket erhöht. Die Startnummer wird zufällig ausgewählt und ist nicht vorherbestimmbar. Der Empfänger kann mit Hilfe der Sequenznummer die Paketreihenfolge wiederherstellen und den Verlust von Paketen erkennen.
 
−
; Timestamp, 32 bit: Der Zeitstempel gibt den Zeitpunkt des ersten Bytes des RTP-Datenpakets an. Der Zeitpunkt muss sich an einem Takt orientieren, der kontinuierlich und linear ist, damit die Synchronität des Streams sichergestellt und Laufzeitunterschiede der Übertragungsstrecke (Jitter) ermittelt werden können. Der Startwert sollte wie die Sequenznummer ein zufälliger Wert sein. Aufeinanderfolgende Pakete können den gleichen Zeitstempel haben, wenn die transportierten Daten z. B. zum selben Einzelbild ("video frame") gehören. Pakete mit aufeinanderfolgenden Sequenznummern können aber auch nicht aufeinanderfolgende Zeitstempel enthalten, wenn wie z. B. bei [[Group of Pictures|komprimiertem Video]] Übertragungs- und Wiedergabereihenfolge nicht übereinstimmen.
 
−
; SSRC, 32 bit: Dieses Feld dient zur Identifikation der Synchronisationsquelle. Der Wert wird zufällig ermittelt, damit nicht zwei Quellen innerhalb der RTP-Session die gleiche Identifikationsnummer besitzen.
 
−
; CSRC List, 0 bis 15 Felder je 32 bit: Die CSRC-Liste dient zur Identifikation der Quellen, die in den RTP-Nutzdaten enthalten sind. Die Anzahl der Listenfelder wird im CC-Feld angegeben. Falls mehr als 15 Quellen vorkommen, werden nur 15 identifiziert. Die Liste wird von Mixern eingefügt, die dazu den Inhalt des SSRC-Feldes der beteiligten Quellen einsetzen.
 
−
 
 
−
=Hier sind einige wichtige Merkmale und Funktionen des RTP-Protokolls=
 
−
==Paketisierung==
 
−
*RTP zerlegt die Audiodatenströme in kleine Pakete. Jedes Paket enthält eine Sequenznummer, Zeitstempel und eine Payload mit den eigentlichen Mediendaten.
 
−
*Die Paketisierung ermöglicht eine effiziente Übertragung und Verarbeitung der Mediendaten.
 
−
==Sequenznummer==
 
−
*Jedes RTP-Paket enthält eine Sequenznummer, die die Reihenfolge der Pakete im Strom angibt.
 
−
*Dies ermöglicht die korrekte Rekonstruktion des Audiosignals beim Empfänger und hilft bei der Behandlung von Paketverlusten oder -reihenfolgeproblemen.
 
−
==Zeitstempel==
 
−
*RTP enthält einen Zeitstempel, der die zeitliche Position der Mediendaten im Verhältnis zum Anfang des Datenstroms angibt.
 
−
*Der Zeitstempel ermöglicht die Synchronisation der Wiedergabe bei Empfängerseite, um ein verzögerungsfreies und konsistentes Audioerlebnis sicherzustellen.
 
−
==Payload-Typ==
 
−
*RTP ermöglicht die Verwendung verschiedener Payload-Typen, um verschiedene Arten von Mediendaten zu kennzeichnen.
 
−
*Je nach Anwendung können verschiedene Codecs oder Medienformate verwendet werden, und der Payload-Typ identifiziert den verwendeten Codec und dessen Parameter.
 
−
==Verzögerungskompensation==
 
−
*RTP kann verwendet werden, um die Verzögerung zwischen Sender und Empfänger zu messen und zu kompensieren.
 
−
*Dies ist wichtig, um die Echtzeitübertragung von Sprache oder anderen Echtzeitdaten zu gewährleisten, bei der Verzögerungen zu Beeinträchtigungen der Kommunikation führen können.
 
−
=Abschliessend=
 
−
*RTP hat selbst keine Fehlerkorrektur- oder Flusskontrollmechanismen.
 
−
*Diese Aufgaben werden in der Regel vom RTCP (RTP Control Protocol) übernommen, das zusammen mit RTP verwendet wird.
 
−
*RTCP ermöglicht die Überwachung und Kontrolle des RTP-Datenstroms, einschließlich Statistiken, Qualitätssicherung und Feedback-Mechanismen.
 

Version vom 27. Juni 2023, 15:55 Uhr

Abgerufen von „http://wiki.ixheim.de/index.php?title=RTP&oldid=47334“