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

Cisco Unified CallManager トランク

---

Cisco Unified CallManager Release 4.0 では、Session Initiation Protocol（SIP）トランクがサポートされるようになりました。Release 4.0 より前の Cisco Unified CallManager は、H.323 トランクのみをサポートしていました。この章では、Cisco Unified CallManager Release 5.0 に関する設計の考慮事項について説明します。ただし、説明の多くは Cisco Unified CallManager Release 4.1、4.0、および 3.3 にも該当します。

現在、H.323 トランクは、他の Cisco Unified CallManager クラスタや、ゲートウェイなどの他の H.323 デバイスに対する接続性を提供します。H.323 トランクは、Cisco Unified CallManager がクラスタ内通信用にサポートするオーディオおよびビデオ コーデックのほとんどをサポートします。ただし、ワイドバンド オーディオ、ワイドバンド ビデオ、および H.264 ビデオについてはサポートしません。

H.323 トランクは、Empty Capabilities Set（ECS）を使用して、保留/保留解除や転送などの補足コール サービスを提供します。この方法は、メディア ストリーム（またはチャネル）を停止または終了し、同一または別のエンドポイント アドレスに対してメディア ストリームを開始または起動するための標準の H.245 メカニズムです。この方法を使用すると、Cisco Unified CallManager は、コールをアクティブにしたままでも、メディア ストリームの送信元および宛先を迅速に制御することができます。

たとえば、H.323 トランクを使用した 2 つのクラスタ（A と B）間のコールについて考えます。クラスタ A のユーザがクラスタ B のユーザを保留にした場合、2 人のユーザ間のメディア ストリームは終了し、クラスタ B のユーザはクラスタ A の Music On Hold（MoH）サーバに接続されます。MoH サーバは、ユーザにメディア（音楽ファイル）を送信するよう指示されます。クラスタ A のユーザがコールを保留解除すると、MoH ストリームが終了し、2 人のユーザ間で双方向メディア ストリームが再開されます（Cisco Unified CallManager は、補足コール サービス用に H.450 をサポートしていません）。このケースでは、MoH は ECS 動作の一例です。H.323 トランクはマルチキャスト MoH をサポートしないため、H.323 トランクの Media Resource Group List（MRGL; メディア リソース グループ リスト）には、ユニキャスト MoH リソースだけを含める必要があります（詳細については、「Music on Hold」を参照してください）。

H.323 トランク上のコールに使用される帯域幅を制御するには、Cisco Unified CallManager で設定され、各トランクに割り当てられる、 リージョン を使用します。リージョンは、そのリージョンの音声コーデック タイプとビデオ帯域幅を指定することで、コールに割り当てられる帯域幅の量を制限します。そのリージョンと別のリージョン間のコールは、指定された帯域幅の制限を超えることはできません。H.323 トランク上でコールを発信するデバイスが、より限定的なリージョン内にある場合や、ビデオなどの特定のコーデックをサポートしない場合、そのデバイスはそのコールに使用可能なコーデックのサブセットになっています。

H.323 トランク上のすべての DTMF（Dual Tone MultiFrequency）シグナリングは、H.245 を使用してアウトバンドで提供されます。

SIP トランクは、ゲートウェイ、プロキシ、ボイスメール システム、および他の Cisco Unified CallManager クラスタなど、他の SIP デバイスへの接続性を提供します。Cisco Unified CallManager 5.0 では、SIP トランクの主な拡張機能が導入され、Cisco Unified CallManager 4.1 および 4.0 での制限（たとえば、単一コーデックのサポート、ビデオ サポートの欠如、RFC 2833 DTMF サポートに必須のメディア ターミネーション ポイント（MTP）など）が解消されました。

Cisco Unified CallManager 5.0 でのそれ以外の SIP トランクに対する主な拡張機能としては、REFER、ヘッダー置換、Subscribe/Notify、Message Waiting Indication（MWI; メッセージ待機インジケータ）、MTP の削除、ビデオ サポート、着信ポート番号 1 つあたり複数の SIP トランク、SIP リダイレクション 3XX、Transport Layer Security（TLS; トランスポート レイヤ セキュリティ）、ダイジェスト認証、コール保持、および T.38 FAX リレーのサポートがあります。SIP トランクの新規拡張機能の全リストについては、次の Web サイトで入手可能な Cisco Unified CallManager 5.0 の製品マニュアルを参照してください。

http://www.cisco.com

