Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) Cisco Unified CallManager Release 5.0

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

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

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

アナログ ステーション ゲートウェイは、Cisco Unified CallManager を POTS（Plain Old Telephone Service; 一般電話サービス）のアナログ電話機、IVR（Interactive Voice Response; 音声自動応答装置）システム、FAX マシン、およびボイスメール システムに接続します。ステーション ゲートウェイは、FXS（Foreign Exchange Station）ポートを備えています。

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

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

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

Cisco アクセス デジタル トランク ゲートウェイは、PRI（一次群速度インターフェイス）、Basic Rate Interface（BRI; 基本速度インターフェイス）、または T1 CAS（チャネル連携信号）などのデジタル トランクを経由して、Cisco Unified CallManager を公衆網または PBX に接続します。デジタル T1 PRI トランクは、所定の従来型ボイスメール システムとの接続にも使用できます。

コア機能要件

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

• DTMF（Dual tone multifrequency）リレー機能

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

• 補足サービス サポート

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

• FAX/モデム サポート

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

• Cisco Unified CallManager 冗長性サポート

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

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

ゲートウェイ プロトコル

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

• H.323

• メディア ゲートウェイ コントロール プロトコル（MGCP）

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

Cisco Unified IP Phone は、超軽量プロトコルである（SCCP）を使用します。SCCP はマスター/スレーブ モデルを使用しますが、H.323 は、ピアツーピア モデルです。MGCP も、マスター/スレーブ モデルを使用します。

プロトコルの選択は、サイト特有の要件と機器の設置ベースによって決まります。たとえば、リモート サイトである支店の大部分のロケーションには、Cisco 2600XM、2800、3700、または 3800 シリーズのルータが設置されます。これらのルータは、Cisco IOS Release 12.2.11(T) および Cisco Unified CallManager Release 3.1 以降で、H.323 と MGCP 0.1 をサポートします。ゲートウェイの設定では、MGCP は設定が単純なので H.323 よりも優先されます。一方、サポートされるインターフェイスの堅牢性により、H.323 が MGCP より優先される場合もあります。

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

また、使用される Cisco Unified CallManager の配置モデルも、ゲートウェイ プロトコルの選択に影響を与える場合があります（「IP テレフォニー配置モデル」の章を参照してください）。

表4-1 では、どのゲートウェイが所定のプロトコルをサポートするかを示しています。これらのプロトコルはそれぞれ、コア ゲートウェイ要件をサポートするために多少異なる方法を使用します。「ゲートウェイ プロトコルとコア機能要件」では、各プロトコルがこれらの機能要件をどのように満たしているかを説明します。

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

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

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

• 「DTMF リレー」

• 「補足サービス」

• 「Cisco Unified CallManager の冗長性」

DTMF リレー

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

SCCP ゲートウェイ

Cisco VG248 などの SCCP ゲートウェイは、伝送制御プロトコル（TCP）ポート 2002 を使用して、DTMF 信号をアウトバンドで伝送します。アウトバンド DTMF は、VG248 用のデフォルトのゲートウェイ設定モードです。

H.323 ゲートウェイ

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

MGCP ゲートウェイ

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

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

Catalyst 6000、DE-30+、および DT-24+ はすべて、Cisco Unified CallManager Release 3.1 以降で MGCP をサポートします。デフォルトで DTMF リレーは使用可能であり、追加の設定は必要ありません。

SIP ゲートウェイ

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

• Named Telephony Events（NTE）、または RFC 2833

• Unsolicited SIP Notify（UN）

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

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

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

補足サービス

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

SCCP ゲートウェイ

Cisco VG224、VG248、および ATA 188 ゲートウェイは、補足サービスを完全にサポートしています。SCCP ゲートウェイは、ゲートウェイと Cisco Unified CallManager 間のシグナリング チャネル、および SCCP を使用して、コール制御パラメータを交換します。

H.323 ゲートウェイ

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

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

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

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

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

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

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

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

図4-1 H.323 ゲートウェイの補足サービス サポート

