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

RFC 3550 - 7. RTP トランスレータとミキサ

7. RTP トランスレータとミキサ (RTP Translators and Mixers)​

エンドシステムに加え、RTP は RTP レベルでの「中間システム」とみなされ得る「トランスレータ (translators)」および「ミキサ (mixers)」の概念をサポートする。このサポートはプロトコルにある程度の複雑さを加えるが、これらの機能の必要性はインターネットでのマルチキャスト音声および映像アプリケーションの実験によって明確に確立されている。トランスレータおよびミキサの利用例（セクション 2.3）はファイアウォールや低帯域接続の存在に由来し、いずれも残存し続ける可能性が高い。

7.1 概説 (General Description)​

RTP トランスレータ／ミキサは 2 つ以上のトランスポートレベル「クラウド (cloud)」を接続する。典型的には、各クラウドは共通のネットワークおよびトランスポートプロトコル（IP/UDP など）に加え、マルチキャストアドレスとトランスポートレベル宛先ポート、あるいは 1 組のユニキャストアドレスとポートによって定義される。（IP バージョン 4 から IP バージョン 6 へのようなネットワークレベルのプロトコルトランスレータは、RTP には不可視にクラウド内に存在し得る。）1 つのシステムは複数の RTP セッションに対するトランスレータまたはミキサとして働き得るが、それぞれは論理的に別個の実体とみなされる。

トランスレータまたはミキサの設置時にループが生じるのを避けるため、以下の規則を守らなければならない (MUST)。

o トランスレータおよびミキサにより接続されるクラウドのうち、1 つの RTP セッションに参加するすべてのクラウドは、これらのパラメータ（プロトコル、アドレス、ポート）の少なくとも 1 つで他のすべてと異なるか、さもなければネットワークレベルで他から隔離されていなければならない (MUST)。

o 最初の規則の派生として、複数のトランスレータまたはミキサが並列に接続されてはならない (MUST NOT)。ただし、何らかの取り決めにより転送すべき送信元の集合を分割する場合を除く。

同様に、1 つ以上の RTP トランスレータまたはミキサを通じて通信できるすべての RTP エンドシステムは同じ SSRC 空間を共有する。すなわち SSRC 識別子はこれらすべてのエンドシステム間で一意でなければならない (MUST)。セクション 8.2 は SSRC 識別子を一意に保ちループを検出する衝突解決アルゴリズムを記述する。

異なる目的およびアプリケーション向けに設計されたトランスレータおよびミキサには多くの種類があり得る。例として、暗号化の追加または除去、データや下位プロトコルの符号化変更、マルチキャストアドレスと 1 つ以上のユニキャストアドレス間の複製などがある。トランスレータとミキサの違いは、トランスレータが異なる送信元からのデータストリームを別々に通過させるのに対し、ミキサはそれらを結合して 1 つの新たなストリームを形成することである。

トランスレータ (Translator)：SSRC 識別子をそのままに RTP パケットを転送する。これにより、すべての送信元からのパケットが同じトランスレータを通過しトランスレータのネットワーク送信元アドレスを担持していても、受信側は個々の送信元を識別できる。ある種のトランスレータはデータを無改変で通過させるが、他のものはデータの符号化、ひいては RTP データペイロード種別およびタイムスタンプを変更してよい (MAY)。複数のデータパケットが 1 つに再符号化される、あるいはその逆が行われる場合、トランスレータは送信パケットに新たなシーケンス番号を割り当てなければならない (MUST)。入力パケットストリームの欠落は出力シーケンス番号に相当する隙間を生じ得る。受信側は、元の送信元がどのペイロード種別またはトランスポートアドレスを用いたかを他の手段で知らなければ、トランスレータの存在を検出できない。

ミキサ (Mixer)：1 つ以上の送信元からの RTP データパケットストリームを受信し、おそらくデータ形式を変更し、何らかの方法でストリームを結合したうえで結合ストリームを転送する。複数の入力送信元間のタイミングは一般に同期していないため、ミキサはストリーム間でタイミング調整を行い結合ストリームに対する独自のタイミングを生成するので、それが同期送信元となる。したがって、ミキサにより転送されるすべてのデータパケットは、ミキサ自身の SSRC 識別子でマークされなければならない (MUST)。混合パケットに寄与した元の送信元の同一性を保持するため、ミキサはそれらの SSRC 識別子をパケットの固定 RTP ヘッダに続く CSRC 識別子リストに挿入すべきである (SHOULD)。あるパケットに対し自身も寄与送信元であるミキサは、そのパケットの CSRC リストに自らの SSRC 識別子を明示的に含めるべきである (SHOULD)。

  一部のアプリケーションでは、ミキサが CSRC リストで送信元を識別しないことも許容され得る (MAY)。しかしこれは、それらの送信元を含むループを検出できない危険をもたらす。