クラスタ間トランキングに使用した場合、SIP トランクは Secure Real-Time Transport Protocol（SRTP）や、Annex M1 を使用した QSIG Tunneling をサポートしません。

H.323 トランク

Cisco Unified CallManager では、次の主要なタイプの H.323 トランクを設定できます。

• 「クラスタ間トランク（非ゲートキーパー制御）」

• 「クラスタ間トランク（ゲートキーパー制御）」

• 「H.225 トランク（ゲートキーパー制御）」

ゲートキーパー トランクの冗長性、復元性、およびロード バランシング

冗長性は、設計の要件に応じて、複数の方法で実現できます。最も簡単に実現するには、ゲートキーパー制御トランクを設定し、そのトランクに割り当てられたデバイス プールに関連付けられている Cisco Unified CallManager グループに、最大 3 つのサブスクライバを割り当てます。この設定により、すべてのサーバが、同じテクノロジー プレフィックスと共に、同じゾーン内の同じゲートキーパーに登録されます。ただし、h323_id に使用される H.323 トランクの名前には、「_ n 」というサフィックスが付加されます。ここで、 n はクラスタ内のノード番号です。この ID は自動的に生成され、変更することはできません。単一のトランクを設定しても、ゲートキーパーは、複数のトランク、つまり Cisco Unified CallManager グループ内のサブスクライバごとに 1 つのトランクを登録します。

追加の冗長性要件がある場合は、別のゲートキーパー制御トランクに、Cisco Unified CallManager グループにある別の名前と別のサブスクライバを設定できますが、それ以外のパラメータはすべて最初のトランクと同じになります。この 2 つ目のトランクによって、追加のサブスクライバがゲートキーパーに登録されます。

標準のサブスクライバ ペアを構成する 2 つのサーバから Cisco Unified CallManager グループを構成し、このグループを含むデバイス プールを割り当てることをお勧めします（サブスクライバの冗長性の詳細については、「コール処理サブスクライバ」を参照してください）。クラスタ全体で完全な冗長性を実現するには、4 つの異なるデバイス プールを使用する 4 つのトランクが必要になります。結果的に、8 つのサブスクライバがゲートキーパーに登録されます（3 つのトランクとより大きな Cisco Unified CallManager グループを使用しても同じ結果となります）。

登録時、Cisco Unified CallManager とゲートキーパー間では複数のパラメータが受け渡しされます。Cisco Unified CallManager は、トランクごとに、ゲートキーパーの Registration Admission Status（RAS）メッセージ用に、一時的なユーザ データグラム プロトコル（UDP）ポートを使用します。このポートは、通常であれば、UDP 1719 です。ただし、Cisco Unified CallManager は、特定の RAS メッセージの宛先であるトランクを判別できる必要があります。したがって、Cisco Unified CallManager は一定範囲の UDP ポートを使用して、動的に割り当てます。

登録プロセス時、トランクは、その Cisco Unified CallManager グループにある他のサブスクライバに関する次の情報を登録します。

• H.225 コール シグナリング ポート

• h323_id

• CanMapAlias サポート

• テクノロジー プレフィックス

• H.225 コール シグナリング アドレス

推奨されるクラスタ化ゲートキーパーが使用されている場合、ゲートキーパーは、代替ゲートキーパー アドレスのリストを返します。このリストは、プライマリ ゲートキーパーで障害が発生した場合や使用可能なリソースが不足した場合に使用されることがあります。

図5-1 は、Gatekeeper Update Protocol（GUP）を使用して通信する、ゲートキーパーのクラスタを示しています（ゲートキーパーの詳細については、「コール処理」の章を参照してください）。

図5-1 ゲートキーパー クラスタ

 

H.323 トランクの Cisco Unified CallManager グループにサブスクライバが 1 つだけ含まれている場合、Cisco Unified CallManager の設定済みゲートキーパーとゲートキーパー クラスタの間の接続は 1 つのみになります（図5-2 を参照）。

図5-2 単一の Cisco Unified CallManager サブスクライバを使用する H.323 トランク

 

トランクに関連付けられた Cisco Unified CallManager グループに複数のサブスクライバが含まれている場合、Cisco Unified CallManager クラスタとゲートキーパー クラスタ間には追加の接続が確立されます（図5-3 を参照）。

図5-3 複数の Cisco Unified CallManager サブスクライバを使用する H.323 トランク

 

