6. Format von RTCP-Feedback-Nachrichten (Format of RTCP Feedback Messages)

Dieser Abschnitt definiert das Format der RTCP-Feedback-Nachrichten mit geringer Verzögerung. Diese Nachrichten werden wie folgt in drei Kategorien eingeteilt:

• Feedback-Nachrichten auf Transportschicht
• Payload-spezifische Feedback-Nachrichten
• Feedback-Nachrichten auf Anwendungsschicht

Feedback-Nachrichten auf Transportschicht dienen der Übertragung allgemeinen Feedbacks, d. h. von Informationen, die unabhängig vom jeweiligen Codec oder der Anwendung sind. Die Informationen werden voraussichtlich auf der Transport-/RTP-Schicht erzeugt und verarbeitet. Derzeit ist nur eine generische negative Bestätigung (NACK) definiert.

Payload-spezifische Feedback-Nachrichten transportieren Informationen, die einem bestimmten Payload-Typ eigen sind, und werden auf der Codec-„Schicht“ erzeugt und verarbeitet. Dieses Dokument definiert einen gemeinsamen Header für alle payload-spezifischen Feedback-Nachrichten. Die Definition spezifischer Nachrichten bleibt RTP-Payload-Format-Spezifikationen oder zusätzlichen Feedback-Format-Dokumenten überlassen.

Feedback-Nachrichten auf Anwendungsschicht ermöglichen die transparente Übermittlung von Feedback von der Anwendung des Empfängers zur Anwendung des Senders. Der Inhalt solcher Nachrichten wird voraussichtlich nicht auf der Transport-/RTP- oder der Codec-Schicht verarbeitet. Die zwischen zwei Anwendungsinstanzen auszutauschenden Daten sind üblicherweise in der Anwendungsprotokoll-Spezifikation definiert und können von der Anwendung identifiziert werden, sodass kein zusätzlicher externer Informationsbedarf besteht. Daher definiert dieses Dokument nur einen gemeinsamen Header für alle Feedback-Nachrichten auf Anwendungsschicht. Aus Protokollsicht wird eine Feedback-Nachricht auf Anwendungsschicht als Sonderfall einer payload-spezifischen Nachricht behandelt.

Hinweis: Eine ordnungsgemäße Verarbeitung einiger FB-Nachrichten auf der Medien-Senderseite kann erfordern, dass der Sender weiß, auf welchen Payload-Typ sich die FB-Nachricht bezieht. Meist lässt sich dies wahrscheinlich aus einem Medienstrom mit nur einem Payload-Typ ableiten. Werden jedoch mehrere Codecs gleichzeitig verwendet (z. B. Audio und DTMF) oder treten Codec-Wechsel auf, kann Payload-Typ-Information explizit als Teil der FB-Nachricht vermittelt werden müssen. Dies gilt für alle payload-spezifischen sowie für Feedback-Nachrichten auf Anwendungsschicht. Es obliegt der Spezifikation einer FB-Nachricht festzulegen, wie Payload-Typ-Information übertragen wird.

Dieses Dokument definiert zwei Feedback-Nachrichten auf Transportschicht und drei (Video-)payload-spezifische FB-Nachrichten sowie einen einzelnen Container für Feedback-Nachrichten auf Anwendungsschicht. Weitere Feedback-Nachrichten auf Transportschicht und payload-spezifische FB-Nachrichten MAY in anderen Dokumenten definiert werden und MUST über IANA registriert werden (siehe Abschnitt 9, „IANA Considerations“).

Die allgemeine Syntax und Semantik der obigen RTCP-FB-Nachrichtentypen werden in den folgenden Unterabschnitten beschrieben.

6.1. Gemeinsames Paketformat für Feedback-Nachrichten

Alle FB-Nachrichten MUST ein gemeinsames Paketformat verwenden, wie in Abbildung 3 dargestellt:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|   FMT   |       PT      |          length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  SSRC of packet sender                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  SSRC of media source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Feedback Control Information (FCI)                 |
|                                                               |

        Figure 3: Common Packet Format for Feedback Messages