MGCP ゲートウェイ

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

図4-2 MGCP ゲートウェイの補足サービス サポート

SIP ゲートウェイ

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

• Cisco Unified CallManager 5.0 System Guide 。次のサイトにあります。

http://www.cisco.com

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

http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax_c/callc_c/sip_c/sipc1_c/index.htm

Cisco Unified CallManager の冗長性

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

SCCP ゲートウェイ

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

H.323 ゲートウェイ

Cisco H.323 ゲートウェイは、Cisco IOS Release 12.1(2)T における dial-peer コマンドと voice class コマンドの複数の拡張機能を使用して、冗長 Cisco Unified CallManager をサポートします。新しいコマンド H.225 tcp timeout <seconds> が追加されました。このコマンドは、H.323 ゲートウェイが、H.323 コール セットアップ用の H.225 制御接続の確立に要する時間をトラッキングします。H.323 ゲートウェイがプライマリ Cisco Unified CallManager との H.225 接続を確立できない場合、別の dial-peer ステートメントで指定されるセカンダリ Cisco Unified CallManager との接続を試行します。H.323 ゲートウェイは、次に高い preference 設定を指定する dial-peer ステートメントに移ります。次のコマンドを使用すると、H.323 ゲートウェイに対して Cisco Unified CallManager の冗長性を設定できます。

MGCP ゲートウェイ

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

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

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

SIP ゲートウェイ

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

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

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

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

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

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

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

• 公衆網（または PBX）アクセスは、アナログですか、デジタルですか。

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

• 公衆網アクセスがデジタルである場合、どのタイプのシグナリングが必要ですか（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 ゲートウェイがクロッキングをサポートすることを期待しますか。

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

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

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

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

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

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

（注） 次の表では、Cisco IOS および Cisco Unified CallManager のリリース番号は、リストされている機能を特定のゲートウェイ プラットフォーム上でサポートできるようになったリリースを指しています。ハードウェア プラットフォームごとの推奨ソフトウェア リリースの推奨事項については、次の Web サイトの資料を参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/ccmcomp.htm

Cisco アナログ ゲートウェイ

表4-2 では、H.323 または SIP（Session Initiation Protocol）を使用する Cisco アナログ ゲートウェイに対してサポートされているインターフェイス タイプをリストしています。 表4-3 では、メディア ゲートウェイ コントロール プロトコル（MGCP）を使用する Cisco アナログ ゲートウェイに対してサポートされているインターフェイス タイプをリストしています。

Cisco デジタル ゲートウェイ

表4-4 ～ 表4-7 では、H.323 または SIP を使用する Cisco デジタル ゲートウェイに対してサポートされているインターフェイス タイプをリストしています。 表4-8 では、メディア ゲートウェイ コントロール プロトコル（MGCP）を使用する Cisco デジタル ゲートウェイに対してサポートされているインターフェイス タイプをリストしています。

FAX パススルーと Cisco FAX リレーに対するゲートウェイ サポート

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

FAX データの元の形式は、デジタルです。しかし、従来の公衆網を経由して送信するために、データは変調され、アナログに変換されます。FAX over IP は、このアナログ変換のプロセスを逆転させて、パケット ネットワーク上でデジタル データを送信した後、受信側の FAX マシン用にそのデジタル データをアナログに再変換します。

大部分の Cisco 音声ゲートウェイは、現在、IP ネットワークを介して FAX トラフィックを送信する、次の 2 通りの方法をサポートします。

• Cisco FAX リレー：FAX リレー モードでは、ゲートウェイが T.30 または T.38 FAX 信号を終端します。

• FAX パススルー：FAX パススルー モードでは、ゲートウェイは、FAX コールを音声コールと区別しません。

FAX トラフィックの送信には、Cisco FAX リレー モードをお勧めします。しかし、特定のゲートウェイが Cisco FAX リレーをサポートしない場合、そのゲートウェイは FAX パススルーをサポートします。

ベスト プラクティス

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

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

–パケット損失

–遅延