このアプローチによってサブスクライバ障害やゲートキーパー障害に対する冗長性が確保されるのは、登録完了後です。これは、トランクの登録時に代替ゲートキーパーの通信が行われるためです。ただし、このアプローチでは、設定済みのゲートキーパーが初期登録時やリセット後に使用不能である場合には、冗長性が確保されません。これは、代替ゲートキーパーのリストがダイナミックであり、データベースに格納されないためです。冗長性のレベルを上げたりロード バランシングを追加したりするには、ゲートキーパー クラスタにある追加のゲートキーパーを Cisco Unified CallManager で設定します。たとえば、元のトランクが要素 2 に登録されている場合は、追加のゲートキーパーを要素 4 として設定できます（図5-4 を参照）。

図5-4 ロード バランシングと追加の冗長性のために設定された追加のゲートキーパー

 

図5-4 の例の場合、Cisco Unified CallManager の設定には次のコンポーネントが含まれます。

• 要素 2 と要素 4 の 2 つのゲートキーパー

• サブスクライバ サーバ A および B を含む Cisco Unified CallManager グループに対して定義された 2 つの H.323 トランク

このアプローチを使用すると、初期設定時に要素 2 または要素 4 が到達不能であっても（つまり、起動中またはトランクのリセット中でも）、引き続き Cisco Unified CallManager クラスタが登録できるようになります。

Cisco Unified CallManager クラスタに着信するコールのロード バランシングは、デフォルトで自動的に行われます。これは、ゲートキーパーが、ゾーン内の登録済みサブスクライバのいずれかをランダムに選択するためです。この動作が期待と異なる場合は、ゲートキーパーで gw-priority 設定コマンドを使用して、このデフォルト動作を変更することができます（例5-1 を参照）。

例5-1 gw-priority コマンドを使用してコールを特定のトランクに送信する

gatekeeper

zone local SJC cisco.com 10.0.1.10

zone prefix SJC 1408....... gw-priority 10 sjc-trunk_2

zone prefix SJC 1408....... gw-priority 9 sjc-trunk_3

zone prefix SJC 1408....... gw-default-priority 0

gw-type-prefix 1#* default-technology

arq reject-unknown-prefix

no shutdown

endpoint ttl 60

 

例5-1 では、H.323 トランクは Cisco Unified CallManager で sjc-trunk として設定されています。また、Cisco Unified CallManager サブスクライバが、クラスタ内のサブスクライバのノード番号を示すために、「_2」と「_3」のサフィックスを自動的に付加します。したがって、この例では、最初の選択肢としてノード 2 を使用します。このノードは、このトランクの CallManager グループにおいて最もプライオリティの高い Cisco Unified CallManager となる必要があります。このケースでは、ノード 3 は 2 番目の選択肢となります。

gw-default-priority 0 を使用するかどうかは任意です。この例で使用したのは、このゾーンで登録するよう不用意に設定される可能性のある他のトランクが一切使用されないようにするためです。

Cisco Unified CallManager クラスタからの発信コールは、次のいずれかの方法でロードバランスできます。

• ルート グループにある単一の H.323 トランクは、常に、Cisco Unified CallManager グループで使用可能な最もプライオリティの高いサブスクライバを使用します。プライオリティの低いサブスクライバが使用されるのは、プライオリティの高いサブスクライバが使用不能になった場合のみです。

• 循環ルート グループにある複数の H.323 トランクは、グループ内のすべての H.323 トランクに均等にコール負荷を分散します。

次の例は、さまざまなシナリオでロード バランシングを設定する方法を示しています。

すべてのコールをクラスタ内の単一のサブスクライバから発信する場合：

• ルート グループ内に単一の H.323 トランクを設定します。

コールをクラスタ内の 4 つのプライマリ サブスクライバに分散する場合：

• 4 つの Cisco Unified CallManager グループに対して 4 つの H.323 トランクを定義し、すべてのトランクを循環ルート グループに含めます。

• Cisco Unified CallManager 冗長性グループは、次のように定義されます。

–サブスクライバ A、サブスクライバ B

–サブスクライバ C、サブスクライバ D

–サブスクライバ E、サブスクライバ F

–サブスクライバ G、サブスクライバ H

サブスクライバ A、C、E、および G はすべてプライマリで、サブスクライバ B、D、F、および H はバックアップです。

コールをクラスタ内の 8 つのサブスクライバに分散する場合：

• 8 つの異なる Cisco Unified CallManager グループに対して 8 つの H.323 トランクを定義し、各グループにサブスクライバを 1 つだけ含め、すべてのトランクを循環ルート グループに含めます。

