Cisco Unified Communications システム リリース 8.x SRND
ゲートウェイ
ゲートウェイ
発行日;2012/12/18 | 英語版ドキュメント(2012/07/30 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 39MB) | フィードバック

目次

ゲートウェイ

この章の新規情報

トラフィック パターンとゲートウェイのサイジング

定義と用語

PSTN トラフィック パターン

一般業務のトラフィック プロファイル

コンタクト センターのトラフィック プロファイル

コンタクト センター トラフィックに対するゲートウェイのサイジング

音声アクティビティ検出(VAD)

コーデック

パフォーマンスの過負荷

パフォーマンスの調整

追加情報

ゲートウェイ冗長性に関する考慮事項

TDM ゲートウェイと VoIP トランキング ゲートウェイ

Cisco ゲートウェイの概要

Cisco アクセス アナログ ゲートウェイ

Cisco アクセス デジタル トランク ゲートウェイ

ゲートウェイ ゲイン設定の調整

ゲートウェイの選択

コア機能要件

ゲートウェイ プロトコル

ゲートウェイ プロトコルとコア機能要件

DTMF リレー

付加サービス

UnifiedCM の冗長性

サイト固有のゲートウェイ要件

FAX とモデムのサポート

ゲートウェイでの FAX パススルーと FAX リレーのサポート

ベスト プラクティス

スーパー G3 FAX のサポート

ゲートウェイでのモデム パススルーとモデム リレーのサポート

ベスト プラクティス

V.90 サポート

サポートされるプラットフォームと機能

プラットフォーム プロトコルのサポート

ゲートウェイ設定例

ビデオ テレフォニー用のゲートウェイ

PSTN からの着信コールのルーティング

PSTN への発信コールのルーティング

自動代替ルーティング(AAR)

最低料金選択機能

ISDN B チャネル バインディング、ロールオーバー、およびビジーアウト

着信コール

発信コール

UnifiedCM でのゲートウェイの設定

コール シグナリング ポート番号

コール シグナリング タイマー

音声ゲートウェイのベアラ機能

ゲートウェイ

ゲートウェイは、IP テレフォニー ネットワークを Public Switched Telephone Network(PSTN; 公衆電話交換網)、従来型の PBX、またはキー システムに接続するための複数の方法を提供します。ゲートウェイには、特殊なエントリレベルのスタンドアロン音声ゲートウェイから、機能が豊富なハイエンド統合ルータや Cisco Catalyst ゲートウェイまで、さまざまなものがあります。

この章では、IP テレフォニー ネットワークに適切なプロトコルと機能サポートを提供するために Cisco ゲートウェイを選択する際に、考慮すべき重要な要素について説明します。この章は、次の項で構成されています。

「トラフィック パターンとゲートウェイのサイジング」

「TDM ゲートウェイと VoIP トランキング ゲートウェイ」

「Cisco ゲートウェイの概要」

「ゲートウェイの選択」

「FAX とモデムのサポート」

「ビデオ テレフォニー用のゲートウェイ」

この章の新規情報

表 13-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

 

表 13-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明箇所
改訂日

ゲートウェイ設定例はこのマニュアルから削除されましたが、次のサイトで入手可能な『 Cisco IOS Fax, Modem, and Text Support over IP Configuration Guide 』にあります。

http://www.cisco.com/en/US/docs/ios/voice/fax/configuration/guide/12_4t/vf_12_4t_book.html

「ゲートウェイ設定例」

2011 年 9 月 30 日

ビデオ テレフォニー ゲートウェイ

「ビデオ テレフォニー用のゲートウェイ」

2010 年 11 月 15 日

FAX とモデムのサポート

「FAX とモデムのサポート」

2010 年 4 月 2 日

トラフィック パターンとゲートウェイのサイジング

この項では、さまざまなトラフィック モデルまたはトラフィック パターンの違いと、それらが音声ゲートウェイの選定にどのように影響するかについて、詳しく説明します。ここでは、トラフィック集約型配置におけるトラフィック パターンとゲートウェイのサイジングに重点を置きます。

定義と用語

この項では、次の用語と定義を使用します。

同時コール

システム内ですべてが同時にアクティブになるコールの数。

最大同時コール

システムで処理可能な、アクティブ(通話)状態にある同時コールの最大数。1 日の 最最繁時 に同時にアクティブになると予測されるコールの数がこの数を超えないようにする必要があります。

コール数/秒(cps)

着呼率。1 秒間に着信したコールの数(つまり、新しいコール セットアップが試行されたコールの数)として定義されます。着呼率は多くの場合 1 時間あたりのコール数で計算されますが、このメトリックでは 1 時間の最後の 5 秒間に 100 件のコールが着信した場合でも平均着呼率は 100 コール/時間となり(これは通信システムとしては非常に低い数値です)、厳密とは言えません。この例を 1 秒間あたりの着呼率に換算すると、20 コール/秒という高い率になります。20 コール/秒の着呼率が 1 時間持続すると、1 時間あたりのコール数は 72,000 件になります。したがって、コール数/時間は、着信バースト トラフィック パターンを処理するシステムの能力を把握するという目的では有効なメトリックではありません。

Busy Hour Call Attempts(BHCA; 最繁時呼数)

1 日の最も忙しい時間(ピーク時間)に試行されたコールの数。これは 1 日の最も忙しい時間のコール数/秒と同じですが、1 秒間ではなく 1 時間で表します。たとえば、10 cps は 36,000 コール/時間と同じです。Busy Hour Call Completions(BHCC; 最繁時呼完了数)というメトリックもありますが、これは一部のコールが成功しなかった場合(ブロック要因が存在する場合など)、BHCA(試行されたコールの数)より低くなる可能性があります。この章では、呼完了率が 100% である(つまり、BHCA = BHCC)と仮定しています。

バースト トラフィック

安定した着呼は、ある期間にわたってコール試行の間隔がほぼ均等であることを意味します。たとえば、着呼率が安定しているときには、60 コール/時間はほぼ 1 分間に 1 回コール試行があることを示します(約 0.02 cps)。着呼が集中すると、ある一定の期間(1 時間など)に到着するコールの間隔が均等でなくなり、短時間にコールが集中して 1 ~数回のスパイクが生じます。最悪のケースでは、着呼率が同じ 60 コール/時間であっても、1 時間のうちの 1 秒間にすべてのコールが集中します。この場合は、その 1 時間中のほぼすべての時間の着呼率は平均 0 cps になり、1 秒間だけが 60 cps と突出します。この種のトラフィックをバースト トラフィックといい、通信システムに非常に大きな負担をかけます。

保留時間

音声コールの「通話時間」。つまり、コールのセットアップから終了までの間の、2 者間に通話路が開いている時間を示します。音声システムのトラフィック エンジニアリングで使用する保留時間の業界平均値は 3 分(180 秒)です。平均コールの保留時間が短くなるほど、コールのセットアップと終了に費やされるシステム CPU 時間の割合が、通話路の維持に費やされる CPU 時間に比べて高くなります。

PSTN トラフィック パターン

音声通信システムの文脈で使用される「トラフィック」は、送受信されるコールの量を指します。特に重要となるのは、PSTN などの外部回線によって伝送されるトラフィックです。トラフィックはアーランで測定され、1 アーランは「1 つのコールが 1 時間持続すること」と定義されています。この項では、アーランについては詳しく説明しません。単に、特定のトラフィック量に対して必要な回線の数を算出する際にアーラン B とアーラン C という数表を使用する、と述べるにとどめます。

必要な外部回線のサイズは、企業で受信および生成されるトラフィックの量によって決まります。ただし、お客様の多くは一般に、IP ベースの通信システムにおいても、それまで TDM ベースのシステムで使用していたのと同じ数の回線を使用し続けます。このサイジング方法は特に問題が発生しなければ有効ですが、その一方で継続的なシステム トラフィック分析プロセスを日常的なメンテナンス業務に組み込むことも重要です。トラフィック分析を行うと、現在のトラフィック レベルに対してシステムのプロビジョニングが過剰である(その結果、不要な回線にコストを費やしている)ことが判明したり、あるいは逆にプロビジョニングが不足していてコールのブロックや損失が起こる可能性のあることが指摘されたりします(この場合は回線数を増やすと状況が改善されます)。

一般業務のトラフィック プロファイル

ほとんどのお客様のトラフィック プロファイルは一般業務パターンです。これは、 最繁時 が通常 1 日 2 時間(午前 10:00 ~ 11:00 と午後 2:00 ~ 3:00)あることを意味します。これらの最繁時パターンは、多くの場合、1 日の業務の始まりや昼休み明けなどの要因に起因します。コールそのものは保留時間が長くなる傾向があり、安定的に着信、終了する傾向も見られます。トラフィック計算に使用する保留時間の一般的な業界平均値は、3 分です。

最繁時のトラフィックを考慮して通信システムを設計していれば、通常は問題は起こりません。それより低いレベルでシステムを設計していると、コールのブロックや損失が発生し、業務に悪影響をもたらすおそれがあります。

コンタクト センターのトラフィック プロファイル

コンタクト センターでは、通常ある一定数のオペレータまたは Interactive Voice Response(IVR; 自動音声応答)システムを利用して大量のコールを処理するという点で、少し異なるトラフィック パターンが見られます。コンタクト センターではリソースを最大限に活用する必要があるため、オペレータ、トランク、および IVR システムは業務時間中(通常は 1 日 24 時間)ずっと煩雑した状態が続きます。コール キューイングの使用が一般的で(着信コール トラフィックがオペレータの処理能力を超えると、次のオペレータが空くまでコールはキュー内で待機します)、オペレータは通常、自分の勤務時間の間、コンタクト センターに寄せられた電話の応対に専念します。

コンタクト センターでのコールの平均保留時間は、多くの場合、一般業務の電話よりも短くなります。コールの平均保留時間が短くなる理由は、IVR システムの段階で用件が済み、オペレータと通話しない場合が多いことによります(これを「セルフサービス コール」と呼ぶことがあります)。オペレータと通話した場合の平均保留時間は 3 分(一般業務トラフィックと同じ)であるのに対して、セルフサービス コールの典型的な保留時間は約 30 秒であることから、コンタクト センター全体での平均保留時間は一般業務トラフィックよりも短くなります。

リソース(IVR ポート、PSTN トランク、オペレータなど)の使用を最適化するというコンタクト センターの目標と、コンタクト センターが電話応対専門の組織であることを考え合せると、コンタクト センターのシステムでは通常の業務環境よりも着呼率は高くなります。これらの着呼率は、一般業務トラフィックとは異なる時間帯(通常の最繁時ではない時間帯)に異なる理由で最大になります。たとえば、特別な休日パックのテレビ CM を流して申し込み用のフリー ダイヤルを知らせた場合、その電話を受け付けるシステムの着呼率は、CM 放送後の約 15 分間にトラフィックのピークを迎えます。この着呼率は、コンタクト センターの平均着呼率を 1 桁上回ることもあります。

コンタクト センター トラフィックに対するゲートウェイのサイジング

短い通話時間とバースト性のある着呼率は、PSTN ゲートウェイのトラフィック処理能力に影響を与えます。このような状況では、通話時間の長いコールを一定期間にわたって均等に受けるような場合に比べて、すべてのコールをタイムリーに処理するためにゲートウェイでより多くのリソースが必要となります。ゲートウェイにはこのようなトラフィック パターンを処理するさまざまな機能が装備されているため、ゲートウェイを選定する際は使用する環境を考慮して入念に検討する必要があります。ゲートウェイの中には、サポートする T1/E1 ポートの数が多い機種や、同時に着信した複数コールの処理能力が高い機種などがあります。

複数のコールがほぼ同時に着信する(つまり、着呼率が高い、またはバースト性がある)トラフィック パターンでは、適切なコール数/秒(cps)性能を持つゲートウェイが最も適しています。このような状況で、コールの保留時間を 15 秒と仮定した場合、Cisco AS5400XM ユニバーサル ゲートウェイでは 16 cps(一度にアクティブにできるコール数は 250)、Cisco 3845 サービス統合型ルータでは 13 cps(一度にアクティブにできるコール数は 200)、Cisco 3945 サービス統合型ルータでは 28 cps(一度にアクティブにできるコール数は 420)を維持できます。Cisco AS5350XM ユニバーサル ゲートウェイのパフォーマンスは、コール数/秒の観点では AS5400XM と同等です。

着呼率が安定したトラフィック パターンでは、通常、ゲートウェイが処理可能なアクティブ コールの最大数がより重要になります。このような状況で、コールの保留時間を 180 秒と仮定した場合、Cisco AS5400XM ユニバーサル ゲートウェイでは 600 の同時アクティブ コール(着呼率は最大 3.3 cps)、Cisco 3845 サービス統合型ルータでは 450 の同時アクティブ コール(着呼率は最大 2.5 cps)、Cisco 3945 サービス統合型ルータでは 720 の同時アクティブ コール(着呼率は最大 4 cps)を維持できます。

これらの数値は、次の条件がすべて該当する場合を前提とします。

CPU 使用率が 75% を超えない。

PSTN ゲートウェイ コールは、ISDN PRI トランクで H.323 を使用して行われる。

Real Time Control Protocol(RTCP)タイマーがデフォルト値の 5 秒に設定されている。

Voice Activity Detection(VAD; 音声アクティビティ検出)がオフになっている。

G.711 のパケット化の周期は 20 ms である。

Cisco IOS Release 15.0.1M が使用されている。

専用の音声ゲートウェイ設定を使用し、イーサネット(GE)出力を有効に、QoS 機能を無効にしている (QoS 対応の出力インターフェイスまたはイーサネット以外の出力インターフェイス、あるいはその両方を使用すると、CPU リソースの消費量が増えます)。

付加コール機能や付加サービス、たとえばセキュリティ全般(アクセス コントロール リストやファイアウォールなど)、音声固有のセキュリティ(TLS、IPSec、SRTP)、AAA ルックアップ、ゲートキーパーを介したコール セットアップ、VoiceXML または TCL 対応のコール フロー、コール アドミッション制御(RSVP)、SNMP ポーリング/ロギングなどを有効にしていない。このような追加のコール機能を有効にすると、CPU リソースの消費量が増えます。

音声アクティビティ検出(VAD)

VAD は、コールの特定の方向の通話路が無音と認識されている間、IP パケットがほとんど生成されないようにするデジタル信号処理機能です。通常は、ある時点で発話しているのは一方の通話者だけなので、パケットは一方向だけに流れればよく、逆方向(無音方向)では不定期のキープアライブを除き、パケットを送信する必要はありません。そのため、VAD を使用すると、VoIP コールで送信される IP パケットの数が大幅に減少し、それに伴ってゲートウェイ プラットフォームの CPU サイクルも大幅に低下します。VAD によってパケットが実際にどの程度減少するかは、コール フロー、アプリケーション、および会話の状況によって異なりますが、VAD 設定を無効にした場合と比べて、パケットが 10 ~ 30% 少なくなる傾向があります。

