8.2.2. Usage with the SDP Offer/Answer Model (SDP Offer/Answer モデルでの使用)

8.2.2. Usage with the SDP Offer/Answer Model (SDP Offer/Answer モデルでの使用)

ユニキャスト用途で SDP を用いた Offer/Answer モデル [8] 上に RTP で H.264 を提示する場合, 次の制限と規則が適用される.

• H.264 のメディア形式構成を識別するパラメータは profile-level-id と packetization-mode である. これらのメディア形式構成パラメータ (profile-level-id の level 部分を除く) は対称に用いなければならない. すなわち応答者 (answerer) は, 1 つ以上のパラメータ値がサポートされない場合を除き, すべての構成パラメータを維持するか, メディア形式 (ペイロード型) を完全に削除しなければならない. profile-level-id の level 部分には level_idc が含まれ, profile_idc が 66, 77 または 88 のとき Level 1b を示すには profile-iop のビット 4 (constraint_set3_flag) も含まれる. profile-level-id の level 部分は変更可能である.

参考注: 対称使用の要件は profile-level-id の level 部分には適用されず, その他のストリーム属性および能力パラメータにも適用されない.

参考注: H.264 [1] では Level 1b を除くすべての level は level_idc を 10 で割った値に等しい. Level 1b は Level 1.0 より高く Level 1.1 より低く, Level 1.0 と Level 1.1 の後に規定されたため特別な方法で通知される. Baseline, Main, Extended プロファイル (profile_idc がそれぞれ 66, 77, 88) では, Level 1b は level_idc が 11 (Level 1.1 と同じ) かつ constraint_set3_flag が 1 で示される. その他のプロファイルでは level_idc が 9 で示される (ただしこれらプロファイルの Level 1b は依然 Level 1 より高く, Level 1 は level_idc が 10, Level 1.1 より低い). SDP Offer/Answer では, オファーに対するアンサーはオファーで示された level 以下を示してよい. Level 1b の特別な示し方のため, profile_idc が 66, 77 または 88 かつ level_idc が 11 のとき, オファー側と応答側はパラメータ profile-level-id の中央オクテットのビット 4 (constraint_set3_flag) を確認しなければならない.

これらの構成の取扱いと照合を簡素化するため, オファーで用いた RTP ペイロード型番号はアンサーでも用いるべきである [8]. アンサーは, オファーと構成が完全に同一でない限り, オファーで用いたペイロード型番号を含んではならない.

参考注: オファー側がアンサーを受け取ったら, オファーで宣言されていないペイロード型を, メディア型 (video/H264) および上記メディア構成パラメータに基づき, 既に宣言したペイロード型と比較する必要がある. これにより, 異なるペイロード型番号がアンサーに用いられていても, 当該構成が新規か既にオファーした構成と等価かを判断できる.

• 存在するとき, パラメータ max-recv-level は受信でサポートする最高 level を宣言する. max-recv-level がない場合, 受信でサポートする最高 level は profile-level-id の level 部分が示すデフォルト level に等しい. 存在するとき, max-recv-level はデフォルト level より高くなければならない.

• パラメータ level-asymmetry-allowed は level の非対称が許されるかを示す.

オファーまたはアンサーのいずれかで level-asymmetry-allowed が 0 (または欠落) の場合, level 非対称は許されない. この場合, オファー側から応答側への方向で用いる level は逆方向と同一でなければならず, 共通 level はオファーとアンサーのデフォルト level の小さい方に等しい.

それ以外では, オファーとアンサーの両方で level-asymmetry-allowed が 1 となり level 非対称が許される. この場合, オファー側→応答側方向の level は応答側が受信でサポートする最高 level に等しくなければならず, 応答側→オファー側方向の level はオファー側が受信でサポートする最高 level に等しくなければならない.

level 非対称が許されない場合, level のアップグレードは許されない. すなわちアンサーのデフォルト level はオファーのデフォルト level 以下でなければならない.

• パラメータ sprop-deint-buf-req, sprop-interleaving-depth, sprop-max-don-diff, sprop-init-buf-time は, オファー側または応答側が当該メディア形式構成で送信する RTP パケットストリームの属性を記述する. これは Offer/Answer パラメータの通常の用法と異なる. 通常そのようなパラメータは, オファー側または応答側が受信できるストリームの属性を宣言する. H.264 では, オファー側は応答側が提示された構成でエンコードされたメディアを受信できると仮定する.

参考注: 上記パラメータは, 宣言する実体が同一構成で送信する任意のストリームに適用される. すなわちソースに依存する. ペイロード型に束縛されるのではなく, 送信時に別のペイロード型へ適用し直す必要がある場合がある.

• 能力パラメータ max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br, redundant-pic-cap, max-rcmd-nalu-size, sar-understood, sar-supported は, オファー側または応答側の受信に関する追加能力を宣言するために用いてよい. 方向属性が sendonly であり, かつこれらのパラメータがオファー側または応答側が受信ストリームについて受け入れる制限を記述するとき, これらのパラメータを含んではならない.

