Cisco Video/TelePresence アーキテクチャ デザイン ガイド

ビデオ フレーム

ビデオとは、連続する複数の画像によって一連の動きを構成したものです。連続する各画像を時間の経過と共に順次表示することで、一連の動きが表現されます。これらの各静止画像をビデオ フレームと言います。各ビデオ フレーム間の時間差が小さいほどリフレシュ レートは高くなるため、ビデオの動きはより自然なものになります。一連の動きを表現するために表示される 1 秒あたりのビデオ フレーム数が多ければ、フレーム間の画像の変化は小さく、動きがより滑らかになるからです。

IP ビデオ ソリューションでの圧縮

IP ビデオの圧縮とはその名のとおり、ビデオ情報全体のサイズを小さくするプロセスです。サイズが非常に小さい IP テレフォニー ストリームの音声データとは異なり、ビデオ データは元々サイズが大きいうえ、そのストリーム フローも大きく変動します。フローが変動する原因は、ビデオが静止部分（背景など）の情報と動きがある部分（人物など）の情報で構成されている点にあります。また動きは常に一定というわけではなく、その対象の大きさも同じではありません。そのため、リアルタイム ビデオを転送する際には、そのサイズやフローの変動を小さくするための複雑なメカニズムが必要となります。ビデオを圧縮すると、そのサイズが軽減されるため転送が容易になります。IP ビデオの主な圧縮方法は次のとおりです。

• 「ロスレス圧縮」

• 「ロッシー圧縮」

いずれの圧縮方法でも、次のような方式を使用できます。

• 「イントラフレーム」

• 「インターフレーム」

ロスレス圧縮

ロスレス IP ビデオ圧縮では、圧縮を解除すると圧縮前の元の画像とまったく同じ状態の画像が復元されます。ロスレス圧縮の場合、統計に基づいて冗長な情報のみ削除されるため、受け取る側はビデオ信号を完全に再現することができます。つまり、圧縮プロセスの中で何らかビデオ情報が意図的に破棄されることはありません。ロスレス圧縮は、元の画像についての情報をすべて保持できることから、主にデータを保管する際に使用されます。ただしビデオをロスレス圧縮しても、生成される情報量は膨大であり、ストリーミングにも支障が出ることになります。そのため、IP ビデオ ソリューションでロスレス ビデオ圧縮が使用されることはほとんどありません。

ロッシー圧縮

IP ビデオでは、ロスレス圧縮よりもロッシー ビデオ圧縮を使用するのが一般的です。ロッシー ビデオ圧縮では、ビデオの中に視聴者にとって不要な情報や認識できない情報が含まれていることを前提として、圧縮プロセスの際にビデオ情報の一部が意図的に破棄されます。たとえば、アナログからデジタルに変換した場合のノイズなどは、この「不要な」ビデオ情報に当たります。ロッシー ビデオ圧縮では、非常に高い画質を維持しながらペイロード サイズを大幅に縮小することができます。この圧縮手法が IP ビデオ ソリューションで多用される理由はここにあります。ビデオ圧縮では常に、ビデオのサイズと画質とがトレードオフの関係にあることに留意する必要があります。この他、フレームの持続時間や、1 秒当たりのフレーム数を表すフレーム レート（単位は fps）にも、他の要素との間にトレードオフの関係があります。たとえば、30 fps で 1080 p の解像度を持つ画像よりも、60 fps で 720 p の解像度を持つ画像の方が、動きが見やすいうえ帯域幅も約 10 % 節約できるため、メリットは大きいと言えます。

イントラフレーム

イントラフレーム方式は、1 回につき 1 つのビデオ フレームを対象にその内容を圧縮するもので、その前後のビデオ フレームは考慮されません。すべてのビデオ フレームが個別に圧縮されるため、特定の圧縮ビデオ フレームを圧縮解除する場合、前後の圧縮ビデオ フレームは必要ありません。つまり、すべての圧縮ビデオ フレームをキー フレームと見なすことができます。