VAD は、エンドポイントや Unified CM ネットワークに配置された音声ゲートウェイではほとんどの場合無効にされており、その他の種類のネットワークに配置された音声ゲートウェイでは、ほとんどの場合、有効にされています。

コーデック

G.711 と G.729A のサンプリング時間はどちらもデフォルトで 20 ms に設定されているため、VoIP コールの一方向のパケット レートは 50 パケット/秒(pps)になります。G.711 の IP パケット(200 バイト)は G.729A のパケット(60 バイト)よりも大きいですが、この差が音声ゲートウェイの CPU パフォーマンスに大きな影響を与えるとは実証されていません。G.711 と G.729 のパケットはどちらもルータには「小さい」IP パケットと見なされます。そのため、パケット レートは CPU パフォーマンスに影響を与える重要なコーデック パラメータです。

パフォーマンスの過負荷

Cisco IOS は、割り込みレベルのイベントを処理するために、ピーク処理中にも CPU の使用率が 100% にならないように設計されています。この項に示すパフォーマンスの数値は、約 75% の平均的な負荷を実行しているプロセッサを基にしています。特定の Cisco IOS ゲートウェイの負荷がこのしきい値を継続的に超えると、次のようになります。

Cisco Technical Assistance Center(TAC)でその配置がサポートされなくなります。

Cisco IOS ゲートウェイで、Q.921 タイムアウト、ダイヤル後遅延の増大、インターフェイス フラップなどの異常な動作が起こります。

Cisco IOS ゲートウェイは短時間のコールのバーストであれば処理できるようになっていますが、推奨される着呼率(コール数/秒)が継続的に超過するような状況はサポートされていません。


) ゲートウェイに未使用のハードウェア ポートがある場合は、そのポートを他のタスクに割り当てたくなるものです(たとえば、CMM ゲートウェイで、トラフィック計算によってPSTN トラフィックに一部のポートしか使えないことがわかっている場合など)。しかし、残りのポートは必ず未使用のままにしておく必要があります。そうしないと、CPU がサポートされるレベルを超えて過負荷状態に陥ります。


パフォーマンスの調整

Cisco IOS 音声ゲートウェイの CPU 使用率は、シャーシで有効にされているすべてのプロセスの影響を受けます。最も低レベルのプロセスの一部(IP ルーティングやメモリのデフラグなど)は、シャーシにライブ トラフィックがないときにも実行されます。

CPU 使用率が下がると、リアルタイムの音声パケットやコール セットアップ命令の処理に十分な CPU リソースを使用できるようになり、Cisco IOS 音声ゲートウェイのパフォーマンスが向上します。CPU 使用率を削減する手法のいくつかを 表 13-2 に示します。

表 13-2 CPU 使用率を削減する手法

手法
CPU 使用率の削減量
説明

VAD を有効にする

最大 20%

VAD を有効にすると、標準的な会話において音声パケットの量が最大 45% 減少します。問題は、音声認識を使用している場合や遅延が長い場合に音声品質が低下する可能性があることです。音声はトーク スパートの開始時に突然生じ、終了時に唐突に消失するように感じられます。

RTCP を無効にする

最大 5%

RTCP を無効にすると、発信側と着信側のゲートウェイ間で送信されるアウトオブバンド情報が減少します。その結果、相手側のゲートウェイに表示される統計情報の品質が低下します。また、コールがすでにアクティブでないかどうかを判断するために RTCP パケットが使用されている場合は、着信側ゲートウェイでコールの「未完結状態」が長くなる可能性があります。

その他の重要でない機能(認証、許可、アカウンティング(AAA)、簡易ネットワーク管理プロトコル(SNMP)、ロギングなど)を無効にする

最大 2%

これらのプロセスは、必要でない場合は無効にできます。これらのプロセスを無効にすると、CPU がその分解放されて CPU 使用率が低下し、リアルタイム トラフィックの処理が高速になります。

コール パターンを変更してコールの長さを長くする(これにより、1 秒あたりのコール数を削減する)

可変

これはさまざまな手法で実現できます。たとえば、コールの最初に長い導入プロンプトを再生する(または既存の導入プロンプトを長くする)、コール スクリプトをコール センターで調整する、といった手法があります。

追加情報

Cisco 音声ゲートウェイの機能とコール センター トラフィックの分析の詳細については、次の資料を参照してください。

Cisco Voice Gateway ソリューション:

http://www.cisco.com/en/US/products/sw/voicesw/index.html#~all-prod

Cisco Unified Communications Manager(Unified CM)でサポートされるゲートウェイ プロトコル:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_0_1/ccmsys/a08gw.html

次の Cisco Voice Gateway でサポートされるインターフェイスおよびシグナリング タイプ:

Cisco 3900 シリーズ サービス統合型ルータ

http://www.cisco.com/en/US/products/ps10536/products_relevant_interfaces_and_modules.html

Cisco 2900 シリーズ サービス統合型ルータ

http://www.cisco.com/en/US/products/ps10537/products_relevant_interfaces_and_modules.html

Cisco 3800 シリーズ サービス統合型ルータ

http://www.cisco.com/en/US/products/ps5855/products_relevant_interfaces_and_modules.html

Cisco 2800 シリーズ サービス統合型ルータ

http://www.cisco.com/en/US/products/ps5854/products_relevant_interfaces_and_modules.html

MGCP、SIP、および H.323 でサポートされるゲートウェイ機能:

http://www.cisco.com/en/US/prod/collateral/routers/ps259/product_data_sheet0900aecd8057f2e0.pdf

SIP ゲートウェイ RFC 準拠:

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps6831/product_data_sheet0900aecd804110a2.html

FXS ゲートウェイでサポートされる Skinny Client Control Protocol(SCCP)機能:

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps2250/ps5516/product_data_sheet09186a00801d87f6.html

ゲートウェイの容量、および会議、トランスコーディング、メディア ターミネーション ポイント(MTP)、MGCP、SIP、H.323 ゲートウェイ機能に必要な Cisco IOS および Unified CM の最小リリース:

http://www.cisco.com/en/US/prod/collateral/routers/ps259/product_data_sheet0900aecd8057f2e0.pdf

音声トラフィックに関する計算手法(アーラン計算など):

http://www.erlang.com/calculator/

ゲートウェイ冗長性に関する考慮事項

ゲートウェイ ソリューションを配置する際は、スケーラビリティと比較したときの冗長性を慎重に考慮してください。たとえば、Cisco VGD 1T3 Voice Gateway は、1 つの物理回路に 28 本の T1 回線を配信する機能を備えています。しかし、PSTN サービスに特有の冗長性に対するニーズを考慮すると、小規模な複数のゲートウェイで全体として物理的に同じ量のサービスを配信するほうが適しています。また、複数のゲートウェイを使用すると、異なる物理的ロケーションでの配置が可能になるため、1 レベル上の冗長性(この場合は空間的な冗長性)が実現されます。

さらに、緊急サービスとのアクセスにかかわるゲートウェイ配置についても考慮する必要があります。場合によっては、複数のソリューションが必要になることもあります。たとえば、リモートの本社にある SIP トランクを介してPSTN に接続されている小規模な支店ロケーションを考えてみます。WAN または SIP トランクに障害が発生した場合でも、支店ロケーションは緊急サービスにアクセスできる必要があります。この場合、最善のソリューションは、ローカルのアナログまたは PRI サービスです。つまり、スタンドアロンのアナログ サービスを使用するか、支店ルータ上で終端する PRI サービスを使用します。

TDM ゲートウェイと VoIP トランキング ゲートウェイ

2006 年ごろまでは、企業内部の VoIP ネットワークを外部の音声サービスに接続するには、従来のPSTN に接続された TDM ゲートウェイを経由する以外に方法はありませんでした。シスコの製品ラインナップには、PSTN をはじめ、PBX やキー システムにもアナログおよびデジタル接続できる各種 TDM ゲートウェイが揃っています。TDM 接続では、低密度アナログ(FXS、FXO)、低密度デジタル(BRI)、高密度デジタル(T1、E1、T3)など、さまざまなインターフェイスを選択できます。

2006 年ごろから、一般に「SIP トランク サービス」と呼ばれる企業向けの新しい音声サービス オプションがサービス プロバイダーから提供されるようになりました。PSTN やその他の企業外部の宛先に SIP トランクを使用して接続するには、企業の VoIP ネットワークのエッジで IP-to-IP 接続が必要です。この相互接続ポイントでは、これまで TDM ゲートウェイによって実現されていたものと同じ機能(境界の設定、コール アドミッション制御、QoS の確保、トラブルシューティングの境界の確保、セキュリティのチェックなど)が引き続き必要となります。SIP トランキング接続では、企業とサービス プロバイダー ネットワーク間の相互接続ポイントにある Cisco Unified Border Element がセッション ボーダー コントローラ(SBC)としてこれらの機能を実行します。Cisco Unified Border Element には、プロトコル変換機能により、H.323 機器と SIP 機器、または異なる種類の SIP 実装を使用した SIP 機器どうしを相互接続する機能もあります。Cisco Unified Border Element ではトランスコーディングも実行可能です。これらのいずれかの機能を利用する場合は、企業ネットワーク内部におけるプロトコル変換またはトランスコーディング サービスなしでは相互運用できない機器間の相互接続ポイントでも Cisco Unified Border Element を使用できます。

TDM ゲートウェイ プラットフォームについては、この章の残りの部分で詳しく説明します。Cisco Unified Border Element については、「Cisco Unified CM トランク」の章に詳細が記載されています。両方の機能を同一の Cisco Integrated Services Router(ISR)プラットフォームで同時に有効にできます。

Cisco ゲートウェイの概要

Cisco アクセス ゲートウェイを使用すると、Cisco Unified Communications Manager(Unified CM)と IP 以外の通信デバイスとの間で情報を交換できます。Cisco アクセス ゲートウェイには、アナログとデジタルの 2 種類があります。

Cisco アクセス アナログ ゲートウェイ

Cisco アクセス アナログ ゲートウェイには、トランク ゲートウェイとステーション ゲートウェイの 2 つのカテゴリがあります。

アクセス アナログ ステーション ゲートウェイ

アナログ ステーション ゲートウェイは、Unified CM を Plain Old Telephone Service(POTS; 一般電話サービス)のアナログ電話機、IVR システム、FAX マシン、およびボイスメール システムに接続します。ステーション ゲートウェイは、Foreign Exchange Station(FXS)ポートを備えています。

アクセス アナログ トランク ゲートウェイ

アナログ トランク ゲートウェイは、Unified CM をPSTN Central Office(CO; セントラル オフィス)または PBX トランクに接続します。トランク ゲートウェイは、PSTN、PBX、またはキー システムへのアクセス用の Foreign Exchange Office(FXO)ポート、および従来型の PBX とのアナログ トランク接続用の E&M(recEive and transMit、または ear and mouth)ポートを備えています。応答と接続解除の監視の問題を最小限に抑えるために、可能な限り、デジタル ゲートウェイを使用してください。アナログ Direct Inward Dialing(DID; ダイヤルイン方式)および Centralized Automatic Message Accounting(CAMA)も、PSTN 接続に使用できます。

Cisco アクセス デジタル トランク ゲートウェイ

Cisco アクセス デジタル トランク ゲートウェイは、Primary Rate Interface(PRI; 一次群速度インターフェイス)、Basic Rate Interface(BRI; 基本速度インターフェイス)、または T1 Channel Associated Signaling(CAS; 個別線信号方式)などのデジタル トランクを経由して、Unified CM をPSTN または PBX に接続します。デジタル T1 PRI トランクは、所定の従来型ボイスメール システムとの接続にも使用できます。

ゲートウェイ ゲイン設定の調整

ゲートウェイを介して Cisco Unified Communications ネットワークをPSTN に接続するには、停電、インピーダンスの不整合、および遅延などによるエコーや信号の減衰から生じる、音声品質問題に適切に対処する必要があります。このため、予期されるすべての音声パスに信号損失の状況を詳細に提供する Network Transmission Loss Plan(NTLP)を確立する必要があります。このプランを使用して、最適な声の大きさと効果的なエコー キャンセレーションを得るために信号の強さを調整する必要があるロケーションを識別できます。すべての通信事業者が同じ損失プランを使用するわけではないこと、また、セルラー ネットワークの存在が NTLP の作成をさらに複雑にすることに注意してください。このような NTLP を作成する前に、ゲートウェイで入力ゲインや出力衰退を調整することは推奨できません。詳細については、次の Web サイトで入手可能な『 Echo Analysis for Voice Over IP 』を参照してください。

http://www.cisco.com/en/US/docs/ios/solutions_docs/voip_solutions/EA_ISD.pdf

ゲートウェイの選択

IP テレフォニー ゲートウェイを選択する場合は、次の点を考慮してください。

「コア機能要件」

「ゲートウェイ プロトコル」

「ゲートウェイ プロトコルとコア機能要件」

「サイト固有のゲートウェイ要件」

コア機能要件

IP テレフォニー アプリケーションで使用するゲートウェイは、次のコア機能要件を満たす必要があります。

Dual Tone MultiFrequency(DTMF)リレー機能

DTMF リレー機能、特にアウトバンド DTMF は、DTMF ディジットを音声ストリームから切り離し、音声ストリームまたはベアラ トラフィックの一部としてではなく、ゲートウェイ プロトコル(H.323、SCCP、MGCP、または SIP)シグナリング チャネルを通じて、シグナリング標識として送信します。音声圧縮に低ビット レート コーデックを使用する場合、DTMF 信号の損失また歪みの可能性があるので、アウトバンド DTMF が必要です。

付加サービス サポート

付加サービスは、一般に、保留、転送、および会議などの基本的なテレフォニー機能です。

FAX/モデム サポート

FAX over IP により、従来のアナログ FAX マシンと IP テレフォニー ネットワークとの相互運用性が可能になります。FAX イメージは、アナログ信号から変換され、パケット ネットワークを介してデジタル データとして伝送されます。詳細については、「FAX とモデムのサポート」を参照してください

Unified CM 冗長性サポート

Cisco Unified Communications は、分散モデルに基づき、高いアベイラビリティを確保しています。Unified CM クラスタには、Unified CM の冗長性が用意されています。ゲートウェイは、プライマリ Unified CM に障害が発生した場合に、セカンダリ Unified CM への「re-home」機能をサポートする必要があります。冗長性は、Unified CM またはネットワークの障害時のコール存続可能性とは異なります。