• Cisco Unified CallManager 冗長性グループは、次のように定義されます。

–サブスクライバ A

–サブスクライバ B

–サブスクライバ C

–サブスクライバ D

–サブスクライバ E

–サブスクライバ F

–サブスクライバ G

–サブスクライバ H

メディア ターミネーション ポイントを使用する H.323 トランク

メディア ターミネーション ポイント（MTP）は、一般に、H.323 トランクの通常動作には必要ありません。ただし、通信相手となるデバイスが、H.323 Version 1 である場合や、補足サービス用に Empty Capabilities Set（ECS）をサポートしていない場合には必要です。

MTP が必要かどうかをテストするには、次の簡単な手順を使用します。

1. 電話機から H.323 トランクを介して他のデバイスにコールを発信します。このコールは通常どおりに発信する必要があります。

2. コールを保留にしてから、保留解除します。コールがドロップする場合は、Cisco Unified CallManager と他のデバイス間の相互運用性を保証するために MTP を使用することをお勧めします。

MTP は、H.323 トランク上でコールを発信する他のデバイスからのメディア ストリームを終端させる場合や、同じ音声ペイロードでメディア ストリームを再発信する場合に非常に役立ちます。ただし、そのような場合、IP アドレスは MTP のアドレスに変更されます。この事実に留意して、次のシナリオで MTP を使用します。

• 企業内の電話機、ゲートウェイ、および他のデバイスがすべて RFC 1918 プライベート アドレスを使用する場合は、すべての音声およびビデオ デバイスにネットワーク アドレス変換（NAT）を使用しなくても、引き続きパブリック ネットワーク上の他のシステムに接続できます。パブリック ネットワークと通信する Cisco Unified 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 に設定します。

Cisco Unified CallManager における H.323 の動作

この項では、H.323 プロトコルを Cisco Unified CallManager で使用および実装する方法、および特定の機能が所定どおりに動作する仕組みとその理由について説明します。

理解する上で最も重要な点は、どのサブスクライバがコール シグナリング デーモンを実行するかということです。このデーモンは、H.323 コールを発信および受信する部分的なコードです。これは、通常、H.225 デーモン（H.225D）と呼ばれます。H.225 は、H.323 プロトコルの一部で、主にコール制御を担当します。H.245 は、H.323 のもう 1 つの主要コンポーネントで、コールのメディア制御を担当します。

特定の H.323 デバイスに対する Cisco Unified CallManager グループのリストに含まれているサブスクライバによって、デーモンを実行するサブスクライバと実行時期が決定されます。この点は非常に重要です。これは、不適切なサブスクライバに送信されたコールは、別の H.225D によって拒否または処理される場合があるためです。たとえば、この状況が発生するのは、Cisco IOS H.323 ゲートウェイに、Cisco Unified CallManager クラスタ内のサブスクライバ C にコールを送信するダイヤルピアが設定されているものの、そのゲートウェイの Cisco Unified CallManager グループのリストにはサブスクライバ A および B しか含まれていない場合です。そのような場合、コールは失敗するか、またはデーモンがサブスクライバ上に設定されていれば H.323 トランク デーモンによって処理されます。

次のシナリオは、H.225D がサブスクライバ上に作成される仕組みとその時期について説明しています。

• H.323 クライアント

H.225D は、H.323 クライアントに関連付けられた Cisco Unified CallManager グループで使用可能な、最もプライオリティの高いサブスクライバ上だけでアクティブになります。

H.323 クライアントがゲートキーパー制御の場合、RasAggregator デバイスは、ゲートキーパー制御の H.323 クライアントに関連付けられた Cisco Unified CallManager グループで使用可能な、最もプライオリティの高いサブスクライバから登録されます。

RasAggregator は、次の 2 つの特殊機能を提供するためにゲートキーパー ゾーンで登録される特殊なデバイスです。

–H.323 クライアントが DHCP を使用している場合は、DNS を使用している Cisco Unified CallManager でそのクライアントを使用できません。ただし、クライアントが Dynamic DNS をサポートしている場合は除きます。RasAggregator を使用すると、Cisco Unified CallManager は、コールを発信するたびに、ゲートキーパーに登録されている特定の H.323 クライアントの IP アドレスを取得できます。ゲートキーパー登録は、H.323 クライアントの E.164 アドレスを含む標準の RAS ARQ メッセージを使用して行われます。ゲートキーパーは、E.164 アドレスを解決し、IP アドレスを ACF メッセージで Cisco Unified CallManager に返します。