Die Felder V, P, SSRC und length sind in der RTP-Spezifikation [1] definiert; ihre Bedeutung ist unten zusammengefasst:

version (V): 2 bits
Dieses Feld identifiziert die RTP-Version. Die aktuelle Version ist 2.

padding (P): 1 bit
Ist das Padding-Bit gesetzt, enthält das Paket am Ende zusätzliche Padding-Oktetts, die nicht zur Steuerinformation gehören, aber im Längenfeld mitgezählt werden.

Feedback message type (FMT): 5 bits
Dieses Feld identifiziert den Typ der FB-Nachricht und wird relativ zum Typ (Transportschicht, payload-spezifisch oder Anwendungsschicht-Feedback) interpretiert. Die Werte für jeden der drei Feedback-Typen sind in den jeweiligen Abschnitten unten definiert.

Payload type (PT): 8 bits
Dies ist der RTCP-Pakettyp, der das Paket als RTCP-FB-Nachricht kennzeichnet. Zwei Werte sind von der IANA definiert:

Name	Value	Brief Description
RTPFB	205	Transport layer FB message
PSFB	206	Payload-specific FB message

Length: 16 bits
Die Länge dieses Pakets in 32-Bit-Wörtern minus eins, einschließlich Header und Padding. Entspricht der Definition des Längenfelds in RTCP-Sender- und Empfängerberichten [1].

SSRC of packet sender: 32 bits
Die Synchronisationsquellenkennung des Erzeugers dieses Pakets.

SSRC of media source: 32 bits
Die Synchronisationsquellenkennung der Medienquelle, auf die sich dieses Feedback bezieht.

Feedback Control Information (FCI): variable Länge
Die folgenden drei Abschnitte legen fest, welche Zusatzinformationen in der FB-Nachricht für jeden Feedback-Typ (Transportschicht, payload-spezifisch oder Anwendungsschicht) MAY enthalten sein dürfen. Weitere FCI-Inhalte MAY in späteren Dokumenten spezifiziert werden.

Jedes RTCP-Feedback-Paket MUST mindestens eine FB-Nachricht im FCI-Feld enthalten. Die Abschnitte 6.2 und 6.3 definieren für jeden FCI-Typ, ob mehrere FB-Nachrichten MAY in ein einzelnes FCI-Feld komprimiert werden dürfen. Ist dies der Fall, MUST sie vom selben Typ sein, d. h. gleiches FMT. Müssen mehrere Feedback-Nachrichtentypen, d. h. mehrere FMTs, vermittelt werden, MUST mehrere RTCP-FB-Nachrichten erzeugt und SHOULD im selben zusammengesetzten RTCP-Paket aneinandergereiht werden.

6.2. Feedback-Nachrichten auf Transportschicht

Feedback-Nachrichten auf Transportschicht werden durch den Wert RTPFB als RTCP-Nachrichtentyp identifiziert.

In diesem Dokument ist eine einzige allgemeine Feedback-Nachricht auf Transportschicht definiert: Generic NACK. Sie wird über den FMT-Parameter wie folgt identifiziert:

• 0: nicht zugewiesen
• 1: Generic NACK
• 2-30: nicht zugewiesen
• 31: reserviert für künftige Erweiterung des Identifikationsnummernraums

Der folgende Unterabschnitt definiert die Formate des FCI-Felds für diesen FB-Nachrichtentyp. Weitere generische Feedback-Nachrichten MAY in Zukunft definiert werden.

6.2.1. Generic NACK

Die Generic-NACK-Nachricht wird durch PT=RTPFB und FMT=1 identifiziert.

Das FCI-Feld MUST mindestens einen und MAY mehr als einen Generic NACK enthalten.

Generic NACK wird verwendet, um den Verlust eines oder mehrerer RTP-Pakete anzuzeigen. Die verlorenen Pakete werden mittels Paketkennung und Bitmaske identifiziert.

Generic-NACK-Feedback SHOULD NOT verwendet werden, wenn das darunter liegende Transportprotokoll dem Sender ähnliche Feedback-Informationen liefern kann (wie z. B. bei DCCP).

Das Feld Feedback Control Information (FCI) hat die folgende Syntax (Abbildung 4):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            PID                |             BLP               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 4: Syntax for the Generic NACK message

