RFC 3550 - 8. SSRC 識別子の割り当てと利用

8. SSRC 識別子の割り当てと利用 (SSRC Identifier Allocation and Use)

RTP ヘッダおよび RTCP パケットの様々なフィールドに担持される SSRC 識別子は、32 ビットのランダム数であり、RTP セッション内でグローバルに一意であることが求められる。同じネットワーク上の参加者や同時に開始する参加者が同じ数を選びそうにならないよう、この数は注意深く選ばれなければならない。

識別子としてローカルネットワークアドレス（IPv4 アドレスなど）を用いるだけでは不十分である。アドレスは一意でない可能性があるからである。RTP トランスレータおよびミキサは異なるアドレス空間を持つ複数のネットワーク間の相互運用を可能にするため、2 つの空間内でのアドレスの割り当てパターンは、ランダム割り当ての場合よりはるかに高い衝突率をもたらし得る。

1 台のホストで動作する複数の送信元も衝突する。

状態を注意深く初期化せずに単に random() を呼び出すことで SSRC 識別子を得るだけでも不十分である。ランダム識別子を生成する方法の例は付録 A.6 にある。

8.1 衝突の確率 (Probability of Collision)

識別子はランダムに選ばれるため、2 つ以上の送信元が同じ数を選ぶ可能性がある。衝突は、すべての送信元が同時に開始される、たとえば何らかのセッション管理イベントにより自動的にトリガされる場合に最も高い確率で生じる。N を送信元数、L を識別子長（ここでは 32 ビット）とすると、2 つの送信元が独立に同じ値を選ぶ確率は、N が大きい場合 [26] について 1 - exp(-N2 / 2(L+1)) と近似できる。N=1000 の場合、確率は概ね 10**-4 である。

典型的な衝突確率は上記の最悪の場合よりはるかに低い。新たな送信元が、他のすべての送信元がすでに一意の識別子を持つ RTP セッションに参加する場合、衝突の確率は単に空間中使用された数の割合である。再び、N を送信元数、L を識別子長とすると、衝突確率は N / 2L である。N=1000 の場合、確率は概ね 2*10-7 である。

衝突の確率は、新たな送信元が最初のパケット（データまたは制御のいずれか）を送信する前に他の参加者からパケットを受信する機会によってさらに低減される。新たな送信元が他の参加者を（SSRC 識別子により）追跡していれば、最初のパケットを送信する前に、自らの識別子が受信済みのいずれとも衝突しないことを確認できる。さもなければ再度選択する。

8.2 衝突解決とループ検出 (Collision Resolution and Loop Detection)

SSRC 識別子衝突の確率は低いが、すべての RTP 実装は衝突を検出しそれを解決するための適切な処置をとる用意をしていなければならない (MUST)。送信元がいかなる時点でも別の送信元が自らのものと同じ SSRC 識別子を用いていることを発見した場合、その送信元は古い識別子について RTCP BYE パケットを送信し、別のランダムなものを選ばなければならない (MUST)。（以下で説明するように、このステップはループの場合に限り 1 回のみ実行される。）受信側が 2 つの他の送信元が衝突していることを発見した場合、異なる送信元トランスポートアドレスや CNAME によって検出できるときは、一方からのパケットを保持し他方からのパケットを破棄してよい (MAY)。2 つの送信元は状況が継続しないよう衝突を解決することが期待される。

ランダムな SSRC 識別子は各 RTP セッションでグローバルに一意に保たれるため、ミキサやトランスレータにより生じ得るループを検出するためにも用いられる。ループは、以下の例のように、無改変またはおそらく混合されたデータおよび制御情報の重複をもたらす。

o トランスレータが、直接あるいはトランスレータの連鎖を通じて、受信したパケットと同じマルチキャストグループへ誤ってパケットを転送する場合。その場合、同じパケットが異なるネットワーク送信元を発信元として複数回現れる。

o 2 つのトランスレータが並列に誤って設定された、すなわち両側で同じマルチキャストグループを持つ場合、双方が一方のマルチキャストグループから他方へパケットを転送する。単方向トランスレータは 2 つのコピーを生成し、双方向トランスレータはループを形成する。

o ミキサは、パケットを受信するのと同じトランスポート宛先へ（直接あるいは別のミキサやトランスレータを通じて）送信することでループを閉じ得る。この場合、ある送信元がデータパケットの SSRC として、また混合データパケットの CSRC として両方に現れ得る。

送信元は自らのパケットがループしていること、または別の送信元からのパケットがループしていること（第三者ループ）を発見し得る。ランダム選択された送信元識別子でのループおよび衝突の両方は、同じ SSRC 識別子だが異なる送信元トランスポートアドレスを持つパケットの到着をもたらす。そのアドレスはパケットを発信したエンドシステムのもの、あるいは中間システムのものであり得る。