イントラフレーム圧縮は圧縮率がインターフレーム方式ほど高くないため、ビデオ ストリーミングやビデオ会議に単独で使用しても、あまりメリットはありません。そのためビデオ会議では、イントラフレーム圧縮は常にインターフレーム方式と併用されます。

インターフレーム

イントラフレーム方式とは異なり、インターフレーム方式では、先行するビデオ フレームについての情報を基にして圧縮が実行されます。インターフレーム方式を実装した一部のビデオ形式（たとえば H.264 などの Advanced Video Coding 形式）では、圧縮を実行する際、後続のビデオ フレームに関する情報も考慮されます。

インターフレーム方式では、ビデオの中で圧縮を行う画像の各部分には常に動きがあるわけではないという事実を基に、コンプレッサから、ビデオ フレームに関するすべての情報ではなく差分（動きのあった部分）のみが転送されます。重要な点は、この方式がキー フレームという考え方を基盤としていることです。キー フレームとは、圧縮処理の基準として使用される初期ビデオ フレームです。したがって、キー フレームがデコーダに到達しなければ、圧縮解除の処理は適正に行われません。このため、インターフレーム方式を採用しているビデオ形式では通常、リカバリのメカニズムが実装されています。インターフレーム圧縮方式では、キー フレームは基準として使用されるため、それを圧縮した内容が前後のフレームに依存することはありません。

IP ビデオ ソリューションのコーデック

コーデック（CODEC）とは、コンプレッサ/デコンプレッサ（COmpressor-DECompressor）またはコーダ/デコーダ（COder-DECoder）を表す用語です。ビデオ コーデック（Cisco TelePresence System または C シリーズのコーデックなど）は、ビデオをエンコードおよびデコードするためのハードウェアまたはソフトウェアです。また、 コーデック という用語は通常、ビデオ形式を表す場合にも使用されます。各ビデオ コーデックは、少なくとも 1 つのビデオ形式を実装することができます。またこれらの形式では、イントラフレーム圧縮方式またはインターフレーム圧縮方式のいずれかを使用したロスレス圧縮またはロッシー圧縮を実装できます。IP ビデオ ソリューションでは、ほとんどすべての IP ビデオ エンドポイントが基本機能としてコーデックを搭載しています。「IP ビデオ ソリューションでの圧縮」で述べられているように、圧縮が必要となる理由は、セッション内で転送するビデオ データのサイズが大きいことにあります。図 3-1 には、圧縮を実行するコーデックが示されています。このコーデックでビデオ ストリームの圧縮処理が行われることにより、そのサイズと変動が軽減されます。

図 3-1 ビデオ圧縮を実行するコーデック

ビデオの圧縮形式

「IP ビデオ ソリューションのコーデック」で述べられているように、ビデオ形式はコーデックと呼ばれることも多く、この 2 つの用語は混用されています。ビデオ形式は、特定の技術に基づいてビデオの圧縮またはエンコードをどのように行うかについての仕様です。たとえば、広く使用されている H.264 は、ロッシー圧縮を採用したビデオ形式です。ビデオ形式は、ビデオをエンコードするビデオ エンドポイントに搭載されたコーデックにより実装されます。IP ビデオ エンドポイントでは、使用するビデオ形式について、コール時にネゴシエーションを行ったうえで同意する必要があります。方法や方式が同じビデオ形式であっても、その特性は必ずしも同じではありません。それぞれのビデオ形式が持つ強みやメリットは、その方法や方式がどのように実装されているのかによって決まります。

一般にビデオ形式は、国際電気通信連合（ITU）電気通信標準化部門（ITU-T）、または国際標準化機構（ISO）と国際電気標準会議（IEC）が共同で策定しています。IP ビデオ ソリューションでの利用頻度が最も高い 3 つのビデオ形式のうち、H.261 と H.263 の 2 つは ITU-T が策定したものであり、H.264（Moving Picture Experts Group（MPEG））は ITU-T、ISO、および IEC が共同で策定したものです。 表 3-1 は、これらの形式が持つ機能と特性を比較したものです。