–遅延変動（ジッタ）

Cisco Unified Communications ネットワークにおける QoS の実装についての詳細は、次の Web サイトで入手可能な『 Cisco Network Infrastructure Enterprise Quality of Service Design 』のガイドを参照してください。

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

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

–コール アドミッション制御（CAC）を使用して、コールが規定の合計帯域幅限界を超えると、拒否されるようにします。

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

• 最良のパフォーマンスを確保するために、起点と終端の両方のゲートウェイで、Cisco FAX リレーを有効にしていることを確認してください。2 つの Cisco IOS ゲートウェイの転送方法が異なる場合、ゲートウェイはネゴシエートして Cisco FAX リレーを使用します。

Cisco FAX リレーをサポートしていない IOS 以外のゲートウェイは、Cisco Digital Access DT-24/DE-30+ だけです。このゲートウェイを Cisco IOS ゲートウェイに接続する場合は、FAX パススルー モードの使用を両方のゲートウェイに設定する必要があります。

• ネットワーク上の恒常的なパケット遅延が 1 秒を超えないこと、および遅延変動（ジッタ）が 240 ミリ秒を超えないことを確認してください。

• 不良パケットの着信頻度が高いネットワークで、パフォーマンスを改善するには、FAX マシンでエラー訂正モード（ECM）を無効にしてください。

• 大部分の FAX マシンは、現在の速度をスロー ダウンすることなく、0.4% ～ 0.6% の範囲内のパケット ドロップを受け入れるようです。しかし、0.8% ～ 1% の範囲内のパケット ドロップがあるネットワークでは、ECM を無効にする必要があります。

• 複数の FAX マシンで ECM を無効にするのを検討する前に、ゲートウェイ自体で ECM を無効にすることができます。しかし、パケット ドロップが発生する場合、FAX のイメージ品質が低下する恐れがあります。したがって、ECM を無効にするときには、長いコール所要時間やコールのドロップを検討する前に、イメージ品質を損なってもよいかどうかを十分に検討してください。また、パケットがドロップする原因を突き止めて、解決するために、ネットワークを監視し、評価することも必要です。

モデム パススルーに対するゲートウェイ サポート

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

• モデム パススルー

• モデム リレー

現在、モデム リレーとモデム パススルーは、どちらも Cisco 音声ゲートウェイでサポートされています。

モデム パススルーとは、パルス符号変調（PCM）符号化パケットと G.711 コーデックを使用して、パケット ネットワークを通じてモデム信号を転送することです。モデム パススルーでは、ゲートウェイがモデム信号と音声信号を区別し、適切なアクションを取ることができなければなりません。ゲートウェイは、モデム信号を検出すると、次のサービスを無効にします。

• エコー キャンセレーション（EC）

• 音声アクティビティ検出（VAD）

モデム パススルー モードでは、ゲートウェイは、モデム コールを音声コールと区別しません。2 台のモデム間の通信は、「音声」コールを介してインバンドにそのまま伝送されます。モデム トラフィックは、QoS 対応の IP インフラストラクチャを介して透過的に伝送され、IP ネットワーク内でデータが復調されることはありません。

モデム コールは「音声」コールを介してインバンドに伝送されるという点で、モデムのアップスピード機能は、パススルーに似ています。違いは、アップスピード機能が使用されるときに、ゲートウェイがある程度まで、モデム コールを認識する点です。リレー メカニズムは使用されませんが、ゲートウェイは、モデム トーンを認識し、「音声」コーデックを G.711（アップスピード部分）に自動的に変更し、コールの期間中 VAD とエコー キャンセレーション（EC）を無効にします。

現在、このアップスピード機能は、Cisco IOS Release 12.1.3T による Cisco AS5300 以外の Cisco IOS プラットフォームではサポートされていません。Cisco 2600XM、3700、VG224、および Catalyst 4000 Access Gateway Module（AGM）プラットフォームの場合、モデムのアップスピード機能は、将来の Cisco IOS リリースでサポートされる予定です。これらのプラットフォームの場合、モデムのアップスピード機能が使用可能になるまで、ダイヤルピアで no vad を設定できます。

