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

6. SSRC の追加と削除

単一の RTP セッション内に存在する SSRC の集合は、セッション内のエンドポイント数の変化、または送信される RTP ストリームの数や種類の変化によって、時間とともに変動しうる。

RTP セッション内のすべてのエンドポイントは、RTCP 報告に、および必要であればメディアの送信に使用する少なくとも 1 つの SSRC を持つ。また、追加のメディアソースを送信するため、または追加の RTCP 報告のために、追加の SSRC を持つこともできる。送信されるメディアソースの集合が変化すれば、送信される SSRC の集合も変化する。メディア形式やクロックレートの変化も、使用される SSRC の集合の変化を必要とすることがある。エンドポイントは、アクティブな RTP ストリームよりも多くの SSRC を持ち、現在 RTP データパケットを送信していない SSRC に関する RTCP を送信して、ピアがそれらの SSRC を認識し、それらがアクティブになり次第メディアを再生できるように関連するコンテキスト(例えば、クロック同期と SDES CNAME)を整えておくこともできる。

以下では、RTP ストリームとそれに関連する SSRC の追加および削除に関するいくつかの考慮事項について述べる。

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

エンドポイントが RTP セッションに参加するとき、送信する、または送信する用意がある RTP ストリームを 0 個、1 個、またはそれ以上持つことができる。送信する予定の RTP ストリームがない場合でも、RTCP フィードバックを送信するために使用する SSRC が依然として必要である。1 つ以上の RTP ストリームを送信する場合、対応する数の SSRC 値が必要になる。エンドポイントが使用する SSRC は、RTP および RTCP パケットを送信することによって、RTP セッション内の他のエンドポイントに知らされる。SSRC は、RTP 以外の手段(例えば [RFC5576])を使用してシグナリングすることもできる。シグナリングによって制限されない限り、エンドポイントはいつでも、新しい SSRC によって識別される追加の RTP ストリームを送信できる(これはシグナリングイベントに関連する可能性があるが、それは本書の範囲外である)。RTP セッションの定義に固有の単一の SSRC 空間を共有しているため、これにより新しい SSRC がセッション内の他のエンドポイントから可視になる。

これまでに RTP ストリームを送信したことがないエンドポイントは、RTCP 報告に使用する SSRC を持つ。そのエンドポイントが RTP ストリームの送信を開始したい場合、そのストリームに既存の SSRC を使用することが推奨される (RECOMMENDED)。そうしないと、RTP セッション内の参加者数が不必要に増加し、相互報告のために RTCP 報告間隔が長くなり、RTCP レポートが大きくなるからである。エンドポイントが複数の RTP ストリームの送信を開始したい場合、2 番目以降の RTP ストリームのために新しい SSRC を生成する必要がある。

以前に RTP ストリームの送信を停止したエンドポイントが新しい RTP ストリームの送信を開始したい場合、一般に既存の SSRC を再利用することはできず、しばしば新しい SSRC を生成する必要がある。なぜなら、SSRC はメディアタイプ(例えば音声から映像へ)や RTP タイムスタンプクロックレートを変更できないからであり [RFC7160]、また SSRC がアプリケーションによって特定の意味に関連付けられている可能性があるからである(注: RTP ストリームは、一時停止中にその SSRC の RTCP が送信される限り、同じ SSRC を使用して一時停止および再開できる。これらの規則は、既存の SSRC を再利用する新しい RTP ストリームにのみ適用される)。

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

SSRC は 2 つの方法のいずれかで RTP セッションから削除される。エンドポイントが SSRC を使用した RTP および RTCP パケットの送信を停止すると、その SSRC は最終的に [RFC3550] のセクション 6.3.5 で記述されているようにタイムアウトする。あるいは、SSRC は [RFC3550] のセクション 6.3.7 で記述されているように RTCP BYE パケットを送信することによって使用から明示的に削除できる。SSRC は RTCP BYE パケットを送信することによって使用から削除することが推奨される (RECOMMENDED)。[RFC3550] は、RTCP BYE が SSRC に対して RTP セッション内で送信される最後の RTP/RTCP パケットであるべきである (SHOULD) と要求していることに注意されたい。エンドポイントがその SSRC に対して RTCP BYE を送信した後に RTP ストリームを再開する必要がある場合、そのストリームのために新しい SSRC 値を生成する必要がある。

RTCP BYE の送信が最終的であるという性質は、エンドポイントが RTP ストリームの送信停止が一時的なものか恒久的なものかを考慮する必要があることを意味する。特定の RTP ストリーム (SSRC) を使用したメディア送信の一時的な中断では、その SSRC に対する RTCP 送信を継続することによって、その SSRC をアクティブな参加者として維持する必要がある。そうすれば、コンテキストが整っていることを確認した上で、メディア送信を即座に再開できる。恒久的に送信を停止する場合、参加者は RTCP BYE を送信して、他の参加者が RTCP 帯域幅リソースを使用し、状態データベースをクリーンアップできるようにする必要がある。

すべての RTP ストリームの送信を停止するが RTP セッションには留まるエンドポイントは、RTCP 報告およびフィードバックに使用される少なくとも 1 つの SSRC を維持しなければならない (MUST)(すなわち、すべての SSRC に対して BYE を送信することはできず、少なくとも 1 つのアクティブな SSRC を保持する必要がある)。一部のフィードバックパケットはメディアタイプに結び付けることができるため、RTP セッション内でメディアタイプごとに 1 つの SSRC を維持する必要があるかもしれない。代替案として、RTCP 報告およびフィードバックに使用する新しい SSRC を作成することもできる。しかし、エンドポイントが RTP セッションから完全に離脱したという認識を避けるために、そのような新しい SSRC は、すべての既存の SSRC を終了する前に、まず確立すべきである。