現在、ほとんどの Cisco IP Video エンドポイントでは、H.264 がデフォルトのビデオ圧縮形式として利用されています。

圧縮ビデオ フレーム

圧縮ビデオ フレームとは、（イントラフレーム方式またはインターフレーム方式、およびロッシー圧縮またはロスレス圧縮を使用した）圧縮処理による生成物のことです。通常の（圧縮されていない）ビデオ フレームの代わりに使用することで、転送するビデオ情報全体のサイズを軽減することができます。図 3-2 は、ビデオ フレームがコーデックで圧縮される過程を示したものです。この例で生成される圧縮ビデオ フレームは I フレームです。

図 3-2 圧縮の処理過程

IP ビデオ ソリューションでは、さまざまなタイプの圧縮ビデオ フレームが使用されます。このうち主なタイプは次のとおりです。

• 「I フレーム」

• 「P フレーム」

• 「B フレーム」

I フレーム

I フレームは、その内部データのみに基づくもので、シーケンスの開始時に圧縮解除（またはデコード）を行うことができます。I フレームの圧縮には、イントラフレーム方式が使用されます。I フレームは、その内容が他のいずれのフレームに依存せず、かつ他のフレームの基準として使用されることから、別名キーフレームと呼ばれることもあります。インターフレーム圧縮の項で説明したように、キーフレーム（初期フレーム）は、圧縮対象である画像シーケンスの先頭に使用されます。Instant Decoder Refresh（IDR）フレーム、Gradual Decoder Refresh（GDR）フレーム、Long-Term Reference Picture（LTRP）フレームは代表的な I フレームです。GDR フレームは、複数のフレームに細分することで送信間隔を短くすることができるのに対し、IDR フレームは 1 つのパケットで送信されます。これが、IDR フレームと GDR フレームとの主な違いです。GDR フレームを使用する目的は、IDR フレームを使用した場合に生じるデータ レートの大幅な上昇を回避し、エンド ユーザにとってより質の高いビデオ再生を実現することにあります。GDR を実装すると、たとえば全体として 1 つのフレームを構成する 10 個の IDR エンコード ビデオ画像を個別に送信することができます。この場合、10 フレームのウィンドウ上で徐々に変化するのは元のフレームのわずか 1/10 であるため、ユーザが知覚するビデオの品質は一般にかなり高くなります。

一方 LTRP フレームは、一部のコーデックに実装されているメディアの復元機能に使用されます。ネットワーク上では避けることが難しい圧縮ビデオの損失やエラーは、デコーダで表示エラーが生じる原因になります。こうしたエラーは、後続の P フレームにも影響を与えます。この問題を回避するには、デコーダからエンコーダへ I フレームを要求してエラーを解消する（エラー フィードバック メカニズム）のが自然な方法です。ただし、別のフレーム（より以前の長時間フレーム）を基準として使用するほうが、対処方法としては適切です。フィードバック メカニズムと、エラーのない LTRP フレームとを併用することにより、消失したビデオ データ（スライスなど）を回復し、エラーのある LTRP フレームを破棄することができます。コーデックにこのような仕組みが実装されている場合、（IDR と GDR のいずれを使用している場合でも）LTRP フレームとなるのは、コーデックに到達する最後の I フレームです。受信側のコーデックでは、この最後の I フレームが LTRP フレームとして保存されますが、その後新たに I フレームが到達した場合は、それが LTRP フレームになります。I フレームが転送中に消失した場合、受信側のコーデックでは LTRP フレームを使用してその回復が試みられます。

I フレームは、イントラフレーム方式を使用して圧縮されます。これは、ビデオ ストリームの帯域幅使用量に直接的な影響を与えます。I フレームの使用頻度が高いほど、より多くの帯域幅が必要となります。