企業での配置用に選択する IP テレフォニー ゲートウェイがすべて、上記のコア要件を満たしていることを確認するには、ゲートウェイ製品の資料を参照してください。さらに、どの IP テレフォニーの実装についても、各サイト特有の機能要件(たとえば、アナログまたはデジタル アクセス、DID、およびキャパシティ要件)があります(「サイト固有のゲートウェイ要件」を参照してください)。

ゲートウェイ プロトコル

Cisco Unified CM(Release 3.1 およびそれ以降)では、次のゲートウェイ プロトコルがサポートされています。

H.323

メディア ゲートウェイ コントロール プロトコル(MGCP)

Cisco Unified CM Release 4.0 以降では、トランク側での Session Initiation Protocol(SIP)がサポートされています。Cisco Unified CM Release 5.0 ~ 7. x の SIP トランクの実装は、より多くの機能をサポートするよう拡張されました。

プロトコルの選択は、サイト特有の要件と機器の設置ベースによって決まります。ゲートウェイの設定では、MGCP は設定が単純なので H.323 または SIP よりも優先されます。一方、サポートされるインターフェイスの堅牢性により、H.323 または SIP が MGCP より優先される場合もあります。

Simplified Message Desk Interface(SMDI)は、ボイスメール システムを PBX または Centrex システムに統合するための標準です。SMDI を介してボイスメール システムに接続し、アナログ FXS またはデジタル T1 PRI を使用するには、SCCP または MGCP プロトコルが必要です。これは、H.323 または SIP デバイスは、ポートのグループから、使用される特定の回線を識別しないからです。この目的に H.323 または SIP ゲートウェイを使用すると、Cisco Message Interface は、着信コールに使用される実際のポートまたはチャネルと、SMDI 情報とを正常に相関させることができません。

また、使用される Unified CM の配置モデルも、ゲートウェイ プロトコルの選択に影響を与える場合があります (「Unified Communications の配置モデル」の章を参照してください)。


) 配置する前に、Cisco IOS ソフトウェアのリリース ノートを調べて、機能またはインターフェイスのサポートを確認してください。


ゲートウェイ プロトコルとコア機能要件

ここでは、各プロトコル(SCCP、H.323、MGCP、および SIP)が次のゲートウェイ機能要件をどのようにサポートするかについて説明します。

「DTMF リレー」

「付加サービス」

「Unified CM の冗長性」

DTMF リレー

DTMF は、信号に音声帯域内の特定の周波数ペアを使用するシグナリング方式です。64 kbps の Pulse Code Modulation(PCM; パルス符号変調)音声チャネルは、これらの信号を容易に伝送できます。しかし、音声圧縮に低ビット レート コーデックを使用する場合、DTMF 信号の損失または歪みの可能性があります。Voice over IP(VoIP)インフラストラクチャを介して DTMF トーンを伝送するアウトバンド シグナリング方式は、コーデックにより誘発されるこれらの症状を簡単に解決します。

SCCP ゲートウェイ

Cisco VG248 は、伝送制御プロトコル(TCP)ポート 2002 を使用して、DTMF 信号をアウトバンドで伝送します。アウトバンド DTMF は、VG248 用のデフォルトのゲートウェイ コンフィギュレーション モードです。

H.323 ゲートウェイ

Cisco 3800 シリーズ製品などの H.323 ゲートウェイは、DTMF 信号をアウトバンドで交換するための拡張 H.245 機能を使用して、Unified CM と情報を交換できます。次の例は、Cisco IOS ゲートウェイ上のアウトバンド DTMF 設定例です。

dial-peer voice 100 voip
destination-pattern 555....
session target ipv4:10.1.1.1
CODEC g729ar8
dtmf-relay h245-alphanumeric
preference 0
 

MGCP ゲートウェイ

Cisco IOS ベースのプラットフォームでは、Unified CM 通信に MGCP を使用します MGCP プロトコルには、 パッケージ の概念があります。MGCP ゲートウェイは、始動後、DTMF パッケージをロードします。MGCP ゲートウェイは、制御チャネルを介して、受信した DTMF トーンを表す シンボル を送信します。次に、Unified CM は、これらの信号を解釈し、アウトバンドでシグナリング エンドポイントに DTMF 信号を渡します。DTMF リレーのグローバル コンフィギュレーション コマンドは、次のとおりです。

mgcp dtmf-relay VOIP codec all mode out-of-band
 

Unified CM MGCP ゲートウェイ設定インターフェイスで、追加の設定パラメータを入力する必要があります。

デフォルトで DTMF リレーは使用可能であり、追加の設定は必要ありません。


) RFC 2833 を通じて DTMF を有効にするには、fm-package コマンドを使用します。このコマンドは、Cisco IOS Release 12.4(6)T 以降で使用できます。


SIP ゲートウェイ

Cisco IOS ベースのプラットフォームでは、Unified CM 通信に SIP を使用できます これらのプラットフォームはさまざまな方式の DTMF をサポートしていますが、Unified CM との通信に使用できるのは次の方式だけです。

Named Telephony Events(NTE)、または RFC 2833

Unsolicited SIP Notify(UN)

Key Press Markup Language(KPML)

次の例は、NTE 用の設定を示しています。

dial-peer voice 100 voip
destination-pattern 555....
session target ipv4:10.1.1.1
session protocol sipv2
dtmf-relay rtp-nte
 

次の例は、UN 用の設定を示しています。

dial-peer voice 100 voip
destination-pattern 555....
session target ipv4:10.1.1.1
session protocol sipv2
dtmf-relay sip-notify
 

DTMF 方式の選択の詳細については、「メディア リソース」の章を参照してください。

付加サービス

付加サービスは、保留、転送、および会議などのユーザ機能を提供します。これらのサービスは、音声通信の確立の基本的な要件であると見なされます。IP テレフォニー ネットワークでの使用について評価される各ゲートウェイは、ソフトウェアの Media Termination Point(MTP; メディア ターミネーション ポイント)を使用しなくても、独自に付加サービスをサポートする必要があります。

SCCP ゲートウェイ

Cisco SCCP ゲートウェイは、完全な付加サービス サポートを提供します。また、Cisco IOS Release 12.4.9T で FXS SCCP ポートもサポートしています。SCCP ゲートウェイは、ゲートウェイと Unified CM 間のシグナリング チャネル、および SCCP を使用して、呼制御パラメータを交換します。

H.323 ゲートウェイ

H.323v2 は、Open/Close LogicalChannel 機能と emptyCapabilitySet 機能を実行します。Cisco IOS Release 12.0(7)T および Cisco Unified CM Release 3.0 以降から始まった、H.323 ゲートウェイによる H.323v2 の使用により、MTP が付加サービスを提供する必要がなくなりました。Unified CM Release 3.1 以降では、トランスコーダが動的に割り当てられるのは、G.711 専用デバイスへのアクセスを提供すると同時に、WAN を介した G.729 ストリームを保持するために、コール中に必要な場合だけです。H.323v2 に対するフル サポートは、Cisco IOS Release 12.1.1T で利用可能です。

Unified CM を H.323 プロキシとして使用して、Cisco IOS ゲートウェイと IP Phone 間で H.323v2 コールがセットアップされた後は、その IP Phone は、ベアラ接続の変更を要求できます。Real-Time Transport Protocol(RTP)ストリームは、Cisco IOS ゲートウェイから IP Phone に直接接続されるので、サポートされる音声コーデックをネゴシエートできます。

図 13-1 と次の手順では、2 台の IP Phone 間のコール転送を示しています。

1. 電話機 1 が Cisco IOS ゲートウェイから電話機 2 にコールを転送しようとする場合、電話機 1 は、SCCP を使用して Unified CM に転送要求を出します。

2. Unified CM は、この要求を H.323v2 CloseLogicalChannel 要求に変換して、Cisco IOS ゲートウェイに送信して、適切な SessionID を求めます。

3. Cisco IOS ゲートウェイは、電話機 1 との RTP チャネルをクローズします。

4. Unified CM は、SCCP を使用して、Cisco IOS ゲートウェイとの RTP 接続をセットアップする要求を、電話機 2 に出します。同時に、Unified CM は、新しい宛先パラメータを指定して(ただし、同じ SessionID を使用)、Cisco IOS ゲートウェイに OpenLogicalChannel 要求を出します。

5. Cisco IOS ゲートウェイがこの要求を確認した後、RTP 音声ベアラ チャネルが、電話機 2 と Cisco IOS ゲートウェイとの間で確立されます。

図 13-1 H.323 ゲートウェイの付加サービス サポート

 

MGCP ゲートウェイ

MGCP ゲートウェイは、MGCP プロトコルを使用して、保留、転送、および会議機能を完全にサポートします。MGCP プロトコルは、すべてのセッション機能を制御する、Unified CM とのマスター/スレーブ プロトコルであるので、Unified CM は、MGCP ゲートウェイの音声接続を容易に操作できます。IP テレフォニー エンドポイント(たとえば、IP Phone)が、セッションの変更(たとえば、コールを別のエンドポイントに転送する)を必要とする場合、そのエンドポイントは、セッションの変更を SCCP を使用して Unified CM に通知します。次に、Unified CM は、Session ID に関連した現在の RTP ストリームを終了し、新しいエンドポイント情報を使用して新しいメディア セッションを開始することを、MGCP ユーザ データグラム プロトコル(UDP)制御接続を使用して、MGCP ゲートウェイに通知します。図 13-2 では、プロトコルが MGCP ゲートウェイ、エンドポイント、および Unified CM 間で交換される様子を示しています。

図 13-2 MGCP ゲートウェイの付加サービス サポート

 

SIP ゲートウェイ

Cisco IOS SIP ゲートウェイへの Unified CM SIP トランク インターフェイスは、保留、ブラインド転送、在席転送などの付加サービスをサポートしています。付加サービスのサポートは、INVITE や REFER などの SIP 方式によって実現されます。詳細については、次のマニュアルを参照してください。

Cisco Unified Communications Manager System Guide 』。次のサイトにあります。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

Cisco IOS SIP Configuration Guide 』。次のサイトにあります。

http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/12_4t/sip_12_4t_book.html

Unified CM の冗長性

IP テレフォニー アーキテクチャの必須部分は、高価な専有の従来型の PBX システムの代わりに、低コストの分散型 PC ベース システムを提供することです。この分散型設計は、クラスタ化された Unified CM の堅固なフォールト トレラント アーキテクチャに適しています。最も単純な形式(2 システムのクラスタ)であっても、セカンダリ Unified CM は、最初にプライマリ Unified CM によって管理されていたすべてのゲートウェイの制御権を引き受ける必要があります。

SCCP ゲートウェイ

ブート後、Cisco VG224、VG248、および ATA 188 ゲートウェイには、Unified CM サーバ情報が提供されます。これらのゲートウェイが初期設定されるときに、Unified CM のリストがゲートウェイにダウンロードされます。このリストでは、プライマリ Unified CM とセカンダリ Unified CM に優先順位が付けられています。プライマリ Unified CM が通信不能になった場合、ゲートウェイはセカンダリ Unified CM に登録されます。

WAN リンク障害用の H.323 VoIP コール プリザベーション

WAN リンク障害用の H.323 VoIP コール プリザベーション拡張機能を使用すると、他のエンドポイントとは異なるエンティティ(シグナリングをルーティングするゲートキーパーや、接続している 2 者間でシグナリングを仲介するコール エージェント(Cisco BTS 10200 Softswitch、Cisco PGW2200 Softswitch、Cisco Unified CM など)など)によってシグナリングが処理される H.323 トポロジにおいて、接続性が維持されます。コール プリザベーションが役立つのは、ゲートウェイと他のエンドポイント(通常は Cisco Unified IP Phone)は同じサイトにあるものの、コール エージェントがリモート サイトにあり、接続障害が起こりやすいような場合です。

H.323 コール プリザベーションは、次の種類の障害と接続に対応します。

障害の種類:

WAN リンクのフラッピングや性能低下などの WAN 障害

Cisco Unified CM ソフトウェアの障害(Unified CM サーバでの ccm.exe サービスのクラッシュなど)

LAN 接続の障害(障害がローカル ブランチで発生した場合を除く)

接続の種類:

Cisco Unified CM で制御された 2 つのエンドポイント間のコールで、次の条件に該当する場合

Unified CM がリロード中の場合

一方または両方のエンドポイントと Unified CM との間で H.225.0 または H.245 メッセージのシグナリングに使用される伝送制御プロトコル(TCP)接続が失われたか、フラッピングしている場合

エンドポイントがクラスタ内の異なる Unified CM に登録されていて、その 2 つの Unified CM 間の TCP 接続が失われた場合

IP Phone 間のコールで、PSTN が同じサイトにある場合

ソフトスイッチによって制御されている Cisco IOS ゲートウェイとエンドポイント間のコールで、シグナリング(H.225.0、H.245、またはその両方)フローはゲートウェイとソフトスイッチ間で実行され、メディア フローはゲートウェイとエンドポイント間で実行される場合

ソフトスイッチがリロード中の場合

ゲートウェイとソフトスイッチ間の H.225.0 または H.245 TCP 接続が失われ、ソフトスイッチがエンドポイント上のコールをクリアしない場合

ソフトスイッチとエンドポイント間の H.225.0 または H.245 TCP 接続が失われ、ソフトスイッチがゲートウェイ上のコールをクリアしない場合

メディア フローアラウンド モードで動作している Cisco Unified Border Element(旧称 Cisco Multiservice IP-to-IP Gateway)がコール フローに含まれていて、その Cisco Unified Border Element がリロードしているか、ネットワークの残りの部分との接続を失った場合

メディアが保持された後、一方の通話者が電話を切るか、メディアがアクティブでないことが検出されると、コールは終了します。コンピュータによって生成されたメディア ストリーム(メディア サーバからの音楽ストリーミングなど)が存在する場合は、メディア非アクティビティ検出は機能しませんが、コールは保留になる可能性があります。Cisco Unified CM はこの状況に対処するため、このようなコールは保持しないようにゲートウェイに指示しますが、サードパーティ製デバイスや Cisco Unified Border Element はそうしたことは行いません。

この機能において、フラッピングは「IP 接続の一時的な喪失が何度も繰り返されること」と定義されています。このような現象は、WAN または LAN の障害によって発生する可能性があります。Cisco IOS ゲートウェイと Cisco Unified CM 間の H.323 VoIP コールは、フラッピングが起こると終了する場合があります。Unified CM は、TCP 接続が失われたことを検出すると、コールをクリアし、TCP FIN を送信してコールで使用されていた TCP ソケットを閉じます。このとき、H.225.0 Release Complete メッセージまたは H.245 End Session メッセージは送信しません。これを quiet clearing と呼びます。ネットワークが短時間復帰した間に Unified CM から送信された TCP FIN がゲートウェイに到達すると、ゲートウェイはコールを終了します。TCP FIN がゲートウェイに到達しなくても、ネットワークが復帰すると、ゲートウェイから送信された TCP キープアライブが Unified CM に到達します。Unified CM はすでに TCP 接続を閉じているので、キープアライブに応答して TCP RST メッセージを送信します。ゲートウェイは RST メッセージを受け取ると、H.323 コールを終了します。

