Zum Hauptinhalt springen

7. SDP-Definitionen

Abschnitt 4 von [RFC4585] definiert ein neues SDP [RFC4566]-Attribut, rtcp-fb, das verwendet werden kann, um die Fähigkeit zur Handhabung spezifischer AVPF-Befehle und -Anzeigen wie Reference Picture Selection, Picture Loss Indication usw. auszuhandeln. Die ABNF für rtcp-fb wird in Abschnitt 4.2 von [RFC4585] beschrieben. In diesem Abschnitt erweitern wir das rtcp-fb-Attribut um die Befehle und Anzeigen, die für die Codec-Steuerung im vorliegenden Dokument beschrieben werden. Wir diskutieren auch die Offer/Answer-Implikationen für die Codec-Steuerungsbefehle und -anzeigen.

7.1. Erweiterung des rtcp-fb-Attributs​

Wie in AVPF [RFC4585] beschrieben, zeigt das rtcp-fb-Attribut die Fähigkeit zur Verwendung von RTCP-Feedback an. AVPF spezifiziert, dass das rtcp-fb-Attribut nur als Media-Level-Attribut verwendet werden darf und nicht auf Sitzungsebene bereitgestellt werden darf. Alle in [RFC4585] für das rtcp-fb-Attribut beschriebenen Regeln in Bezug auf Payload-Typ und mehrere rtcp-fb-Attribute in einer Sitzungsbeschreibung gelten auch für die neuen in dieser Spezifikation definierten Feedback-Nachrichten.

Die ABNF [RFC4234] für rtcp-fb, wie in [RFC4585] definiert, lautet

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

wobei rtcp-fb-pt der Payload-Typ und rtcp-fb-val den Typ der Feedback-Nachricht wie ack, nack, trr-int und rtcp-fb-id definiert. Um beispielsweise die Unterstützung von Feedback für Picture Loss Indication anzuzeigen, deklariert der Sender Folgendes in SDP

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 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 nack pli

In diesem Dokument definieren wir einen neuen Feedback-Wert "ccm", der die Unterstützung der Codec-Steuerung mittels RTCP-Feedback-Nachrichten anzeigt. Der "ccm"-Feedback-Wert SOLLTE mit Parametern verwendet werden, die die spezifischen unterstützten Codec-Steuerungsbefehle anzeigen. In diesem Dokument definieren wir vier solche Parameter, nämlich:

  • "fir" zeigt Unterstützung für Full Intra Request (FIR) an.
  • "tmmbr" zeigt Unterstützung für Temporary Maximum Media Stream Bit Rate Request/Notification (TMMBR/TMMBN) an. Es hat einen optionalen Unterparameter, um die maximale Sitzungspaketrate (gemessen in Paketen pro Sekunde) anzugeben, die verwendet werden soll. Wenn nicht enthalten, wird dies standardmäßig auf unendlich gesetzt.
  • "tstr" zeigt Unterstützung für Temporal-Spatial Trade-off Request/Notification (TSTR/TSTN) an.
  • "vbcm" zeigt Unterstützung für H.271 Video Back Channel Messages (VBCMs) an. Es hat null oder mehr Unterparameter, die die unterstützten H.271 "payloadType"-Werte identifizieren.

In der ABNF für rtcp-fb-val, die in [RFC4585] definiert ist, gibt es einen Platzhalter namens rtcp-fb-id, um neue Feedback-Typen zu definieren. "ccm" wird als neuer Feedback-Typ in diesem Dokument definiert, und die ABNF für die Parameter für ccm wird hier definiert (bitte beziehen Sie sich auf Abschnitt 4.2 von [RFC4585] für die vollständige ABNF-Syntax).

rtcp-fb-val        =/ "ccm" rtcp-fb-ccm-param

rtcp-fb-ccm-param  = SP "fir"   ; Full Intra Request
                   / SP "tmmbr" [SP "smaxpr=" MaxPacketRateValue]
                                ; Temporary max media bit rate
                   / SP "tstr"  ; Temporal-Spatial Trade-Off
                   / SP "vbcm" *(SP subMessageType) ; H.271 VBCMs
                   / SP token [SP byte-string]
                           ; for future commands/indications
subMessageType = 1*8DIGIT
byte-string = <as defined in section 4.2 of [RFC4585] >
MaxPacketRateValue = 1*15DIGIT

7.2. Angebot und Antwort (Offer/Answer)​

Die Offer/Answer [RFC3264]-Implikationen für Codec-Steuerungsprotokoll-Feedback-Nachrichten sind ähnlich wie die in [RFC4585] beschriebenen. Der Anbieter DARF die Fähigkeit zur Unterstützung ausgewählter Codec-Befehle und -Anzeigen angeben. Der Antwortende MUSS alle CCM-Parameter entfernen, die den CCMs entsprechen, die er in dieser bestimmten Mediensitzung nicht unterstützen möchte (z. B. weil er die betreffende Nachricht nicht implementiert oder weil seine Anwendungslogik nahelegt, dass die Unterstützung der Nachricht keinen Mehrwert bringt). Der Antwortende DARF KEINE neuen ccm-Parameter zusätzlich zu dem hinzufügen, was angeboten wurde.

