Zum Hauptinhalt springen

4. SDP-Definitionen (SDP Definitions)

Dieser Abschnitt definiert eine Reihe zusätzlicher SDP-Parameter zur Beschreibung einer Sitzung. Alle sind als Attribute auf Medienebene definiert.

4.1. Profil-Identifikation​

Das in [4] definierte AV-Profil wird z. B. im Kontext des Session Description Protocol (SDP) [3] als „AVP“ bezeichnet. Das in diesem Dokument spezifizierte Profil wird als „AVPF“ bezeichnet.

Feedback-Informationen nach den in diesem Dokument geänderten Zeitregeln MUST NOT für eine bestimmte Mediensitzung gesendet werden, es sei denn, die Beschreibung dieser Sitzung weist die Verwendung des Profils „AVPF“ aus (ausschließlich oder gemeinsam mit anderen AV-Profilen).

4.2. RTCP-Feedback-Fähigkeits-Attribut​

Es wird ein neues payload-format-spezifisches SDP-Attribut definiert, um die Fähigkeit zur Nutzung von RTCP-Feedback wie in diesem Dokument spezifiziert anzuzeigen: a=rtcp-fb. Das Attribut rtcp-fb MUST ausschließlich als SDP-Medienattribut verwendet werden und MUST NOT auf Sitzungsebene angegeben werden. Das Attribut rtcp-fb MUST nur in Mediensitzungen verwendet werden, für die „AVPF“ angegeben ist.

Das Attribut rtcp-fb SHOULD verwendet werden, um anzugeben, welche RTCP-FB-Nachrichten MAY in dieser Mediensitzung für den angegebenen Payload-Typ verwendet werden können. Ein Platzhalter-Payload-Typ („*“) MAY verwendet werden, um anzuzeigen, dass das RTCP-Feedback-Attribut für alle Payload-Typen gilt. Werden mehrere Feedback-Arten unterstützt und/oder soll dasselbe Feedback für eine Teilmenge der Payload-Typen festgelegt werden, MUST mehrere Zeilen a=rtcp-fb verwendet werden.

Wenn kein Attribut rtcp-fb angegeben ist, MAY RTP-Empfänger Feedback mit anderen geeigneten RTCP-Feedback-Paketen senden, wie für den jeweiligen Medientyp definiert. RTP-Empfänger MUST NOT darauf vertrauen, dass RTP-Sender auf FB-Nachrichten reagieren. Der RTP-Sender MAY einige Feedback-Nachrichten ignorieren.

Wenn eine oder mehrere Attribute rtcp-fb in einer Mediensitzungsbeschreibung vorhanden sind, MUST die RTCP-Empfänger für die Mediensitzung(en) mit rtcp-fb

  • alle rtcp-fb-Attribute ignorieren, deren Semantik sie nicht vollständig verstehen (d. h. sie verstehen die Bedeutung nicht aller Werte in der Zeile a=rtcp-fb);

  • Feedback-Informationen wie in diesem Dokument spezifiziert bereitstellen SHOULD, und zwar mit einem der in einem der rtcp-fb-Attribute dieser Mediensitzung angegebenen RTCP-Feedback-Pakete; und

  • andere FB-Nachrichten als die in einer der rtcp-fb-Attributzeilen aufgeführten MUST NOT verwenden.

In Verbindung mit dem Offer/Answer-Modell [8] MAY der Anbietende seinem Peer eine Menge dieser AVPF-Attribute vorlegen. Der Antwortende MUST alle Attribute entfernen, die er nicht versteht sowie solche, die er generell nicht unterstützt oder in dieser Mediensitzung nicht nutzen möchte. Der Antwortende MUST keine Feedback-Parameter zur Medienbeschreibung hinzufügen und MUST Werte solcher Parameter nicht ändern. Die Antwort ist für die Mediensitzung bindend, und sowohl Anbietender als auch Antwortender MUST nur über auf diese Weise ausgehandelte Feedback-Mechanismen verwenden. Sowohl Anbietender als auch Antwortender MAY unabhängig entscheiden, nur RTCP-FB-Nachrichten einer Teilmenge der ausgehandelten Mechanismen zu senden, sie SHOULD jedoch bei Empfang auf alle ausgehandelten FB-Typen angemessen reagieren.

RTP-Sender MUST darauf vorbereitet sein, jede Art von RTCP-FB-Nachrichten zu empfangen, und MUST alle RTCP-FB-Nachrichten, die sie nicht verstehen, still verwerfen.

Die Syntax des Attributs rtcp-fb ist wie folgt (Feedback-Typen und optionale Parameter sind alle groß-/kleinschreibungssensitiv):