P フレーム

予測フレーム（P フレーム）は、I フレームよりも圧縮率が高いフレームです。P フレームは、インターフレーム エンコード方式を使用して圧縮されます。P フレームは、ビデオ ストリームの中で I フレームに後続するフレームであり、先行する I フレームから変更されたビデオ情報のみ保持します。インターフレーム圧縮の項で説明したように、P フレームを正しくデコードするためには、直近の I フレーム（キー フレーム）を組み合わせて使用する必要があります。

B フレーム

P フレームを使用すると圧縮率は大幅に高くなりますが、双方向予測フレーム（B フレーム）を使用すれば全体の圧縮率はさらに高まります。B フレームは、直前の I フレームおよび後続の P フレームを参照し、それらの画像間の差分のみを保持します。ただし 2 つのアンカー フレームの間に十分なバッファを確保するためにはコーデックのメモリを 2 倍にする必要があるため、一部のコーデックでは（コールで使用されるビデオ形式が B フレームをサポートしている場合でも）B フレームを実装できません。また B フレームを使用した場合は、いくらかの遅延が新たに発生します。この遅延は B フレームの実装ロジックに起因するものです。

図 3-3 は、ビデオ ストリーム内の圧縮ビデオ フレームの順序を図示したものです。この例の場合、コーデックは I フレーム、P フレーム、および B フレームを実装できるものとします。

図 3-3 ビデオを表示する順序

IP ビデオ ソリューションの解像度形式

簡単に言えば、解像度形式とは画像サイズのことです。現在は多くのビデオ エンドポイントが、ビデオを表示するスクリーンに合わせて画像を拡大または縮小する機能を備えています。遠くからでもビデオを見られるようにするにはこうした機能が必要ですが、その場合画像の鮮明度は低下します。

ビデオ解像度形式は正式には、表示の際に使用される特定のピクセル数とスキャン方式との組み合わせとして定義されます。次のリストおよび図 3-4 は、IP ビデオ ソリューションで使用される主なビデオ解像度形式を列記および図示したものです。

• CIF：Common Intermediate Format（共通中間フォーマット）

• QCIF：Quarter CIF

• 360 p：垂直 360、プログレッシブ スキャン

• 480 p：垂直 480、プログレッシブ スキャン

• 720 p：垂直 720、プログレッシブ スキャン

• 1080 i：垂直 1080、インターレース ビデオ

• 1080 p：垂直 1080、プログレッシブ スキャン

図 3-4 主なビデオ解像度

ISDN 経由でのビデオ

ビデオ会議が広く利用されるようになったのは、Integrated Services Digital Network（ISDN）規格が登場して以降です。そのため ISDN は、ビデオ会議が普及するきっかけとなった最初のテクノロジーであると目されています。その後ビデオ会議の普及が進むにつれて、より優れた相互運用性や復元機能、ビデオ品質を実現する新しいソリューションが次々と登場しました。そしてシスコがビデオ会議の市場に参入する頃になると、ISDN ビデオ端末に最先端の技術を取り入れる必要があるということが強く認識されるようになります。シスコは、既存の ISDN ビデオ端末から新しい IP ビデオ ネットワークに接続できるよう、H.320 ゲートウェイとして Cisco Unified Videoconferencing 3500 シリーズ製品を IP ビデオ ソリューションに組み入れました。それ以降シスコは、ISDN ビデオをサポートするため、さまざまな H.320 デバイスをポートフォリオに組み入れています。これらの H.320 デバイスを Cisco Unified Communications Manager（Unified CM）や Cisco TelePresence Video Communication Server（VCS）などのゲートキーパーに接続することで、IP ビデオ エンドポイントから、PSTN クラウドの反対側に位置する ISDN ビデオ エンドポイントへのアクセスが実現されます。