Packet ID (PID): 16 bits
Das PID-Feld spezifiziert ein verlorenes Paket. Es bezieht sich auf die RTP-Sequenznummer des verlorenen Pakets.

bitmask of following lost packets (BLP): 16 bits
BLP ermöglicht die Meldung von Verlusten bei beliebigen der 16 RTP-Pakete unmittelbar nach dem durch PID angegebenen RTP-Paket. Die Definition von BLP ist identisch mit [6]. Bezeichnet man das am wenigsten signifikante Bit von BLP als Bit 1 und das am meisten signifikante als Bit 16, dann ist Bit i der Bitmaske 1, wenn der Empfänger RTP-Paketnummer (PID+i) (modulo 2^16) nicht empfangen hat und diesen Verlust meldet; andernfalls ist Bit i 0. Beachten Sie, dass der Sender MUST NOT annehmen darf, ein Empfänger habe ein Paket empfangen, nur weil dessen Bit in der Maske 0 ist. Z. B. wäre das am wenigsten signifikante Bit von BLP 1, wenn das zu PID gehörige Paket und das folgende Paket verloren gingen. Der Sender kann jedoch nicht schließen, dass die Pakete PID+2 bis PID+16 empfangen wurden, nur weil die Bits 2 bis 15 von BLP 0 sind; er weiß nur, dass der Empfänger sie zu diesem Zeitpunkt nicht als verloren gemeldet hat.

Die Länge der FB-Nachricht MUST auf 2+n gesetzt werden, wobei n die Anzahl der im FCI-Feld enthaltenen Generic NACKs ist.

Die Generic-NACK-Nachricht referenziert den Payload-Typ implizit über die Sequenznummer(n).

6.3. Payload-spezifische Feedback-Nachrichten

Payload-spezifische FB-Nachrichten werden durch PT=PSFB als RTCP-Nachrichtentyp identifiziert.

Bisher sind drei payload-spezifische FB-Nachrichten plus eine Feedback-Nachricht auf Anwendungsschicht definiert. Sie werden über den FMT-Parameter wie folgt identifiziert:

Value	Meaning
0	unassigned
1	Picture Loss Indication (PLI)
2	Slice Loss Indication (SLI)
3	Reference Picture Selection Indication (RPSI)
4-14	unassigned
15	Application layer FB (AFB) message
16-30	unassigned
31	reserved for future expansion of the sequence number space

Die folgenden Unterabschnitte definieren die FCI-Formate für die payload-spezifischen FB-Nachrichten; Abschnitt 6.4 definiert das FCI-Format für die Feedback-Nachricht auf Anwendungsschicht.

6.3.1. Picture Loss Indication (PLI)

Die PLI-FB-Nachricht wird durch PT=PSFB und FMT=1 identifiziert.

Im FCI-Feld MUST genau eine PLI enthalten sein.

6.3.1.1. Semantik

Mit der Picture Loss Indication teilt ein Decoder dem Encoder mit, dass eine undefinierte Menge codierter Videodaten eines oder mehrerer Bilder verloren gegangen ist. In Verbindung mit einem Videocodierverfahren auf Basis von Inter-Bildvorhersage wird ein Encoder, der eine PLI empfängt, darauf aufmerksam, dass die Vorhersagekette gebrochen sein kann. Der Sender MAY auf eine PLI mit der Übertragung eines Intra-Bildes reagieren, um Resynchronisation zu erreichen (womit diese Nachricht der in [6] definierten FIR-Nachricht ähnelt); der Sender MUST jedoch die in Abschnitt 7 beschriebene Staukontrolle berücksichtigen, die MAY seine Fähigkeit einschränken, ein Intra-Frame zu senden.

Andere RTP-Payload-Spezifikationen wie RFC 2032 [6] definieren bereits ein Feedback für bestimmte Codecs. Eine Anwendung, die beide Schemata unterstützt, MUST beim Senden von Feedback den in dieser Spezifikation definierten Mechanismus verwenden. Aus Gründen der Abwärtskompatibilität SHOULD eine solche Anwendung auch in der Lage sein, das im jeweiligen RTP-Payload-Format definierte Feedback zu empfangen und darauf zu reagieren, falls das Payload-Format dies verlangt.