音声のようなアプリケーションにおいて、ミキサのトランスレータに対する利点は、入力側で複数の送信元が能動的であっても出力帯域幅が 1 つの送信元のそれに制限されることである。これは低帯域リンクで重要であり得る。欠点は、出力側の受信側がどの送信元を通過させるかあるいはミュートするかを制御できないことである（ミキサの遠隔制御の仕組みが実装されない限り）。ミキサによる同期情報の再生成は、受信側が元のストリームのメディア間同期を行えないことも意味する。マルチメディアミキサならそれが可能である。

     [E1]                                    [E6]
      |                                       |
E1:17 |                                 E6:15 |
      |                                       |   E6:15
      V  M1:48 (1,17)         M1:48 (1,17)    V   M1:48 (1,17)
     (M1)-------------><T1>-----------------><T2>-------------->[E7]
      ^                 ^     E4:47           ^   E4:47
 E2:1 |           E4:47 |                     |   M3:89 (64,45)
      |                 |                     |
     [E2]              [E4]     M3:89 (64,45) |
                                              |        legend:

[E3] --------->(M2)----------->(M3)------------| [End system] E3:64 M2:12 (64) ^ (Mixer) | E5:45 | [E5] source: SSRC (CSRCs) ------------------->

   図 3: エンドシステム、ミキサ、トランスレータを含む RTP ネットワークの例

ミキサおよびトランスレータの集まりを図 3 に示し、SSRC および CSRC 識別子への影響を説明する。図では、エンドシステムは長方形（E と名付け）、トランスレータは三角形（T と名付け）、ミキサは楕円（M と名付け）で示される。表記 "M1:48(1,17)" は、ミキサ M1 を発信元とするパケットを指し、M1 の（ランダムな）SSRC 値 48 と、E1 および E2 からのパケットの SSRC 識別子をコピーした 2 つの CSRC 識別子 1 および 17 によって識別される。

7.2 トランスレータにおける RTCP 処理 (RTCP Processing in Translators)​

データパケットの転送（おそらく変更あり）に加え、トランスレータおよびミキサは RTCP パケットも処理しなければならない (MUST)。多くの場合、彼らはエンドシステムから受信した複合 RTCP パケットを分解し、SDES 情報を集約し、SR または RR パケットを修正する。この情報の再送信は、パケット到着時、またはトランスレータないしミキサ自身の RTCP 間隔タイマによって引き起こされてよい (MAY)。

データパケットを変更しないトランスレータ、たとえばマルチキャストアドレスとユニキャストアドレス間で単に複製するものは、RTCP パケットもそのまま転送してよい (MAY)。何らかの方法でペイロードを変換するトランスレータは、SR および RR 情報に対応する変換を行い、それが依然としてデータの特性および受信品質を反映するようにしなければならない (MUST)。これらのトランスレータは RTCP パケットを単に転送してはならない (MUST NOT)。一般に、トランスレータは異なる送信元からの SR および RR パケットを 1 つのパケットに集約すべきではない (SHOULD NOT)。なぜならそれは LSR および DLSR フィールドに基づく伝播遅延測定の精度を低下させるからである。

SR 送信側情報：トランスレータは自身の送信側情報を生成せず、あるクラウドから受信した SR パケットを他へ転送する。SSRC はそのままにするが、送信側情報は変換に応じて必要なら修正されなければならない (MUST)。トランスレータがデータ符号化を変更する場合、"sender's byte count" フィールドを変更しなければならない (MUST)。複数のデータパケットを 1 つの出力パケットに結合する場合、"sender's packet count" フィールドを変更しなければならない (MUST)。タイムスタンプ周波数を変更する場合、SR パケットの "RTP timestamp" フィールドを変更しなければならない (MUST)。

SR/RR 受信報告ブロック：トランスレータはあるクラウドから受信した受信報告を他のクラウドへ転送する。これらはデータと逆向きに流れることに注意。SSRC はそのままにする。トランスレータが複数のデータパケットを 1 つの出力パケットに結合し、したがってシーケンス番号を変更する場合、パケット欠落フィールドおよび "extended last sequence number" フィールドに対し逆の操作を行わなければならない (MUST)。これは複雑であり得る。極端な場合、受信報告を変換する意味のある方法が存在しない可能性があり、トランスレータは受信報告をまったく転送しないか、自身の受信に基づく合成報告を転送してよい (MAY)。一般規則は、特定の変換にとって意味のあることを行うことである。

  トランスレータは自身の SSRC 識別子を必要としないが、自身が受信したことについて報告を送信する目的で 1 つを割り当ててもよい (MAY)。これらは、受信報告は通常すべての参加者へマルチキャストされるため、接続された各クラウドへ、それぞれそのクラウドへ送信されたデータストリームの変換に対応して送信される。