–また、RasAggregator を使用すると、H.323 クライアントによるコールはすべて Cisco Unified CallManager を経由するようになり、クライアント自身の間では直接やり取りされないことが保証されます。これにより、ダイヤリング規則とコーデック制限が適用されることが保証されます。

• H.323 ゲートウェイ

H.225D は、H.323 ゲートウェイに関連付けられた Cisco Unified CallManager グループにあるすべてのサブスクライバ上でアクティブになります。

• H.323 トランク

H.225D は、H.323 トランクに関連付けられた Cisco Unified CallManager グループにあるすべてのサブスクライバ上でアクティブになります。

RAS デーモンは、関連付けられている Cisco Unified CallManager グループにあるすべてのサブスクライバから、トランクをゲートキーパーに登録します。

Cisco Unified CallManager クラスタ内のサブスクライバに H.323 コールが着信すると、コールを受け入れるかまたは拒否するか、受け入れる場合はどの H.225D がコールを受信するかなど、さまざまな決定が下されます。図5-5 は、このプロセスの仕組みを示しています。

図5-5 H.323 コールの受け入れまたは拒否を判別するプロセス

Cisco Unified CallManager の H.323 プロトコルには、次の追加機能が含まれています。

• Protocol Auto Detect

この機能では、コールごとに、発信側デバイスが Cisco Unified CallManager Release 3.2 以降を使用しているかどうかを判別できます。コールを受信するたびに、Cisco Unified CallManager は H.225 User-to-User Information Element（UUIE）を検索します。この UUIE は、もう一方の側が別の Cisco Unified CallManager であるかどうかを示します。UUIE が見つかった場合、Cisco CallManager は常に Intercluster Trunk Protocol を使用します。UUIE が見つからない場合は、設定済みのプロトコルをそのデバイスに対して使用します。この機能を使用すると、H.225 ゲートキーパー制御トランクは、コールごとに Intercluster Trunk Protocol と H.225 を切り替えることができます。これにより、Cisco Unified CallManager クラスタと他の H.323 デバイスを組み合せてゲートキーパーを使用することができます。Intercluster Trunk Protocol は、H.225 と類似していますが、特定の機能を Cisco Unified CallManager クラスタ間で正しく動作させる仕組みが異なります。

• Tunneled Q.SIG または H.323 Annex M1

Cisco Unified CallManager 4.1(3) のリリースから、この機能はすべての H.323 トランク上で有効にできるようになりました。これにより、特定の H.323 Annex M1 機能を、Cisco Unified CallManager クラスタと、同じく H.323 Annex M1 をサポートする他の確認済みシステムとの間に実装することができます。これらの機能には、次のものがあります。

–パス交換

–メッセージ待機インジケータ（MWI）

–コールバック

• 代替エンドポイント

この機能をサポートするゲートキーパー、たとえば Cisco Multimedia Conference Manager（MCM）Gatekeeper などに登録する場合、Cisco Unified CallManager はゲートキーパーに対し、H.323 トランクへのコールの代替宛先を通知できます。この代替エンドポイントまたは代替宛先は、この H.323 トランクが呼び出されたときに、ゲートキーパーによって発信側デバイスに送信されます。代替エンドポイントは、ゲートキーパーに登録されている H.323 トランクに関連付けられた Cisco Unified CallManager グループのリストに含まれている他のサブスクライバです。

• 代替ゲートキーパー

この機能をサポートするゲートキーパーに H.323 トランクが登録される場合（たとえば、Cisco ゲートキーパー クラスタ）、Cisco Unified CallManager には、このゲートキーパーが失敗した場合や独自のリソースを使い果たした場合に、登録、コール アドミッション要求、および他の RAS 機能を処理できる他のゲートキーパーに関する情報が動的に通知されます。

• CanMapAlias

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 トランク上でビデオを使用するときに特に重要です。これは、元の帯域幅要求が許容最大限の量を要求するためです。この機能を有効にすると、コール アドミッション制御が、コールのセットアップ中にネゴシエートされた実際の帯域幅を使用することが保証されます。

SIP トランク

