Zum Hauptinhalt springen

8.2.2. Usage with the SDP Offer/Answer Model (SDP Offer/Answer-Modell)

8.2.2. Usage with the SDP Offer/Answer Model (SDP Offer/Answer-Modell)​

Wenn H.264 über RTP mit SDP im Offer/Answer-Modell [8] für Unicast ausgehandelt wird, gelten folgende Einschränkungen und Regeln:

  • Die eine Medienformat-Konfiguration für H.264 identifizierenden Parameter sind profile-level-id und packetization-mode. Diese Medienformat-Konfigurationsparameter (außer dem Level-Teil von profile-level-id) MÜSSEN symmetrisch verwendet werden; der Antwortende MUSS entweder alle Konfigurationsparameter beibehalten oder das Medienformat (Payload-Typ) vollständig entfernen, wenn mindestens ein Parameterwert nicht unterstützt wird. Der Level-Teil von profile-level-id umfasst level_idc und bei profile_idc 66, 77 oder 88 zur Angabe von Level 1b Bit 4 (constraint_set3_flag) von profile-iop. Der Level-Teil von profile-level-id ist änderbar.

Hinweis (informativ): Symmetrie gilt nicht für den Level-Teil von profile-level-id und nicht für andere Stromeigenschaften und Fähigkeitsparameter.

Hinweis (informativ): In H.264 [1] entspricht jedes Level außer Level 1b dem Wert level_idc/10. Level 1b liegt über Level 1.0 und unter Level 1.1 und wird ad hoc signalisiert. Für Baseline, Main und Extended ( profile_idc 66, 77, 88) wird Level 1b durch level_idc 11 und constraint_set3_flag 1 angezeigt. Für andere Profile durch level_idc 9 (Level 1b bleibt über Level 1 mit level_idc 10). In SDP Offer/Answer darf die Antwort ein Level ≤ Angebot zeigen. Bei profile_idc 66/77/88 und level_idc 11 müssen Anbietende und Antwortende Bit 4 des mittleren Oktetts von profile-level-id prüfen.

Zur Vereinfachung SOLL derselbe RTP-Payload-Typ wie im Angebot in der Antwort verwendet werden [8]. Eine Antwort DARF den im Angebot verwendeten Payload-Typ nicht enthalten, es sei denn, die Konfiguration ist identisch.

Hinweis (informativ): Der Anbietende muss nach Erhalt der Antwort Payload-Typen, die nicht im Angebot standen, anhand von video/H264 und den Konfigurationsparametern mit bereits angebotenen vergleichen, um neue vs. äquivalente Konfigurationen zu erkennen.

  • max-recv-level, falls vorhanden, gibt das höchste Empfangslevel an. Fehlt es, entspricht es dem Standard-Level aus dem Level-Teil von profile-level-id. Wenn vorhanden, MUSS max-recv-level höher sein als das Standard-Level.

  • level-asymmetry-allowed steuert Level-Asymmetrie.

Ist level-asymmetry-allowed in Angebot oder Antwort 0 oder fehlt, ist keine Asymmetrie erlaubt; das Level Offerer→Answerer MUSS dem entgegengesetzten entsprechen; gemeinsames Level ist das Minimum der Standard-Level beider Seiten.

Sind in Angebot und Antwort beide Werte 1, ist Asymmetrie erlaubt: Offerer→Answerer = höchstes Empfangslevel des Antwortenden; Answerer→Offerer = höchstes Empfangslevel des Anbietenden.

Ohne Asymmetrie ist kein Level-Upgrade erlaubt; das Standard-Level in der Antwort MUSS ≤ dem im Angebot sein.

  • sprop-deint-buf-req, sprop-interleaving-depth, sprop-max-don-diff, sprop-init-buf-time beschreiben Eigenschaften des vom Anbietenden oder Antwortenden gesendeten RTP-Stroms für die Konfiguration – abweichend von üblicher Offer/Answer-Semantik (dort oft Empfangsfähigkeit). Bei H.264 nimmt der Anbietende an, der Antwortende kann mit der angebotenen Konfiguration empfangen.