• インターリーブされた H.264 ストリームについて, オファー側はオファーに去インターリーブバッファサイズ sprop-deint-buf-req を含めなければならない. オファー側と応答側が受信ストリームの去インターリーブバッファリング能力を相互に通知できるように, 両者に deint-buf-cap の含有を推奨する. インターリーブストリームでは, 受信側の能力が不明なとき, バッファ要件の異なる複数ペイロード型の提示も推奨される.

• 存在するとき (SDP の a=fmtp 行に含まれるか, [9] のセクション 6.3 に従い fmtp ソース属性で伝達される), sprop-parameter-sets または sprop-level-parameter-sets パラメータはパラメータセットの帯外搬送に用いられる. ただし帯外搬送を用いても, パラメータセットは帯内でも追加で搬送してよい.

応答側は, オファー側→応答側方向で帯外パラメータセット搬送が用いられたかにかかわらず, 自らが送信するストリームに帯外または帯内のいずれでもパラメータセットを用いてよい. アンサーに含まれるパラメータセットはオファーに含まれるものと独立である. 応答側→オファー側とその逆の 2 つの異なるビデオストリームをデコードするためである.

オファー側→応答側方向のパラメータセット搬送には次の規則が適用される.

• オファーは sprop-parameter-sets と sprop-level-parameter-sets のいずれか一方または両方を含んでもよい. オファーに両方ともない場合, パラメータセットは帯内のみで搬送される.

• アンサーに in-band-parameter-sets が 1 と等しい場合, オファー側はパラメータセットを帯内で伝送しなければならない. それ以外では次が適用される.

• オファー側→応答側方向で用いる level がオファーのデフォルト level と等しい場合:

  • オファーの a=fmtp 行に sprop-parameter-sets がある場合, 応答側は入局 NAL ユニットストリームをデコードするためにその中のパラメータセットを用いる準備をしなければならない.

  • オファーで fmtp ソース属性により sprop-parameter-sets が伝達される場合: アンサーに use-level-src-parameter-sets が 1 または fmtp ソース属性がある場合, 応答側はそのパラメータセットでデコードする準備をしなければならない. それ以外ではオファー側はパラメータセットを帯内で伝送しなければならない.

  • オファーに sprop-parameter-sets がない場合, オファー側はパラメータセットを帯内で伝送しなければならない.

  • 応答側はオファーに存在する sprop-level-parameter-sets (a=fmtp 行または fmtp ソース属性のいずれか) を無視しなければならない.

• それ以外, オファー側→応答側方向の level がオファーのデフォルト level と異なる場合:

  • 応答側はオファーに存在する sprop-parameter-sets を無視しなければならない.

  • アンサーに use-level-src-parameter-sets が 1 でも fmtp ソース属性もない場合, 応答側はオファーの sprop-level-parameter-sets を無視し, オファー側はパラメータセットを帯内で伝送しなければならない.

  • アンサーに use-level-src-parameter-sets が 1 または fmtp ソース属性がある場合, 応答側はオファーの sprop-level-parameter-sets のうち受理した level (アンサーのデフォルト level) に対応するパラメータセットでデコードする準備をし, それ以外のパラメータセットは無視しなければならない.

  • オファーの sprop-level-parameter-sets に, オファー側→応答側方向の level 用のパラメータセットがない場合, オファー側はパラメータセットを帯内で伝送しなければならない.

応答側→オファー側方向のパラメータセット搬送には次の規則が適用される.

• アンサーは sprop-parameter-sets または sprop-level-parameter-sets のいずれか一方を含んでもよいが, 両方を含んではならない. アンサーに両方ともない場合, 帯内のみで搬送される.

• オファーに in-band-parameter-sets が 1 と等しい場合, 応答側はアンサーに sprop-parameter-sets または sprop-level-parameter-sets を含めてはならず, パラメータセットを帯内で伝送しなければならない. それ以外では次が適用される.

• 応答側→オファー側方向の level がアンサーのデフォルト level と等しい場合:

  • アンサーの a=fmtp 行に sprop-parameter-sets がある場合, オファー側はそのパラメータセットで入局ストリームをデコードする準備をしなければならない.

  • アンサーで fmtp ソース属性により sprop-parameter-sets が伝達される場合: オファーに use-level-src-parameter-sets が 1 または fmtp ソース属性がある場合, オファー側はそのパラメータセットでデコードする準備をしなければならない. それ以外では応答側はパラメータセットを帯内で伝送しなければならない.

  • アンサーに sprop-parameter-sets がない場合, 応答側はパラメータセットを帯内で伝送しなければならない.

  • オファー側はアンサーに存在する sprop-level-parameter-sets を無視しなければならない.

