メインコンテンツまでスキップ

6. SSRC の追加と削除

6.1. RTP ストリームの追加​

エンドポイントが新しい RTP ストリームを追加するとき（つまり、新しい SSRC の使用を開始するとき）：

  • 新しい SSRC のための RTCP パケットをできるだけ早く送信しなければなりません（MUST）
  • 初回の RTCP パケットには、CNAME を含む SDES パケットを含めるべきです（SHOULD）
  • 他の参加者は、これらの RTCP パケットから新しい SSRC について知ることになります
  • エンドポイントは、新しい SSRC がセッション内で一意であることを保証しなければなりません（MUST）

6.2. RTP ストリームの削除​

エンドポイントが SSRC の使用を停止するとき：

  • その SSRC のための BYE パケットを送信すべきです（SHOULD）
  • BYE パケットにより、他の参加者は自身のデータベースからその SSRC を迅速に削除できます
  • BYE が送信されない場合、他の参加者は最終的にその SSRC をタイムアウトさせます
  • BYE を送信した後、その SSRC は同じセッション内で再利用すべきではありません（SHOULD NOT）

7. パケットレートが大きく異なるストリームに対する RTCP の考慮事項

エンドポイントが非常に異なるパケットレートを持つ複数の RTP ストリームを送信する場合、特別な考慮事項が適用されます。

7.1. SSRC のタイムアウト​

7.1.1. RTP/AVPF の T_rr_interval パラメータの問題​

オリジナルの RTP/AVPF 仕様では、ストリームのレートが異なると SSRC のタイムアウトに問題がありました。T_rr_interval パラメータにより、低レートのストリームが途中でタイムアウトしてしまう可能性がありました。

7.1.2. 時期尚早なタイムアウトの回避​

時期尚早なタイムアウトを避けるために：

  • 受信者は、RTP パケットの欠如のみに基づいて SSRC をタイムアウトさせてはなりません（MUST NOT）
  • SSRC がまだアクティブかどうかを判断する際には、RTCP パケットを考慮しなければなりません（MUST）
  • タイムアウト期間は、RTP パケットレートではなく、RTCP レポーティング間隔に基づくべきです

7.1.3. RTP/AVP と RTP/AVPF 間の相互運用性​

RTP/AVP エンドポイントと RTP/AVPF エンドポイントが相互作用する場合：

  • 両者は互換性のあるタイムアウト規則を使用しなければなりません
  • より保守的なタイムアウト規則を適用すべきです
  • SSRC が時期尚早にタイムアウトしないよう注意を払う必要があります

7.1.4. 更新された SSRC タイムアウト規則​

本文書は、RFC 4585 を以下のタイムアウト規則で更新します。

以下の条件を満たす場合、SSRC は非アクティブと見なされ、参加者データベースから削除してもよい（MAY）ものとします。

  • その SSRC について、RTCP レポーティング間隔の5倍の期間、RTP または RTCP パケットが受信されていない場合
  • その SSRC について BYE パケットが受信された場合

タイムアウト計算に使用される RTCP レポーティング間隔は、以下の通りとします。

  • RTP/AVP の場合: セッション帯域幅に基づいて計算された間隔
  • RTP/AVPF の場合: T_rr_interval と計算された間隔のいずれか大きい方

7.2. RTCP 送信の調整​

7.2.1. RTP/AVP および RTP/SAVP​

RTP/AVP および RTP/SAVP プロファイルの場合：

  • RTCP 帯域幅は、エンドポイントからのすべての SSRC 間で共有されます
  • エンドポイントは、その SSRC 間で RTCP 帯域幅を公平に分配すべきです
  • 低レートのストリームも、タイムアウトを避けるために定期的に RTCP を送信すべきです

7.2.2. RTP/AVPF および RTP/SAVPF​

RTP/AVPF および RTP/SAVPF プロファイルの場合：

  • T_rr_interval パラメータは SSRC ごとに適用されます
  • 各 SSRC は、少なくとも T_rr_interval ごとに1回、定期的な RTCP パケットを送信しなければなりません
  • フィードバックメッセージは、プロファイルの制約内でより頻繁に送信できます

8. セキュリティに関する考慮事項

RTP [RFC3550] および RTP/AVPF [RFC4585] のセキュリティに関する考慮事項が適用されます。複数の SSRC を使用することによって新しいセキュリティ脆弱性が導入されることはありませんが、実装者は以下の点に注意する必要があります。

  • SSRC の衝突: 悪意のあるエンドポイントが意図的に SSRC の衝突を引き起こす可能性があります
  • リソースの枯渇: 攻撃者が多数の SSRC を作成して受信機のリソースを枯渇させる可能性があります
  • なりすまし: 適切な認証がない場合、攻撃者が SSRC を偽装する可能性があります

実装は以下を行うべきです（SHOULD）：

  • RTP および RTCP パケットを保護するために SRTP [RFC3711] を使用する
  • 単一のエンドポイントから受け入れる SSRC の数を制限する
  • RTCP CNAME およびその他のメカニズムを通じて SSRC の所有権を検証する

9. 引用文献

9.1. 規定引用文献​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3550] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
  • [RFC4585] Ott, J., et al., "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
  • [RFC3711] Baugher, M., et al., "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

9.2. 参考引用文献​

  • [RFC4588] Rey, J., et al., "RTP Retransmission Payload Format", RFC 4588, July 2006.
  • [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
  • [CLUE-FRAME] Duckworth, M., et al., "Framework for Telepresence Multi-Streams", Work in Progress, 2015.
  • [SDP-BUNDLE] Holmberg, C., et al., "Negotiating Media Multiplexing Using SDP", Work in Progress, 2016.
  • [MULTI-RTP] Westerlund, M., et al., "Multiple RTP Sessions on a Single Lower-Layer Transport", Work in Progress, 2016.
に最終更新