したがって、送信元が信じるソーストランスポートアドレスを変更した場合、ループした送信元として解釈されるのを避けるため、新たな SSRC 識別子を選んでもよい (MAY)。（これは MUST ではない。なぜなら RTP の一部のアプリケーションでは、送信元はセッション中にアドレスを変更すると予想されるためである。）トランスレータが再起動し、結果としてパケットを転送するソーストランスポートアドレス（UDP ソースポート番号の変更など）を変更した場合、SSRC 識別子は元の送信元により適用され変更されないため、受信側にはそれらのパケットすべてがループしたように見えることに注意。この問題は再起動を通じてソーストランスポートアドレスを固定しておくことで回避できるが、いずれにせよ受信側のタイムアウト後に解決される。

トランスレータまたはミキサの向こう側で生じるループや衝突は、すべてのパケットのコピーがトランスレータまたはミキサを通過する場合、ソーストランスポートアドレスを用いて検出できない。しかし衝突は、2 つの RTCP SDES パケットのチャンクが同じ SSRC 識別子だが異なる CNAME を含むときに検出され得る。

これらの競合を検出し解決するため、RTP 実装は以下で説明するものと類似のアルゴリズムを含まなければならない (MUST)。ただし実装は、衝突する第三者送信元からのどのパケットを保持するかについて異なる方針を選んでもよい (MAY)。以下で説明するアルゴリズムは、確立された送信元と衝突する新たな送信元やループからのパケットを無視する。それは、参加者自身の SSRC 識別子との衝突を、古い識別子について RTCP BYE を送信し新しいものを選ぶことで解決する。しかし衝突が参加者自身のパケットのループにより生じた場合、アルゴリズムは新たな識別子を 1 回のみ選び、それ以降はループするソーストランスポートアドレスからのパケットを無視する。これは BYE パケットの氾濫を避けるために必要である。

このアルゴリズムは、送信元識別子で索引付けられ、その識別子で受信した最初の RTP パケットおよび最初の RTCP パケットのソーストランスポートアドレスと、その送信元の他の状態を含む表を保持することを要する。2 つのソーストランスポートアドレスが必要なのは、たとえば UDP ソースポート番号が RTP パケットと RTCP パケットで異なり得るためである。しかし、両ソーストランスポートアドレスでネットワークアドレスは同じであると仮定してよい。

RTP または RTCP パケットで受信された各 SSRC または CSRC 識別子は、そのデータまたは制御情報を処理するため、送信元識別子表で検索される。パケットのソーストランスポートアドレスは、一致しない場合にループまたは衝突を検出するため、表内の対応するソーストランスポートアドレスと比較される。制御パケットについては、自身の SSRC 識別子を持つ各要素、たとえば SDES チャンクは個別の検索を要する。（受信報告ブロック内の SSRC 識別子は例外である。なぜならそれは報告者が聞いた送信元を識別し、その SSRC 識別子は報告者が送信した RTCP パケットのソーストランスポートアドレスとは無関係だからである。）SSRC または CSRC が見つからない場合、新たなエントリが作成される。これらの表エントリは、対応する SSRC 識別子を持つ RTCP BYE パケットが一致するソーストランスポートアドレスで受信されたとき、あるいは比較的長い間パケットが到着しなくなったとき（セクション 6.2.1 参照）に削除される。

受信側の動作開始時に同じホスト上の 2 つの送信元が同じ送信元識別子で送信している場合、受信した最初の RTP パケットが一方の送信元から、受信した最初の RTCP パケットが他方から来る可能性があることに注意。これにより誤った RTCP 情報が RTP データと関連付けられるが、この状況は十分に稀であり無害であるため無視してよい。

参加者自身のデータパケットのループを追跡するため、実装は競合していると判明したソーストランスポートアドレス（識別子ではない）の別リストを保持しなければならない (MUST)。送信元識別子表と同様、競合する RTP および RTCP パケットを別個に追跡するため 2 つのソーストランスポートアドレスを保持しなければならない (MUST)。競合アドレスリストは短く、通常は空であることに注意。このリストの各要素はソースアドレスに加え、最後に競合パケットを受信した時刻を格納する。あるソースから競合パケットが約 10 の RTCP 報告間隔（セクション 6.2 参照）の間到着しなくなったとき、要素はリストから削除されてよい (MAY)。