6.3.1.2. Nachrichtenformat

PLI benötigt keine Parameter. Daher MUST das Längenfeld 2 sein, und es MUST keine Feedback Control Information geben.

Die Semantik dieser FB-Nachricht ist unabhängig vom Payload-Typ.

6.3.1.3. Zeitregeln

Die Zeitgebung folgt den in Abschnitt 3 skizzierten Regeln. In Systemen, die sowohl PLI als auch andere Feedback-Typen einsetzen, kann es ratsam sein, für PLI die regulären RTCP-RR-Zeitregeln zu befolgen, da PLI nicht so verzögerungskritisch ist wie andere FB-Typen.

6.3.1.4. Anmerkungen

PLI-Nachrichten lösen typischerweise das Senden vollständiger Intra-Bilder aus. Intra-Bilder sind mehrfach größer als vorhergesagte (Inter-)Bilder. Ihre Größe ist unabhängig vom Erzeugungszeitpunkt. In den meisten Umgebungen, insbesondere bei bandbreitenbegrenzten Verbindungen, impliziert ein Intra-Bild eine zulässige Verzögerung, die ein Vielfaches der typischen Bilddauer beträgt. Beispiel: Bei 10 fps Sendebildrate und einem Intra-Bild, das als zehnmal so groß wie ein Inter-Bild angenommen wird, muss eine volle Sekunde Latenz akzeptiert werden. In einer solchen Umgebung ist keine besonders kurze Verzögerung beim Senden der FB-Nachricht nötig. Daher hat das Warten auf den nächsten nach den RTCP-Zeitregeln gemäß [2] mit Tmin=0 zulässigen Zeitpunkt keinen negativen Einfluss auf die Systemleistung.

6.3.2. Slice Loss Indication (SLI)

Die SLI-FB-Nachricht wird durch PT=PSFB und FMT=2 identifiziert.

Das FCI-Feld MUST mindestens eine und MAY mehr als eine SLI enthalten.

6.3.2.1. Semantik

Mit der Slice Loss Indication kann ein Decoder einem Encoder mitteilen, dass der Verlust oder die Beschädigung eines oder mehrerer aufeinanderfolgender Makroblöcke in Scan-Reihenfolge erkannt wurde (siehe unten). Diese FB-Nachricht MUST NOT für Videocodecs mit nicht einheitlichen, dynamisch änderbaren Makroblockgrößen wie H.263 mit aktiviertem Anhang Q verwendet werden. In einem solchen Fall kann ein Encoder die beschädigte räumliche Region nicht immer identifizieren.

6.3.2.2. Format

Die Slice Loss Indication verwendet ein zusätzliches FCI-Feld, dessen Inhalt Abbildung 6 zeigt. Die Länge der FB-Nachricht MUST auf 2+n gesetzt werden, wobei n die Anzahl der im FCI-Feld enthaltenen SLIs ist.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            First        |        Number           | PictureID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 6: Syntax of the Slice Loss Indication (SLI)

First: 13 bits
Die Makroblock-(MB-)Adresse des ersten verlorenen Makroblocks. Die MB-Nummerierung erfolgt so, dass der Makroblock in der oberen linken Bildecke Makroblock 1 ist und die Nummer je Makroblock von links nach rechts und dann von oben nach unten in Raster-Scan-Reihenfolge zunimmt (sodass bei N Makroblöcken im Bild der untere rechte Makroblock die Nummer N trägt).

Number: 13 bits
Die Anzahl verlorener Makroblöcke in der oben beschriebenen Scan-Reihenfolge.

PictureID: 6 bits
Die sechs niederwertigsten Bits der codec-spezifischen Kennung, mit der das Bild referenziert wird, in dem der Verlust der Makroblöcke auftrat. Bei vielen Videocodecs ist PictureID identisch mit der Temporal Reference.

Die Anwendbarkeit dieser FB-Nachricht ist auf eine kleine Menge von Videocodecs beschränkt; daher werden keine expliziten Payload-Typ-Informationen bereitgestellt.