(In der folgenden ABNF werden fmt, SP und CRLF wie in [3] definiert verwendet.)

     rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF

     rtcp-fb-pt         = "*"   ; wildcard: applies to all formats
                        / fmt   ; as defined in SDP spec

     rtcp-fb-val        = "ack" rtcp-fb-ack-param
                        / "nack" rtcp-fb-nack-param
                        / "trr-int" SP 1*DIGIT
                        / rtcp-fb-id rtcp-fb-param

     rtcp-fb-id         = 1*(alpha-numeric / "-" / "_")

     rtcp-fb-param      = SP "app" [SP byte-string]
                        / SP token [SP byte-string]
                        / ; empty

     rtcp-fb-ack-param  = SP "rpsi"
                        / SP "app" [SP byte-string]
                        / SP token [SP byte-string]
                        / ; empty

     rtcp-fb-nack-param = SP "pli"
                        / SP "sli"
                        / SP "rpsi"
                        / SP "app" [SP byte-string]
                        / SP token [SP byte-string]
                        / ; empty

Die Literale der obigen Grammatik haben folgende Semantik:

Feedback-Typ „ack“:

Dieser Feedback-Typ zeigt an, dass positive Bestätigungen für Feedback unterstützt werden.

Der Feedback-Typ „ack“ MUST nur verwendet werden, wenn die Mediensitzung im in Abschnitt 3.6.1 definierten ACK-Modus arbeiten darf.

Es MUST Parameter angegeben werden, um verschiedene Arten positiver Bestätigungs-Feedbacks zu unterscheiden.

Der Parameter „rpsi“ kennzeichnet die Verwendung von Reference Picture Selection Indication-Feedback wie in Abschnitt 6.3.3 definiert.

Ist der Parameter „app“ angegeben, kennzeichnet dies die Verwendung von Feedback auf Anwendungsebene. In diesem Fall MAY zusätzliche Parameter nach „app“ verwendet werden, um verschiedene Arten von Feedback auf Anwendungsebene zu unterscheiden. Dieses Dokument definiert keine spezifischen Parameter für „app“.

Weitere Parameter für „ack“ MAY in anderen Dokumenten definiert werden.

Feedback-Typ „nack“:

Dieser Feedback-Typ zeigt an, dass negative Bestätigungen für Feedback unterstützt werden.

Der Feedback-Typ „nack“ ohne Parameter kennzeichnet die Verwendung des generischen NACK-Feedback-Formats wie in Abschnitt 6.2.1 definiert.

Die folgenden drei Parameter werden in diesem Dokument für die Verwendung mit „nack“ in Verbindung mit dem Medientyp „video“ definiert:

  • „pli“ kennzeichnet die Verwendung von Picture Loss Indication-Feedback wie in Abschnitt 6.3.1.

  • „sli“ kennzeichnet die Verwendung von Slice Loss Indication-Feedback wie in Abschnitt 6.3.2.

  • „rpsi“ kennzeichnet die Verwendung von Reference Picture Selection Indication-Feedback wie in Abschnitt 6.3.3.

„app“ kennzeichnet die Verwendung von Feedback auf Anwendungsebene. Nach „app“ MAY zusätzliche Parameter angegeben werden, um verschiedene Arten von Feedback auf Anwendungsebene zu unterscheiden. In diesem Dokument werden keine spezifischen Parameter für „app“ definiert.

Weitere Parameter für „nack“ MAY in anderen Dokumenten definiert werden.

Weitere Feedback-Typen <rtcp-fb-id>:

Andere Dokumente MAY zusätzliche Feedback-Typen definieren; zur Erweiterbarkeit der Grammatik wird rtcp-fb-id als Platzhalter eingeführt. Ein neuer Feedback-Schemaname MUST eindeutig sein (und MUST bei IANA registriert werden). Zusammen mit einem neuen Namen MUST seine Semantik, Paketformate (falls nötig) und Betriebsregeln spezifiziert werden.

Mindestintervall für reguläres RTCP „trr-int“:

Das Attribut „trr-int“ dient zur Angabe des Mindestintervalls T_rr_interval zwischen zwei regulären (vollständig zusammengesetzten) RTCP-Paketen in Millisekunden für diese Mediensitzung. Ist „trr-int“ nicht angegeben, wird ein Standardwert von 0 angenommen.

Es wird angenommen, dass detailliertere Informationen zu Feedback auf Anwendungsebene (wie in Abschnitt 6.4 definiert) als Feedback-Typen und Parameter anderweitig vermittelt werden. Daher werden in diesem Dokument keine weiteren Festlegungen zu Typen und Parametern getroffen.

Weitere Feedback-Typen sowie weitere Parameter können in anderen Dokumenten definiert werden.

Ob Empfänger Feedback senden und ob (wie) Sender das bereitgestellte Feedback nutzen, liegt bei den jeweiligen Parteien.

4.3. RTCP-Bandbreiten-Modifikatoren​

Die standardmäßigen RTCP-Bandbreitenzuweisungen gemäß [1] und [2] MAY durch Bandbreiten-Modifikatoren überschrieben werden, die die maximale RTCP-Bandbreite explizit festlegen. Für die Verwendung mit SDP sind solche Modifikatoren in [4] spezifiziert: b=RS:<bw> und b=RR:<bw> MAY verwendet werden, um RTP-Sendern bzw. -Empfängern eine andere Bandbreite (in Bit pro Sekunde) zuzuweisen. Die Vorrangregeln aus [4] gelten zur Bestimmung der tatsächlich von Sendern und Empfängern genutzten Bandbreite.