示されるアルゴリズムでは、参加者自身の送信元識別子および状態が送信元識別子表に含まれていると仮定される。アルゴリズムは、参加者自身の送信元識別子に対する別個の比較を最初に行うよう再構成されてもよい (MAY)。

  if (SSRC または CSRC 識別子が送信元識別子表に見つからない) {
      data または control のソーストランスポートアドレス、
          SSRC または CSRC および他の状態を格納する新エントリを作成;
  }

  /* 識別子は表に見つかった */

  else if (表エントリが制御パケットの受信で作成され、
           かつ今回が最初のデータパケット、あるいはその逆) {
      このパケットのソーストランスポートアドレスを格納;
  }
  else if (パケットのソーストランスポートアドレスが
           この識別子に対する表エントリに保存されたものと一致しない) {

      /* 識別子衝突またはループが示される */

      if (送信元識別子が参加者自身のものではない) {
          /* 任意のエラーカウンタステップ */
          if (送信元識別子が CNAME 項を含む RTCP SDES チャンクからで、
              その CNAME が表エントリの CNAME と異なる) {
              第三者衝突をカウント;
          } else {
              第三者ループをカウント;
          }
          data パケットまたは control 要素の処理を中止;
          /* 新送信元を保持する別の方針を選んでもよい */
      }

      /* 参加者自身のパケットの衝突またはループ */

      else if (ソーストランスポートアドレスが競合 data または
               control ソーストランスポートアドレスリストに見つかる) {
          /* 任意のエラーカウンタステップ */
          if (送信元識別子が CNAME 項を含む RTCP SDES チャンクからでなく、
              または CNAME が参加者自身のもの) {
              自身のトラフィックがループした発生をカウント;
          }
          競合アドレスリストエントリに現在時刻をマーク;
          data パケットまたは control 要素の処理を中止;
      }

      /* 新たな衝突、SSRC 識別子を変更 */

      else {
          衝突の発生を記録;
          競合 data または control ソーストランスポートアドレスリストに
              新エントリを作成し現在時刻をマーク;
          古い SSRC 識別子で RTCP BYE パケットを送信;
          新たな SSRC 識別子を選択;
          処理中の data または control パケットのソーストランスポート
              アドレスを古い SSRC とともに送信元識別子表に新エントリとして作成;
      }
  }

このアルゴリズムでは、新たに競導する送信元アドレスからのパケットは無視され、元の送信元アドレスからのパケットは保持される。元の送信元から長期間パケットが到着しなければ、表エントリはタイムアウトし、新たな送信元が引き継げる。これは元の送信元が衝突を検出し新たな送信元識別子へ移動した場合に生じ得るが、通常の場合は元の送信元から RTCP BYE パケットを受信し、タイムアウトを待たずに状態を削除する。

元の送信元アドレスがミキサを通じて受信された（すなわち CSRC として学習された）もので、後に同じ送信元が直接受信された場合、混合内の他の送信元が失われない限り、受信側は新たな送信元アドレスへ切り替えることが推奨される。さらに、移動体のような一部の送信元が RTP セッション中にアドレスを変更し得る電話のようなアプリケーションでは、RTP 実装は新たな送信元トランスポートアドレスからのパケットを受け入れるよう衝突検出アルゴリズムを修正すべきである (SHOULD)。真の衝突が生じた場合のアドレス間の揺り戻しを防ぐため、アルゴリズムはこの場合を検出し切り替えを避ける手段を含むべきである (SHOULD)。

衝突により新たな SSRC 識別子が選ばれた場合、候補識別子はまず送信元識別子表で検索され、他の送信元によりすでに使用されていないか確認されるべきである (SHOULD)。そうである場合、別の候補を生成しなければならず (MUST)、手順を繰り返す。

マルチキャスト宛先へのデータパケットのループは深刻なネットワーク洪水をもたらし得る。すべてのミキサおよびトランスレータは、ループを断ち切れるよう、ここにあるものと類似のループ検出アルゴリズムを実装しなければならない (MUST)。これは過剰トラフィックを元のトラフィックの 1 つの重複コピー以下に制限すべきであり、それによりループの原因を発見し修正できるようセッションを継続できる可能性がある。しかし、ミキサまたはトランスレータがループを適切に断ち切らず高いトラフィックレベルとなる極端な場合、エンドシステムがデータまたは制御パケットの送信を完全に停止する必要があるかもしれない。この決定はアプリケーションに依存し得る。適切にエラー状態が示されるべきである (SHOULD)。送信は長いランダムな時間（分のオーダー）の後に定期的に再試行されてよい (MAY)。

8.3 階層的符号化での利用 (Use with Layered Encodings)

別々の RTP セッションで伝送される階層的符号化（セクション 2.4 参照）については、単一の SSRC 識別子空間をすべての層のセッションで用いるべきであり (SHOULD)、コア（ベース）層を SSRC 識別子の割り当ておよび衝突解決に用いるべきである (SHOULD)。送信元が衝突したことを発見した場合、ベース層のみで RTCP BYE パケットを送信するが、すべての層で SSRC 識別子を新たな値へ変更する。