6.3.2.3. Zeitregeln

Die Effizienz von Algorithmen mit Slice Loss Indication sinkt stark, wenn die Indication nicht zeitnah übertragen wird. Bewegungskompensation verbreitet beschädigte Pixel, die nicht als beschädigt gemeldet wurden. Daher wird dringend empfohlen, den in Abschnitt 3 beschriebenen Algorithmus zu verwenden.

6.3.2.4. Anmerkungen

Der Begriff Slice wird hier im Sinne von MPEG-1 verwendet – eine aufeinanderfolgende Anzahl von Makroblöcken in Scan-Reihenfolge. Neuere Videocodierstandards verstehen Slice teils anders. In H.263 (1998) gibt es z. B. das Konzept „rectangular slice“. Der Verlust eines rechteckigen Slices kann dazu führen, dass mehr als eine SLI nötig ist, um die Region verlorener/beschädigter MBs genau zu identifizieren.

Das erste Feld des FCI definiert den ersten Makroblock eines Bildes als 1 und nicht, wie man vermuten könnte, als 0. Dies dient der Angleichung an den vergleichbaren Mechanismus in ITU-T Rec. H.245 [24]. Die maximale Makroblockanzahl pro Bild (2**13 oder 8192) entspricht den maximalen Bildgrößen der meisten ITU- und ISO/IEC-Videocodecs. Bieten künftige Codecs größere Bilder und/oder kleinere Makroblöcke, muss eine zusätzliche FB-Nachricht definiert werden. Die sechs niederwertigsten Bits des Temporal-Reference-Felds gelten als ausreichend, um das Bild mit dem Verlust anzugeben.

Die Reaktion auf eine SLI ist nicht Teil dieser Spezifikation. Eine typische Reaktion ist Intra-Refresh für die betroffene räumliche Region.

Algorithmen wurden berichtet, die von der Bewegungskompensation betroffene Regionen verfolgen, um Intra-Makroblöcke in all diese Bereiche zu senden, unabhängig vom Zeitpunkt des FB (siehe H.263 (2000) Anhang I [17] und [15]). Obwohl der FB-Zeitpunkt bei diesen Algorithmen weniger kritisch ist, ist zu beachten, dass sie große Bildteile korrigieren und daher bei verzögertem FB deutlich mehr Daten senden müssen.

6.3.3. Reference Picture Selection Indication (RPSI)

Die RPSI-FB-Nachricht wird durch PT=PSFB und FMT=3 identifiziert.

Im FCI-Feld MUST genau eine RPSI enthalten sein.

6.3.3.1. Semantik

Moderne Videocodierstandards wie MPEG-4 visual version 2 [16] oder H.263 version 2 [17] erlauben die Nutzung älterer Referenzbilder als des jüngsten für prädiktive Codierung. Typisch wird eine FIFO-Warteschlange von Referenzbildern geführt. Hat ein Encoder von einem Verlust der Encoder-Decoder-Synchronität erfahren, kann ein als korrekt bekanntes Referenzbild verwendet werden. Da dieses Referenzbild zeitlich weiter entfernt ist als üblich, wird das prädiktiv codierte Bild mehr Bits benötigen.

Sowohl MPEG-4 als auch H.263 definieren ein binäres Format für die „Nutzlast“ einer RPSI-Nachricht mit Informationen wie temporaler ID des beschädigten Bildes und Größe der beschädigten Region. Diese Bitkette ist typischerweise klein (einige Dutzend Bits), variabler Länge und in sich geschlossen, d. h. sie enthält alle Informationen, die für die Referenzbildauswahl nötig sind.

Sowohl MPEG-4 als auch H.263 erlauben RPSI auch mit positivem Feedback, d. h. es werden Bilder (oder Slices) gemeldet, die fehlerfrei decodiert wurden. Jede Form positiven Feedbacks MUST NOT in Mehrteilnehmer-Sitzungen verwendet werden (positives Feedback zu einzelnen Referenzbildern in RTCP-Intervallen ist ohnehin wenig nützlich).

6.3.3.2. Format