SDES：トランスレータは一般に、あるクラウドから受信した SDES 情報を変更せず他へ転送するが、帯域幅が限られている場合は非 CNAME SDES 情報をフィルタすると決定してよい (MAY)。SSRC 識別子衝突検出が働くよう、CNAME は転送されなければならない (MUST)。自身の RR パケットを生成するトランスレータは、それらの RR パケットを送信する同じクラウドへ、自身に関する SDES CNAME 情報を送信しなければならない (MUST)。

BYE：トランスレータは BYE パケットを変更せず転送する。パケットの転送を停止しようとするトランスレータは、それまでそのクラウドへ転送されていたすべての SSRC 識別子（自身が報告を送信していた場合はトランスレータ自身の SSRC 識別子を含む）を含む BYE パケットを、各接続クラウドへ送信すべきである (SHOULD)。

APP：トランスレータは APP パケットを変更せず転送する。

7.3 ミキサにおける RTCP 処理 (RTCP Processing in Mixers)​

ミキサは自身の新たなデータストリームを生成するため、SR や RR パケットを通過させず、代わりに両側向けに新たな情報を生成する。

SR 送信側情報：ミキサは、ソースストリームの特性が混合で失われるため、混合する送信元からの送信側情報を通過させない。同期送信元として、ミキサは混合データストリームに関する送信側情報を持つ自身の SR パケットを生成し、混合ストリームと同じ方向へ送信すべきである (SHOULD)。

SR/RR 受信報告ブロック：ミキサは各クラウド内の送信元に対する自身の受信報告を生成し、同じクラウドへのみ送信する。これらの受信報告を他のクラウドへ送信してはならない (MUST NOT)。また、あるクラウドからの受信報告を他へ転送してもならない (MUST NOT)。なぜなら送信元はそこでは SSRC ではなく（CSRC のみである）からである。

SDES：ミキサは一般に、あるクラウドから受信した SDES 情報を変更せず他へ転送するが、帯域幅が限られている場合は非 CNAME SDES 情報をフィルタすると決定してよい (MAY)。SSRC 識別子衝突検出が働くよう、CNAME は転送されなければならない (MUST)。（ミキサが生成した CSRC リスト内の識別子が、エンドシステムが生成した SSRC 識別子と衝突し得る。）ミキサは、SR または RR パケットを送信する同じクラウドへ、自身に関する SDES CNAME 情報を送信しなければならない (MUST)。

  ミキサは SR や RR パケットを通過させないため、典型的には複合 RTCP パケットから SDES パケットを抽出する。オーバヘッドを最小化するため、SDES パケットからのチャンクはミキサ発信の SR または RR パケットに積み重ねられる単一の SDES パケットに集約されてよい (MAY)。SDES パケットを集約するミキサは、複合パケットが長くなるため個別の送信元より多くの RTCP 帯域幅を消費するが、ミキサは複数の送信元を代表するため適切である。同様に、受信したまま SDES パケットを通過させるミキサは、単一送信元レートより高いレートで RTCP パケットを送信することになるが、やはりパケットは複数の送信元から来るため正しい。RTCP パケットレートはミキサの各側で異なり得る。

  CSRC 識別子を挿入しないミキサは、SDES CNAME の転送を控えてもよい (MAY)。この場合、2 つのクラウドの SSRC 識別子空間は独立である。前述のように、この動作モードはループを検出できない危険をもたらす。

BYE：ミキサは BYE パケットを転送しなければならない (MUST)。パケットの転送を停止しようとするミキサは、それまでそのクラウドへ転送されていたすべての SSRC 識別子（自身が報告を送信していた場合はミキサ自身の SSRC 識別子を含む）を含む BYE パケットを、各接続クラウドへ送信すべきである (SHOULD)。

APP：ミキサによる APP パケットの扱いはアプリケーション固有である。

7.4 カスケードされたミキサ (Cascaded Mixers)​

RTP セッションは、図 3 に示すようなミキサおよびトランスレータの集まりを含み得る。2 つのミキサがカスケードされている場合（図の M2 および M3 など）、ミキサが受信するパケットはすでに混合されており、複数の識別子を持つ CSRC リストを含み得る。2 つ目のミキサは、すでに混合された入力パケットからの CSRC 識別子と、未混合の入力パケットからの SSRC 識別子を用いて、出力パケットの CSRC リストを構築すべきである (SHOULD)。これは図のミキサ M3 からの出力アークに付された M3:89(64,45) に示される。カスケードされていないミキサの場合と同様、結果の CSRC リストが 15 を超える識別子を持つ場合、残りは含められない。