WAN リンク障害用の H.323 VoIP コール プリザベーション拡張機能の設定には、 call preserve コマンドの設定を含める必要があります。Cisco Unified Communications Manager を使用している場合は、Service Parameters ウィンドウから Allow Peer to Preserve H.323 Calls パラメータを有効にする必要があります。

call preserve コマンドを発行すると、H.225.0 または H.245 接続でのアクティブ コールに関するソケットの終了またはソケット エラーがゲートウェイで無視されるため、これらの接続を使用しているコールを終了せずにソケットを閉じることができます。

すべてのコールに対して H.323 VoIP コール プリザベーションを有効にする例

次の設定例では、すべてのコールに対して H.323 VoIP コール プリザベーションを有効にします。

voice service voip
h323
call preserve
 

MGCP ゲートウェイ

MGCP ゲートウェイにも、プライマリ Unified CM との通信が失われた場合に、セカンダリ Unified CM にフェールオーバーする機能があります。フェールオーバーが起きても、アクティブ コールは保持されます。

MGCP ゲートウェイのコンフィギュレーション ファイル内で、プライマリ Unified CM は、 call-agent <hostname> コマンドを使用して指定され、セカンダリ Unified CM のリストは、 ccm-manager redundant-host コマンドを使用して追加されます。プライマリ Unified CM とのキープアライブは、MGCP アプリケーション レベルのキープアライブ メカニズムを介して行われます。このメカニズムでは、MGCP ゲートウェイは、空の MGCP notify(NTFY)メッセージを Unified CM に送信し、確認応答を待ちます。バックアップ Unified CM とのキープアライブは、TCP キープアライブ メカニズムを介して行われます。

プライマリ Unified CM が後で使用可能になると、MGCP ゲートウェイは、元の Unified CM に「re-home」(つまり復帰)できます。この復帰は、ただちに行われることもあれば、設定可能な時間が経過した後、または接続されているすべてのセッションが解除された後に行われることもあります。これは、次のグローバル コンフィギュレーション コマンドを使用して使用可能になります。

ccm-manager redundant-host <hostname1 | ipaddress1 > <hostname2 | ipaddress2>
[no] call-manager redundancy switchback [immediate|graceful|delay <delay_time>]
 

SIP ゲートウェイ

Cisco IOS SIP ゲートウェイでの冗長性は、H.323 と同様の方法で実現できます。SIP ゲートウェイがプライマリ Unified CM との接続を確立できない場合、高い優先順位を持ち、別の dial-peer ステートメントで指定されるセカンダリ Unified CM との接続を試行します。

デフォルトでは、Cisco IOS SIP ゲートウェイは dial-peer で設定された Unified CM の IP アドレスに SIP INVITE 要求を 6 回送信します。SIP ゲートウェイは、その Unified CM から応答を受信しなかった場合、他の dial-peer で設定された、優先順位の高い Unified CM との接続を試行します。

Cisco IOS SIP ゲートウェイは、INVITE に対する SIP 100 応答を 500 ms 待ちます。デフォルトでは、Cisco IOS SIP ゲートウェイがバックアップ Unified CM に到達するまでに最大 3 秒かかります。SIP INVITE の再試行回数は、 sip-ua 設定で retry invite <number> コマンドを使用して変更できます。また、Cisco IOS SIP ゲートウェイが SIP INVITE 要求に対する SIP 100 応答を待つ期間は、 sip-ua 設定で timers trying <time> コマンドを使用して変更できます。

バックアップ Unified CM へのフェールオーバーを高速化する別の方法としては、 dial-peer 文での monitor probe icmp-ping コマンドの設定があります。Unified CM がインターネット制御メッセージ プロトコル(ICMP)エコー メッセージ(ping)に応答しなかった場合、そのダイヤル ピアはシャットダウンされます。このコマンドが役に立つのは、Unified CM が到達不能のときだけです。ICMP エコーメッセージは、10 秒ごとに送信されます。

次のコマンドを使用すると、Cisco IOS SIP ゲートウェイに対して Unified CM の冗長性を設定できます。

sip-ua
retry invite <number>
timers trying <time>
 
dial-peer voice 101 voip
destination-pattern 2...
session target ipv4:10.1.1.101
preference 0
monitor probe icmp-ping
session protocol sipv2
 
 
dial-peer voice 102 voip
destination-pattern 2...
session target ipv4:10.1.1.102
preference 1
monitor probe icmp-ping
session protocol sipv2
 

サイト固有のゲートウェイ要件

IP テレフォニーの実装にはそれぞれ、サイト固有の要件があります。次の質問は、IP テレフォニー ゲートウェイの選択に役立ちます。

PSTN (または PBX)アクセスは、アナログですか、デジタルですか。

PSTN または PBX には、どのタイプのアナログ(FXO、FXS、E&M、DID、CAMA)インターフェイス、またはデジタル(T1、E1、CAS、CCS)インターフェイスが必要ですか。

PSTN アクセスがデジタルである場合、どのタイプのシグナリングが必要ですか(T1 CAS、Q.931 PRI、E1 CAS、または R2)。

PBX は、現在どのタイプのシグナリングを使用していますか。

FXO または FXS: ループ スタートまたはグラウンド スタート

E&M: ウィンク スタート、ディレイ スタート、またはイミディエート スタート

E&M: タイプ I、II、III、IV、または V

T1: CAS、Q.931 PRI(ユーザ側またはネットワーク側)、QSIG、DPNSS、または Proprietary D チャネル(CCS)シグナリング

E1: CAS、R2、Q.931 PRI(ユーザ側またはネットワーク側)、QSIG、DPNSS、Proprietary D チャネル(CCS)シグナリング

PBX は、現在どのタイプのフレーム同期(SF、ESF、または G.704)と回線エンコーディング(B8ZS、AMI、CRC-4、または HDB3)を使用していますか。

PBX に、専有シグナリングを渡す必要がありますか。必要な場合、そのシグナリングはどのタイムスロットで渡されますか。それは HDLC フレームですか。

ゲートウェイにどれくらいのキャパシティが必要ですか。つまり、チャネルがいくつ必要ですか (一般に、音声チャネルが 12 本以上必要な場合は、デジタルの方が、アナログ ソリューションより費用対効果が高くなります)。

ダイヤルイン方式(DID)が必要ですか。必要な場合は、アナログか、デジタルかを指定してください(日本ではアナログ DID 未対応)。

発呼回線 ID(CLID)が必要ですか。

発信者名が必要ですか。

どのタイプの FAX およびモデム サポートが必要ですか。

どのタイプの音声圧縮が必要ですか。

どのタイプの付加サービスが必要ですか。

PBX はクロッキングをサポートしますか。または PBX は、Cisco ゲートウェイがクロッキングをサポートすることを期待しますか。

必要なすべてのゲートウェイ、ルータ、およびスイッチを収容するラック スペースがありますか。


Direct Inward Dial(DID; ダイヤルイン方式)とは、オペレータが介在しなくても、外部コールを直接、端末回線に着信できるようにする Private Branch eXchange(PBX; 構内交換機)またはセントレック(Centrex)機能のことです。



発呼回線 ID(CLI、CLID、または ANI)とは、着呼側に対して発信番号を表示する、デジタル電話ネットワークで利用可能なサービスを指します。セントラル オフィス機器は、発信者の電話番号を識別し、発信者についての情報をコール自体と一緒に送信できるようにします。CLID は、Automatic Number Identification(ANI; 自動番号識別)と同義です。


Cisco Unified Communications ゲートウェイは、大部分の主要 PBX ベンダー製品と相互運用でき、EIA/TIA-464B に準拠しています。

可能な選択肢を絞り込むには、サイト固有およびコアのゲートウェイ要件から始めるのが適しています。必要な機能を指定した後、該当する設定ごとに、企業における規模と複雑さが異なる単一サイトの配置であるか、マルチサイトによる配置であるかに関係なく、ゲートウェイの選択を行うことができます。

次の表では、さまざまな Cisco ゲートウェイ モデルによってサポートされる機能とインターフェイス タイプをまとめています。


) 次の表では、Cisco IOS および Unified CM のリリース番号は、リストされている機能を特定のゲートウェイ プラットフォーム上でサポートできるようになったリリースを指しています。Cisco IOS 機能の詳細については、Cisco Feature Navigator(http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp)を参照してください。


FAX とモデムのサポート

ここでは、Unified CM と Cisco 音声ゲートウェイで使用可能な FAX とモデムのサポートについて説明します。まず、Cisco 音声ゲートウェイ上での FAX とモデムのサポートの概要を説明した後、サポートされるプラットフォームとコンフィギュレーション ファイル例をリストします。

ゲートウェイでの FAX パススルーと FAX リレーのサポート

FAX over IP により、従来のアナログ FAX マシンと IP テレフォニー ネットワークとの相互運用性が可能になります。FAX イメージは、アナログ信号から変換され、パケット ネットワークを介してデジタルで伝送されます。

元の形式では、FAX データはデジタルで、ハイレベル データ リンク制御(HDLC)フレームに含まれています。しかし、従来のPSTN を経由して送信するために、これらのデジタル HDLC フレームはアナログ搬送波に変調されます。このアナログ搬送波は、PSTN 環境で効果的に FAX を送信するためには必要ですが、IP パケット ネットワークで使用されるデジタル転送方式にとっては最適ではありません。そのため、IP インフラストラクチャ上で FAX を送信できるように、専用の転送方法が考案されました。

IP 上で FAX を転送する主な方法には、パススルーとリレーの 2 つがあります。パススルーは最も単純な方法で、音声コーデックが人間の音声に対して行うのと同じように、アナログ FAX 信号をサンプリングしてデジタル化します。使用可能なコーデックは多数存在しますが、Cisco 音声ゲートウェイのパススルーでは、アナログ FAX 信号の歪みが最も少ないという理由で、常に G.711 コーデックを使用して FAX 情報が伝送されます。元の音声コールで高圧縮コーデックが使用されている場合は、アップスピード機能を使用してそのコーデックが G.711 に変更されます。パススルーは一般に Voice Band Data(VBD; 音声帯域データ)とも呼ばれています。シスコでは、モデム パススルーと FAX パススルーの 2 種類のパススルーを提供しています。この 2 つのパススルー バージョンの名前は、Cisco IOS コマンドライン インターフェイス(CLI)での設定から導出されます。これらのパススルー バージョン間のこの他の違いは、スイッチオーバーとトリガー トーンに集中しています。これらについては、以降の各パラグラフで詳しく説明します。

モデム パススルーは、通常、シスコ独自の Named Signaling Event(NSE)パケットを使用して、コールを音声モードからパススルー モードに切り替えます。一般に、これは NSE ベースのスイッチオーバーと呼ばれます。この音声モードからパススルーへの切り替えは、FAX パススルーだけでなくリレーにとっても重要な概念です。Cisco 音声ゲートウェイ上のコールはすべて音声コールとして開始され、そのコールが FAX コールであるとゲートウェイで認識された場合にだけ、モードが適切に切り替えられます。

モデム パススルー機能は、FAX またはモデム コールの開始時に、2100 Hz CED または ANSam トーンによってトリガーされます。CED トーンは G3 FAX および低速モデムと関連付けられていますが、ANSam トーンは SG3 FAX および高速モデムによって使用されます。従来的には、ANSam または CED トーンが検出されたとき、モデム パススルーはシスコ独自の NSE パケットを使用して、音声モードからモデム パススルーへのスイッチオーバーのリモート音声ゲートウェイをシグナリングしていました。しかし現在は、モデム パススルーでは、NSE ベースのスイッチオーバーだけでなく、H.323 または SIP 呼制御プロトコルを使用したプロトコルベースのスイッチオーバーもサポートしています。モデム パススルーは、H.323 または SIP を使用してスイッチオーバーを処理するように設定されている場合、標準ベースの NTE メッセージも使用します。これにより、オプションでリモート音声ゲートウェイをシグナリングして、エコー キャンセラを無効にします。このようなモデム パススルーの拡張機能によって、サードパーティ製のデバイスとの相互運用性が向上します。これらの拡張機能は、Cisco IOS Release 12.4(24)T 以降で導入されています。

その名前にかかわらず、モデム パススルーは FAX コールにも広く使用されます。モデム パススルーをアクティブにするには、Cisco IOS コマンドライン インターフェイス(CLI)で、 modem passthrough コマンド(H.323、SIP、および SCCP 音声ゲートウェイの場合)か、 mgcp modem passthrough コマンド(MGCP 音声ゲートウェイの場合)を使用します。

FAX パススルーでは、モデム パススルーとは異なり、NSE ベースのスイッチオーバーをサポートしていません。FAX パススルーでは常に、基礎となる呼制御プロトコルに基づいて、コールを音声モードから FAX パススルーに切り替えます。FAX パススルーでは、H.323 および SIP の呼制御プロトコルを使用して、プロトコルベースのスイッチオーバーだけをサポートしています。FAX パススルーでは、スイッチオーバーに呼制御プロトコルを利用するため、通常はサードパーティ製のデバイスと相互運用できます。

FAX パススルーは、G3 FAX コールに関連付けられた V.21 フラグの検出によってトリガーされます。したがって、この転送方式はモデムや SG3 FAX コールに対しては使用できません。H.323 および SIP 音声ゲートウェイ上で FAX パススルーを有効にするコマンドは、 fax protocol pass-through です。

図 13-3 は、Cisco 音声ゲートウェイで FAX コールに使用される 2 種類のパススルー実装を示しています。

図 13-3 シスコの FAX コール用のパススルー実装

 

リレーは IP 上で FAX を送信するもう 1 つの主要な方法で、その実装はパススルーに比べて少し複雑です。リレーは、 復調 と呼ばれるプロセスによって FAX 信号からアナログ搬送波を取り除き、FAX HDLC データ フレームを復元します。続いて、これらの HDLC フレームから関連情報を取り出して FAX リレー プロトコルに効率的にパッケージ化し、相手側のゲートウェイに転送します。相手側で受信されると、FAX 情報がリレー プロトコルから取り出されて FAX HDLC フレームに再構築され、アナログ搬送波に変調されて FAX マシンに送信されます。