Das FCI für die RPSI-Nachricht folgt dem in Abbildung 7 dargestellten Format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      PB       |0| Payload Type|    Native RPSI bit string     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   defined per codec          ...                | Padding (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: Syntax of the Reference Picture Selection Indication (RPSI)

PB: 8 bits
Die Anzahl ungenutzter Bits, die nötig sind, um die Länge der RPSI-Nachricht auf ein Vielfaches von 32 Bits aufzufüllen.

0: 1 bit
MUST bei Übertragung auf null gesetzt und beim Empfang ignoriert werden.

Payload Type: 7 bits
Gibt den RTP-Payload-Typ an, in dessen Kontext die native RPSI-Bitkette MUST interpretiert werden muss.

Native RPSI bit string: variable Länge
Die RPSI-Information, nativ durch den Videocodec definiert.

Padding: #PB bits
Eine Anzahl auf null gesetzter Bits, um den Inhalt der RPSI-Nachricht auf die nächste 32-Bit-Grenze aufzufüllen. Die Anzahl der Padding-Bits MUST im PB-Feld angegeben werden.

6.3.3.3. Zeitregeln

RPSI ist noch verzögerungskritischer als Algorithmen mit SLI. Je älter die RPSI-Nachricht, desto mehr Bits muss der Encoder ausgeben, um die Encoder-Decoder-Synchronität wiederherzustellen. Siehe [15] zu Overhead von RPSI für bestimmte Bitraten/Bildraten/Verlustraten.

Daher sollten RPSI-Nachrichten typischerweise so bald wie möglich gesendet werden, unter Verwendung des Algorithmus aus Abschnitt 3.

6.4. Feedback-Nachrichten auf Anwendungsschicht

Feedback-Nachrichten auf Anwendungsschicht sind ein Sonderfall payload-spezifischer Nachrichten und werden durch PT=PSFB und FMT=15 identifiziert. Es MUST genau eine Feedback-Nachricht auf Anwendungsschicht im FCI-Feld enthalten sein, es sei denn, die Struktur der Feedback-Nachricht auf Anwendungsschicht selbst erlaubt Stapelung (z. B. durch feste Größe oder explizite Längenangabe).

Diese Nachrichten transportieren anwendungsdefinierte Daten direkt von der Empfänger- zur Senderanwendung. Die transportierten Daten werden durch die FB-Nachricht nicht identifiziert. Daher MUST die Anwendung die Nachrichtennutzlast identifizieren können.

Üblicherweise definieren Anwendungen eigene Nachrichtensätze, z. B. NEWPRED-Nachrichten in MPEG-4 [16] (in RTP-Paketen gemäß RFC 3016 [23] getragen) oder FB-Nachrichten in H.263/Anhang N, U [17] (paketisiert gemäß RFC 2429 [14]). Diese Nachrichten benötigen keine zusätzlichen Informationen aus der RTCP-Nachricht. Die Anwendungsnachricht wird daher wie folgt einfach in das FCI-Feld gelegt und das Längenfeld entsprechend gesetzt.

Application Message (FCI): variable Länge
Dieses Feld enthält die ursprüngliche Anwendungsnachricht, die vom Empfänger zur Quelle transportiert werden soll. Das Format ist anwendungsabhängig. Die Länge ist variabel. Sind die Anwendungsdaten nicht 32-Bit-ausgerichtet, MUST Padding-Bits und -Bytes hinzugefügt werden, um 32-Bit-Ausrichtung zu erreichen. Die Kennzeichnung von Padding obliegt der Anwendungsschicht und ist in dieser Spezifikation nicht definiert.

Die Spezifikation der Feedback-Nachricht auf Anwendungsschicht MUST festlegen, ob die Nachricht spezifisch im Kontext eines bestimmten Codecs (identifiziert durch den RTP-Payload-Typ) interpretiert werden muss. Ist ein Bezug zum Payload-Typ für die ordnungsgemäße Verarbeitung nötig, MUST die Spezifikation der Feedback-Nachricht auf Anwendungsschicht eine Möglichkeit definieren, die Payload-Typ-Information als Teil der Feedback-Nachricht auf Anwendungsschicht selbst zu vermitteln.