H.320 規格には、ISDN でのマルチメディア（ここでの内容に関係があるのはビデオ用の H.221）が規定されています。H.320 では元々、ISDN でビデオを使用する際のビデオ形式として H.261 または H.263 が規定されており、前回の更新時に H.264 が追加されました。H.221 には、Px64 kbps、H0（384 kbps）、H11（1536 kbps）、および H12（1920 kbps）という 4 つの転送モードが定義されています。ビデオがエンコードされると、選択したビデオ形式（H.261 など）は H.221 規格に基づいて多重化されます。

ISDN は、サポートしているビデオ解像度形式の画像サイズが大きく制限されていることから、ナローバンド テレビ電話システムと呼ばれます。ISDN は、ビデオ解像度形式として QCIF、CIF、4CIF、および 16CIF をサポートしています。

この種のソリューションは、サポートしている ISDN サービス プロバイダーに依存するという点に大きな特徴があります。この ISDN サービス プロバイダーが常時関与することにより、異なる ISDN 端末間でコールを行うことができます（図 3-5 を参照）。

図 3-5 画像 4。ISDN 経由でのビデオと使用されるプロトコル

IP ビデオ テレフォニー

実際に導入された初めてのビデオ会議テクノロジーが ISDN 経由でのビデオだとすれば、ビデオ会議をはるかに大きな規模で企業に導入できるようにしたのが IP ビデオ テレフォニーです。IP ビデオ テレフォニーを使用すると、さまざまな方法で企業にビデオを導入することかできます。PC 上で稼動するソフトウェア クライアントを介することによりユーザの IP 電話でビデオを使用できるほか、専用のビデオ エンドポイントやビデオ会議ブリッジを組み込むことで、充実したメディア利用を実現することができます。ISDN 経由でのビデオとは異なり、IP ビデオ テレフォニーはビデオ解像度、復元機能、および相互運用性に優れています。

いずれの IP ビデオ テレフォニー ソリューションにとっても欠かせないものがコール制御要素です。この要素ではコール ルーティングが行われるほか、多くの場合、相互運用性や特殊機能に関わる処理も行われます。シスコが初めて提供した IP ビデオ テレフォニー関連の製品は、コール制御を行うための Cisco Unified Communications Manager（Unified CM）です。図 3-6 は、シスコの IP ビデオ テレフォニーにおけるトポロジーの一例です。

図 3-6 IP ビデオ テレフォニー

図 3-7 に示したように、IP ビデオ テレフォニーでは、ISDN 経由でのビデオ（米国の場合は 1.54 Mbps）のように 2 Mbps に制限されないさまざまな物理転送メディアにより柔軟な転送を行うことで、より優れたビデオ解像度が実現しています。また、IP（ビデオ用のユーザ データグラム プロトコル）でカプセル化されたパケットを、イーサネット、ワイヤレス通信、マルチプロトコル ラベル スイッチング（MPLS）などを経由して伝送することが可能です。新しい転送メディア（MPLS、イーサネット、光通信など）と IP との相乗効果により、高解像度に伴う大量の圧縮ビデオ フレームでも転送することができます。新しいコーデックにより実装された新たなエラー回復技術により復元機能も強化されていますが、下位互換性は維持されています。

図 3-7 IP による圧縮ビデオ フレームのカプセル化

デスクトップ ビデオ会議

デスクトップ ビデオ会議は、次世代コミュニケーションとして IP ビデオが強化されています。デスクトップ ビデオ会議は、インスタント メッセージ プログラムに対するオドオンとして導入されました。同時に IP ビデオ テレフォニー技術関連の企業はその長所を認識し、従来の IP テレフォニー環境に接続できるソフトウェア ビデオ クライアントを開発しました。技術によっては、現在のようなハードウェア IP 電話が利用されるものもあれば、ソフトウェア IP 電話が利用されるものもあります。シスコが初めて提供したデスクトップ会議は、Cisco Unified Video Advantage（VT Advantage）でした。これは、ハードウェア IP 電話とソフトウェア IP 電話のどちらでもビデオ機能を利用できるようにしたソフトウェア ビデオ クライアントです。