シスコは、T.38 と Cisco FAX リレーの 2 種類の FAX リレーをサポートしています。ITU 標準の T.38 を使用すると、T.38 仕様をサポートしているサードパーティ製デバイスと Cisco ゲートウェイを相互運用できます。ほとんどの場合、T.38 FAX リレーは呼制御プロトコルを使用して音声モードを T.38 FAX リレー モードに切り替えます(これをプロトコルベースまたは標準ベースの T.38 FAX リレーと呼びます)。ただし、シスコ独自の NSE を使用してモード切り替えを行うように T.38 FAX リレーを設定することもできます(これを NSE ベースの T.38 FAX リレーと呼びます)。サードパーティ製デバイスとの相互運用性を確保するには、プロトコルベースの T.38 を使用する必要があります。

Cisco FAX リレーは標準化前の実装で、Cisco 音声ゲートウェイに固有の機能です。これは、ほとんどすべての Cisco 音声ゲートウェイのデフォルトの FAX 転送設定でもあります。T.38 FAX リレーおよびパススルーで使用される NSE ベースまたはプロトコルベースの方法とは異なり、Cisco FAX リレーは、特定の RTP ダイナミック Payload Types(PT; ペイロード タイプ)を利用して音声モードからリレー モードに移行します。図 13-4 に、シスコの FAX リレー方式を示します。

図 13-4 シスコの FAX コール用のリレー実装

 

FAX トラフィックの転送に推奨される方法は、FAX リレー モード(もっと具体的に言うと T.38)です。ただし、T.38 FAX リレーがサポートされていない場合は、代わりに Cisco FAX リレーまたはパススルーを使用できます。

ベスト プラクティス

Cisco 音声ゲートウェイで FAX サポートを最大限に実装するには、次の推奨事項とガイドラインが役立ちます。

QoS を使用する場合は、できる限り、次のパラメータが最小になる方法を採用してください。

パケット損失

遅延

遅延変動(ジッタ)

IP を経由するすべての FAX 転送は、パケット損失の影響を非常に受けやすくなっています。パケット損失はわずかであっても FAX 障害を引き起こす可能性があります。ネットワークでパケット損失が問題となっている場合は、T.38 FAX リレーの冗長性機能を使用する必要があります。また、ネットワーク上の恒常的なパケット遅延が 1 秒を超えないこと、および遅延変動(ジッタ)が T.38 および Cisco FAX リレーで 300 ミリ秒を超えないことを確認してください。パススルーを使用する場合、ジッタは VoIP 設計のベスト プラクティスに従い、30 ms 以下に抑える必要があります。Cisco Unified Communications ネットワークにおける QoS の実装についての詳細は、次の Web サイトにある『 Enterprise QoS Solution Reference Network Design Guide 』を参照してください。

http://www.cisco.com/go/designzone

FAX コールの完全性を確保するには、次のヒントが役立ちます。

Call Admission Control(CAC; コール アドミッション制御)を使用して、コールが規定の合計帯域幅限界を超えると、拒否されるようにします。次の表に、一般的な FAX 転送方式の FAX コール帯域幅使用量の概算値を示します。

 

FAX 転送方式
帯域幅1

モデム パススルーまたは FAX パススルー(G.711)

83 kbps

冗長性のあるモデム パススルー

170 kbps

T.38(冗長性なし)

25 kbps

T.38(高速冗長性レベルの設定値は 1)

41 kbps

T.38(高速冗長性レベルの設定値は 2)

57 kbps

Cisco FAX リレー

48 kbps

1.帯域幅の値は、イーサネットまたはフレーム リレー L2 ヘッダーを使用した場合の概算値です。T.38 および Cisco FAX リレー帯域幅の値は、FAX ページを 14.4 kbps で送信している間だけ発生し、ピークに達します。

モデムと FAX のすべての専用ポートで、コール ウェイティングを使用不可にします。

T.38 FAX リレーは、ネットワークの考慮事項に基づいて最良の FAX パフォーマンスを実現するよう設計されており、FAX トラフィックの転送方法として最も推奨されます。

他社の T.38 製品との相互運用性を確保する場合は、プロトコルベースの T.38 を使用します。

特定の Cisco 音声ゲートウェイ(Cisco VG248 やいずれかの Cisco IOS SCCP ゲートウェイなど)と通信する場合は、NSE ベースの T.38 を使用する必要があります。旧バージョンの Unified CM では、プロトコルベースの T.38 のサポートがかぎられているため、代わりに NSE ベースの T.38 FAX リレーを使用することを推奨します。

Unified CM のシナリオで、さまざまなコール シグナリング プロトコルを実行しているゲートウェイ間に T.38 を導入する場合は、プロトコルベースの T.38 が第一候補です。最新リリースの Cisco Unified CM では、H.323、SIP、および MGCP 呼制御プロトコルを使用するプロトコルベースの T.38 をサポートしています。インストールされている Cisco Unified CM のバージョンでプロトコルベースの T.38 がサポートされていない場合、または SCCP ゲートウェイが関係している場合は、NSE ベースの T.38 を使用します。ご使用のバージョンの Unified CM でプロトコルベースの T.38 がサポートされているかどうかを確認するには、次の Web サイトにある Cisco Unified Communications Manager のリリース ノートを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_release_notes_list.html

T.38 FAX リレーは、現行のほとんどの Cisco 音声ゲートウェイ(特に Cisco IOS を実行しているもの)でサポートされています。詳細については、該当するゲートウェイ モデルの製品データ シートを参照してください。

Error Correction Mode(エラー訂正モード; ECM)は、FAX コールにおいて取り決められた機能です。これによって、FAX ページは確実にエラーなく受信されます。しかし、ECM は、エラーがあれば再送信を試行するため、FAX の送信回数とコール失敗が増えることがあります。必要に応じて、複数の FAX マシンで ECM を無効にするのではなく、ゲートウェイ自体で ECM を無効にすることを検討してください。ただし、パケット ドロップやその他の IP またはPSTN の障害が発生した場合、FAX のイメージ品質が低下することがあります。したがって、ECM を無効にするときには、コールの所要時間が長くなったりコールがドロップする代わりに、イメージ品質を損なってもよいかどうかを十分に検討してください。また、ネットワークをモニタおよび評価して、FAX ページのエラーの原因となっている障害を特定し、解決する必要があります。

スーパー G3 FAX のサポート

Super-Group 3(SG3; スーパー G3)分類は、一般には「高速」FAX または V.34 FAX と呼ばれ、V.34 変調を使用して、最大 FAX ページ送信速度を 33.6 kbps に高めます。SG3 FAX マシンは、最大ページ送信速度 14.4 kbps をサポートする標準の G3 FAX マシンとの後方互換性があります。

Cisco IOS Release 12.4.4T 以降を使用する Cisco IOS ゲートウェイは、T.38 または Cisco FAX リレーが設定されているとき、Super Group 3(SG3; スーパー G3)FAX 送信をサポートします。ただし、Group 3 の速度がネゴシエートされる場合だけです。この機能の詳細については、次の Web サイトにある『 Cisco IOS Fax, Modem, and Text Support over IP Configuration Guide, Cisco IOS Release 15.1M&T 』を参照してください。

http://www.cisco.com/en/US/docs/ios/voice/fax/configuration/guide/15_1/vf_15_1_book.html

SG3 高速 FAX を本来の速度で送信する場合は、モデム パススルーを使用する必要があります。Cisco IOS バージョン 15.1.1T のリリースでは、新しい機能により、T.38 FAX リレーによる SG3 FAX のネイティブ サポートが提供されます。

ゲートウェイでのモデム パススルーとモデム リレーのサポート

一般に、音声ゲートウェイを使用して IP ネットワーク上のモデム セッションをサポートするには、次の 3 通りのメカニズムがあります。

モデム パススルー

Cisco モデム リレー

セキュア モデム リレー(STE エンドポイント間の安全な通信)

これらの各メカニズムはいずれもモデム コールを転送できますが、リレー方式は特定のモデム変調方式だけがサポートされているという点で限定的です。これに対し、モデム パススルーは、通常、どのような変調方式でも処理できます。

IP ネットワーク経由でのモデム信号の転送を取り扱う際は、ゲートウェイで発生するモードの切り替えについて理解しておくことが重要です。Cisco ゲートウェイ上のコールはすべて、最初は音声コールとして開始されます。モデム間のコールであっても、まず音声コールとしてセットアップされます。続いて、そのコールが真にモデム コールであるとゲートウェイで認識されると、モードの切り替えが発生して、音声コール モードからモデム パススルー モードまたはモデム リレー モードに切り替わります。音声モードからモデム パススルーまたはモデム リレーへのコールの切り替え方法には、いくつかの種類があります。

「ゲートウェイでの FAX パススルーと FAX リレーのサポート」の項ですでに説明したように、モデム パススルーでは、独自の NSE パケットまたは H.323/SIP プロトコル スタックを使用して、音声コールをパススルー モードに切り替えます。モデム信号が検出されると、ゲートウェイはこれらの NSE メッセージを使用して、これからモデム コールを送信することを互いに通知できます。また、H.323 または SIP 呼制御プロトコル内の特殊メッセージも使用できます。続いて、モデム信号の転送を適切に処理できるように調整を行います。たとえば、音声コーデックの G.711 へのアップスピード、Voice Activity Detection(VAD; 音声アクティビティ検出)の無効化、エコー キャンセラの無効化などの調整が必要に応じて行われます。モデム パススルーは G.711 コーデックを使用してアナログ モデム信号を単純にサンプリングするため、どのようなモデム変調方式でも処理できますが、常に最高の速度になるとは限りません。

Cisco モデム リレーはシスコ独自の実装で、V.34 モデム コールを IP ネットワーク経由で効率的に転送します。V.90 コールもサポートされますが、V.34 の速度に強制的に減速されます。モデム パススルーと同様に、NSE パケットを使用して、音声モードから Cisco モデム リレーへの切り替えが処理されます。

セキュア モデム リレー(「STE エンドポイント間の安全な通信」ともいいます)は、電話コールを IP インフラストラクチャ上で安全に転送できるよう設計されています。Secure Terminal Equipment(STE)と呼ばれる特殊なデバイスにより、V.32 変調を使用して暗号化された音声が伝送されます。セキュア モデム リレーは、SCCP および MGCP ゲートウェイが配置された Unified CM 環境において、STE 間の情報の転送を処理できるようになっています。セキュア モデム リレーは Cisco モデム リレーと互換性がありません。その主な理由の 1 つは、セキュア モデム リレーではモードの切り替えに NSE ではなく V.150.1 ベースの State Signaling Event(SSE)メッセージが使用されることです。

セキュア モデム リレーは STE 信号を転送するために特別に設計されたもので、政府機関または国防関連の配置以外ではほとんど使用されていません。ほとんどの場合、モデム コールの転送には Cisco モデム リレーまたはモデム パススルーを使用します。セキュア モデム リレーの詳細については、次の Web サイトにある「 Secure Communication Between IP-STE Endpoint and Line-Side STE Endpoint 」を参照してください。

http://www.cisco.com/en/US/docs/ios/12_4t/12_4t4/htv1501.html

図 13-5 に、シスコのモデム転送の実装をまとめた図を示します。モデム リレーはモデム パススルーに比べて帯域幅効率が高く、ネットワークの耐障害性にも優れているため、可能な場合は常にモデム リレーを使用してください。モデム リレーの欠点は、サポートされている変調方式がきわめて限定されていることです。それに対してモデム パススルーは、どのようなモデム変調方式でも処理できます。

図 13-5 シスコのモデム コール用のパススルー実装とリレー実装

 

ベスト プラクティス

IP インフラストラクチャを介して転送されるモデム トラフィックの最適なパフォーマンスを確保するには、次の推奨ベスト プラクティスを守ってください。

IP ネットワークで Quality of Service(QoS)が使用可能になっていること、および LAN、MAN、および WAN 環境で、QoS を提供するためのすべての推奨事項に従っていることを確認します。できる限り、次のパラメータが最小になる方法を採用してください。

パケット損失:FAX とモデムのトラフィックには、本質的に損失のない転送が必要です。パケットが 1 つでも損失すると、再送信が行われることがあります。

遅延

遅延変動(ジッタ)

詳細については、次の Web サイトにある『 Enterprise QoS Solution Reference Network Design Guide 』を参照してください。

http://www.cisco.com/go/designzone

Call Admission Control(CAC; コール アドミッション制御)を使用して、コールが規定の合計帯域幅限界を超えると、拒否されるようにします。計画の目的で、モデム変調が転送されるかどうかにかかわらず、モデム パススルー コールは常に約 83 kbps の帯域幅を消費するとします。冗長性が有効になっている場合は、170 kbps の帯域幅を消費するとします。モデム通信の性質上、モデム リレー帯域幅は断続的となりますが、V.34 接続の最大速度 33.6 kbps に対して約 45 kbps のピークを見込んで計画します。ここに挙げた帯域幅の値は概算値であり、イーサネットまたはフレーム リレーが L2 トランスポートであることを前提としています。

可能な場合は常に、モデム リレーを使用します。変調方式がモデム リレーでサポートされていない場合は、モデム パススルーを使用します。

IP ネットワークにモデムを接続して、IP ネットワークの問題のトラブルシューティングや診断をしないでください。この場合、IP インフラストラクチャを構成するデバイスのトラブルシューティングに使用されるモデムは、一般電話サービス(POTS)に接続する必要があります。

Cisco モデム リレーとモデム パススルーでは NSE に基づいてモードが切り替えられるため、異なる呼制御プロトコルを使用しているゲートウェイ同士でも簡単に通信できます。たとえば、Unified CM に接続されている MGCP ゲートウェイと H.323 ゲートウェイは、Cisco モデム リレーまたはモデム パススルーを正常にネゴシエートできます。これは、Unified CM によってすでに設定されている RTP 音声メディア ストリームの中で NSE 切り替えが行われるためです。

モデムと FAX のすべての専用ポートで、コール ウェイティングを使用不可にします。

V.90 サポート

現在、Cisco 機器は V.34 モデムのみをサポートします。V.90 モデムは既存のハードウェアで機能し、V.34 よりも高速ですが、V.90 の完全なサポートは保証できません。

サポートされるプラットフォームと機能

FAX とモデムの機能をサポートしている Cisco プラットフォームは、次のとおりです。

Cisco IOS ゲートウェイは次のものをサポートします。

モデム パススルー。

H.323 および SIP プロトコルに基づく FAX パススルー。

T.38 FAX リレー。T.38 の NSE ベースの切り替えとプロトコルベースの切り替えがどちらもサポートされます。ただし、SCCP は例外で、NSE ベースの T.38 FAX リレーだけがサポートされます。

Cisco FAX リレー。Nextport DSP カードを使用する Cisco AS5350、AS5400、および AS5850 は、Cisco FAX リレーをサポートしていません。また、PVDM3 DSP モジュールも、Cisco FAX リレーをサポートしていません。

Cisco モデム リレー。

IOS 以外の Cisco ゲートウェイは次のものをサポートします。