Hinweis (informativ): Diese Parameter gelten pro Quelle/Konfiguration, nicht zwingend an den Payload-Typ gebunden.

  • max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br, redundant-pic-cap, max-rcmd-nalu-size, sar-understood, sar-supported KÖNNEN zusätzliche Empfangsfähigkeiten deklarieren. Sie DÜRFEN NICHT vorkommen, wenn die Richtung sendonly ist und sie Empfangsgrenzen beschreiben.

  • Der Anbietende MUSS bei verschachteltem H.264 sprop-deint-buf-req anbieten. Beide Seiten SOLLTEN deint-buf-cap angeben. Bei unbekanntem Empfänger SOLLTEN mehrere Payload-Typen mit unterschiedlichen Pufferanforderungen angeboten werden.

  • sprop-parameter-sets / sprop-level-parameter-sets (in a=fmtp oder fmtp-Quellattribut [9] 6.3) dienen außerbandigem Transport; in-band zusätzlich erlaubt.

Der Antwortende kann für seinen Strom unabhängig vom Offerer→Answerer außerbandig oder in-band senden. Parametersätze in Angebot und Antwort sind unabhängig (zwei Video-Strome).

Parameter-Transport Offerer → Answerer

  • Angebot kann einen oder beide sprop-* enthalten; fehlen beide, nur in-band.

  • Antwort mit in-band-parameter-sets=1 → Anbietender MUSS Parametersätze in-band senden.

  • Wenn das in Richtung Offerer→Answerer zu verwendende Level dem Standard-Level im Angebot entspricht:

Steht sprop-parameter-sets in der a=fmtp-Zeile des Angebots, MUSS der Antwortende bereit sein, die darin enthaltenen Parametersätze zur Dekodierung des eingehenden NAL-Einheitenstroms zu verwenden.

Wird sprop-parameter-sets im Angebot per fmtp-Quellattribut übermittelt: Enthält die Antwort use-level-src-parameter-sets=1 oder das fmtp-Quellattribut, MUSS der Antwortende diese Parametersätze nutzen können; andernfalls MUSS der Anbietende in-band senden.

Fehlt sprop-parameter-sets im Angebot, MUSS der Anbietende in-band senden.

Der Antwortende MUSS sprop-level-parameter-sets im Angebot ignorieren (falls vorhanden, egal ob a=fmtp oder fmtp-Quellattribut).

  • Wenn das in Richtung Offerer→Answerer zu verwendende Level nicht dem Standard-Level im Angebot entspricht:

Der Antwortende MUSS sprop-parameter-sets im Angebot ignorieren (falls vorhanden, egal ob a=fmtp oder fmtp-Quellattribut).

Wenn weder in der Antwort use-level-src-parameter-sets=1 noch das fmtp-Quellattribut vorkommt, MUSS der Antwortende sprop-level-parameter-sets im Angebot ignorieren, und der Anbietende MUSS in-band senden.

Wenn in der Antwort use-level-src-parameter-sets=1 oder das fmtp-Quellattribut vorkommt, MUSS der Antwortende die für das akzeptierte Level (Standard-Level in der Antwort) in sprop-level-parameter-sets des Angebots enthaltenen Parametersätze nutzen können und alle anderen darin ignorieren.

Fehlen im Angebot in sprop-level-parameter-sets Parametersätze für das für Offerer→Answerer zu verwendende Level, MUSS der Anbietende in-band senden.

Parameter-Transport Answerer → Offerer

  • Antwort darf höchstens eines von sprop-parameter-sets / sprop-level-parameter-sets enthalten; fehlen beide → nur in-band.

  • Angebot mit in-band-parameter-sets=1 → Antwortender DARF keine sprop-* in Antwort haben und MUSS in-band senden.

  • Wenn das in Richtung Answerer→Offerer zu verwendende Level dem Standard-Level in der Antwort entspricht:

Steht sprop-parameter-sets in der a=fmtp-Zeile der Antwort, MUSS der Anbietende bereit sein, die darin enthaltenen Parametersätze zur Dekodierung des eingehenden NAL-Einheitenstroms zu verwenden.

Wird sprop-parameter-sets in der Antwort per fmtp-Quellattribut übermittelt: Enthält das Angebot use-level-src-parameter-sets=1 oder das fmtp-Quellattribut, MUSS der Anbietende diese Parametersätze nutzen können; andernfalls MUSS der Antwortende in-band senden.