モデム アップスピード機能は、Catalyst 6000 ゲートウェイ モジュールでもサポートされています。

ベスト プラクティス

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

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

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

–遅延

–遅延変動（ジッタ）

詳細は、次の Web サイトで入手可能な『 Cisco Network Infrastructure Enterprise Quality of Service Design 』のガイドを参照してください。

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

• コール アドミッション制御（CAC）を使用して、コールが規定の合計帯域幅限界を超えると、拒否されるようにします。

• モデムを使用するすべてのコールに、G.711 を使用します。ゲートウェイの 1 つがモデム リレーをサポートしていない場合、モデム パススルーがネゴシエートされます（G.711 のみ）。モデムが使用される場合、すべてのコールに G.711 を使用することが最善の方法です。

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

• 可能な場合、単一のシグナリング プロトコルとゲートウェイ ファミリーを使用して、相互運用性の問題を最小限にします。

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

V.90 サポート

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

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

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

アナログ ゲートウェイ

Cisco IOS ゲートウェイ：

• 2600XM および 2691（FXS）

• 2800（FXS）

• 3725 および 3745（FXS）

• 3800（FXS）

• VG200（FXS）

• VG224

• 1751 および 1760

• コミュニケーション メディア モジュール（CMM）FXS カード

IOS 以外のゲートウェイ：

• VG248

• ATA 188

• 6624

デジタル ゲートウェイ

Cisco IOS ゲートウェイ：

• 2600XM および 2691

• 2800

• 3725 および 3745

• 3800

• VG200

• VG224

• 1751 および 1760

• 7200 および 7500

• AS5300、5350、5400、および 5850

• コミュニケーション メディア モジュール（CMM）

IOS 以外のゲートウェイ：

• 6608

（注） FAX とモデムのサポート テストは、Cisco IOS ゲートウェイ上の Cisco IOS Release 12.3(1)、および Cisco VG248 Analog Phone Gateway の Release 1.2.1 を使用して、上記のプラットフォーム上で実行されました。

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

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

高いレベルで、Cisco IOS Release 12.3(1)（Cisco 6608 のロード 47 と Cisco 6624 のロード 41）、および VG248 の Release 1.2.1 は、Cisco FAX リレー、モデム パススルー、および音声機能の相互運用性をサポートします。Cisco IOS Release 12.2(11)T1 より前には、Cisco IOS と IOS 以外の音声プラットフォーム間では、音声と Cisco FAX リレーのみがサポートされていました。これは、パススルー Named Service Event（NSE）方式の非互換性により、モデム パススルーが相互運用できなかったからです。

ネットワークにおける一般的なプロトコルの組み合せの一部には、MGCP と H.323、SCCP と H.323、および SCCP と MGCP があります。一般的な音声ゲートウェイには、Cisco VG224、VG248、2600XM、2800、3700、3800、5300、および Catalyst 6000 が含まれます。

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

（注） Cisco ATA 188、VG248、および Catalyst 6000 プラットフォームは現在、T.38 FAX リレーをサポートしていません。これらのプラットフォームが Cisco AS5350 または AS5400 ゲートウェイに接続される場合、FAX アプリケーションに対して FAX パススルーのみがサポートされます。

ゲートウェイの組み合せと機能の相互運用性

FAX とモデムの相互運用性について最も多い質問は、図4-3 に示されているような、Cisco IOS ゲートウェイ（たとえば、Cisco 2800 や 3800）と IOS 以外のゲートウェイ（たとえば、Cisco VG248）との組み合せに関するものです。

図4-3 Cisco IOS と IOS 以外のゲートウェイを組み合せる構成

FAX とモデムの相互運用性について次に多い質問は、図4-4 に示されているような、Cisco IOS ゲートウェイのみを使用する構成に関するものです。

図4-4 Cisco IOS ゲートウェイのみを使用する構成