Cisco VG248 は、モデム パススルー、NSE ベースの T.38 FAX リレー、および Cisco FAX リレーをサポートします。

Cisco 6608 および 6624 は、モデム パススルーと Cisco FAX リレーだけをサポートします。

Cisco ATA は、FAX コールについてだけモデム パススルーをサポートします。ATA でモデム コールに対してモデム パススルーを使用することは、正式にはサポートされていません。


) ここに示した FAX とモデムのサポート情報は、Cisco IOS ゲートウェイについては Cisco IOS Release 12.4(9)T 以降、Cisco VG248 Analog Phone Gateway については Release 1.3.1 以降で有効です。


プラットフォーム プロトコルのサポート

企業ソリューションで現在使用されている一般的な呼制御プロトコルには、H.323、Session Initiation Protocol(SIP)、メディア ゲートウェイ コントロール プロトコル(MGCP)、および Skinny Client Control Protocol(SCCP)があります。すべての Cisco 音声プラットフォームが、これらのプロトコル、または FAX とモデム機能をすべてサポートしているわけではないので、相互運用性の問題が発生します。また、Cisco 2800 シリーズや Cisco 3800 シリーズなどの Cisco IOS ゲートウェイを、VG248 などの IOS 以外のゲートウェイと組み合わせる場合は、さらに相互運用性の問題が発生します。ここでは、FAX、モデム、およびプロトコルの機能の相互運用性をサポートしているゲートウェイの組み合わせをリストしています。

ネットワークにおける一般的なプロトコルの組み合わせ例としては、MGCP と H.323、SCCP と H.323、SCCP と SIP、MGCP と SIP、H.323 と SIP、SCCP と MGCP などがあります。

表 13-3 では、FAX とモデムの相互運用性を現在サポートしている、プロトコルの組み合わせをリストしています。

表 13-3 FAX とモデムの機能がサポートされる呼制御プロトコルの各種組み合わせ

プロトコルの組み合わせ
モデム リレー
モデム パススルー2
T.38 FAX リレー
Cisco FAX リレー
FAX パススルー

MGCP を使用する Unified CM と、H.323 または SIP を使用する Unified CM との組み合わせ

Yes

Yes

Yes3

Yes

No

MGCP を使用する Unified CM と、MGCP を使用する Unified CM との組み合わせ

Yes

Yes

Yes2

Yes

No

SCCP と、H.323 または SIP を使用する Unified CM との組み合わせ

Yes

Yes

Yes4

Yes

No

SCCP と、MGCP を使用する Unified CM との組み合わせ

Yes

Yes

Yes3

Yes

No

H.323 を使用する Unified CM と、H.323 または SIP との組み合わせ

Yes

Yes

Yes2

Yes

Yes

SIP を使用する Unified CM と、H.323 または SIP との組み合わせ

Yes

Yes

Yes2

Yes

Yes

2.モデム パススルーは、モデム パススルー コールと FAX パススルー コールの両方で機能します。

3.NSE ベースの T.38 FAX リレーは機能しますが、プロトコルベースの T.38 FAX リレーが機能するかどうかは Unified CM のバージョンによります。バージョン情報については、http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_release_notes_list.html にある Cisco Unified Communications Manager のリリース ノートを参照してください。

4.SCCP プロトコルは、NSE ベースの T.38 FAX リレーだけで機能します。


表 13-3 は一般的な情報を示したものです。製品によっては、この表に記載されていない制限がある場合がありますので、注意してください。たとえば、Cisco ATA は H.323、SIP、および SCCP の呼制御プロトコルをサポートしていますが、どの呼制御プロトコルが使用されているかにかかわらず、モデム パススルーだけがサポートされます。


ゲートウェイ設定例

Cisco ゲートウェイでの FAX およびモデムのサポートに関する詳細な設定情報については、次のサイトで入手可能な『 Cisco IOS Fax, Modem, and Text Support over IP Configuration Guide 』を参照してください。

http://www.cisco.com/en/US/docs/ios/voice/fax/configuration/guide/12_4t/vf_12_4t_book.html

ビデオ テレフォニー用のゲートウェイ

ビデオゲートウェイは、IP テレフォニー ネットワークまたはPSTN へのビデオコールを終端します。ビデオ ゲートウェイは、ビデオをサポートし、そのコールを H.323 や SIP などのプロトコルを使用して IP ネットワーク上のビデオ コールに変換する ISDN トランクとデータをやり取りする必要がある点で音声ゲートウェイとは異なります。企業は、音声コールとビデオ コールでゲートウェイを分けることを検討することも、音声コールとビデオ コールの両方をルーティングする統合ゲートウェイを設置することもできます。

次の点を考慮することによって、音声とビデオで別々のゲートウェイが必要なのか、統合ゲートウェイが必要なのかを判断できます。

ダイヤル プラン:ビデオ ユーザ用に別のダイヤル プランを用意できる場合は、既存のエンタープライズ ダイヤル プランを維持しながら、別のビデオ ゲートウェイを使用できます。

ビデオ ユーザ:主にビデオよりも音声を使用するユーザの方が圧倒的に多い場合は、別のビデオ ゲートウェイを使用してビデオ コール ユーザにサービスを提供することを推奨します。

ロケーション:多数のビデオ ユーザが地理的に分散している場合は、統合ゲートウェイを使用して総所有コスト(TCO)を削減することを推奨します。

ビデオ IVR、自動応答、トランク上でのボンディングなどの付加的なビデオ機能:統合ゲートウェイでサポートされない高度な機能をサポートするには、専用ビデオ ゲートウェイが必要です。

プロトコル:会社の方針や標準に合わせるために、ゲートウェイ プロトコルが重要な要素になる可能性があります。

キャパシティ:専用ゲートウェイの場合、サポートされる同時コールの量はそれほど大きくない可能性がありますが、統合ゲートウェイでは音声コールに加えてビデオ コールもサポート可能なため、より大きなキャパシティを期待できます。

デバイス管理:保守、管理、およびトラブルシューティングを容易にしておくことは重要な要素になる可能性があります。専用ゲートウェイはどちらかと言えば管理/設定用のユーザ インターフェイス(GUI)として利用するのに適しており、統合ゲートウェイはトラブルシューティングに使用するのに適しています。ただし、こうした要素は製品によって異なります。

専用ビデオ ゲートウェイ

音声ゲートウェイを含む大規模な音声インフラストラクチャを所有する企業は、ユーザがビデオ コールを PSTN に発信するためのビデオ ゲートウェイを追加できます。Cisco Unified Videoconferencing 3500 および 5200 シリーズ ビデオ ゲートウェイをこの目的に使用できます。

図 13-6 に、音声ゲートウェイ用に既存のプロトコルを使用しており、Unified CM ユーザが音声コールとビデオ コールを PSTN に発信できるようにビデオ ゲートウェイを追加できる、企業での展開の一例を示します。

図 13-6 音声と IP ビデオ テレフォニーに別々のPSTN 回線を使用する Unified CM システム

 

Unified Videoconferencing ゲートウェイはビデオ コール用として優れていますが、シスコ音声ゲートウェイが提供するすべての機能をサポートしているわけではありません。Unified Videoconferencing ゲートウェイには、次の特性があります。

H.323 と H.320 のみをサポートします。

スタンドアロン デバイスです。Cisco IOS ルータまたは Cisco Catalyst スイッチに統合することはできません。

T1/E1-PRI および ISDN BRI のみサポートします。

H.261、H.263、および H.264 ビデオ コーデックをサポートします。

G.711、G.722、G.722.1、G.723.1、および G.728 のみをサポートし、G.729 オーディオはサポートしません。

H.245 Empty Capabilities Set(ECS)をサポートします。

T.120 および H.239 データ共有プロトコルをサポートします。

H.235 暗号化をサポートします。

Cisco 音声ゲートウェイに固有の、多数の管理機能とトラブルシューティング機能をサポートしません。

このように製品間の違いがあるため、Cisco Unified Videoconferencing 3500 シリーズ ゲートウェイは、Cisco 音声ゲートウェイの代わりとしては推奨できません。IP テレフォニーのユーザが通信環境にビデオを追加するには、両方のタイプのゲートウェイを配置して、すべての音声コールに Cisco 音声ゲートウェイを使用し、Cisco Unified Videoconferencing 3500 シリーズ ゲートウェイをビデオ コールのみに使用する必要があります。また、配置する Cisco IOS ゲートウェイのモデルによっては、PSTN サービス プロバイダーから音声とビデオに別個の回線を調達する必要がある場合もあります。

音声ゲートウェイとビデオ ゲートウェイを別々にする場合は(図 13-6 を参照)、着信コールと発信コールの両方に対するルート プランも別々にする必要があります。着信コールの場合、Direct Inward Dial(DID; ダイヤルイン)内線を 1 つしか持たないユーザが音声コールとビデオ コールの両方を受信することはできません。通常、各ユーザは、あらかじめ音声コール用の DID を持っています。そのシナリオにビデオを導入する場合は、何か別の方法でユーザにダイヤルする必要があります。たとえば、別の DID 番号を使用する方法や、ビデオ ゲートウェイのメイン番号にダイヤルし、音声自動応答装置(IVR)から促されてユーザのビデオ内線に入るなどの方法があります。発信コールの場合は、単一のPSTN アクセス コードを音声コールとビデオ コールの両方に使用することができません。通常、ユーザはすでに音声用の既知のアクセス コード(多くの米国企業における 9 など)を持っていますが、そのシナリオにビデオを導入した場合、ビデオ コールを発信するユーザは何か別のアクセス コードをダイヤルする必要があります。

2 つのタイプのゲートウェイを導入するための、もう 1 つの考慮事項は、それらのゲートウェイの配置です。通常、企業は多数のPSTN ゲートウェイ リソースを中央サイト(複数の場合もある)に集約し、それぞれの支社も、いくつかのローカル ゲートウェイ リソースを持っています。たとえば、Cisco Catalyst 6500 ゲートウェイを中央サイトに配置し、そのゲートウェイに複数の T1/E1 回線を接続する一方で、各支社に Cisco Integrated Services Router(ISR)と、ローカル CO へのアナログまたはデジタルのトランクが配備されている場合があります。このシナリオにビデオを導入するユーザは、ビデオに必要なPSTN 回線の数と、ビデオ ゲートウェイの配置場所も決定する必要があります。たとえば、少数の Cisco Unified Videoconferencing ビデオ ゲートウェイのみを中央サイトに配置するのか、それとも各支社にもゲートウェイを配置するのか、といったことです。

最後に、トール バイパスを設けるためには IP ネットワーク内でコールをどのようにリモート ゲートウェイへルーティングするのか、および IP ネットワークが使用不能になったり、コールを完了できるだけの帯域幅がない場合に、PSTN 上でコールをどのように再ルーティングするのかを考慮してください。具体的には、ビデオ コール用の Automated Alternate Routing(AAR; 自動代替ルーティング)を起動するのか、といったことです。

統合ビデオ ゲートウェイ

企業は、音声とビデオ両方のゲートウェイ機能を備えた統合デバイスを検討できます。このデバイスは、管理対象デバイスの数が少なくなり、ダイヤル プランが単純になるというメリットを企業にもたらします。このゲートウェイは、コールが音声の場合は音声コールとして処理し、コールがビデオの場合はビデオ コールとして処理します。

Cisco IOS Integrated Video Gateway には次のような特徴があります。

Cisco ISO-13871 ボンディングをサポートします。

H.320、H.323、および SIP サポートを提供します。

既存のビデオ コーデックと H.264 ビデオ コーデックをサポートします。

さまざまな着信側および発信側変換機能を提供します。

さまざまなロギングおよびトラブルシューティング機能を提供します。

次の留意点は、Cisco IOS Integrated Video Gateway の展開に適用されます。

追加のビデオ コール用の PSTN リンクに必要な容量を考慮してください。

T.120 などのデータ アプリケーションを使用するためのデバイスが必要かどうかと、IP ネットワークで使用される追加の帯域幅を考慮してください。

H.320 ゲートウェイでサポートする必要がある会議で使用される遠端カメラ制御や DTMF などの機能が必要かどうかを考慮してください。

PSTN からの着信コールのルーティング

PSTN からの着信コールをルーティングするには、次のいずれかの方法を使用します。

Unified CM クラスタ内にあるビデオ対応デバイスごとに、少なくとも 2 つの異なる電話番号を割り当て、1 つの回線を音声用、もう 1 つをビデオ用とします。この方法では、外部の(PSTN)発信者はビデオを有効にするために、正しい番号をダイヤルする必要があります。

ビデオ コールの場合は、外部の発信者にビデオ ゲートウェイのメイン番号をダイヤルしてもらいます。Cisco Unified Videoconferencing ゲートウェイは統合 IVR を提供し、発信者に相手側の内線番号の入力を求めます。次に、Unified CM は、それがビデオ コールであることを認識し、宛先デバイスを呼び出します。この方法では、発信者はそれぞれの着信側ごとに 2 つの異なる DID 番号を覚える必要はありませんが、着信ビデオ コールをダイヤルするという余分な手順が増えます。


) 外部のビデオ エンドポイントは、IVR プロンプトに着信側の内線番号を入力するために、DTMF をサポートしている必要があります。


次の例は、2 番めの方法を示しています。

ユーザの Cisco Unified IP Phone 7960 は、Cisco Unified Video Advantage を実行している PC に接続されています。IP Phone の内線番号は 51212 で、完全修飾 DID 番号は 1-408-555-1212 です。DID 番号をダイヤルするだけで、音声専用コールのPSTN からそのユーザに到達できます。CO は、Cisco 音声ゲートウェイに接続した T1-PRI 回線(複数の場合もある)を通じて、その DID 番号にコールを送信します。ゲートウェイでコールが受信されると、Unified CM はゲートウェイが音声専用であることを認識し、そのコール用に 1 つの音声チャネルのみのネゴシエーションを行います。逆に、PSTN からビデオ コールのためにそのユーザに到達するには、ビデオ ゲートウェイのメイン番号をダイヤルした後、ユーザの内線番号を入力する必要があります。たとえば、1-408-555-1000 をダイヤルするとします。CO は、Cisco Unified Videoconferencing 3500 シリーズ ビデオ ゲートウェイに接続した T1-PRI 回線(複数の場合もある)を通じて、その番号にコールを送信します。ゲートウェイでコールが受信されると、IVR プロンプトが発信元に、到達すべき相手の内線番号の入力を求めます。発信者が DTMF トーンで内線番号を入力すると、Unified CM はゲートウェイにビデオ機能があることを認識し、そのコール用に音声とビデオの両方のチャネルをネゴシエートします。

ゲートウェイの番号操作