デスクトップ ビデオ会議クライアントでは、コンピュータのリソースを使用してソフトウェアによるビデオのエンコードおよびデコードが実行されます。ビデオ解像度形式が高度になり、ビデオ形式が複雑になるほど、必要となるコンピュータのリソースは増加します。コンピュータの性能が向上すると同時に、より効率的なエンコードおよびデコードのメカニズムが開発されることで、エンド ユーザの間でも高度なデスクトップ ビデオ会議クライアントが普及するようになりました。図 3-8 は、セッション中のビデオ ソフトウェア クライアントの一般的な使用方法と基本的なトポロジーを図示したものです。

図 3-8 ソフトウェア ビデオ会議

イマーシブ ビデオ会議

新しい方式によるビデオ会議の模索が続く中で、IP ビデオ ソリューションの新たな実装方法が考案されました。それが、テレプレゼンスと呼ばれるビデオ システムです。これは、相手を等身大に映し出すことができるため、遠隔地の会議参加者とより自然なコミュニケーションを取ることができます。初めて登場したテレプレゼンス システムは、値段が高いうえ専用のネットワーク環境が必要でもあったため、あまり導入されませんでした。2006 年、イマーシブ ビデオ会議の市場に進出したシスコは、ネットワークに関する膨大なノウハウを駆使して、本格的な統合型ネットワーク テレプレゼンス製品を開発しました。そして、イマーシブ ビデオ会議を開発する他社もシスコに追随して、統合型ネットワーク テレプレゼンス システムの開発に乗り出しました。

Cisco TelePresence には、従来の IP ビデオ テレフォニーと共通する点がいくつかあります。圧縮ビデオ フレームがユーザ データグラム プロトコル（UDP）でカプセル化されることで、IP ビデオ テレフォニーで使用されている同種のメディアにアクセスすることができるほか、IP ビデオ テレフォニーで使用されているビデオ形式と互換性が確保されます。ただし Cisco TelePresence には、IP ビデオ テレフォニーと共通点がある反面、一部異なる要素もあります。Cisco TelePresence では、特に大会議室での使用に適した高解像度のカメラおよびディスプレイが使用されます。Cisco TelePresence でも、コール制御はコール エージェントによって処理されますが、コール開始時にユーザがシステムを操作する方法は IP ビデオ テレフォニーとは異なります。

テレプレゼンス システムでは、高解像度カメラを使用して鮮明なビデオを撮影できます。このビデオはエンコードおよびデコードを経て、高解像度ディスプレイに表示されます、これによってビデオ エクスペリエンスは可能な限り維持されます。さらに、会議室がスタジオのような環境になるよう特殊な調整を行うことで、より現実感のある会議を実現できます。前述したように、エンド ユーザが会議を開始する際にテレプレゼンス システムを操作する方法は IP ビデオ テレフォニーとは異なります。テレプレゼンス システムは通常、ボタンを押して会議を開始できるメカニズムを備えています。Cisco TelePresence では、このようなセッション開始機能を One Button To Push（OBTP）と呼びます。図 3-9 は、イマーシブな Cisco TelePresence における基本的なポイントツーポイント コールでのメディアおよびシグナリングのフローを示したものです。

図 3-9 イマーシブ テレプレゼンス

クラウドホスト型ビデオ ソリューション

クラウドホスト型ビデオ ソリューションは、インターネット経由でのビデオ コミュニケーションを可能にすることで、エンタープライズグレードのビデオ コラボレーションを手頃な価格で利用できるようにしたサブスクリプション ベースのサービスです。