Die Antwort ist für die Mediensitzung bindend, und sowohl Anbieter als auch Antwortender DÜRFEN KEINE Feedback-Nachrichten verwenden, außer denen, die beide Seiten explizit als unterstützt angegeben haben. Mit anderen Worten, nur die gemeinsame Teilmenge der CCM-Parameter aus Angebot und Antwort darf verwendet werden.

Beachten Sie, dass das Einbeziehen eines CCM-Parameters in ein Angebot oder eine Antwort anzeigt, dass die Partei (Anbieter oder Antwortender) zumindest in der Lage ist, die entsprechenden CCMs zu empfangen und darauf zu reagieren. In Fällen, in denen der Empfang einer ausgehandelten CCM die Partei verpflichtet, mit einer anderen CCM zu antworten, muss sie auch diese Fähigkeit haben. Obwohl es nicht vorgeschrieben ist, CCMs eines ausgehandelten Typs zu initiieren, wird im Allgemeinen erwartet, dass eine Partei CCMs bei Bedarf initiiert.

Der Sitzungsmaximum-Paketratenparameter-Teil der TMMBR-Anzeige ist deklarativ, und der höchste Wert aus Angebot und Antwort MUSS verwendet werden. Wenn der Sitzungsmaximum-Paketratenparameter nicht in einem Angebot vorhanden ist, DARF er vom Antwortenden NICHT aufgenommen werden.

7.3. Beispiele​

Beispiel 1: Das folgende SDP beschreibt einen Punkt-zu-Punkt-Videoanruf mit H.263, wobei der Initiator des Anrufs seine Fähigkeit zur Unterstützung der FIR- und TSTR/TSTN-Codec-Steuerungsnachrichten deklariert. Das SDP wird in einem High-Level-Signalisierungsprotokoll wie SIP übertragen.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Point-to-Point call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir

Im obigen Beispiel ist der Sender in der Lage, den Trade-off anzupassen, wenn er eine TSTR-Nachricht von der entfernten Partei erhält, wie in der RTCP-TSTN-Feedback-Nachricht angegeben.

Beispiel 2: Das folgende SDP beschreibt einen SIP-Endpunkt, der einem Video-Mixer beitritt, der eine Mehrparteien-Videokonferenzsitzung hostet. Der Teilnehmer unterstützt nur den FIR (Full Intra Request)-Codec-Steuerungsbefehl und deklariert dies in seiner Sitzungsbeschreibung.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multiparty Video Call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm fir

Wenn die Video-MCU entscheidet, das Video dieses Teilnehmers zu routen, sendet sie eine RTCP-FIR-Feedback-Nachricht. Nach Erhalt dieser Feedback-Nachricht muss der Endpunkt eine vollständige Intra-Anfrage generieren.

Beispiel 3: Das folgende Beispiel beschreibt die Offer/Answer-Implikationen für die Codec-Steuerungsnachrichten. Der Anbieter möchte "tstr", "fir" und "tmmbr" unterstützen. Das angebotene SDP lautet

-------------> Offer
      v=0
      o=alice 3203093520 3203093520 IN IP4 host.example.com
      s=Offer/Answer
      c=IN IP4 192.0.2.124
      m=audio 49170 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 51372 RTP/AVPF 98
      a=rtpmap:98 H263-1998/90000
      a=rtcp-fb:98 ccm tstr
      a=rtcp-fb:98 ccm fir
      a=rtcp-fb:* ccm tmmbr smaxpr=120

Der Antwortende möchte nur die FIR- und TSTR/TSTN-Nachrichten unterstützen, und das Antwort-SDP lautet

<---------------- Answer

      v=0
      o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
      s=Offer/Answer
      c=IN IP4 192.0.2.37
      m=audio 47190 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 53273 RTP/AVPF 98
      a=rtpmap:98 H263-1998/90000
      a=rtcp-fb:98 ccm tstr
      a=rtcp-fb:98 ccm fir

Beispiel 4: Das folgende Beispiel beschreibt die Offer/Answer-Implikationen für H.271 Video Back Channel Messages (VBCMs). Der Anbieter möchte VBCM und die Unternachrichten vom payloadType 1 (ein oder mehrere Bilder, die ganz oder teilweise verloren sind) und 2 (eine Menge von Blöcken eines Bildes, die ganz oder teilweise verloren sind) unterstützen.

-------------> Offer
      v=0
      o=alice 3203093520 3203093520 IN IP4 host.example.com
      s=Offer/Answer
      c=IN IP4 192.0.2.124
      m=audio 49170 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 51372 RTP/AVPF 98
      a=rtpmap:98 H263-1998/90000
      a=rtcp-fb:98 ccm vbcm 1 2

Der Antwortende möchte nur Unternachrichten vom Typ 1 unterstützen

<---------------- Answer

      v=0
      o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
      s=Offer/Answer
      c=IN IP4 192.0.2.37
      m=audio 47190 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 53273 RTP/AVPF 98
      a=rtpmap:98 H263-1998/90000
      a=rtcp-fb:98 ccm vbcm 1

Im obigen Beispiel werden also nur VBCM-Anzeigen unterstützt, die aus "payloadType" 1 bestehen.

Letztes Update am