Anwendungen, die bewusst über stark asymmetrische Verbindungen (z. B. Satellitenverbindungen) arbeiten, SHOULD diesen Mechanismus nutzen, um die Feedback-Rate bei hohen Bandbreitenströmen zu senken und eine deterministische Überlastung der Feedback-Pfade zu vermeiden.

4.4. Beispiele​

Beispiel 1: Die folgende Sitzungsbeschreibung beschreibt eine Sitzung aus Audio und DTMF [18] für Punkt-zu-Punkt-Kommunikation, wobei der DTMF-Strom generische NACKs verwendet. Diese Sitzungsbeschreibung könnte in einer SIP-INVITE-, 200-OK- oder ACK-Nachricht enthalten sein, um anzuzeigen, dass der Absender in der Lage ist und bereit ist, Feedback für den von ihm gesendeten DTMF-Strom zu empfangen.

     v=0
     o=alice 3203093520 3203093520 IN IP4 host.example.com
     s=Media with feedback
     t=0 0
     c=IN IP4 host.example.com
     m=audio 49170 RTP/AVPF 0 96
     a=rtpmap:0 PCMU/8000
     a=rtpmap:96 telephone-event/8000
     a=fmtp:96 0-16
     a=rtcp-fb:96 nack

Damit können Sender und Empfänger eine zuverlässige Übertragung von DTMF-Ereignissen in einer Audio-Sitzung bereitstellen. Bei einem 64-kbit/s-Audiostrom mit einem Empfänger stehen dem Empfänger 2,5 % RTCP-Bandbreite für den negativ bestätigenden Strom zur Verfügung, d. h. 250 Byte pro Sekunde oder etwa 2 RTCP-Feedback-Nachrichten pro Sekunde. Der Empfänger kann damit bis zu zwei fehlende DTMF-Audiopakete pro Sekunde einzeln mitteilen.

Beispiel 2: Die folgende Sitzungsbeschreibung beschreibt eine Multicast-Video-Sitzung (nur Video, entweder H.261 oder H.263+), bei der die Videoquelle generische NACKs für beide Codecs und Reference Picture Selection für H.263 akzeptiert. Eine solche Beschreibung könnte über das Session Announcement Protocol (SAP) vermittelt worden sein.

     v=0
     o=alice 3203093520 3203093520 IN IP4 host.example.com
     s=Multicast video with feedback
     t=3203130148 3203137348
     m=audio 49170 RTP/AVP 0
     c=IN IP4 224.2.1.183
     a=rtpmap:0 PCMU/8000
     m=video 51372 RTP/AVPF 98 99
     c=IN IP4 224.2.1.184
     a=rtpmap:98 H263-1998/90000
     a=rtpmap:99 H261/90000
     a=rtcp-fb:* nack
     a=rtcp-fb:98 nack rpsi

Der Sender kann einen eingehenden generischen NACK als Hinweis nutzen, so bald wie möglich (unter Beachtung der Staukontrolle) ein neues Intra-Frame zu senden. Der Empfang einer Reference Picture Selection Indication (RPSI)-Nachricht erlaubt dem Sender, auf ein großes Intra-Frame zu verzichten; stattdessen kann er weiter Inter-Frames senden, wählt jedoch das angegebene Bild als neue Codierreferenz.

Beispiel 3: Die folgende Sitzungsbeschreibung definiert dieselbe Mediensitzung wie Beispiel 2, erlaubt aber den gemischten Betrieb von AVP- und AVPF-RTP-Entitäten (siehe auch nächster Abschnitt). Beide Medienbeschreibungen verwenden dieselben Adressen; dennoch sind zwei m=-Zeilen nötig, um Informationen über beide anwendbaren RTP-Profile zu vermitteln.

     v=0
     o=alice 3203093520 3203093520 IN IP4 host.example.com
     s=Multicast video with feedback
     t=3203130148 3203137348
     m=audio 49170 RTP/AVP 0
     c=IN IP4 224.2.1.183
     a=rtpmap:0 PCMU/8000
     m=video 51372 RTP/AVP 98 99
     c=IN IP4 224.2.1.184
     a=rtpmap:98 H263-1998/90000
     a=rtpmap:99 H261/90000
     m=video 51372 RTP/AVPF 98 99
     c=IN IP4 224.2.1.184
     a=rtpmap:98 H263-1998/90000
     a=rtpmap:99 H261/90000
     a=rtcp-fb:* nack
     a=rtcp-fb:98 nack rpsi

Diese beiden m=-Zeilen SHOULD durch ein geeignetes Verfahren gruppiert werden, um anzuzeigen, dass beide Alternativen dieselben Inhalte tragen. Ein Beispielrahmen dafür ist in [10] definiert.

In diesem Beispiel haben RTCP-Feedback-fähige Empfänger gelegentlich einen Vorteil, Ereignisse früher an den Sender zu melden (was der ganzen Gruppe nützen kann). Im Durchschnitt liefern jedoch alle RTP-Empfänger dieselbe Feedback-Menge. Die Zusammenarbeit zwischen AVP- und AVPF-Entitäten wird im nächsten Abschnitt ausführlich behandelt.

Letztes Update am