Cisco Unified Videoconferencing 3500 シリーズ ゲートウェイは、PSTN から受信したコールの番号を操作できません。Q.931 Called Party Number フィールドで渡されたものと正確に同じ数の番号を受け取り、それらすべてを Unified CM に送信します。したがって、Unified CM は番号を操作して、宛先デバイスの電話番号(DN)と照合する必要があります。たとえば、CO スイッチからゲートウェイへの回線が 10 桁を渡すように設定されていて、着信側の内線番号が 5 桁しかない場合、Unified CM は、一致する DN を検索する前に、先頭の 5 桁を削除する必要があります。この番号操作は、次のいずれかの方法で実装できます。

Cisco Unified Videoconferencing ゲートウェイからの着信コールを伝達する H.323 ゲートウェイ デバイスまたは H.225 ゲートキーパー制御トランク上で Significant Digits フィールドを設定します。

この方法では、Unified CM に、着信番号の下位 N 桁だけに注目するよう指示できます。たとえば、Significant Digits を 5 に設定すると、Unified CM は着信番号の最後の 5 桁以外を無視します。これは最も簡単な方法ですが、そのゲートウェイから受信したすべてのコールに影響を及ぼします。したがって、可変長の内線番号がある場合、この方法は推奨できません。

トランスレーション パターンを設定し、それを Cisco Unified Videoconferencing ゲートウェイからの着信コールを伝達する H.323 ゲートウェイ デバイスまたは H.225 ゲートキーパー制御トランクのコーリング サーチ スペースに格納します。

この方法では、Unified CM は受信した完全な桁数でコールを照合し、着信番号を修正してから、得られた変更後の番号に対して番号分析を続行できます。この方法は前の方法に比べてわずかながら複雑ですが、柔軟性があり、コールの照合と修正をきめ細かく行うことができます。

PSTN への発信コールのルーティング

発信コールをPSTN へルーティングするには、次のいずれかの方法を使用します。

音声コールとビデオ コールに異なるアクセス コード(異なるルート パターン)を割り当てます。たとえば、ユーザが 9 の後にコール先のPSTN 電話番号をダイヤルすると、それがコールを音声ゲートウェイに送るルート パターンと一致します。同様に、数字の 8 を、ビデオ ゲートウェイにコールを渡すルート パターンとして使用することもできます。

Unified CM クラスタ内にあるビデオ対応デバイスごとに、少なくとも 2 つの異なる電話番号を割り当て、1 つの回線を音声用、もう 1 つをビデオ用とします。その後、2 つの回線に異なるコーリング サーチ スペースを指定します。ユーザが第 1 の回線上でアクセス コード(たとえば 9)をダイヤルすると音声ゲートウェイにつながり、同じアクセス コードを第 2 の回線上でダイヤルするとビデオ ゲートウェイにつながります。この方法では、ユーザが 2 つの異なるアクセス コードを覚える必要がありませんが、コールの発信時に電話機で正しい回線を押す必要があります。

ゲートウェイ サービス プレフィックス

Cisco Unified Videoconferencing ゲートウェイは、発信コールの速度を定義するためにサービス プレフィックスを使用します。ゲートウェイでサービス プレフィックスを設定するときは、次のいずれかの速度を選択する必要があります。

Voice-only

128 kbps

256 kbps

384 kbps

768 kbps

Auto(動的に決定され、128 kbps ~ 768 kbps の範囲の任意のコール速度をサポート)


) 上記の各速度は、64 kbps の倍数を表します。56 kbps のダイヤリング用として、サービス プレフィックスの設定ページには、各チャネルを 56 kbps に制限するチェックボックスがあります。したがって、制限モードを有効にした 128 kbps サービスは 112 kbps サービスになり、制限モードを有効にした 384 kbps サービスは 336 kbps になり、その他も同様です。


IP エンドポイントからPSTN へ向かうコールは、ゲートウェイがそのコールにどのサービスを使用するかを決定できるように、着信番号の先頭にサービス プレフィックスを含んでいる必要があります。オプションとして、番号の先頭にサービス プレフィックスを含んでいないコールに使用する、デフォルト プレフィックスを設定できます。この方法は、非常に複雑になる可能性があります。ユーザは、求めるコール速度を得るためにダイヤルすべきプレフィックスを覚えておく必要があるからです。また、管理者は、Unified CM で複数の(速度ごとに 1 つずつ)ルート パターンを設定する必要があります。ただし、Auto 速度を使用するとその手間を最小にできます。コールの大多数が 1 チャネルあたり 64 kbps(たとえば、128 kbps、384 kbps、512 kbps、768 kbps など)を使用して行われる場合には、Auto サービスを使用できます。その場合、1 チャネルあたり 56 kbps(たとえば、112 kbps、336 kbps など)のコールを行うまれなケースに備えて、1 つだけ別のサービスを作成すれば済みます。

ゲートウェイは、# をダイヤル末尾の文字として認識するので、サービス プレフィックスの中に必ず # 文字を使用することを推奨します。この文字をサービス プレフィックスに入れておくと、ゲートウェイのメイン番号をダイヤルして IVR に接続してからオフネット番号にダイヤルするといった料金詐欺にゲートウェイが使用されることを防止できます。# は、サービス プレフィックスの先頭(推奨)と末尾どちらでもかまいません。たとえば、ビデオ コールでPSTN に到達するためのアクセス コードが 8 であれば、サービス プレフィックスを #8 または 8# として設定することを推奨します。あるいは、上記のように 2 つのサービス プレフィックスを使用する場合は、Auto の 64 kbps サービスに #80 を使用し、Auto の 56 kbps サービスに #81 を使用するという方法もあります。

サービス プレフィックスを使用する場合の欠点は、Cisco Unified Videoconferencing ゲートウェイにコールを送信するときに、Unified CM で着信番号の前にサービス プレフィックスを付加する必要があることです。ユーザに # をダイヤルさせるのはあまり使いやすくないので、ダイヤルされた番号の前に Unified CM が # を付加するように設定することを推奨します。たとえば、PSTN にビデオ コールをダイヤルするアクセス コードが 8 の場合、Unified CM でルート パターンを 8.@ として設定し、ルート パターン設定の中で、そのルート パターンがダイヤルされたときは必ず前に #8 を付加するように、着信番号変換ルールを設定します。あるいは、上記のようにサービス プレフィックスを 2 つ使用する場合は、80.@ を Auto 64 kbps サービス(着信番号の前に # を付ける)に使用し、81.@ を Auto 56 kbps サービス(着信番号の前に # を付ける)に使用するという方法もあります。

自動代替ルーティング(AAR)

IP ネットワークにコールを処理できるだけの帯域幅がない場合、Unified CM はコール アドミッション制御メカニズムを使用して、コールの処理方法を決定します。「IP ビデオ テレフォニー」の説明のように、Unified CM は設定に従って、次のいずれかの処理を実行します。

コールに失敗し、発信側に対してビジー トーンを再生し、発信側の画面に Bandwidth Unavailable メッセージを表示します。

ビデオ コールを音声専用コールとして再試行します。

Automated Alternate Routing(AAR; 自動代替ルーティング)を使用し、PSTN ゲートウェイなどの代替パス上でコールを再ルーティングします。

最初の 2 つのオプションについては、「IP ビデオ テレフォニー」の章に説明があります。ここでは、AAR オプションについて説明します。

音声コールまたはビデオ コールに AAR を使用できるようにするには、発信側デバイスと着信側デバイスを AAR グループのメンバーとして設定し、着信側デバイスに外部電話番号マスクを設定する必要があります。外部電話番号マスクによって、ユーザの内線用の完全修飾 E.164 アドレスが指定されます。また、AAR グループによって、コールが PSTN 上で正しくルーティングされるために、着信側デバイスの外部電話番号マスクの前に付加すべき数字が示されます。

たとえば、ユーザ A が San Jose AAR グループに属し、ユーザ B が San Francisco AAR グループに属しているとします。ユーザ B の内線番号は 51212 で、外部電話番号マスクは 6505551212 です。AAR グループは、San Jose と San Francisco の AAR グループ間のコールに対して、番号の前に 91 を付加するよう設定されています。この場合、ユーザ A が 51212 をダイヤルし、2 つのサイト間の IP WAN 上にそのコールを処理できるだけの帯域幅がない場合、Unified CM はユーザ B の外部電話番号マスクである 6505551212 を選択し、その前に 91 を付加して 916505551212 への新規コールを生成し、ユーザ A 用の AAR コーリング サーチ スペースを使用します。

ビデオ コールにも同じロジックが適用されますが、プロセスに 1 つだけ手順が追加されます。ビデオ対応デバイスに対して、Retry Video Call as Audio というフィールドが存在します。「IP ビデオ テレフォニー」の章で説明するように、このオプションを有効(オン)にした場合、Unified CM は AAR を実行しないで、同じコール(つまり、51212 へのコール)を音声専用コールとして再試行します。このオプションを無効(オフ)にした場合、Unified CM は AAR を実行します。Unified CM のデフォルトでは、すべてのビデオ対応デバイスで Retry Video Call as Audio オプションが有効(オン)になります。したがって、ビデオ コールで AAR を使用できるようにするには、Retry Video Call as Audio オプションを無効(オフ)にする必要があります。また、ロケーション間でリソース予約プロトコル(RSVP)に基づいたコール アドミッション制御ポリシーが使用されている場合は、RSVP ポリシーを音声ストリームとビデオ ストリームの両方について Mandatory に設定する必要があります。

さらに、Unified CM は、着信側デバイスだけを見て Retry Video Call as Audio オプションが有効か無効かを判断します。したがって、上記のシナリオで AAR プロセスが実行されるためには、ユーザ B の電話機で Retry Video Call as Audio オプションが無効にされている必要があります。

最後に、デバイスは 1 つの AAR グループだけに所属できます。AAR グループによって、どの数字を前に付加するかが決定されるため、再ルーティングされたコールにどのゲートウェイが使用されるかにも影響があります。前項で述べたように、PSTN への発信コール ルーティングの設定に何を選択したかに応じて、AAR によって再ルーティングされるビデオ コールは、ビデオ ゲートウェイでなく音声ゲートウェイに送られる可能性もあります。したがって、AAR グループと AAR コーリング サーチ スペースの構築は入念に行い、必ず正しい数字が付加され、AAR に正しいコーリング サーチ スペースが使用されるようにしてください。

こうした考慮事項により、大規模な企業環境での AAR の設定がかなり複雑になる可能性がありますが、エンドポイントのタイプが 2 つのどちらかに限定されている場合(IP Phone が音声専用コール用で、Tandberg T-1000 などのシステムがビデオ コール専用など)には AAR の実装が容易です。エンドポイントが音声とビデオの両方のコールに対応している場合(Cisco Unified Video Advantage または Cisco IP Video Phone 7985G など)は、AAR の設定が非常に複雑になることがあります。したがって、音声とビデオのエンドポイントが混在する大企業では、ユーザごとに AAR の重要性をよく考え、専用のビデオ会議室や経営幹部用ビデオ システムなど、一部のビデオ デバイスだけに AAR を使用してください。 表 13-4 に、さまざまなデバイス タイプで AAR を使用するのが適切なシナリオのリストを示します。

表 13-4 デバイス タイプ別の AAR 使用条件

デバイス タイプ
デバイスを使用したコールの宛先
AAR の必要性
コメント

IP Phone

他の IP Phone およびビデオ対応デバイス

Yes

ビデオ対応デバイスにコールするときでも、発信元デバイスが音声専用なので、コールを音声ゲートウェイにルーティングするように AAR を設定できます。

Cisco Unified Video Advantage の搭載された IP Phone、または Cisco IP Video Phone 7985G

他のビデオ対応デバイスのみ

Yes

デバイスは必ずビデオ コールに使用されるので、AAR グループを設定できます。

IP Phone およびその他のビデオ対応デバイス

No

音声専用コールではビデオ コールと異なるルーティングを行うように AAR グループを設定するのは困難です。

Sony 社製または Tandberg 社製の SCCP エンドポイント

他のビデオ対応デバイスのみ

Yes

デバイスは必ずビデオ コールに使用されるので、AAR グループを設定できます。

IP Phone およびその他のビデオ対応デバイス

No

音声専用コールではビデオ コールと異なるルーティングを行うように AAR グループを設定するのは困難です。

H.323 または SIP クライアント

他のビデオ対応デバイスのみ

Yes

デバイスは必ずビデオ コールに使用されるので、AAR グループを設定できます。

IP Phone およびその他のビデオ対応デバイス

No

音声専用コールではビデオ コールと異なるルーティングを行うように AAR グループを設定するのは困難です。

最低料金選択機能

Least-Cost Routing(LCR; 最低料金選択機能)と Tail-End Hop-Off(TEHO; テールエンド ホップオフ)は、VoIP ネットワークでは非常によく知られており、ビデオ コールにも利用できます。一般的にどちらの用語も、長距離電話番号へのコールが IP ネットワークを通じて宛先に最も近いゲートウェイにルーティングされ、通話料金が安くなるような、コール ルーティング ルールの設定方法を指しています。Cisco Unified CM Release 4.1 の場合、LCR は基本的に TEHO と同じ意味です。Unified CM は、次に示すような豊富な番号分析機能と番号操作機能を使用して、この機能をサポートします。

パーティションとコーリング サーチ スペース

トランスレーション パターン

ルート パターンとルート フィルタ

ルート リストとルート グループ

LCR をビデオ コール用に設定するのは、音声コールの場合よりも少し複雑で、その理由は次のとおりです。

この章ですでに述べたように、ビデオ コールには独自の専用ゲートウェイが必要です。

ビデオ コールには、音声コールをはるかに上回る帯域幅が必要です。

専用ゲートウェイに関しては、LCR をビデオ コールに使用するかどうかを決めるための基礎となるロジックは、「自動代替ルーティング(AAR)」の項で説明したロジックとほとんど同じです。音声とビデオ用にさまざまなタイプのゲートウェイが必要になるため、LCR で音声コールを 1 つのゲートウェイに送り、ビデオ コールを別のゲートウェイに送るために必要なすべてのパーティション、コーリング サーチ スペース、トランスレーション パターン、ルート パターン、ルート フィルタ、ルート リスト、およびルート グループを設定するのは、かなり複雑な作業になる可能性があります。