どちらのシナリオの回答も、基本的に同じです。6608 上の Cisco IOS ロード 47、および VG248 上の Release 1.2.1 より前では、音声と Cisco FAX リレーのみがサポートされ、FAX パススルーとモデム パススルーは、NSE の非互換性によりサポートされません。6608 上の Cisco IOS ロード 47 以降、6624 上のロード 41 以降、および VG248 上の Release 1.2.1 は、この 3 つのプラットフォームはすべて、コール制御プロトコルに関係なく、音声、Cisco FAX リレー、およびモデム パススルー用に、Cisco IOS ゲートウェイと相互運用できます。NSE パススルー方式は、シグナリング パスではなく、ベアラ パスで動作するので、コール制御プロトコルとは関係しません。

類似ゲートウェイ間の機能サポート

表4-11 では、同じ一般的なタイプのゲートウェイ間（たとえば、Cisco VG248 と 6608 間、2600XM と 3700 間、または 2600XM と AS5300 間）でサポートされる FAX とモデムの機能をリストします。両方のプラットフォームが所定の機能をサポートする限り、プラットフォームは相互運用します。

ゲートウェイ設定例

ここでは、FAX とモデムをサポートするためのゲートウェイ設定例を示します。

Cisco IOS ゲートウェイの設定

H.323

MGCP

Cisco VG248 の設定

Cisco IOS ゲートウェイ用の Cisco Unified CallManager 設定

Cisco IOS ゲートウェイ（たとえば、Cisco 6608 や 6624）用に Cisco Unified CallManager を設定するには、Cisco CallManager で次の手順を実行します。

ステップ 1 Cisco Unified CallManager Administration で、 Device > Gateway の順に選択して、 Find/List Gateways ウィンドウを表示します。

ステップ 2 変更するゲートウェイを検索するか（すでに存在する場合）、または Add a New Gateway をクリックして新しいゲートウェイを Cisco Unified CallManager データベースに追加します。

ステップ 3 適切なタイプのゲートウェイ（たとえば、Cisco Catalyst 6000）を選択した後、 FAX Relay Enable をクリックして Cisco FAX リレーを使用可能にします。

ステップ 4 NSE Type ドロップダウン リスト ボックスを使用して、モデム パススルー用に IOS Gateways を選択します。

ステップ 5 Update をクリックして変更内容を保存します。

ステップ 6 ゲートウェイをリセットして変更内容を適用します。

この設定は、Cisco VG248、6608、6624、および IOS ゲートウェイ間での、音声、Cisco FAX リレー、およびモデム パススルーをサポートします。ただし、Cisco FAX リレーをサポートしない Cisco AS5350 および AS5400 ゲートウェイを除きます。また、この設定は、パススルー モードの V.34 モデム接続もサポートします。V.90 モデム接続は保証されていませんが、ネットワーク ジッタの量とクロック同期によっては可能です。

FAX とモデム パススルー用のクロック ソーシング

FAX とモデム パススルーを正常に機能させるには、クロック信号が重要な役割を果たします。ゲートウェイのクロックは、Stratum クロッキングが提供される公衆網クロックと同期させる必要があります。このクロック同期がないと、FAX および（特に）モデムのパススルーは機能しません。クロックを正しく同期させるには、T1 コントローラで次の設定を入力してください（この例では、T1 コントローラは、公衆網に接続している音声ゲートウェイです）。

また、公衆網に接続している他のすべてのインターフェイスでも、この設定を入力してください。

T.38 FAX リレー

T.38 FAX リレーは、Cisco ATA 188、VG248、6608、および 6624 ゲートウェイではサポートされていませんが、Cisco 2800 および 3800 シリーズ ルータなど、大部分の高性能 Cisco IOS 音声プラットフォームではサポートされています。H.323 または SIP モードで動作する場合、これらのプラットフォームは MGCP をサポートしません。

T.38 FAX リレーは、次のいずれかの方法で設定できます。

• 「Named Service Event（NSE）を使用して制御されるゲートウェイ」