Cisco Unified CallManager 4. x では、DTMF サポートのためにすべての SIP トランクが MTP を割り当てる必要があります。Cisco Unified CallManager 5.0 では、MTP チェックボックスが不要になり、MTP Required フラグはデフォルトでオフになります。この制限が解消されたことで、全体的なパフォーマンスが向上し、開放された MTP リソースを他のアプリケーションで使用できるようになりました。エンドポイントが RFC 2833 またはアウトオブバンド DTMF 方式の使用をエンドツーエンドでネゴシエートできる場合、DTMF イベントに MTP が割り当てられることがなくなりました。エンドポイント間で共通の DTMF 方式をネゴシエートできない場合、Cisco Unified CallManager 5.0 は動的に MTP を挿入します。

すべての SIP トランク コールに MTP が割り当てられないようにするために、Cisco Unified CallManager 5.0 には遅延メディアのサポート（SDP なしの INVITE）が含まれています。SIP アプリケーションの中には、遅延メディアをサポートしていないものがあります。そのような場合は、SIP Trunk 設定ページで MTP を事前に割り当てておくことにより、SIP トランクを初期メディアとして設定する必要があります。MTP の詳細については、「メディア リソース」の章を参照してください。

SIP トランクを使用したクラスタ間トランク

クラスタ間トランキングに SIP トランクを使用する主な利点の 1 つは、コール存続可能性です。ただし、H.323 トランクと比較した場合、SIP トランクは Secure Real-Time Transport Protocol（SRTP）や、Annex M1 を使用した QSIG Tunneling をサポートしません。

Cisco Unified CallManager Release 3.3 以降の H.323 トランクとは異なり、SIP トランクは単一の IP アドレスまたは DNS Server（SRV）レコードだけを指すことができます。DNS SRV 機能のないクラスタ間 SIP トランクにフェールオーバーおよびロード バランシングを提供するためには、複数の SIP トランクを設定します。さらに、その SIP トランクは、ルート グループおよびルート リストのメンバーになる必要があります。また、重要な点として、Cisco Unified CallManager が受け入れるコールが、設定済み SIP トランクのいずれかの宛先アドレスと IP アドレスが一致する SIP デバイスからのコールだけであることにも注意してください。さらに、SIP メッセージの着信ポート番号は、その SIP トランク用に設定されたポート番号と一致している必要があります。その結果、コールが着信する可能性のある、あらゆる遠端 SIP デバイスのすべての IP アドレスと一致するように、できるだけ多くの SIP トランクに宛先アドレスを設定するようにしてください。この方式は、複数の Cisco Unified CallManager クラスタがある場合には適さないため、その場合は DNS SRV で SIP トランクを使用することをお勧めします。図5-6 は、DNS SRV を使用したクラスタ間 SIP トランク コールのコール フローを示しています。

図5-6 DNS SRV を使用したクラスタ間 SIP トランクのコール フロー

図5-6 は、このコール フローにおける次の手順を示しています。

1. Cluster1 内の IP Phone が 87522001 にコールします。

2. コールはルート パターン 8752XXXX と一致し、このパターンは cluster2.foo.com の DNS SRV を使用した SIP トランクを指しています。Cluster1 の CCM3 は、このコールを処理するノードです。その SIP トランクはこのノードに登録されているためです。CCM3 は、cluster2.foo.com の DNS SRV ルックアップを送信します。

3. DNS サーバは、CCM-A.cluster2.foo.com と CCM-B.cluster2.foo.com の 2 つのレコードで応答します。CCM-A.cluster2.foo.com の方がプライオリティが高いので、コールはその Cisco Unified CallManager に対して試みられます。SIP Invite が送信される前に、CCM-A.cluster2.foo.com に関して別の DNS ルックアップが行われます。

4. CCM3 は、SIP Invite を 87522001@cluster2.foo.com に送信します。宛先アドレスは CCM-A の IP アドレスに設定されます。

5. Cisco Unified CallManager は、このコールをローカル コールとして解釈します。Uniform Resource Identifier（URI; ユニフォーム リソース識別子）のホスト部分が Cluster FQDN エンタープライズ パラメータと一致しているためです。Cluster2 には、CCM3 の宛先が設定された SIP トランクがありません。したがって、DNS SRV を使用して SIP トランクに設定されたすべてのドメインに対して、DNS SRV ルックアップを行います。その場合、例では cluster1.foo.com の DNS SRV の宛先を持つ単一のトランクが示されています。

6. DNS サーバは 2 つのエントリを返し、そのうちの 1 つが Invite の発信元 IP アドレスと一致します。クラスタはコールを受け入れ、内線 87522001 にコールをルーティングします。