• それ以外, 応答側→オファー側方向の level がアンサーのデフォルト level と異なる場合:

  • オファー側はアンサーに存在する sprop-parameter-sets (SDP の a=fmtp または fmtp ソース属性) を無視しなければならない.

  • オファーに use-level-src-parameter-sets が 1 でも fmtp ソース属性もない場合, オファー側はアンサーの sprop-level-parameter-sets を無視し, 応答側はパラメータセットを帯内で伝送しなければならない.

  • オファーに use-level-src-parameter-sets が 1 または fmtp ソース属性がある場合, オファー側はアンサーの sprop-level-parameter-sets のうち応答側→オファー側方向の level に対応するパラメータセットでデコードする準備をし, それ以外は無視しなければならない.

  • アンサーの sprop-level-parameter-sets に当該方向の level 用のパラメータセットがない場合, 応答側はパラメータセットを帯内で伝送しなければならない.

[9] のセクション 6.3 に従い fmtp ソース属性で sprop-parameter-sets または sprop-level-parameter-sets が伝達される場合, パラメータの受信者は受理した level に対応するパラメータセットを格納し, fmtp ソース属性の一部として与えられたソースと関連付けなければならない. あるソースに関連付けられたパラメータセットは, 同一ソースからの RTP パケット内の NAL ユニットのデコードにのみ用いなければならない. この機構を用いる場合, SSRC の衝突検出と解決は [9] に従わなければならない.

参考注: fmtp ソース属性による sprop-parameter-sets および sprop-level-parameter-sets の伝達は, Topo-Video-switch-MCU [29] などのトポロジでパラメータセットの帯外搬送を可能にするために用いられる.

マルチキャストで配信されるストリームには次の規則が適用される.

• メディア形式構成は profile-level-id (level 部分を含む) と packetization-mode で識別される. これらのメディア形式構成パラメータ (profile-level-id の level 部分を含む) は対称に用いなければならない. すなわち応答側はすべての構成パラメータを維持するか, メディア形式を完全に削除しなければならない. マルチキャストでは Offer/Answer における profile-level-id の level 部分は変更できない.

• 処理と照合を簡素化するため, オファーで用いた RTP ペイロード型番号はアンサーでも用いるべきである [8]. 構成がオファーと同一でない限り, アンサーはオファーで用いたペイロード型番号を含んではならない.

• 受信したパラメータセットは発信ソースと関連付けられ, 同一ソースからの入局 NAL ユニットストリームのデコードにのみ用いなければならない.

• 上記を守る限り, その他のパラメータの規則はユニキャストと同じである.

表 6 は, 方向属性ごとにすべてのメディアタイプパラメータをどう解釈しなければならないかを示す.

表 6. 方向属性ごとのパラメータの解釈

パラメータ	sendrecv	recvonly	sendonly
profile-level-id	C	C	P
max-recv-level	R	R	-
packetization-mode	C	C	P
sprop-deint-buf-req	P	-	P
sprop-interleaving-depth	P	-	P
sprop-max-don-diff	P	-	P
sprop-init-buf-time	P	-	P
max-mbps	R	R	-
max-smbps	R	R	-
max-fs	R	R	-
max-cpb	R	R	-
max-dpb	R	R	-
max-br	R	R	-
redundant-pic-cap	R	R	-
deint-buf-cap	R	R	-
max-rcmd-nalu-size	R	R	-
sar-understood	R	R	-
sar-supported	R	R	-
in-band-parameter-sets	R	R	-
use-level-src-parameter-sets	R	R	-
level-asymmetry-allowed	O	-	-
sprop-parameter-sets	S	-	S
sprop-level-parameter-sets	S	-	S

凡例:

• C: 送受信ストリームの構成
• O: offer/answer モード
• P: 送信されるストリームの属性
• R: 受信側の能力
• S: 帯外パラメータセット
• -: 使用不可 (存在する場合は無視すべき)

受信側能力を宣言するパラメータは一般にダウングレード可能であり, 送信側の可能な動作の上限を表す. したがって送信側は, これらのパラメータのより低いまたは等しい値だけでエンコーダを設定してもよい.

構成点を宣言するパラメータは変更できない. 例外はユニキャスト用途における profile-level-id の level 部分である.

送信側の能力が宣言され, かつダウングレード不可のパラメータがその宣言に用いられる場合, それらは送信側が受信ストリームについて受け入れ可能な構成を表す. 相互運用性を高めるには, パケット化モードなど複数の代替構成を提示することが望ましい. 単一ペイロード型では複数構成を提示できない. したがって複数の構成オファーには, それぞれに対応する RTP ペイロード型が必要である.

受信側はペイロード形式の機能の一部しかサポートしなくても, すべてのメディアタイプパラメータを理解すべきである. これにより, 受信メディアのオファーが受信側のサポート範囲にダウングレードされうるかを把握できる.

応答側は追加のメディア形式構成でオファーを拡張してもよい. しかし利用を可能にするには, 多くの場合メディア送信側が用いるストリーム属性パラメータをオファー側が再オファーする必要がある. その結果, オファー側は当該メディア形式構成を送信だけでなく受信できなければならない.

オファー側が送受信で非対称な能力にしたい場合, level-asymmetry-allowed を 1 にして level の非対称を許可できる. または recvonly と sendonly と宣言した別々のメディア行で異なる RTP セッションを提示してもよい. これはシステムにさらなる影響を与え, 2 行を関連付ける外部意味が必要になる場合がある.