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

SCCP

Skinny Client Control Protocol（SCCP）は、シスコが IP テレフォニー アプリケーション用に初めて開発したものです。IP テレフォニーは進化する過程でビデオとの統合が行われました。それによって生まれたのが Cisco IP Video Telephony です。SCCP では、伝送制御プロトコル（TCP）が転送プロトコルとして指定されているほか、エンドポイントとアーキテクチャ上の関係（マスター/スレーブ関係とも呼ぶ）を持つコール エージェントが定義されています。SCCP と、このセクションで説明するその他のコール制御プロトコルとの最も根本的な違いは、このコール エージェントにあります。SCCP では、集中型のコール エージェントが採用されているため、他のコール制御プロトコルではまず不可能と思われる非常に高度なコール機能を実現することができます。

SCCP では、コール エージェントとエンドポイントとの間にマスター/スレーブ（クライアント/サーバ）関係が定義されているため、コール機能が実行されるためには、コール エージェントが常時エンドポイントから利用可能な状態にあることが必要です。そのため SCCP は、エンドポイントがコール エージェント コンポーネントとは独立に機能する必要がある環境には適さない場合があります。

図 4-1 は、Cisco Unified Communications Manager（Unified CM）をコール エージェントとして導入した場合の SCCP コール制御シグナリングの役割を図示したものです。

図 4-1 SCCP シグナリング

前述したように SCCP の仕様では、ビデオ環境において高度なコール機能がサポートされます。これらの機能のうち、保留、保留解除、ミュート、および会議は、通常の音声コールの場合とまったく同様に機能します。SCCP エンドポイントの機能の中で大きな特徴があるのは、アドホック ビデオ会議およびミュートです。アドホック ビデオ会議をサポートしているのは SCCP だけではありませんが、SCCP に加えて、予約なしのビデオ会議をビデオ エンドポイントに実装していることにより、ユーザはより簡単にアドホック ビデオ会議へ参加することができます。コール制御サーバが互換性のある SCCP MCU と連動している場合、ユーザは事前に会議の予約をしなくても、キーを 1 つ押すだけで SCCP ビデオ電話から会議を開始することができます。ここに、H.323 との大きな違いがあります。H.323 では予約なしの会議を確立する際、ユーザが常時接続の会議接続先にダイヤルする必要があります。

ビデオに関する SCCP のミュート機能も、他のプロトコルの場合とは動作に違いがあります。SCCP ビデオ端末上でミュートがアクティブになると、H.323 や SIP のミュート機能とは異なり、音声とビデオが同時にミュートになります。

SCCP では、ビデオ エンドポイント上で高度なコール機能が使用できるのは、そのテクノロジーおよびアーキテクチャが電話に類似しているためです。したがって、ビデオに対しても電話に似たレガシーな動作が一部強制されることになります。Uniform Resource Identifier（URI）ダイヤリングやデータ共有がサポートされていないのも、レガシーな動作に見られる特徴の 1 つです。このためビデオを導入する際に SCCP と他のプロトコルを併用する場合は、SCCP が持つアーキテクチャ上の制約を考慮することが重要です。 表 4-1 は、SCCP で実装されないその他の機能をまとめたものです。ビデオに対して H.323 または SIP を併用する場合はこれらを考慮する必要があります。

SCCP メッセージは 16 進数にエンコードされるため、伝送データから直接その内容を読み取ることは困難です。ただし、このエンコード メカニズムにより、SCCP メッセージは一般に他のコール制御プロトコルを使用したメッセージよりもサイズが小さくなります。たとえば、コール制御トラフィックが暗号化されていない場合、SIP 電話は平均 538 bps であるのに対し、SCCP 電話は平均 256 bps です。

H.323

SCCP とは異なり、H.323 は単独の規格やプロトコルではなく、国際電気通信連合（ITU）の電気通信標準化部門（ITU-T）によって策定された複数のプロトコルおよび推奨事項を 1 つにまとめたものです。H.323 は、機能、想定される動作、および実装がきわめて厳密に定義されています。そのため H.323 は、通信ベンダーや通信プロバイダーの間の相互運用においては有利な立場にあります。H.323 の実装は、非常に明確に定義されているため、ベンダーの相互運用によって実現される事柄について、誤解が生じる余地はほとんどありません。