• 「H.245 または SDP（Session Description Protocol）による機能交換を使用して制御されるゲートウェイ」

• 「H.323 Annex D を使用したコール エージェント制御の T.38」

Named Service Event（NSE）を使用して制御されるゲートウェイ

この設定では、次の Cisco IOS ゲートウェイ設定例に示されているように、ダイヤルピア上の静的 T.38 設定を使用します。

H.323

MGCP

H.245 または SDP（Session Description Protocol）による機能交換を使用して制御されるゲートウェイ

この T.38 FAX リレー設定方法には、次の特性が適用されます。

• T.38 機能はゲートウェイ間で交換されます。FAX トーンの検出後に T.38 FAX リレーに切り替わることを起点側のゲートウェイに知らせるために、Named Service Event（NSE）メッセージが、RTP ストリーム上で終端側のゲートウェイから送信されます。この NSE メッセージは RTP ストリーム上で送信されるので、コール制御信号に対しては透過されます。

• Cisco Unified CallManager は、MGCP ではこの機能交換をサポートできません。したがって、T.38 機能が交換されない場合であっても、設定コマンドを使用して強制的に T.38 FAX リレーに切り替える必要があります。

• 選択可能なフォールバック方法は、次の 3 通りです。

–Cisco FAX リレー（デフォルト）

–FAX パススルー

–なし

次に、このタイプの設定例を示します。

H.323

MGCP

Cisco VG248 および 6608 または 6624 を使用するトポロジでは、次の Cisco IOS コマンドを使用してください。

これらの 2 つのコマンドにより、Cisco IOS ゲートウェイは、T.38 FAX リレーとモデム パススルーを実行するために他の Cisco IOS ゲートウェイと相互運用するだけでなく、Cisco FAX リレーとモデム パススルーを実行するために VG248 とも相互運用できるようになります。

H.323 Annex D を使用したコール エージェント制御の T.38

この T.38 FAX リレー設定方法には、次の特性が適用されます。

• コール制御エージェント（たとえば、Cisco Unified CallManager）が T.38 FAX リレーを制御し、ゲートウェイはパッシブ モードで動作します。

• ゲートウェイ間で NSE メッセージは送信されません。

• このタイプの設定では、T.38 FAX リレーは、コール制御プロトコルに対して透過的ではありません。コール エージェントは、H.323 と SIP 間のプロトコル変換を実行します。

• この方法により、T.38 FAX リレーは、Cisco IOS Release 12.3(1) で設定できます。Cisco BTS 10200 Softswitch もこの方法をサポートします。

• Cisco Voice Media Streaming Application は T.38 をサポートしませんが、Cisco IOS メディア ターミネーション ポイント（MTP）は T.38 をサポートします。したがって、メディア リソース グループ リスト（MRGL）の中で Cisco IOS MTP に正しい優先順位付けが行われるようにしてください。

次に、このタイプの設定例を示します。

H.323

MGCP

公衆網からの着信コールのルーティング

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

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

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

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

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

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

ゲートウェイの番号操作

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

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

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

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

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

公衆網への発信コールのルーティング

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

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

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

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

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

自動代替ルーティング（AAR）

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

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

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

• 自動代替ルーティング（AAR）を使用し、公衆網ゲートウェイなどの代替パス上でコールを再ルーティングします。

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

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

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

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

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

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

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

最低料金選択機能

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

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

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

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

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

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

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

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

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

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

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

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

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

• 公衆網から IP ネットワークへの着信コール

• IP ネットワークから公衆網への発信コール

着信コール

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

