10. 実装例 (Implementation Examples)

本ドキュメントが義務付けるのは相互運用に必要な送信者および受信者の振る舞いのみである. 加えて, 特定環境を対象としたレート制御やバッファ管理などのあるアルゴリズムは, 再送の効率を高めうる.

本節は, 本仕様の範囲で許される異なる実装オプションの概観を示す.

最初の例は最小限の受信者実装を述べる. この実装では, 失われた RTP パケットの再送, 再送の損失の効率的な検出, 必要に応じた複数回再送が可能である. 必要な処理のほとんどはサーバ側で行われる.

2 番目の例は, (小規模な) マルチキャストグループでレイヤード符号化と組み合わせて再送を用いる方法を示す. 再送とレイヤード符号化は補完的な手法になりうることを示す.

10.1. 最小受信者実装の例

本節は複数回再送を支援する実装の例を示す. 送信者は MPEG-4 動画 RTP ペイロード形式を用いてオリジナルデータを RTP パケットで送信する. NACK フィードバックメッセージが [1] に従って用いられると仮定する. SSRC 多重化の SDP 記述例を以下に示す.

v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000

形式固有パラメータ "rtx-time" は, サーバが送信パケットを 3.0 秒間再送バッファに保持し, その後は再送バッファから削除され再び送られないことを示す.

本実装例では, 再送を扱うために必要な RTP 受信者処理を最小限に抑える. 受信者は受信シーケンス番号に観測されたギャップからパケット損失を検出する. AVPF プロファイル [1] で定義されるとおり NACK により送信者に失われたパケットを通知する. 受信者は, 自身の受信バッファの寸法を決めるにあたり, 通知された送信者再送バッファ長を考慮すべきである. またバッファ長から, パケットの再送を最大何回要求できるかを導出すべきである.

送信者は選択的にパケットを再送すべきである, すなわちパケットの重要度, 受信者へのネットワーク接続の観測サービス品質 (QoS), および輻輳状態に応じて要求されたパケットを再送するか選ぶべきである. 明らかに, 受信者数が増えると送信者の処理は, 各受信者に状態情報と処理負荷を割り当てる必要があるため増加する.

10.2. マルチキャストにおけるレイヤード符号化メディアの再送

本節はマルチキャストセッションで再送をレイヤード符号化と組み合わせる方法を示す. 再送の枠組みは小規模マルチキャストアプリケーションにのみ提供されることに注意. 大規模グループの信頼性マルチキャストにおける NACK インプロージョンやフィードバックトラフィックによる深刻な輻輳などの問題については RFC 2887 [10] を参照.

重要度の異なるパケットは異なる RTP セッションで送られる. 異なるレイヤに対応する再送ストリーム自体, 異なる再送レイヤと見なせる. 異なる再送ストリームの相対的重要度は, 異なるオリジナルストリームの相対的重要度を反映すべきである.

マルチキャストでは, 本ドキュメントの 5.3 節に従い, オリジナルと再送ストリームの SSRC 多重化は許されない. この理由から, 再送ストリームは MUST でセッション多重化を用いて異なる RTP セッションで送られなければならない.

レイヤード符号化メディアのマルチキャスト再送の SDP 記述例を以下に示す.

m=video 8000 RTP/AVPF 98
c=IN IP4 224.2.1.0/127/3
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
m=video 8000 RTP/AVPF 99
c=IN IP4 224.2.1.3/127/3
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000

サーバと受信者は前の例で示した再送方式を実装してよい. 加えて, パケットが属するレイヤに応じて失われたパケットの要求および再送を選んでもよい.