H.323 では、集中型のコール制御要素がなくてもユーザ間通信をサポートするピアツーピア プロトコル モデルが使用されます。H.323 は堅牢なため、さまざまなベンダーのエンドポイントとピアツーピア接続された、ゲートキーパーなどのコール制御要素が使用されるケースも珍しくありません。前述したように H.323 は複合的なプロトコルです。H.323 ピアでは、コール セットアップおよびコール アドミッション制御のネゴシエーションに H.225 が使用され、メディア チャネルのネゴシエーションに H.245 が使用されます。H.225 では、転送プロトコルとしてユーザ データグラム プロトコル（UDP）および TCP が使用されますが、H.245 で使用されるのは TCP のみです。これはファイアウォールには不便なように見えますが、H.323 はテレコミュニケーション業界に深く浸透しているため、ほとんどのファイアウォール ベンダーは H.323 パケットの効率的なインスペクションを実現しています。

図 4-2 は、ゲートキーパーをコール制御要素とした H.323 の使用例を図示したものです。

図 4-2 H.323 シグナリング

H.323 は、多種多様なビデオ会議機能を強力にサポートしています。中でも重要なのは、アプリケーション共有と遠端カメラ制御（FECC）です。H.323 エンドポイントでは、FECC に H.224 および H.281、データ共有に H.239 が使用されます。FECC およびアプリケーション共有が H.323 でサポートされていることは、アーキテクチャに関して H.323 と他のコール制御プロトコルとが大きく異なる点です。たとえば、SIP ではアプリケーション共有の実装方法が定義されていないのに対し、H.323 では Annex Q、および H.281 と H.224 の実装を通じてそれが明確に定義されています。H.323 の FECC の場合、カメラ制御命令は H.281 に組み込まれ、さらに H.224 でカプセル化されます。そのため RTP を使用すれば、既存のネットワーク インフラでも堅固な方法で FECC 命令を転送することができます。

H.323 では、アプリケーション共有についても、きわめて明確に定義されており、そのサポートは H.239 に従って行われます。H.239 では、予備的なビデオ チャネルの管理方法および追加方法が定義されているほか、追加したビデオ チャネルを介してアプリケーション ビデオを送信する方法も定義されています。さらに H.239 では、トークン システムを使用することにより、会議中同時に 1 人の参加者しかアプリケーション共有を利用できないようになっています。

H.323 と他のプロトコルとでは、一部の機能に大きな違いがあります。たとえば、一部の H.323 エンドポイントにはアドホック会議が実装されますが、H.323 ではそのアーキテクチャに、会議リソースのトラッキングを実行したり会議を確立したりするための集中型のコール制御要素は指定されていません。そのため、ほとんどの H.323 エンドポイントでは、アドホック会議を行う際にユーザが常時接続の会議ブリッジにダイヤルする必要があります。

また H.323 では H.235 によるメディア暗号化が定義されているものの、シグナリング暗号化の定義は H.323 の対象外であるという点も、H.323 と他のプロトコルとの違いの 1 つです。このため H.323 を実装する際、コール シグナリングを保護する必要がある場合は、TLS またはインターネット プロトコル セキュリティ（IPsec）を使用するのが一般的です。ただしベンダーが異なればコール シグナリングを保護する方法も異なるため、この場合にはベンダーが相異なるエンドポイント間の相互運用性に問題が生じる可能性があります。

H.323 の仕様は先進的ですが、H.323 の機能がサポートしているのはビデオと音声のみであり、インスタント メッセージやプレゼンスなどのサービスにまでサポートの範囲が拡張されることはありません。ビデオと音声以外の通信手段を追加的に組み込む可能性がある IP ビデオ ネットワークを設計する際は、H.323 が新しいサービスをサポートすることはないという点を十分考慮する必要があります。