ある会社に Cisco 3526 IP/VC ゲートウェイがあり、それが ISDN PRI 回線でセントラル オフィス（CO）のスイッチに接続されています。この場合、ISDN PRI 回線は 23 の B チャネルを提供します。ビデオ コールが公衆網から 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 3540 IP/VC ゲートウェイは 2 つの ISDN PRI 接続を提供し、両方のポートにまたがったボンディング チャネルをサポートします。たとえば、ポート 1 の空きが 5 チャネルしかなく、ポート 2 がアイドル状態であるため、23 チャネルが使用可能であるとします。この場合、ポート 1 から 5 チャネル、ポート 2 から 1 チャネルを使用してボンディングすることにより、第 4 の 384 kbps のコールに成功できます。これにより、コントローラ 2 上に残る空きは 22 チャネルとなり、ある時点で着信コールが再びビジーアウトしきい値に到達します。その時点で、ポート 2 上の残りのチャネルはビジーアウトされ、それ以後のすべての着信コールは原因コード「Network Congestion」で拒否されます。Cisco Unified Videoconferencing ゲートウェイでは、異なるゲートウェイにまたがってチャネルを結合したり、同じ Cisco 3544 シャーシ内にあるさまざまな Cisco 3540 ゲートウェイ モデルにまたがってチャネルを結合したりすることができないため、ボンディングできる最大ポート数は 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 3500 シリーズの IP/VC ゲートウェイは、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 方式ではなく、次項で述べるように Cisco Unified CallManager のルート グループとルート リストの構造を使用する方法があります。

Cisco Unified CallManager でのゲートウェイの設定

Cisco Unified CallManager では、次のいずれかの方法で IP/VC ゲートウェイを設定できます。

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

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

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

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

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

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

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

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

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

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

• H.245TCSTimeout

• Media Exchange Interface Capability Timer

• Media Exchange Timer

これらの各タイマーを、Cisco Unified CallManager 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」に設定されます。Cisco 音声ゲートウェイ、一部のレガシー PBX、および大部分のセルラー電話会社は、Unrestricted Digital Information の bearer-caps をサポートしていません。したがって、音声ゲートウェイへのコールを Cisco Unified CallManager がビデオ コールとして試みた場合、コールが失敗することがあります。

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

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

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

たとえば、ビデオ対応デバイス（関連付けられた VT Advantage クライアントを持つ Cisco Unified IP Phone など）が Cisco 音声ゲートウェイと同じリージョン内で設定されているネットワークを考えてみます。ユーザが外線にアクセスするために 9 をダイヤルすると、Cisco Unified CallManager は、発信側デバイスがビデオ対応であって、リージョンが 384 kbps のビデオ帯域幅を許可するように設定されていることを確認します。Cisco Unified CallManager は、そのコールに対して bearer-caps を Unrestricted Digital Information に設定します。ところが、コールが Cisco 音声ゲートウェイへのコールなので、ゲートウェイはそのコールを原因コード「Incompatible Destination」で拒否します。この問題は、H.323 音声ゲートウェイを使用し、Cisco Unified Video Advantage に関連付けられた IP Phone のあるすべてのネットワークで発生します。ユーザにとっては、Cisco Unified Video Advantage をインストールするまで、すべてが順調に機能しているように見えますが、Cisco Unified Video Advantage を実行している PC を IP Phone に接続するとすぐに、公衆網へのコールが失敗します。

この状況になるのは、H.323 音声ゲートウェイへのコールだけです。Cisco 音声ゲートウェイが Cisco Unified CallManager との通信に MGCP を使用している場合、この問題は発生しません。それは、Cisco Unified CallManager の MGCP プロトコル スタック上ではビデオがサポートされておらず、しかも、MGCP モードでは、Cisco Unified CallManager が公衆網への D チャネル シグナリングを完全に制御するためです。同様に、Cisco 音声ゲートウェイが Cisco Unified CallManager との通信に SIP を使用している場合も、この問題は発生しません。その理由は、Cisco Unified CallManager の SIP プロトコル スタック上でビデオがサポートされていないためです。たとえサポートされていたとしても、ゲートウェイは、Cisco Unified CallManager の発信 SDP（Session Description Protocol）アドバタイズメントで渡されたビデオ機能を無視するだけです。

このような状況を防止するには、次の例に示すように、 voice-port 設定モードで bearer-caps コマンドを使用することにより、すべての Cisco H.323 音声ゲートウェイに bearer-caps を設定します。