Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン Cisco CallManager Release 4.0 および 4.1
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月18日
章のタイトル： Cisco CallManagerトランク
Cisco CallManagerトランク
Cisco CallManager Release 4.0 では、Session Initiation Protocol（SIP）トランクがサポートされるようになりました。Release 4.0 より前の Cisco CallManager は、H.323 トランクのみをサポートしていました。この章では、Cisco CallManager Release 4.1 に関する設計の考慮事項について説明します。ただし、説明の多くは Release 4.0 および 3.3 にも該当します。
現在、H.323 トランクは、他の Cisco CallManager クラスタや、ゲートウェイなどの他の H.323 デバイスに対する接続性を提供します。H.323 トランクは、Cisco CallManager がクラスタ内通信用にサポートするオーディオおよびビデオ コーデックのほとんどをサポートします。ただし、ワイドバンド オーディオ、ワイドバンド ビデオ、および H.264 ビデオについてはサポートしません。
H.323 トランクは、Empty Capabilities Set（ECS）を使用して、保留/保留解除や転送などの補足コール サービスを提供します。この方法は、メディア ストリーム（またはチャネル）を停止または終了し、同一または別のエンドポイント アドレスに対してメディア ストリームを開始または起動するための標準の H.245 メカニズムです。この方法を使用すると、Cisco CallManager は、コールをアクティブにしたままでも、メディア ストリームの送信元および宛先を迅速に制御することができます。
たとえば、H.323 トランクを使用した 2 つのクラスタ（A と B）間のコールについて考えます。クラスタ A のユーザがクラスタ B のユーザを保留にした場合、2 人のユーザ間のメディア ストリームは終了し、クラスタ B のユーザはクラスタ A の Music On Hold（MOH）サーバに接続されます。MOH サーバは、ユーザにメディア（音楽ファイル）を送信するよう指示されます。クラスタ A のユーザがコールを保留解除すると、MOH ストリームが終了し、2 人のユーザ間で双方向メディア ストリームが再開されます（Cisco CallManager は、補足コール サービス用に H.450 をサポートしていません）。このケースでは、MOH は ECS 動作の一例です。H.323 トランクはマルチキャスト MOH をサポートしないため、H.323 トランクの Media Resource Group List（MRGL; メディア リソース グループ リスト）には、ユニキャスト MOH リソースだけを含める必要があります（詳細については、「Music on Hold」を参照してください）。
H.323 トランク上のコールに使用される帯域幅を制御するには、Cisco CallManager で設定され、各トランクに割り当てられる、 リージョン を使用します。リージョンは、そのリージョンのオーディオ コーデック タイプと帯域幅を指定することで、コールに割り当てられる帯域幅の量を制限します。そのリージョンと別のリージョン間のコールは、指定された帯域幅の制限を超えることはできません。H.323 トランク上でコールを発信するデバイスが、より限定的なリージョン内にある場合や、ビデオなどの特定のコーデックをサポートしない場合、そのデバイスはそのコールに使用可能なコーデックのサブセットになっています。H.323 トランク上のすべての DTMF（Dual Tone MultiFrequency）シグナリングは、H.245 を使用してアウトバンドで提供されます。
SIP トランクは、ゲートウェイ、プロキシ、ボイスメール システム、および他の Cisco CallManager クラスタなど、他の SIP デバイスへの接続性を提供します。SIP トランクには、H.323 トランクとは異なる次の特性があります。
•
G.711 A-law および mu-law コーデックをサポートする
• コールごとにメディア ターミネーション ポイント（MTP）を必要とする（MTP も RFC 2833 DTMF をサポートする）
H.323 トランク
Cisco CallManager では、次の主要なタイプの H.323 トランクを設定できます。
クラスタ間トランク（非ゲートキーパー制御）
このトランクは、最も単純なもので、単一のマルチクラスタ キャンパスまたは分散型コール処理配置で他の Cisco CallManager クラスタに接続するために使用されます。このトランクは、コール アドミッション制御にゲートキーパーを使用しません。ただし、帯域幅制御が必要な場合は、Cisco CallManager で設定されたロケーションを使用できます。
このタイプのトランクを定義する場合、同一の宛先クラスタに最大 3 つのリモート Cisco CallManager サーバを定義できます。トランクは、定義されているすべてのサーバに自動的にロードバランスされます。リモート クラスタでは、対応するクラスタ間トランク（非ゲートキーパー制御）を設定することが重要です。このトランクには、最初のクラスタでリモート Cisco CallManager サーバとして定義されているサーバと同じサーバを含む Cisco CallManager 冗長性グループを割り当てます。同様の設定は、クラスタ間トランクによって接続された各 Cisco CallManager クラスタでも必要です。
たとえば、クラスタ 1 にクラスタ 2 へのトランクがあり、クラスタ 2 にクラスタ 1 へのトランクがある場合は、次の設定が必要になります。
–サーバ B、C、および D を、クラスタ 2 へのトランクに関連付けられたデバイス プールで定義されている Cisco CallManager 冗長性グループのメンバーとして設定します。
–非ゲートキーパー制御トランクに、クラスタ 2 のリモート サーバ D、E、および F を設定します。
–サーバ D、E、および F を、クラスタ 1 へのトランクに関連付けられたデバイス プールで定義されている Cisco CallManager 冗長性グループのメンバーとして設定します。
クラスタ間トランク（ゲートキーパー制御）
クラスタ数が多くなる場合は、クラスタ間非ゲートキーパー制御トランクの代わりに、クラスタ間ゲートキーパー制御トランクを使用する必要があります。ゲートキーパー制御トランクを使用する主な利点は、クラスタとフェールオーバー時間を全体的に管理できることです。非ゲートキーパー制御トランクでは、一般に、トランクのフル メッシュを設定する必要があります。ただし、この作業は、クラスタ数が増加すると管理負担になる場合があります。また、クラスタ内のサブスクライバ サーバが到達不能になった場合は、5 秒（デフォルト）でコールの試行がタイムアウトします。クラスタ全体が到達不能になった場合、コール障害または公衆網を介した再ルーティングのどちらかが発生するまでの試行回数は、トランク用に定義されたリモート サーバの数と、ルート リストまたはルート グループ内のトランクの数によって異なります。リモート サーバと非ゲートキーパー制御トランクの数が多いと、コール遅延が過剰になることがあります。
ゲートキーパー制御トランクを使用する場合は、ゲートキーパーに登録されている他のすべてのクラスタとゲートキーパーを介して通信できるトランクを 1 つだけ設定します。クラスタまたはサブスクライバが到達不能になった場合、ゲートキーパーは自動的に、コールをクラスタ内の別のサブスクライバに送信するか、または他のサブスクライバが存在しなければコールを拒否します。その結果、ほとんど遅延させることなく、公衆網を介して（必要な場合）コールを再ルーティングすることができます。単一の Cisco ゲートキーパーを使用すると、100 のクラスタすべてが、それぞれ 1 つのトランクを、相互にコールできるすべてのクラスタに登録できます。非ゲートキーパー制御トランクを使用する場合、この同じトポロジでは、各クラスタに 99 のトランクを設定する必要があります。クラスタ間ゲートキーパー制御トランクは、他の Cisco CallManager と通信する場合にのみ使用される必要があります。これは、このトランクを他の H.323 デバイスで使用すると、補足サービスに問題が発生する場合があるためです。また、Release 3.2 より前の Cisco CallManager との下位互換性を確保する場合は、クラスタ間ゲートキーパー制御トランクを使用する必要があります。
H.225 トランク（ゲートキーパー制御）
H.225 ゲートキーパー制御トランクは、本質的にはクラスタ間ゲートキーパー制御トランクと同じですが、Cisco CallManager クラスタ Release 3.2 以降のほか、ゲートウェイ、会議システム、およびクライアントなどの他の H.323 デバイスと連携動作する機能を持つ点が異なります。この機能は、コールごとに検出メカニズムを通じて実現されます（この検出プロセスの詳細については、「Cisco CallManager における H.323 動作」を参照してください）。このタイプのトランクは、すべての Cisco CallManager クラスタが Release 3.2 以降の場合に推奨される H.323 トランクです。
ゲートキーパー トランクの冗長性、復元性、およびロード バランシング
冗長性は、設計の要件に応じて、複数の方法で実現できます。最も簡単に実現するには、ゲートキーパー制御トランクを設定し、そのトランクに割り当てられたデバイス プールに関連付けられている Cisco CallManager 冗長性グループに、最大 3 つのサブスクライバを割り当てます。この設定により、すべてのサーバが、同じテクノロジー プレフィックスと共に、同じゾーン内の同じゲートキーパーに登録されます。ただし、h323_id に使用される H.323 トランクの名前には、「_ n 」というサフィックスが付加されます。ここで、 n はクラスタ内のノード番号です。この ID は自動的に生成され、変更することはできません。単一のトランクを設定しても、ゲートキーパーは、複数のトランク、つまり Cisco CallManager 冗長性グループ内のサブスクライバごとに 1 つのトランクを登録します。
追加の冗長性要件がある場合は、別のゲートキーパー制御トランクに、Cisco CallManager 冗長性グループにある別の名前と別のサブスクライバを設定できますが、それ以外のパラメータはすべて最初のトランクと同じになります。この 2 つ目のトランクによって、追加のサブスクライバがゲートキーパーに登録されます。
標準のサブスクライバ ペアを構成する 2 つのサーバから Cisco CallManager 冗長性グループを構成し、この冗長性グループを含むデバイス プールを割り当てることをお勧めします（サブスクライバの冗長性の詳細については、「コール処理サブスクライバ」を参照してください）。クラスタ全体で完全な冗長性を実現するには、4 つの異なるデバイス プールを使用する 4 つのトランクが必要になります。結果的に、8 つのサブスクライバがゲートキーパーに登録されます（3 つのトランクとより大きな冗長性グループを使用しても同じ結果になる場合があります）。
登録時、Cisco CallManager とゲートキーパー間では複数のパラメータが受け渡しされます。Cisco CallManager は、リンクごとに、ゲートキーパーの Registration Admission Status（RAS）メッセージ用に、エフェメラルなユーザ データグラム プロトコル（UDP）ポートを使用します。このポートは、通常であれば、UDP 1719 です。ただし、Cisco CallManager は、特定の RAS メッセージの宛先であるトランクを判別できる必要があります。したがって、Cisco CallManager は一定範囲の UDP ポートを使用して、動的に割り当てます。
登録プロセス時、トランクは、その Cisco CallManager 冗長性グループにある他のサブスクライバに関する次の情報を登録します。
推奨されるクラスタ化ゲートキーパーが使用されている場合、ゲートキーパーは、代替ゲートキーパー アドレスのリストを返します。このリストは、プライマリ ゲートキーパーで障害が発生した場合や使用可能なリソースが不足した場合に使用されることがあります。
図5-1 は、Gatekeeper Update Protocol（GUP）を使用して通信する、ゲートキーパーのクラスタを示しています（ゲートキーパーの詳細については、「コール処理」を参照してください）。
H.323 トランクの Cisco CallManager 冗長性グループにサブスクライバが 1 つだけ含まれている場合、Cisco CallManager の設定済みゲートキーパーとゲートキーパー クラスタの間の接続は 1 つのみになります（図5-2 を参照）。
図5-2 単一の Cisco CallManager サブスクライバに対する H.323 トランク
トランクに関連付けられた Cisco CallManager 冗長性グループに複数のサブスクライバが含まれている場合、Cisco CallManager クラスタとゲートキーパー クラスタ間には追加の接続が確立されます（図5-3 を参照）。
図5-3 複数の Cisco CallManager サブスクライバに対する H.323 トランク
このアプローチによってサブスクライバ障害やゲートキーパー障害に対する冗長性が確保されるのは、登録完了後です。これは、トランクの登録時に代替ゲートキーパーの通信が行われるためです。ただし、このアプローチでは、設定済みのゲートキーパーが初期登録時に使用不能である場合や、結果的にリセットされる場合には、冗長性が確保されません。これは、代替ゲートキーパーのリストがダイナミックであり、データベースに格納されないためです。冗長性のレベルを上げたりロード バランシングを追加したりするには、ゲートキーパー クラスタにある追加のゲートキーパーを Cisco CallManager で設定します。たとえば、元のトランクが要素 2 に登録されている場合は、追加のゲートキーパーを要素 4 として設定できます（図5-4 を参照）。
図5-4 ロード バランシングと追加の冗長性のために設定された追加のゲートキーパー
図5-4 の例の場合、Cisco CallManager の設定には次のコンポーネントが含まれます。
• サブスクライバ サーバ A および B を含む Cisco CallManager 冗長性グループに対して定義された 2 つの H.323 トランク
このアプローチを使用すると、初期設定時に要素 2 または要素 4 が到達不能であっても（つまり、起動中またはトランクのリセット中でも）、引き続き Cisco CallManager クラスタが登録できるようになります。
Cisco CallManager クラスタに着信するコールのロード バランシングは、デフォルトで自動的に行われます。これは、ゲートキーパーが、ゾーン内の登録済みサブスクライバのいずれかをランダムに選択するためです。この動作が期待と異なる場合は、ゲートキーパーで gw-priority 設定コマンドを使用して、このデフォルト動作を変更することができます（例5-1 を参照）。
例5-1 gw-priority コマンドを使用してコールを特定のトランクに送信する
例5-1 では、H.323 トランクは Cisco CallManager で sjc-trunk として設定されています。また、Cisco CallManager サブスクライバが、クラスタ内のサブスクライバのノード番号を示すために、「_2」と「_3」のサフィックスを自動的に付加します。したがって、この例では、最初の選択肢としてノード 2 を使用します。このノードは、このトランクの CallManager 冗長性グループにおいて最もプライオリティの高い Cisco CallManager となる必要があります。このケースでは、ノード 3 は 2 番目の選択肢となります。
gw-default-priority 0 を使用するかどうかは任意です。この例で使用したのは、このゾーンで登録するよう不用意に設定される可能性のある他のトランクが一切使用されないようにするためです。
Cisco CallManager クラスタからの発信コールは、次のいずれかの方法でロードバランスできます。
• ルート グループにある単一の H.323 トランクは、常に、Cisco CallManager 冗長性グループで使用可能な最もプライオリティの高いサブスクライバを使用します。プライオリティの低いサブスクライバが使用されるのは、プライオリティの高いサブスクライバが使用不能になった場合のみです。
• 循環ルート グループにある複数の H.323 トランクは、グループ内のすべての H.323 トランクに均等にコール負荷を分散します。
次の例は、さまざまなシナリオでロード バランシングを設定する方法を示しています。
すべてのコールをクラスタ内の単一のサブスクライバから発信する場合：
• ルート グループ内に単一の H.323 トランクを設定します。
コールをクラスタ内の 4 つのプライマリ サブスクライバに分散する場合：
• 4 つの Cisco CallManager 冗長性グループに対して 4 つの H.323 トランクを定義し、すべてのトランクを循環ルート グループに含めます。
• Cisco CallManager 冗長性グループは、次のように定義されます。
サブスクライバ A、C、E、および G はすべてプライマリで、サブスクライバ B、D、F、および H はバックアップです。
コールをクラスタ内の 8 つのサブスクライバに分散する場合：
• 8 つの異なる Cisco CallManager 冗長性グループに対して 8 つの H.323 トランクを定義し、各グループにサブスクライバを 1 つだけ含め、すべてのトランクを循環ルート グループに含めます。
メディア ターミネーション ポイントに対する H.323 トランク
メディア ターミネーション ポイント（MTP）は、一般に、H.323 トランクの通常動作には必要ありません。ただし、通信相手となるデバイスが、H.323 Version 1 である場合や、補足サービス用に Empty Capabilities Set（ECS）をサポートしていない場合には必要です。
MTP が必要かどうかをテストするには、次の簡単な手順を使用します。
1. 電話機から H.323 トランクを介して他のデバイスにコールを発信します。このコールは通常どおりに発信する必要があります。
2. コールを保留にしてから、保留解除します。コールがドロップする場合は、Cisco CallManager と他のデバイス間の相互運用性を保証するために MTP を使用することをお勧めします。
MTP は、H.323 トランク上でコールを発信する他のデバイスからのメディア ストリームを終端させる場合や、同じ音声ペイロードでメディア ストリームを再発信する場合に非常に役立ちます。ただし、そのような場合、IP アドレスは MTP のアドレスに変更されます。この事実に留意して、次のシナリオで MTP を使用します。
• 企業内の電話機、ゲートウェイ、および他のデバイスがすべて RFC 1918 プライベート アドレスを使用する場合は、すべての音声およびビデオ デバイスにネットワーク アドレス変換（NAT）を使用しなくても、引き続きパブリック ネットワーク上の他のシステムに接続できます。パブリック ネットワークと通信する Cisco CallManager サブスクライバがパブリック IP アドレスを使用している場合、シグナリングはルーティングされます。また、すべての MTP もパブリック アドレスを使用している場合、RFC 1918 アドレスを持つデバイスからのメディアは MTP で終端され、再度発信されます。ただし、今度は、パブリック ネットワーク上でルーティング可能なパブリック アドレスが割り当てられます。このアプローチを使用すると、RFC 1918 アドレスを持つ何万台ものデバイスが、パブリック ネットワークと通信できるようになります。この同じ方法を使用すると、企業ネットワークにあるデバイスが他の企業またはサービス プロバイダーと通信するときに、そのデバイスの実際の IP アドレスを隠すことができます。
• 信頼性境界を設定すると、ファイアウォールを通過させることや、アクセス コントロール リスト（ACL）を使用したアクセスを許可することができます。通常、メディアがファイアウォールを通過できるようにするには、アプリケーション レイヤ ゲートウェイ（ALG）またはフィックスアップを使用して、動的にメディア ストリームにアクセス許可を与えるか、または、ファイアウォールを越えて通信する必要のある音声デバイスすべてで使用するための広範囲のアドレスおよびポートを割り当てます。H.323 トランクを使用し、ファイルまたは ACL を通過するすべてのコールには、MTP から発信されるメディアが割り当てられます。このメディアでは、単一の IP アドレスまたは狭い範囲の IP アドレスを使用できます。
これらの方法を両方使用する場合、 MTP Required チェックボックスをオンにすると、デフォルトで、H.323 トランク上のコールが許可されます。このことは、MTP リソースが使用不能の場合や、使い果たされた場合でも同様です。このデフォルト動作により、コールの音声パスが使用不能になる場合があります。この動作を変更するには、H.323 セクションにある Cisco CallManager サービス パラメータ Fail Call if MTP allocation fails を True に設定します。
メディア ターミネーション ポイントに対する SIP トランク
Cisco CallManager は、使用中のプロトコルによって提供されるアウトバンド シグナリング メカニズムを使用して、DTMF 信号を送受信します。メディアがエンドポイント間を直接流れる場合でも、シグナリングは常に Cisco CallManager とエンドポイント間で行われるため、この動作は Session Initiation Protocol（SIP）では多少異なります。SIP では、DTMF を送信する一般的な方法として、RFC 2833 が使用されます。RFC 2833 は、メディア ストリームにおける RTP ペイロードの特定のタイプとして DTMF ディジットを送信します。DTMF ディジットは、コーデックによって符号化されるトーンとしては送信されません。Cisco CallManager が SIP トランクを介して DTMF を検出および送信できるようにするには、SIP トランクに関連付けられた MRGL に、RFC 2833 をサポートする MTP を含める必要があります（詳細については、「メディア ターミネーション ポイント（MTP）」を参照してください）。
図5-5 は、Skinny Client Control Protocol（SCCP）を介してアウトバンドで Cisco CallManager に送信されるディジット 3 の DTMF 信号を示しています。この信号は、次に、SCCP を介してアウトバンドで MTP に送信されます。MTP は、次に、DTMF ディジットが 3 であることを示すために、RFC 2833 RTP パケットをメディア ストリームに挿入します。MTP が RFC 2833 RTP パケットを受信した場合は、同じイベントが逆の順序で発生します。この場合、パケットは、メディア ストリームから抽出され、アウトバンドで Cisco CallManager に送信されます。
Cisco CallManager における H.323 動作
この項では、H.323 プロトコルを Cisco CallManager で使用および実装する方法、および特定の機能が所定どおりに動作する仕組みとその理由について説明します。
理解する上で最も重要な点は、どのサブスクライバがコール シグナリング デーモンを実行するかということです。このデーモンは、H.323 コールを発信および受信する部分的なコードです。これは、通常、H.225 デーモン（H.225D）と呼ばれます。H.225 は、H.323 プロトコルの一部で、主にコール制御を担当します。H.245 は、H.323 のもう 1 つの主要コンポーネントで、コールのメディア制御を担当します。
特定の H.323 デバイスに対する Cisco CallManager 冗長性グループのリストに含まれているサブスクライバによって、デーモンを実行するサブスクライバと実行時期が決定されます。この点は非常に重要です。これは、不適切なサブスクライバに送信されたコールは、別の H.225D によって拒否または処理される場合があるためです。たとえば、この状況が発生するのは、Cisco IOS H.323 ゲートウェイに、Cisco CallManager クラスタ内のサブスクライバ C にコールを送信するダイヤルピアが設定されているものの、そのゲートウェイの Cisco CallManager 冗長性グループのリストにはサブスクライバ A および B しか含まれていない場合です。そのような場合、コールは失敗するか、またはデーモンがサブスクライバ上に設定されていれば H.323 トランク デーモンによって処理されます。
次のシナリオは、H.225D がサブスクライバ上に作成される仕組みとその時期について説明しています。
H.225D は、H.323 クライアントに関連付けられた Cisco CallManager 冗長性グループで使用可能な、最もプライオリティの高いサブスクライバ上だけでアクティブになります。
H.323 クライアントがゲートキーパー制御の場合、RasAggregator デバイスは、ゲートキーパー制御の H.323 クライアントに関連付けられた Cisco CallManager 冗長性グループで使用可能な、最もプライオリティの高いサブスクライバから登録されます。
RasAggregator は、次の 2 つの特殊機能を提供するためにゲートキーパー ゾーンで登録される特殊なデバイスです。
–H.323 クライアントが DHCP を使用している場合、Cisco CallManager が DNS を使用しているときは、Cisco CallManager でそのクライアントを使用することはできません。これは、H.323 クライアントでは、ダイナミック DNS をサポートする H.323 クライアントが必要になるためです。RasAggregator を使用すると、Cisco CallManager は、コールを発信するたびに、ゲートキーパーに登録されている特定の H.323 クライアントの IP アドレスを取得できます。ゲートキーパー登録は、H.323 クライアントの E.164 アドレスを含む標準の RAS ARQ メッセージを使用して行われます。ゲートキーパーは、E.164 アドレスを解決し、IP アドレスを ACF メッセージで Cisco CallManager に返します。
–また、RasAggregator を使用すると、H.323 クライアントによるコールはすべて Cisco CallManager から発信されるようになり、クライアント自身の間では直接やり取りされないことが保証されます。これにより、ダイヤリング規則とコーデック制限が適用されることが保証されます。
H.225D は、H.323 ゲートウェイに関連付けられた Cisco CallManager 冗長性グループにあるすべてのサブスクライバ上でアクティブになります。
H.225D は、H.323 トランクに関連付けられた Cisco CallManager 冗長性グループにあるすべてのサブスクライバ上でアクティブになります。
RAS デーモンは、関連付けられている Cisco CallManager 冗長性グループにあるすべてのサブスクライバから、トランクをゲートキーパーに登録します。
Cisco CallManager クラスタ内のサブスクライバに H.323 コールが着信すると、コールを受け入れるかまたは拒否するか、受け入れる場合はどの H.225D がコールを受信するかなど、さまざまな決定が下されます。図5-6 は、このプロセスの仕組みを示しています。
図5-6 H.323 コールの受け入れまたは拒否を判別するプロセス
Cisco CallManager の H.323 プロトコルには、次の追加機能が含まれています。
この機能では、コールごとに、発信元デバイスが Cisco CallManager Release 3.2 以降を使用しているかどうかを判別できます。コールを受信するたびに、Cisco CallManager は H.225 User-to-User Information Element（UUIE）を検索します。この UUIE は、もう一方の側が別の Cisco CallManager であるかどうかを示します。UUIE が見つかった場合、Cisco CallManager は常に Intercluster Trunk Protocol を使用します。UUIE が見つからない場合は、設定済みのプロトコルをそのデバイスに対して使用します。この機能を使用すると、H.225 ゲートキーパー制御トランクは、コールごとに Intercluster Trunk Protocol と H.225 を切り替えることができます。これにより、Cisco CallManager クラスタと他の H.323 デバイスを組み合せてゲートキーパーを使用することができます。Intercluster Trunk Protocol は、H.225 と類似していますが、特定の機能を Cisco CallManager クラスタ間で正しく動作させる仕組みが異なります。
• Tunneled Q.SIG または H.323 Annex M1
Cisco CallManager 4.1(3) のリリースから、この機能はすべての H.323 トランク上で有効にできるようになりました。これにより、特定の H.323 Annex M1 機能を、Cisco CallManager クラスタと、同じく H.323 Annex M1 をサポートする他の確認済みシステムとの間に実装することができます。これらの機能には、次のものがあります。
この機能をサポートするゲートキーパー（Cisco MCM Gatekeeper など）に登録する場合、Cisco CallManager はゲートキーパーに対し、H.323 トランクへのコールの代替宛先を通知できます。この代替エンドポイントまたは代替宛先は、この H.323 トランクが呼び出されたときに、ゲートキーパーによって発信元デバイスに送信されます。代替エンドポイントは、ゲートキーパーに登録されている H.323 トランクに関連付けられた Cisco CallManager 冗長性グループのリストに含まれている他のサブスクライバです。
この機能をサポートするゲートキーパーに H.323トランクが登録される場合（たとえば、Cisco ゲートキーパー クラスタ）、Cisco CallManager には、このゲートキーパーが失敗した場合や独自のリソースを使い果たした場合に、登録、コール アドミッション要求、および他の RAS 機能を処理できる他のゲートキーパーに関する情報が動的に通知されます。
H.323 トランクは、ゲートキーパーに Admission Request（ARQ; 許可要求）を送信すると、Admission Confirmation message（ACF; アドミッション確認）で異なる E.164 番号を受信する場合があります。このことは、元の着信番号をこの新しい番号で置き換える必要があることを示しています。この機能では、Gatekeeper Transaction Message Protocol（GKTMP）を使用して Cisco ゲートキーパーと通信するルート サーバが必要になります。
（注） CanMapAlias は、着信番号に関してのみサポートされます。
H.323 トランクは、ゲートキーパーの帯域幅情報をアップデートし、特定のコールに割り当てられた帯域幅の要求量が変更されたことを示すことができます。この機能は、デフォルトでは無効になっています。この機能を制御するには、H.323 セクションにある Cisco CallManager サービス パラメータ BRQ Enabled を True に設定します。この機能は、H.323 トランク上でビデオを使用するときに特に重要です。これは、元の帯域幅要求が許容最大限の量を要求するためです。この機能を有効にすると、コール アドミッション制御が、コールのセットアップ中にネゴシエートされた実際の帯域幅を使用することが保証されます。
フィードバック