4. SDP 定義
本節はセッションを記述するための追加 SDP パラメータを定義する. いずれもメディアレベル属性として定義される.
4.1. プロファイル識別
[4] で定義される AV プロファイルは, Session Description Protocol (SDP) [3] などの文脈では「AVP」と呼ばれる. 本ドキュメントで指定するプロファイルは「AVPF」と呼ばれる.
本ドキュメントで指定する変更後タイミング規則に従うフィードバック情報は, 当該メディアセッションの記述が「AVPF」プロファイルの使用を示さない限り (単独または他の AV プロファイルと併用), そのメディアセッションに対して送ってはならない (MUST NOT).
4.2. RTCP フィードバック能力属性
本ドキュメントで指定する RTCP フィードバックの使用能力を示すため, ペイロード形式固有の新しい SDP 属性 a=rtcp-fb を定義する. rtcp-fb 属性は SDP メディア属性としてのみ用いなければならず (MUST), セッションレベルでは提供してはならない (MUST NOT). rtcp-fb 属性は「AVPF」が指定されたメディアセッションにのみ用いなければならない (MUST).
rtcp-fb 属性は, 示されたペイロードタイプについて当該メディアセッションで用いてよい (MAY) RTCP FB メッセージを示すために用いることが望ましい (SHOULD). ワイルドカードペイロードタイプ (*) は, 属性がすべてのペイロードタイプに適用されることを示すために用いてよい (MAY). 複数のフィードバック種別を支持する場合や, ペイロードタイプの部分集合に同じフィードバックを指定する場合は, 複数行の a=rtcp-fb を用いなければならない (MUST).
rtcp-fb 属性が指定されない場合, RTP 受信者は当該メディアタイプ向けに定義された他の適切な RTCP フィードバックパケットでフィードバックを送ってもよい (MAY). RTP 受信者は RTP 送信者がいずれかの FB メッセージに反応することを前提としてはならない (MUST NOT). RTP 送信者は一部のフィードバックメッセージを無視してもよい (MAY).
メディアセッション記述に 1 つ以上の rtcp-fb 属性が存在する場合, 当該 rtcp-fb を含むメディアセッションの RTCP 受信者は次を満たさなければならない:
-
a=rtcp-fb行のすべての値の意味を理解しない属性 (すなわちセマンティクスを完全に理解しない属性) は, すべて無視しなければならない (MUST); -
本ドキュメントで指定するとおり, 当該メディアセッションのいずれかの
rtcp-fb属性に指定された RTCP フィードバックパケットのいずれかを用いてフィードバック情報を提供することが望ましい (SHOULD); -
rtcp-fb属性行のいずれかに列挙されていない他の FB メッセージを用いてはならない (MUST NOT).
offer/answer モデル [8] と併用する場合, オファラはピアにこれらの AVPF 属性の集合を提示してもよい (MAY). アンサーラは, 理解しない属性および一般的に支持しないか当該メディアセッションで用いたくない属性を除去しなければならない (MUST). アンサーラはメディア記述にフィードバックパラメータを追加してはならず (MUST NOT), そのようなパラメータの値を変更してはならない (MUST NOT). アンサーはメディアセッションに拘束力を持ち, オファラとアンサーラはこの方法で交渉されたフィードバック機構のみを用いなければならない (MUST). オファラとアンサーラは, 交渉されたフィードバック機構の部分集合に限って RTCP FB メッセージを送ることを独立に決めてもよい (MAY) が, 受信時には交渉されたすべての FB 種別に適切に反応することが望ましい (SHOULD).
RTP 送信者はあらゆる種類の RTCP FB メッセージの受信に備えなければならず (MUST), 理解しない RTCP FB メッセージはすべて黙って破棄しなければならない (MUST).
rtcp-fb 属性の構文は次のとおり (フィードバック種別と任意パラメータはすべて大文字/小文字を区別する):
(以下の ABNF で fmt, SP, CRLF は [3] で定義されるとおり用いる.)
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
上記文法のリテラルの意味は次のとおり.
フィードバック種別 "ack":
肯定確認フィードバックが支持されることを示す.
"ack" は, メディアセッションがセクション 3.6.1 で定義する ACK モードで動作してよい場合にのみ用いなければならない (MUST).
肯定確認フィードバックの異なる種別を区別するため, パラメータを提供しなければならない (MUST).
パラメータ "rpsi" は, セクション 6.3.3 で定義する Reference Picture Selection Indication フィードバックの使用を示す.
パラメータ "app" が指定される場合, アプリケーション層フィードバックの使用を示す. この場合, "app" に続く追加パラメータでアプリケーション層フィードバックのさらなる区別に用いてもよい (MAY). 本ドキュメントは "app" 固有のパラメータを定義しない.
"ack" のさらなるパラメータは他の文書で定義してもよい (MAY).
フィードバック種別 "nack":
否定確認フィードバックが支持されることを示す.
パラメータなしの "nack" は, セクション 6.2.1 の Generic NACK フィードバック形式の使用を示す.
本ドキュメントではメディアタイプ "video" と併用する "nack" に対し次の 3 パラメータを定義する:
-
"pli": セクション 6.3.1 の Picture Loss Indication フィードバック.
-
"sli": セクション 6.3.2 の Slice Loss Indication フィードバック.
-
"rpsi": セクション 6.3.3 の Reference Picture Selection Indication フィードバック.
"app" はアプリケーション層フィードバックを示す. "app" の後に追加パラメータを付けてもよい (MAY). 本ドキュメントは "app" 固有パラメータを定義しない.
"nack" のさらなるパラメータは他の文書で定義してもよい (MAY).
その他のフィードバック種別 <rtcp-fb-id>:
他の文書は追加のフィードバック種別を定義してもよい (MAY). 文法を拡張するため rtcp-fb-id をプレースホルダとして導入する. 新しいフィードバックスキーム名は一意でなければならず (MUST), IANA に登録しなければならない (MUST). 名前とともにセマンティクス, 必要ならパケット形式, 運用規則を指定しなければならない (MUST).
Regular RTCP 最小間隔 "trr-int":
属性 "trr-int" は, 当該メディアセッションにおける 2 つの Regular (完全複合) RTCP パケット間の最小間隔 T_rr_interval をミリ秒で指定する. 指定がなければデフォルト 0 とみなす.
アプリケーション層フィードバック (セクション 6.4) についてより具体的な情報は, 別途定義されるフィードバック種別とパラメータで伝達されると想定される. したがって本ドキュメントではさらなる種別・パラメータの規定は行わない.
さらなるフィードバック種別およびパラメータは他の文書で定義されうる.
フィードバックを送るかどうかは受信者次第であり, フィードバックの利用方法は送信者次第である.
4.3. RTCP 帯域修飾子
[1] および [2] の標準 RTCP 帯域割当は, 最大 RTCP 帯域を明示的に定義する帯域修飾子で上書きしてもよい (MAY). SDP での使用は [4] で指定される: b=RS:<bw> および b=RR:<bw> はそれぞれ RTP 送信者と受信者に異なる帯域 (ビット毎秒) を割り当てるために用いてよい (MAY). 実際に用いる帯域は [4] の優先規則で決まる.
衛星リンクなど強い非対称リンク上で動作することが分かっているアプリケーションは, 高帯域ストリームのフィードバックレートを下げ, フィードバック経路の決定的な輻輳を防ぐためにこの機構を用いることが望ましい (SHOULD).
4.4. 例
例 1: 次のセッション記述は, ポイントツーポイント通信で音声と DTMF [18] から成り, DTMF ストリームが Generic NACK を用いる. SIP INVITE, 200 OK, または ACK に含まれ, 送信者が自ら送信する DTMF ストリームに対するフィードバックを受け取れる用意があることを示しうる.
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
64 kbit/s 音声で受信者 1 人なら, 否定確認ストリームに 2.5% の RTCP 帯域, すなわち毎秒約 250 バイトまたは約 2 件の RTCP フィードバックメッセージとなる. 受信者は毎秒最大 2 つの欠落 DTMF 音声パケットを個別に伝えられる.
例 2: 次は H.261 または H.263+ のマルチキャスト動画のみのセッションを示し, 動画ソースは両コーデックに対し Generic NACK を, H.263 に対し Reference Picture Selection を受け入れる. SAP などで伝達されうる.
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
例 3: 例 2 と同じメディアセッションだが AVP と AVPF の混合動作を許す (次節も参照). 両メディア記述は同一アドレスだが, 適用 RTP プロファイルの両方を伝えるには 2 本の m= 行が必要である.
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
この 2 本の m= 行は, 実質同じ内容の代替であることを示す適切な機構でグループ化することが望ましい (SHOULD). [10] にサンプル枠組みがある.
この例では, RTCP フィードバック対応受信者は時折, 送信者へより早く事象を報告できる利点を得うる (グループ全体に利益になりうる). しかし平均的には, すべての RTP 受信者は同量のフィードバックを提供する. AVP と AVPF 実体の相互運用は次節で詳述する.