帯域幅の要件に関しては、LCR を使用するかどうかは、特定のロケーションとの間を結ぶビデオ コールの LCR をサポートできるだけの帯域幅が、使用している IP ネットワークにあるかどうかで決まります。現在の帯域幅が十分でない場合は、IP ネットワークをアップグレードしてビデオ コール用の空きを作ったり、ローカル ゲートウェイを導入してPSTN 上でコールをルーティングしたりするためのコストと、ビデオ コールの利点を比較する必要があります。たとえば、ある中央サイトに 1.544 Mbps の T1 フレーム リレー回線を介して支店が接続されているとします。その支店内には、20 人のビデオ機能を持つユーザがいます。1.544 Mbps の T1 回線は、最大でほぼ 4 つの 384 kbps ビデオ コールを処理できます。この場合、中央サイトまでビデオ コールをルーティングして、通話料金を節約することに意味があるかどうかが問題です。サポートするコールの数に応じて、1.544 Mbps の T1 回線をもっと高速のものにアップグレードしなければならない場合もあります。ビデオには、そうしたアップグレードに要する毎月の追加料金に見合うだけの重要性があるのでしょうか。ない場合は、その支店に Cisco Unified Videoconferencing ゲートウェイを導入すると、LCR に煩わされずに済みます。ただし、支店ごとにローカル Cisco Unified Videoconferencing ゲートウェイを配置すれば費用がかかるため、最終的には、ビデオと PSTN 間のコールがビジネスにどれほど重要かを判断する必要があります。ビデオが重要でない場合は、帯域幅をアップグレードしたりビデオ ゲートウェイを購入したりするよりも、Retry Video Call as Audio 機能を使用し、使用可能な帯域幅を超過した場合にビデオ コールを音声専用コールとして再ルーティングした方がよいこともあります。コールが音声専用までダウングレードされると、LCR を実行するためのローカル ゲートウェイ リソースと帯域幅は、もっと手ごろな価格で設定しやすいものになります。

ISDN B チャネル バインディング、ロールオーバー、およびビジーアウト

Cisco IOS Release 12.4.20T 以降のリリースでは、Cisco IOS H.320 ゲートウェイで ISO-13871 ボンディング手法がサポートされており、これによって最大速度 1 Mbps のビデオ コールがサポートされます。この機能により、Cisco IOS ルータを音声コールとビデオ コールの両方に対応する統合ゲートウェイとして使用できます。

H.320 ビデオは、複数の ISDN チャネルをまとめて使用することで、フルモーション ビデオの受け渡しに必要な速度を実現します。このボンディング メカニズムの問題の 1 つは、着信 ISDN ビデオ コールを受信した時点でゲートウェイにはそのコールに必要なチャネル数がわからず、コールを受け入れて発信元デバイスから必要な追加チャネル数を指示されて、初めてそれがわかることです。その要求を満たせるだけの B チャネルがないと、コールは切断されます。したがって、そのような状況が発生する可能性を最小にするよう、慎重なトラフィック エンジニアリングが必要です。基本的に、次に着信する可能性があるコールを処理できる、十分な B チャネルを常に使用可能にしておく必要があります。

この B チャネルの問題は、次の 2 つのケースで発生します。

PSTN から IP ネットワークへの着信コール

IP ネットワークからPSTN への発信コール

着信コール

着信コールについて、次のシナリオを考えてみます。

ある会社に Cisco Unified Videoconferencing 3527 ゲートウェイがあり、それが ISDN PRI 回線でセントラル オフィス(CO)のスイッチに接続されています。この場合、ISDN PRI 回線は 23 の B チャネルを提供します。ビデオ コールがPSTN から 384 kbps で受信されます。このコールは 6 つの B チャネルを使用するので、残りの空きは 17 になります。最初のコールがまだアクティブな間に、第 2 と第 3 の 384 kbps のコールがその回線上で受信されます。それぞれのコールが 6 チャネルを使用するので、残りの空きは 5 チャネルになります。第 4 の 384 kbps のコールが受信されると、ゲートウェイはそのコールに応答しますが、十分な B チャネルの空きがないこと(残りチャネルは 5 つだけだが、コールに必要なチャネルは 6 つ)を認識し、接続を解除します(「16: Normal Call Clearing」を理由とした Q.931 RELEASE COMPLETE を送信)。第 4 のコールを試みた発信側は、コールの失敗の原因がわからず、番号を繰り返しリダイヤルしてコールを発信しようとします。

Cisco Unified Videoconferencing ゲートウェイでは、こうした問題が起きる可能性を最小にするために、ゲートウェイが一定の使用率しきい値(総帯域幅に対するパーセンテージとして設定)に到達したときに、ゲートウェイから CO へ残りの B チャネル(この例では 5 チャネル)をビジーアウトする要求を送信するように設定できます。

さらに、トランク グループ内で CO から複数の ISDN 回線をプロビジョニングできます。最初の回線がビジーアウトしきい値に到達した時点で、コールはグループ内の次の PRI へロールオーバーされます。Cisco Unified Videoconferencing 3500 シリーズ ゲートウェイは 2 本の ISDN PRI 接続を提供し、両方のポートにまたがるボンディング チャネルをサポートします。たとえば、ポート 1 の空きが 5 チャネルしかなく、ポート 2 がアイドル状態であるため、23 チャネルが使用可能であるとします。この場合、ポート 1 から 5 チャネル、ポート 2 から 1 チャネルを使用してボンディングすることにより、第 4 の 384 kbps のコールに成功できます。これにより、コントローラ 2 上に残る空きは 22 チャネルとなり、ある時点で着信コールが再びビジーアウトしきい値に到達します。その時点で、ポート 2 上の残りのチャネルはビジーアウトされ、それ以後のすべての着信コールは原因コード「Network Congestion」で拒否されます。Cisco Unified Videoconferencing ゲートウェイでは、複数のゲートウェイにまたがってチャネルを結合したり、同じ Cisco 3545 シャーシ内の複数の Cisco 3500 シリーズ ゲートウェイ モデルにまたがってチャネルを結合したりすることができないため、ボンディングできる最大ポート数は 2 つです。CO スイッチは、トランク グループ内の第 3 または第 4 の PRI にコールをロールオーバーできます(ほとんどの CO が最大 6 回線のトランク グループをサポートしています)が、たとえば、PRI 番号 1 と PRI 番号 2 の間でチャネルをボンディングできても、PRI 番号 1 と PRI 番号 3 の間でボンディングすることはできません。

上記のビジーアウト ロジックは、すべてのコールが同じ速度で行われることを前提としています。たとえば、あるポート上で 384 kbps の 2 つのコールがアクティブなときに、128 kbps のコールが着信したとします。このコールは 2 チャネルしか使用しないため、3 つのコールに合計 14 チャネル(6+6+2 = 14)が使用され、回線上に 9 チャネルの空きが残ります。ところが、ビジーアウトしきい値が(すべてのコールが 384 kbps で行われると想定して)18 チャネルに設定されていると、このビジーアウトしきい値でまだ使用可能なチャネルは 4 つだけになります。この時点で別の 384 kbps のコールが着信すると、そのコールは、残りの 4 チャネルではコールのサポートに不十分なため、失敗します。また、18 チャネルというビジーアウトしきい値にまだ達していない(14 チャネルしか使用されていない)ので、回線はビジーアウトされず、コールは次の回線にロールオーバーされません。この状態は、既存のコールの 1 つが切断されるまで続きます。このような状況を避けるため、すべてのコールを単一のコール速度に標準化できるようにすることが重要です。

発信コール

発信コールでも着信コールと同じ状況が起きる可能性がありますが、ビジーアウトの発生の仕方は異なります。Cisco Unified Videoconferencing 3500 シリーズ ゲートウェイは、Resource Availability Indicator および Resource Availability Confirm(RAI/RAC)というメッセージをサポートしています。RAI/RAC メッセージは H.225 RAS 仕様で定義されており、ゲートウェイが満杯でコールをそれ以上ゲートキーパーにルーティングできないことを、ゲートウェイからゲートキーパーに伝えるために使用されます。ゲートウェイはビジーアウトしきい値に達すると、ステータスが True の RAI メッセージをゲートキーパーに送信します。True は「これ以上のコールの送信不可」を意味し、False は「送信可」を意味します。ゲートウェイは、ビジーアウトしきい値を下回るとすぐに RAI=False を送信します。発信コールのビジーアウトしきい値は着信コールのビジーアウトしきい値とは別のもので、それぞれ別々に設定できるので、着信コールを次の空き回線にロールオーバーしても発信コールは引き続き受け入れられ、その逆も同様です。たとえば、RAI しきい値を 12 チャネルに設定し、ISDN ビジーアウトしきい値を 18 チャネルに設定できます。その場合、384 kbps の 2 つのコールがアクティブのとき、発信コールは次の空きゲートウェイにロールオーバーされますが、3 番めの 384 kbps の着信コールは引き続き受け入れられます。同じように効率的に発信コールのビジーアウト フェールオーバーを実現する方法として、RAI/RAC 方式ではなく、次項で述べるように Unified CM のルート グループとルート リストの構造を使用する方法があります。

Unified CM でのゲートウェイの設定

Unified CM では、次のいずれかの方法で Unified Videoconferencing ゲートウェイを設定できます。

H.323 ゲートウェイとして設定し、Unified CM でコールをそのゲートウェイに直接ルーティングします。

ゲートキーパーへの H.225 ゲートキーパー制御トランクを設定し、ゲートキーパーを通じてそのゲートウェイにコールをルーティングします。

ゲートウェイが 1 つだけであれば、多くの場合、トランクを介してゲートウェイに到達するよりも、Unified CM で直接設定した方が簡単です。ロード バランシングと冗長性を得るために複数のゲートウェイを使用している場合は、それらのゲートウェイをすべて Unified CM で設定し、ルート グループとルート リストの中に配置する方法があります。または、ゲートキーパーへの H.225 トランクを設定してゲートウェイ間の RAI/RAC を使用し、コールの送信先となるゲートウェイをゲートキーパーが Unified CM に指示するように設定する方法があります。

PSTN から Unified CM への着信コールの場合、各 Cisco Unified Videoconferencing ゲートウェイを 1 つのゲートキーパーに登録する方法と、それらのゲートウェイを、すべての着信コール要求の送り先とする最大 3 台の Unified CM サーバの IP アドレスを使用して設定する方法があります。この方法は、ピアツーピア モードと呼ばれます。どちらの方法でも最終的な目標は、各ゲートウェイが受信したすべての着信コールを Unified CM に送り、Unified CM がコールのルーティング方法を決定できるようにすることです。コールをゲートウェイから Unified CM にルーティングするようゲートキーパーを設定する方法の詳細については、「ゲートキーパー」を参照してください。

コール シグナリング ポート番号

デフォルトでは、Cisco Unified Videoconferencing ゲートウェイは、ウェルノウン ポート 1720 の代わりに TCP ポート 2720 を監視します。ただし、同様にデフォルトで、Unified CM は H.323 コールをポート 1720 に送信します。ゲートウェイで監視するポートは変更できます。また、Unified CM からの送信先ポートを Unified CM の H.323 ゲートウェイ デバイス設定で変更することもできます。いずれの方法でも、ゲートウェイへの発信コールが成功するためには、両側で一致している必要があります。

着信方向では、Cisco Unified Videoconferencing ゲートウェイは、ピアツーピア モードで動作するように設定された場合、コールをポート 1720 で Unified CM に送信します。ゲートキーパーに登録するように設定された場合、Unified CM は、ランダムに生成されたポート番号をすべてのゲートキーパー制御トランクに使用します。この方法では、Unified CM が同じゲートキーパーに対して複数のトランクを持つことができます。このポート番号は、Unified CM からゲートキーパーへの Registration Request(RRQ)に含まれているため、ゲートウェイから Unified CM への着信 H.225 セットアップ メッセージは、このポート番号に送られます。ただし、ゲートウェイが Unified CM で H.323 ゲートウェイ デバイスとして直接設定されている場合、Unified CM はコールが H.225 トランクの TCP ポートに着信したことを無視し、発信元 IP アドレスをデータベースに設定されている H.323 ゲートウェイ デバイスと照合します。一致するデバイスが見つからない場合、Unified CM はそのコールがトランクに着信したかのように扱います。

発信方向に関しては、Unified CM がゲートキーパー制御 H.225 トランクを使用してゲートウェイに到達している場合は、ゲートキーパーが Unified CM に、どの TCP ポートを使用してゲートウェイに到達すべきかを知らせます。ゲートウェイが Unified CM で H.323 ゲートウェイ デバイスとして設定されている場合(ピアツーピア モード)、Unified CM は、ポート 2720(デフォルト)か 1720(ゲートウェイで監視ポートが変更された場合)にコールを送るように設定されている必要があります。

コール シグナリング タイマー

H.320 ボンディングに固有の遅延のため、ビデオ コールは音声コールよりも接続に時間がかかる場合があります。Unified CM のいくつかのタイマーは、デフォルトで音声コールをできるだけ高速に処理するように調整されているため、それが原因でビデオ コールが失敗する場合があります。したがって、H.320 ゲートウェイ コールをサポートするには、次のタイマーをデフォルト値から変更する必要があります。

H.245TCSTimeout

Media Exchange Interface Capability Timer

Media Exchange Timer

これらの各タイマーを、Unified CM Administration の Service Parameters で 25 まで増やすことを推奨します。このパラメータは、クラスタ全体のサービス パラメータなので、既存の H.323 Cisco 音声ゲートウェイへの音声コールも含めて、あらゆるタイプの H.323 デバイスへのコールに影響を与えることに注意してください。

音声ゲートウェイのベアラ機能

H.323 コールは、どのタイプのコールを行うかを示すために、H.225/Q.931 Bearer Capabilities Information Element(bearer-caps)を使用します。音声専用コールでは、bearer-caps が「speech」または「3.1 KHz Audio」に設定され、ビデオ コールでは bearer-caps が「Unrestricted Digital Information」に設定されます。一部のデバイスでは、Unrestricted Digital Information の bearer-caps をサポートしていません。Unified CM が H.323 ビデオ コールとしてコールを試みると、これらのデバイスへのコールは失敗する場合があります。

Unified CM は、次の要因に基づいて、どの bearer-caps を設定するかを決定します。

発信側デバイスまたは着信側デバイス(あるいはその両方)がビデオ対応かどうか

それらのデバイス間のコールにビデオを許可するように Unified CM のリージョンが設定されているかどうか

Unified CM では、ビデオ コールをオーディオとして再試行する機能をサポートしており、この機能は設定を介して有効にできます。Unified CM がビデオ コールの bearer-caps を「Unrestricted Digital」に設定し、コールが失敗すると、Unified CM は同じコールの bearer-caps を「speech」に設定したオーディオ コールとして再試行します。

H.323 を使用する場合、Cisco IOS ゲートウェイは、コールの設定で受信するベアラ機能に基づいて、コールを音声またはビデオとして処理できます。SIP を使用する場合、ゲートウェイはコールのネゴシエーションのため、ISDN 機能を SDP に変換します。

Cisco 音声ゲートウェイが Unified CM との通信に MGCP を使用している場合、この問題は発生しません。それは、Unified CM の MGCP プロトコル スタック上ではビデオがサポートされておらず、しかも、MGCP モードでは、Unified CM がPSTN への D チャネル シグナリングを完全に制御するためです。