さらに、H.323 メッセージはバイナリ形式にエンコードされるため、適切なディセクタを使用することなくその内容を解釈することはかなり困難であり、プロトコル メッセージを実装した場合にはリトルエンディアンおよびビッグエンディアンのエラーが発生する可能性があります。H.323 メッセージは SIP メッセージよりサイズが小さいですが、帯域幅の差はほとんどありません。

SIP

Session Initiation Protocol（SIP）は、ピアツーピア プロトコルです。最も単純な実装では、SIP エンドポイント間で通信する場合、互いに相手の場所が認識できていれば、コール制御エンティティは必要ありません。ただし SIP では、エンドポイントからサービス、リソース、およびダイヤル可能な未知の接続先を利用できるように、クライアント/サーバ関係が定義されています。SIP は、インターネット技術特別調査委員会（IETF）によって定義されたもので、複数の Request for Comments（RFC）にまとめられています。SIP の根幹となるルールは RFC 3261 で定義されていますが、その他に SIP の規格に関する RFC が十数項目以上存在します。

企業への導入の際に SIP を使用した場合は、そのほとんどでコール制御要素（クライアント/サーバ モデル）が導入されます。それにより、機能の充実したユーザ エクスペリエンスを実現できるほか、ダイヤル可能なドメインの制御やコール制御の一元化が可能になります。SIP 要素には、ユーザ エージェント クライアント（UAC）およびユーザ エージェント サーバ（UAS）という 2 つの基本カテゴリがあります。他の要素への接続を要求する側の要素が UAS、その要求を受け取る側の要素が UAC です。セッション中、同一の要素がトランザクションごとに UAC になったり UAS になったりすることはありますが、対処するトランザクションは 1 つに限定されます。

図 4-3 SIP シグナリング

SIP は、音声通信およびビデオ通信の確立以外にも処理を行うことができるなどさまざまな観点から見て、テレコミュニケーション シグナリング プロトコルよりも通信セッション シグナリング プロトコルに分類するのが妥当です。SCCP および H.323 は単なるテレコミュニケーション プロトコルであるのに対し、SIP ではインスタント メッセージやプレゼンスなどを使用できます。SIP プロトコルの仕様には数多くのサービスをサポートできるという強みがありますが、その要因の 1 つとなっているのが、UAS 要素および UAC 要素では、認識できない事柄やサポートできない事柄が常に無視されるという事実です。ただし、これによってベンダー間の相互運用は煩雑になるため、場合によってはこの強みが SIP の短所の 1 つになることもあります。さらに SIP は、SCCP や H.323 に比べると仕様の内容が概略的であるため、ベンダー間の相互運用が円滑に行えない場合があります。たとえば SIP には、一部の機能を実装する方法が複数あります。同じ機能をベンダーごとに異なる方法で実装した場合、それらには互換性がありません。

他のコール シグナリング プロトコルで定義された機能の中には、SIP で定義されていないもの、またはそのコール シグナリング プロトコルの場合とは動作が異なるものが存在するという点にも注意が必要です。たとえば、RFC 4353 より以前には、アドホック会議の実装方法を定義した規格はなく、SIP の実装時には不明な点を補うためさまざまな手法が用いられました。Cisco IP Video Telephony の場合は、XML を使用して独自の手法を開発することによりアドホック会議が実装されました。

その他、アプリケーション共有も SIP では定義が不明確なものの 1 つです。実装の際には、'm'（media-type）属性を使用して、アプリケーション共有メディアを送信するタイミングおよび追加のビデオ チャネルを設定するタイミングを指定する場合があります。しかし、SIP ではこれらの機能を実装する方法が明確に定義されていないため、SIP ベンダー間のアプリケーション共有が円滑に行うことができません。

テキストベースである SIP では、8-bit Unicode Transformation Format（UTF-8）でエンコードされた ISO 10646 文字セットが使用されます。コール制御トラフィックが非暗号化モードの場合、SIP 電話は平均 538 bps であるのに対し、SCCP 電話は平均 256 bps です。SIP では、TCP または UDP を使用できます。SIP を実装する場合は通常、ポート 5060 が使用されますが、別のポート上で SIP を実装することもできます。