Fehlt sprop-parameter-sets in der Antwort, MUSS der Antwortende in-band senden.

Der Anbietende MUSS sprop-level-parameter-sets in der Antwort ignorieren (falls vorhanden, egal ob a=fmtp oder fmtp-Quellattribut).

  • Wenn das in Richtung Answerer→Offerer zu verwendende Level nicht dem Standard-Level in der Antwort entspricht:

Der Anbietende MUSS sprop-parameter-sets in der Antwort ignorieren (falls vorhanden).

Wenn weder im Angebot use-level-src-parameter-sets=1 noch das fmtp-Quellattribut vorkommt, MUSS der Anbietende sprop-level-parameter-sets in der Antwort ignorieren, und der Antwortende MUSS in-band senden.

Wenn im Angebot use-level-src-parameter-sets=1 oder das fmtp-Quellattribut vorkommt, MUSS der Anbietende die für das in Answerer→Offerer zu verwendende Level in der Antwort in sprop-level-parameter-sets enthaltenen Parametersätze nutzen können und alle anderen darin ignorieren.

Fehlen in der Antwort in sprop-level-parameter-sets Parametersätze für das zu verwendende Level, MUSS der Antwortende in-band senden.

Bei fmtp-Quellattribut [9] 6.3 MUSS der Empfänger Parametersätze für akzeptiertes Level speichern und der Quelle zuordnen; nur dieselbe Quelle dekodieren; SSRC-Konfliktbehandlung gemäß [9].

Hinweis (informativ): fmtp-Quellattribut eignet sich für Topo-Video-switch-MCU [29].

Multicast

  • Konfiguration: profile-level-id inkl. Level und packetization-mode; alle Konfigurationsparameter inkl. Level-Teil MÜSSEN symmetrisch sein; Level-Teil im Multicast-Offer/Answer nicht änderbar. Gleicher Payload-Typ wie im Angebot SOLL in Antwort; Antwort DARF Payload-Typ aus Angebot nur bei identischer Konfiguration enthalten.

  • Empfangene Parametersätze MÜSSEN der Ursprungsquelle zugeordnet und nur für dieselbe Quelle verwendet werden.

  • Übrige Parameter wie Unicast, sofern dies eingehalten wird.

Tabelle 6. Bedeutung der Parameter je Richtungsattribut

Parametersendrecvrecvonlysendonly
profile-level-idCCP
max-recv-levelRR-
packetization-modeCCP
sprop-deint-buf-reqP-P
sprop-interleaving-depthP-P
sprop-max-don-diffP-P
sprop-init-buf-timeP-P
max-mbpsRR-
max-smbpsRR-
max-fsRR-
max-cpbRR-
max-dpbRR-
max-brRR-
redundant-pic-capRR-
deint-buf-capRR-
max-rcmd-nalu-sizeRR-
sar-understoodRR-
sar-supportedRR-
in-band-parameter-setsRR-
use-level-src-parameter-setsRR-
level-asymmetry-allowedO--
sprop-parameter-setsS-S
sprop-level-parameter-setsS-S

Legende: C Konfiguration Senden/Empfangen; O Offer/Answer; P Stromeigenschaften; R Empfangsfähigkeit; S außerbandige Parametersätze; - nicht verwendbar (SOLLTEN ignoriert werden).

Empfangsfähigkeiten sind typischerweise nach unten anpassbar (Obergrenze). Konfigurationspunkte sind unveränderlich außer Level-Teil von profile-level-id im Unicast.

Nicht abwärts-kompatibel deklarierte Senderfähigkeiten beschreiben akzeptable Empfangskonfiguration. Mehrere Alternativen (z. B. Packetization) erfordern jeweils eigenen Payload-Typ.

Ein Empfänger SOLL alle Medientyp-Parameter verstehen, auch wenn er nur eine Teilmenge nutzt.

Ein Antwortender KANN das Angebot erweitern; oft ist ein zweites Angebot nötig, um Stromeigenschaften zu liefern, und der Anbietende muss dann auch empfangen können.

Asymmetrie: level-asymmetry-allowed=1 oder getrennte recvonly/sendonly-Medienzeilen (mit externer Semantik zur Verknüpfung).

Letztes Update am