このソリューション モデルがその他のソリューション モデルと大きく異なるのは、お客様はビデオ エンドポイント（Cisco TelePresence System EX90 や PC など）を用意するだけで、IP ビデオ インフラストラクチャの費用を先行負担しないという点です。ビデオ エンドポイントの多重化や制御は自社で行う必要がないため、インフラストラクチャに巨額の投資を行うことなくビデオ コラボレーションを実現することができます。このソリューション モデルでは、インターネット接続ができること、および IP ビデオ プロバイダーの登録が必要です。ただし、このソリューションを自社管理モデルに移行した場合でも、その IP ビデオ エンドポイントは再利用することができます。

クラウドホスト型ビデオ ソリューションを使用すれば、IP ビデオ サービスを使用した分だけ料金を支払えばよいため、IP ビデオ インフラストラクチャの費用が大きな負担になるという問題は解消されます。この種のビデオ ソリューションとしては、ビデオ機能を備えた Cisco Callway や Cisco WebEx などがあります。これらのソリューションを使用すれば、管理作業のオーバーヘッドやインフラストラクチャへの投資費用を低く抑えながら、ユーザにビデオ サービスを提供することができます。

相互運用性

テクノロジーが進歩すれば必ず、新しいテクノロジーとレガシー テクノロジーとを連携させる形で運用する必要が出てきます。相互運用性は、異種の IP ビデオ テクノロジーを連携させるのに伴う問題を解消するためのものです。ただし適用できるのは、対象となるテクノロジーにより実装できる機能に限定されます。たとえば、ISDN 規格はテキストの転送に対応しているため、一部の ISDN 端末ではビデオ コール中に参加者のスクリーンにテキストを送信することができます。しかし、テキストの転送に対応していない規格が他のテクノロジーに実装されていれば、このテキストを ISDN ドメインの外部（IP ビデオ テレフォニーなど）に転送することは技術的に不可能です。

相互運用性は通常、異種テクノロジーの境界で機能する製品または製品スイートにより実現されます。一般に、ビデオ ソリューションの相互運用性を実現する製品（単独製品または製品群）には、ビデオ トランスコーダ、ビデオ ゲートウェイ、ビデオ会議ブリッジなどの種類があります。図 3-10 は、相互運用性の一般的なシナリオ（マルチポイント コントロール ユニット（MCU）による相互運用性の実現）を示したものです。

図 3-10 ビデオ会議システムにおける相互運用性

レガシー マルチポイント コントロール ユニット

初期のマルチポイント コントロール ユニット（MCU）アーキテクチャでは、実現するサービスや機能が制限されていました。これらのレガシー MCU は、コントローラ ブレードおよびデジタル シグナル プロセッサ（DSP）ブレードという 2 つの主要ハードウェア コンポーネントを備えていました。コントローラ ブレードは、ローカルの DSP 資産しか認識できないため、別の MCU の資産を認識し、それらをカスケードしてビデオ マルチポイント コールで使用することはできませんでした。さらに、特定の解像度しかサポートされておらず、トランスレーティングもサポートされていないか、サポートされていたとしても性能は低いものでした。

その後一部のレガシー MCU では高解像度ビデオがサポートされるようになったものの、大半のレガシー MCU では標準的な解像度のビデオしかサポートされないのが一般的でした。

テレプレゼンス相互運用プロトコル（TIP）

テレプレゼンス相互運用プロトコル（TIP）は元々シスコが開発したもので、後にオープン ソース プロトコルとして国際マルチメディア遠隔通信コンソーシアム（IMTC）に提供されました。TIP 規格では、マルチスクリーンおよびオーディオ ストリームを 2 つのリアルタイム転送プロトコル（RTP）フロー（ビデオ用および音声用にそれぞれ 1 つずつ）に多重化する方法が定義されています。これにより、マルチスクリーン エンドポイントとシングルスクリーン エンドポイントの併用のほか、ポイントツーポイント セッションおよびマルチポイント セッションが可能となります。また TIP の仕様には、リアルタイム転送プロトコル（RTP）アプリケーション拡張を使用して、セッションの確立時にプロファイル機能やメディア別フロー オプションを提示する方法についても定義されています。さらには、ストリーム中にデバイスからフィードバックを行う方法や復元メカニズムを作動させる方法も定義されています。

