Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン Cisco CallManager Release 4.0 および 4.1

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

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

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

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

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

アナログ トランク ゲートウェイは、Cisco 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 CallManager を公衆網または PBX に接続します。デジタル T1 PRI トランクは、所定の従来型ボイスメール システムとの接続にも使用できます。

コア機能要件

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

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

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

• 補足サービス サポート

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

• FAX/モデム サポート

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

• Cisco CallManager 冗長性サポート

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

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

ゲートウェイ プロトコル

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

• H.323

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

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

プロトコルの選択は、サイト特有の要件と機器の設置ベースによって決まります。たとえば、リモート サイトである支店の大部分のロケーションには、Cisco 2600XM または 3700 シリーズ ルータが設置されます。これらのルータは、Cisco IOS Release 12.2.11(T) および Cisco CallManager Release 3.1 以降で、H.323 と MGCP 0.1 をサポートします。ゲートウェイの設定では、MGCP が H.323 より優先されます。これは、設定が簡単であり、プライマリからセカンダリの Cisco CallManager に Cisco CallManager をフェールオーバーするときに、コールが切断されずに保持されるからです。一方、サポートされるインターフェイスの堅牢性により、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 CallManager の配置モデルも、ゲートウェイ プロトコルの選択に影響を与える場合があります（「IP テレフォニー配置モデル」を参照してください）。

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

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

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

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

• 「DTMF リレー」

• 「補足サービス」

• 「Cisco 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 CallManager と情報を交換できます。次の例は、Cisco IOS ゲートウェイ上のアウトバンド DTMF 設定例です。

MGCP ゲートウェイ

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

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

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

補足サービス

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

SCCP ゲートウェイ

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

H.323 ゲートウェイ

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

Cisco 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. IP Phone 1 が Cisco IOS ゲートウェイから Phone 2 にコールを転送しようとする場合、Phone 1 は、SCCP を使用して Cisco CallManager に転送要求を出します。

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

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

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

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

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

MGCP ゲートウェイ

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

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

Cisco CallManager の冗長性

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

SCCP ゲートウェイ

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

H.323 ゲートウェイ

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

（注） Cisco CallManager の冗長性は、コールの存続可能性を意味するものではありません。プライマリ Cisco CallManager に障害が起きると、IP Phone と、H.323 ゲートウェイを介して接続されている電話機との間のすべてのコールが終了します。

MGCP ゲートウェイ

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

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

プライマリ Cisco CallManager が後で使用可能になると、MGCP ゲートウェイは、元の Cisco 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 IP テレフォニー ゲートウェイは、大部分の主要 PBX ベンダー製品と相互運用でき、EIA/TIA-464B に準拠しています。

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

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

（注） 次の表では、Cisco IOS および Cisco 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 FAX 信号を終端します。

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

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

ベスト プラクティス

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

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

–パケット損失

–遅延

–遅延変動（ジッタ）

Cisco IP テレフォニー ネットワークにおける 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、メディア ゲートウェイ コントロール プロトコル（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 リレーのみがサポートされていました。これは、パススルー ネットワーク サービス エンジン（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 CallManager 設定

Cisco IOS ゲートウェイ（たとえば、Cisco 6608 と 6624）用に Cisco CallManager を設定するには、Cisco CallManager で次の手順を実行します。また、これらの設定手順については、図4-5 および図4-6 も参照してください。

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

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

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

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

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

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

図4-5 Cisco CallManager におけるゲートウェイ設定

図4-6 Cisco CallManager におけるゲートウェイ設定（続き）

この設定は、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 音声プラットフォームではサポートされています。

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

• 「ネットワーク サービス エンジン（NSE） を使用して制御されるルース ゲートウェイ」

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

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

ネットワーク サービス エンジン（NSE） を使用して制御されるルース ゲートウェイ

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

H.323

MGCP

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

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

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

• Cisco CallManager は、H.323 または 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 および MGCP を使用したコール エージェント制御の T.38

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

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

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

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

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

• Cisco CallManager は、T.38 FAX リレーのコール エージェント制御をサポートしません。したがって、この T.38 FAX リレー設定方法は、Cisco CallManager の配置には適用されません。

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

H.323

MGCP