図 3-11 に図示されているように、TIP では、スクリーン（およびその音声）のスイッチングをどのように行うかが指定されていることで、さまざまなベンダーのマルチスクリーン IP ビデオ ソリューションの相互運用が可能になっています。TIP は、ビデオ エンドポイント、ビデオ トランスコーダ、ビデオ ゲートウェイ、および MCU（ビデオ会議ブリッジ）で使用されます。

図 3-11 実行中の TIP 多重化

ClearPath

Cisco ClearPath は、パケット損失が 15 % までであれば、それに伴う悪影響を排除することができるテクノロジーです。これは、さまざまなメディア復元メカニズムを組み合わせたダイナミックなテクノロジーです。たとえば損失メディアを使用している場合、ClearPath があるとパケット損失の影響を相殺することができるため、ユーザ エクスペリエンスが向上します。ClearPath はデフォルトで有効です。ビデオ コミュニケーションの両端でサポートされている場合に使用されます。ClearPath モードは xConfiguration Conference PacketLossResilience Mode コマンドによって設定されます。ClearPath 内のメディア復元メカニズムはすべて H.264 規格に準拠しているため、生成されるエンコード ビット ストリームも H.264 に準拠しています。ClearPath は、コール セットアップ プロトコルに依存しないよう設計されているため、H.323 エンドポイント、SIP エンドポイント、および XMPP エンドポイントで使用できます。

ClearPath では次のようなテクノロジーによって、最良のユーザ エクスペリエンスが実現されています。

• 「ダイナミック ビット レート調整」

• 「Long Term Reference Picture」

• 「ビデオ対応の前方誤り訂正（FEC）」

ダイナミック ビット レート調整

ダイナミック ビット レート調整は、使用できる可変帯域幅に合わせてコール レートを調整するものです。これにより、パケット損失の状況に基づいてコールの速度が上下します。ClearPath の場合、パケット損失が減少すると速度が上昇します。ClearPath では、RTCP を介して送信側プロアクティブ方式が使用されます。この場合、送信側では常に RTCP レシーバー レポートの確認が行われ、その内容に従ってビット レートが調整されます。

Long Term Reference Picture

長時間参照フレーム リカバリは、パケット損失の後に I フレームを使用することなくエンコーダ/デコーダの再同期化を行うための手法です。パケット損失が発生した場合は、従来の I フレームの代わりに修正 P フレームを使用することができます。これにより、フレームを復元するために転送するデータは約 90 % 少なくなります。

Long Term Reference Picture（LTRP）は、エンコーダおよびデコーダで保持される I フレームで、保持終了の明示的な信号を受信するまでその状態が維持されます。長時間参照フレームまたは LTRP の詳細については、「I フレーム」を参照してください。

ビデオ対応の前方誤り訂正（FEC）

前方誤り訂正（FEC）では所定のアルゴリズムに従って、転送される情報に冗長性が付与されます。この冗長性があることにより、受信側では、メッセージのいずれかの箇所でエラーが発生した場合でもそれが一定数以下であれば、送信側に追加データを要求することなく、そのエラーを検出し訂正することができます。FEC では、受信側でエラーを訂正する場合、データの再送信を要求するためのリバース チャネルは必要ありませんが、その代わりとして、より高い転送チャネル帯域幅が常に必要となります。FEC では最も重要なデータ（通常は修正 P フレーム）が保護されます。これにより、それらのフレームは受信側で確実に受信されます。エンドポイントでは、帯域幅が 768 kbps を下回る場合 FEC は使用されません。また、1.5 % 以上のパケット損失が発生していない場合も FEC は適用されません。FEC の有効性は ClearPath によりモニタリングされます。FEC に有効性が認められない場合は、ClearPath により FEC の実行が中止されます。