Cisco Unified Customer Voice Portal（CVP）ソリューション リファレンス ネットワーク デザイン（SRND）Release 8.0(x)

拠点における入力/出力ゲートウェイ

この展開モデルでは、通常、拠点オフィスに展開した入力ゲートウェイを使用して、発信者にアクセスを提供します。アクセスには、中央番号や非地理的番号ではなく、市内電話番号を使用します。この機能は、複数の国にまたがる国際展開で特に重要になります。出力ゲートウェイは、集中型 PSTN ブレークアウト用、または分散型 TDM プラットフォームの Unified CVP スイッチング ソリューションへの統合用として、拠点に展開されます。ゲートウェイを除く他の Unified CVP コンポーネントはすべて中央に展開され、WAN リンクによって各拠点から中央データセンターまでのデータ接続が実現されます。

拠点における入力または VoiceXML ゲートウェイ

拠点で実行される他の音声サービスについて考慮する必要があります。たとえば、拠点として通常使用されるのは、ACD エージェント電話と非エージェント電話の両方をサポートするリモート Cisco Unified Communications Manager（Unified CM）サイトです。また、このモデルでは、必然的に、PSTN ゲートウェイが Unified CVP コールの入力用としてだけでなく、そのサイトの標準ユーザ コールの入力/出力用としても使用されます。VoiceXML ゲートウェイ機能と音声ゲートウェイ機能が同じ拠点の異なるデバイスに存在する環境では、VRU レッグがローカルの VoiceXML リソースに送信されるように、ダイヤル プランに特別な注意を払う必要があります。Unified CVP コール サーバの settransferlabel メカニズムは、共存する VoiceXML ゲートウェイ コンフィギュレーションと音声ゲートウェイ コンフィギュレーションにのみ適用されるためです。

拠点の入力ゲートウェイと VoiceXML ゲートウェイが同じゲートウェイに存在しない場合は、コールが拠点内で処理され、WAN を介して別の VoiceXML ゲートウェイに送信されないようにします。それには、次の 2 つの方法があります。

• Unified ICM に複数のユーザ（1 つの拠点当たり 1 人）を設定します。

このオプションでは、Unified ICM コンフィギュレーションを利用して、コールを着信番号に基づいて識別します。着信番号は、拠点サイトを表すユーザに関連付けられます。ネットワーク VRU が必要な場合は、Unified ICM のユーザに関連付けられているネットワーク VRU が選択され、発信者がそのネットワーク VRU に送信されます。これにより、それぞれに一意のラベルを付けた複数のネットワーク VRU を使用できます。この方法の欠点は、各ネットワーク VRU が Unified ICM でそれぞれ独自の VRU スクリプトを必要とすることです。多数のリモート サイトが必要な場合は、Unified ICM コンフィギュレーションで各ネットワーク VRU スクリプトをすばやく変更する必要があり、そのオーバーヘッドが非常に高くなります。

• Unified CVP で SigDigits 機能を使用するように設定します。

Unified CVP の SigDigits 機能を使用すると、SIP プロキシまたはゲートキーパーでダイヤル プランを使用して、コールを適切なサイトにルーティングできます。コールが入力ゲートウェイに到達すると、ゲートウェイはコールを Unified CVP に送信する前にディジットを付加します。ダイヤル プランの観点では、付加されるディジットはそのサイトに固有のものです。

コールが Unified CVP に到達すると、Unified CVP は付加されたディジットを削除してからメモリに格納します。結果として、元の DID でコールが到達したことになります。その後、Unified CVP は、元の DID（Unified ICM の着信番号と一致）を使用して、コールの到達について Unified ICM に通知します。

Unified ICM が Unified CVP にラベルを返して、IVR 処理用に VoiceXML ゲートウェイにコールを転送したり、エージェントの電話にコールを転送したりすることが可能になると、Unified CVP はメモリ内に格納されたディジットを付加してから転送を開始します。SIP プロキシまたはゲートキーパーのダイヤル プランにディジットの付加を設定する際には、特定のディジット文字列が付加されたコールが特定の VoiceXML ゲートウェイまたは出力ゲートウェイに送信されるようにする必要があります。H.323 を使用している場合、付加されるディジットは tech プレフィクスとして付加されます。

重要な点として、VXML ゲートウェイがコールを受信すると、ディジットを再び削除するように CVP ブートストラップ サービスが設定され、コールの IVR レッグのセットアップ時に着信 VXML 要求で元の DN が使用されるようになることに留意してください。また、ディジットはトランスレーション ルート DN の先頭にも付加されることがある点、および出力または受信側コンポーネント（Cisco Unified CM など）で元の DN を確認するにはディジットの削除が必要になる場合がある点についても留意してください。

SigDigits という用語は、この機能を表すために使用されます。Unified CVP で機能を有効にして、削除する有効ディジット数を指定するためのコマンドは、H.323 では setsigdigits X であり、SIP の Operations Console では Prepend Digits であるためです。

Unified ICM コンフィギュレーションのオーバーヘッドが最小限に抑えられるため、この方法が推奨されます。必要になるのは、単一のネットワーク VRU と単一セットの VRU スクリプト/Unified ICM ルーティング スクリプトだけです。そのため、Unified ICM の観点では、すべての Unified CVP Server および VoiceXML ゲートウェイが単一のネットワークワイドの仮想 IVR として機能します。

また、SigDigits 機能を使用すると、マルチクラスタのコール アドミッション制御の問題を解決することもできます（詳細については、「コール アドミッション制御の考慮事項」を参照してください）。

Unified CVP VXML Server とゲートウェイを共存させる場合

すべてのゲートウェイとサーバを中央に展開するか、各サイトでそれぞれ独自のセットの Unified CVP VXML Server とゲートウェイを共存させます。

共存させる場合の利点：

• WAN が停止しても、セルフサービス アプリケーションには影響しません。

• WAN 帯域幅が不要です。

共存させる場合の欠点：

• 拠点オフィスをレプリケートして使用する場合、追加の Unified CVP VXML Server が必要になります。

• アプリケーションを複数の Unified CVP VXML Server に展開する場合、オーバーヘッドが増加します。

集中型 Unified CVP VXML Server を使用して拠点にゲートウェイを展開する場合

集中型 VoiceXML の利点：

• 管理とレポート生成が一元化されます。

• Unified CVP VXML Server の機能を拠点オフィス間で共有できます。

集中型 VoiceXML の欠点：

• 拠点の存続可能性が制限されます。

• VoiceXML over HTTP トラフィックを増やすには、WAN 帯域幅のサイズを調整する必要があります。

Cisco Unified Communications Manager

Unified CVP 環境では、Cisco Unified Communications Manager（Unified CM）は入力ゲートウェイとして使用することも、出力ゲートウェイとして使用することもできます。一般的には、Unified CM は出力ゲートウェイとして使用されます。通常、発信者は PSTN からコールを行い、Unified CVP によってキューイングされた後、エージェントでの処理のために Unified CM にスイッチングされるためです。発信者が PSTN からではなく、IP 電話からコールを行う場合、Unified CVP の観点では Unified CM は入力ゲートウェイになります。

出力ゲートウェイとしての Unified CM

通常、Unified CVP は、ダイヤル プランの解決とコール アドミッション制御を行うのにゲートキーパーに依存します。Unified CVP とともに Unified CM を展開するには、入力 Unified CVP ゲートウェイとエージェント IP 電話間のコールに Unified CM コール アドミッション制御を使用する必要があります。Unified CVP コール サーバは実際には Unified CM に対して H.323 コールを行うコンポーネントであるため、Unified CM で入力 Unified CVP ゲートウェイを正しく識別するのは困難です。そのため、Unified CM は、コールの発信元をリモートの入力ゲートウェイではなく集中型 Unified CVP コール サーバであると見なします。

H.323 セットアップ内の sourcesignaladdress フィールドを入力ゲートウェイの IP アドレスに設定すると、Unified CVP コール サーバでこの問題を解決できます。Unified CVP からセットアップを受信すると、Unified CM はソース シグナリング アドレスを確認し、コールの発信元を特定するときにこのアドレスを使用する必要があることを認識します。Unified CM にはこの入力ゲートウェイ IP が設定されているため、Unified CM は Unified CM ロケーションのコール アドミッション制御のコンフィギュレーションを使用して、入力ゲートウェイと宛先 IP 電話のロケーション間で帯域幅を差し引きします。Unified CVP コール サーバを Unified CM のゲートウェイとして設定しないでください。代わりに、Unified CVP コール サーバには、ゲートキーパー制御の H.323 トランクを介してコールを Unified CM に送信させる必要があります（コール アドミッション制御メカニズムの詳細については、「コール アドミッション制御の考慮事項」を参照してください）。

入力ゲートウェイとしての Unified CM

IP 電話が Unified CVP へのコールを開始すると、Unified CM は Unified CVP への入力ゲートウェイとして機能します。コールは、H.323 または SIP トランクを使用して Unified CVP に送信されます。これらのタイプのコール フローの詳細については、「Cisco Unified Communications Manager により発生したコール」の章を参照してください。

マルチキャスト Music-on-Hold（MOH）

ユニキャスト MOH の代わりとして、Unified CM の補足サービスを利用してマルチキャスト Music-on-Hold を実現できます。次の 2 つの方法でこの機能の使用を展開できます。

• Unified CM を使用して、ローカル LAN でのパケットのマルチキャストを行います。

• 拠点ゲートウェイを使用して、ローカル LAN でのマルチキャストを行います。

ゲートウェイに Survivable Remote Site Telephony（SRST）が設定されている場合は、後者の方法を使用します。この方法を使用すると、展開で MOH をローカルに使用でき、WAN リンク上での MOH ストリーミングを避けることができます。

（注） マルチキャスト MOH の使用に関する参照資料
Call Manager Enterprise（CME）で MOH を設定する方法については、次の URL を参照してください。
http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmemoh.html#wpmkr1022205

設計上の考慮事項

マルチキャスト MOH を使用する場合は、次の点を考慮してください。

• modem passthrough nse codec g711ulaw をグローバルに設定したり、入力/出力ゲートウェイのダイヤル ピアに設定したりすることは避けてください。このように設定すると、10 ～ 12 秒のタイムアウト期間後、Unified CM によって MOH が停止される可能性があります。

• 入力ゲートウェイにメディア非アクティビティを設定しないでください。マルチキャスト MOH では RTP も RTCP も送信しないため、メディア非アクティビティのコンフィギュレーションが原因でコールが切断される可能性があります。media-inactivity-criteria all 設定では、マルチキャスト トラフィックはサポートされていません。

• 5400 プラットフォームでは ccm-manager ベースの MOH サブシステムはサポートされていないため、5400 プラットフォームでは SIP ベースのマルチキャスト MOH はサポートされていません。この制限には、Unified CM MOH サーバからブロードキャストされるマルチキャスト パケットを TDM 発信者が認識する機能も含まれます。

ゲートキーパー コール アドミッション制御

Unified CVP が入力ゲートウェイから、TDM ACD/IVR に接続された出力ゲートウェイにコールをスイッチングする純粋な TDM 環境では、ゲートキーパーがコール アドミッション制御機能を処理できます。

Unified CM が出力ゲートウェイである場合、ゲートキーパー コール アドミッション制御は、入力 Unified CVP ゲートウェイと IP 電話がそれぞれ異なるサイトにある場合にのみ使用できます。ただし、ゲートキーパー ダイヤル プラン解決は引き続き使用されることに留意してください。

Unified CM ロケーションベースのコール アドミッション制御はクラスタのリモート サイト間で使用されるため、通常、ゲートキーパーはダイヤル プラン解決にのみ使用されます。実装で複数セットのゲートキーパーを使用する必要がある状況でコールのルーティングが行われる可能性もあるため、ダイヤル プランおよびゲートキーパー解決でのコールのルーティングについて理解することが重要です。特に重要となるのは、複数の Unified CM クラスタでリモート サイトを制御している状況でこのモデルを使用する場合です。このトピックの詳細については、「H.323 ゲートキーパー コール ルーティング」を参照してください。

Unified CM コール アドミッション制御

Unified CM が Unified CVP との間でコールを送受信していて、Unified CVP ゲートウェイと IP 電話エージェントがリモート サイトに共存している場合、コール フローを理解して、コール アドミッション制御を正しく設計および制御できるようにすることが重要です。

H.323 コール フロー

ゲートキーパーと Unified CM では、帯域幅の使用情報は共有されません。ネットワークがゲートキーパーと IP 電話の両方で共有されている場合、2 つの異なるコール アドミッション制御メカニズムを使用して、コールを行うのに十分な帯域幅があるかが判断されます。コール アドミッション制御にゲートキーパーを使用する代わりに、Unified CM ロケーションを Unified CVP コールのコール アドミッション制御メカニズムとして使用することが可能です。Unified CM でエンドポイントのロケーションを判断する方法は、コール アドミッション制御を適切に設計するうえで重要です。

Unified CVP コールと非 CVP コールの基本コール フローを考慮してください。ユーザが IP 電話を選択し、リモート サイトから中央サイトへのコールを行う場合、Unified CM はエンドポイントのロケーション定義と Unified CM リージョンのコンフィギュレーションで定義されているコーデック要件を考慮し、コールを許可するかどうかを決定します。Unified CM が制御コール エージェントとなって、これらのエンドポイント間のコール アドミッション制御とコーデック要件を制御することに留意してください。

デフォルトでは、Unified CM は着信 H.323 コールのソース IP アドレスを確認して、コールの発信元 H.323 デバイスを判断します。その後、Unified CM は、このデバイスのコンフィギュレーションを使用して、そのロケーションを判断し、コールのコール アドミッション制御を行います。Unified CVP がリモートの拠点ゲートウェイから Unified CM IP 電話にコールを配信する場合、Unified CVP は H.323 シグナリングの途中に展開されるため、Unified CM の観点ではソース IP アドレスは Unified CVP Server になります。Unified CVP Server は Unified CM とともに中央に展開されるため、Unified CVP Server の IP アドレスに基づいてコール アドミッション制御を行うことはできません。Unified CM では、Unified CVP から到達したコールの実際の発信元が特定の拠点のゲートウェイであることを認識して、コール アドミッション制御を正しく計算できる必要があります。この問題を解決するためには、発信元ゲートウェイの IP アドレスを識別する情報を H.323 SETUP メッセージのペイロードに挿入するように Unified CVP を設定する必要があります。また、H.323 コールが到達するゲートウェイを判断するときにこの情報を確認するように Unified CM を設定する必要があります。

この場合、次のように、1 つの Unified CM サービス パラメータを有効にし、別のパラメータがそのデフォルト値に設定されるようにする必要があります。

• クラスタワイドのサービス パラメータである [Accept unknown TCP connection] を [True] に変更します（デフォルト設定は [False] です）。

• [Device Name of gatekeeper trunk that will use port 1720] サービス パラメータはデフォルト設定の空白のままにします。

[True] に設定すると、[Accept Unknown TCP Connection] サービス パラメータによって着信 H.323 コールの動作が変わります。Unified CM は、不明な H.225 TCP 接続を受け入れ、H.323 SETUP メッセージを待ちます。その後、Unified CM は、User-to-User Information Element（UUIE; ユーザツーユーザ情報要素）を抽出し、発信元ゲートウェイの IP アドレスを格納した sourceCallSignalAddress フィールドを調べます。Unified CM は、このアドレスと設定されているゲートウェイを比較します。一致した場合、コールは Unified CVP Server ではなく音声ゲートウェイから発信されたかのように処理されます。Unified CVP Server の IP アドレスは、H.323 ゲートウェイとして設定してはなりません。設定すると、Unified CM は最初にソース IP アドレスで一致し、sourceCallSignalAddress フィールドの情報は確認しません。Unified CVP を H.323 ゲートウェイとして指定せずに、Unified CVP から Unified CM にコールを配信するには、Unified CM で H.323 ゲートキーパー トランクを設定し、Unified CVP がそのトランク上でゲートキーパーを介してコールを Unified CM に送信するようにする必要があります。

Unified CM の [Device Name of gatekeeper trunk that will use port 1720] サービス パラメータは、ゲートキーパー制御のトランクをポート 1720 のゲートキーパーに強制的に登録するために使用します。この機能を使用すると、ポート 1720 でシグナリングされる着信 H323 コールがゲートキーパー制御のトランク コールとして即座に処理されるようになります。この場合、H.225 シグナリング アドレスは調べられません。

この動作は、Unified CM がゲートキーパー制御の H.323 コールを処理する従来の動作とは異なります。通常、ゲートキーパー制御のコールはすべてハブ ロケーション（ロケーション [None] または [Hub_None]）から発信されます。これらの変更により、コールはゲートキーパー制御のコールとしては処理されず、ロケーションベースのコール アドミッション制御が適用されるようになります。このモデルでは、Unified CM は、設定されているゲートウェイのリストにあるゲートウェイ シグナリング アドレスと一致しない場合、コールを拒否します。図 3-1 に、H.323 コール処理用の決定ツリーを示します。

図 3-1 Cisco Unified CM H.323 シグナリング フロー トポロジ

Unified CM コール アドミッション制御と正しく連携するように Unified CVP を設定するには、VBAdmin を使用して Unified CVP Server パラメータ setlocationsbasedcac on を設定します。Unified CVP は、この設定に従って sourceCallSignalAddress フィールドに入力し、Unified CM へのコールの送信時に TCP ポート 1720 を使用します。

Unified CM から発信されるコールとこの機能を組み合わせて使用すると、Unified CVP によって入力された sourceCallSignalAddress が Unified CM の IP アドレスになります。コールが転送されて Unified CM に戻ると、このフィールドが検査され、その IP アドレスが設定されているゲートウェイが検索されますが、コールは失敗します。これは、通常 Unified CM はゲートウェイとして設定されないためです。この問題を回避するには、クラスタの各 Unified CM を H.323 ゲートウェイとして設定します。ただし、これらのゲートウェイを使用してコールを送信するように Unified CM ダイヤル プランを設定することは避けてください。

複数の Cisco Unified CM クラスタ

複数の集中型 Unified CM クラスタをリモート サイト用に使用する場合、エージェントの選択に基づくコールのルーティングについて別途考慮する必要があります。マルチクラスタ環境では、各クラスタはロケーションベースのコール アドミッション制御メカニズム内でリモート サイトのグループを管理し、これらのサイトへの音声コールを追跡します。上記のような変更を適用した場合、Unified CM はロケーションベースのコール アドミッション制御メカニズム内で H.323 コールを考慮します。H.323 はピアツーピア プロトコルであるため、H.323 ゲートウェイはコールを他のコール エージェントにシグナリングできます。上記のロケーションベースのコール アドミッション制御メカニズムを考慮する際には、リモート ゲートウェイのロケーションを所有する Unified CM クラスタにコールをシグナリングすることをそのリモート ゲートウェイに通知する必要があります。ただし、Unified CCE 環境では、Unified ICM は、エージェントの可用性の追跡時に、それらのエージェントが展開されているクラスタを考慮しません。この機能により Unified CCE のスケーラビリティは高まりますが、このタイプの実装では考慮が必要です。

Unified CVP 入力ゲートウェイからのコールの宛先 IP 電話が、別のクラスタに登録された別のサイトにある場合、入力ゲートウェイのコール アドミッション制御を処理するクラスタを経由してルーティングされ、その後で宛先クラスタにルーティングされます。コールが入力ゲートウェイから宛先クラスタに直接ルーティングされる場合、入力ゲートウェイのコール アドミッション制御を処理するクラスタは、WAN を横断するコールを認識せず、帯域幅を適切に差し引きしません。

このコール ルーティングを処理するには、Unified CVP の SigDigits 機能とそれに関連付けられているダイヤル プラン コンフィギュレーションを使用します。Unified CVP の SigDigits 機能を使用すると、SIP プロキシまたはゲートキーパーでダイヤル プランを使用して、コールを特定の Unified CM クラスタにルーティングできます。コールが入力ゲートウェイに到達すると、ゲートウェイはコールを Unified CVP に送信する前にディジットを付加します。ダイヤル プランの観点では、付加されるディジットはそのサイトに固有のものです。コールが Unified CVP に到達すると、Unified CVP は付加されたディジットを削除してからメモリに格納します。結果として、元の DID でコールが到達したことになります。Unified ICM が Unified CVP にラベルを返して、エージェントの電話にコールを転送することが可能になると、Unified CVP はメモリ内に格納されたディジットを付加してから転送を開始します。SIP プロキシまたはゲートキーパーのダイヤル プラン コンフィギュレーションにはディジットの付加が設定され、特定のディジット文字列が付加されたコールが特定の Unified CM クラスタに送信されるようになります。H.323 を使用している場合、ディジットは tech プレフィクスとして付加されます。

SigDigits 機能の仕組みの詳細については、「分散型 VoiceXML ゲートウェイ（分離入力ゲートウェイおよび VoiceXML）」を参照してください。

SIP コール フロー

SIP ベースのコール フローを使用した場合、Cisco Unified CM 6.0（およびそれ以前のリリース）は Unified CVP からの着信 SIP INVITE のソース IP アドレスしか確認できません。この制限によりコール アドミッション制御で問題が発生します。Unified CM は、コールの発信元 Unified CVP の背後にあるゲートウェイを識別できないためです。

Cisco Unified CM 6.1 では、SIP トランクが強化され、コールの発信元デバイスの特定時に、ソース IP アドレスの先を確認したり、SIP ヘッダー内の情報を検査したりできます。この強化により、Unified CVP のリモート ポートではなく元のソース IP アドレスで SIP トランクを動的に選択できるようになったため、Unified CVP とは異なるソース トランクで別の SIP プロファイルおよび設定を使用できます。

さらに具体的に説明すると、SIP INVITE の Call-Info ヘッダーによって発信元デバイスが次の形式で指定されます。

<sip: IPAddress:port >;purpose=x-c isco-origIP

ここで、 IPAddress:port は、発信元デバイスとその SIP シグナリング ポートを示します。

このソース IP SIP トランク選択機能は、コール アドミッション制御の帯域幅モニタリングには影響しません。Unified CM Release 8.0 では、Unified CVP および Unified CM のロケーション コンフィギュレーションを使用して、SIP で帯域幅モニタリングが実行されます。Unified CM のロケーション サーバでは、コール アドミッション制御の帯域幅情報を操作するために、次のヘッダーが使用されます。

Call-Info: [urn:x-cisco-remotecc:callinfo];x-cisco-loc-id="PKID";x-cisco-loc-name="Loc-NAME"

RSVP

Cisco Unified CM 5.0 ではクラスタ内のエンドポイント間における Resource Reservation Protocol（RSVP; リソース予約プロトコル）のサポートが導入され、8.0 UCM では SIP トランク上の RSVP が導入されています。RSVP は、コール アドミッション制御に使用されるプロトコルであり、ネットワーク内のルータでコール用の帯域幅を予約するために使用されます。8.0 リリースの SIP または H323 では、Unified CVP コール サーバを介した呼制御シグナリングに RSVP は使用できません。CAC の推奨ソリューションは、Unified CVP および Unified CM のロケーション コンフィギュレーションを採用することです。

RSVP の詳細については、次の URL から入手可能な最新バージョンの『 Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 』を参照してください。

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

H.323 ゲートキーパー コール ルーティング

リモート H.323 ゲートウェイと Unified CM クラスタが適切に設定されている場合は、まず最初に、ゲートキーパーを使用しない場合にこのコンフィギュレーションが H.225 にどのように影響するかを検討します。

Cisco IOS ゲートウェイにダイヤルピア宛先を設定する場合、そのゲートウェイのコールを処理している Unified CM サーバの IP アドレスを指し示すダイヤルピアを設定する必要があります。これらのサーバ IP アドレスは、Unified CM コンフィギュレーションに含まれる対象のゲートウェイに関するデバイス プール定義の冗長グループにあるサーバと一致する必要があります（図 3-2 を参照）。リモート H.323 ゲートウェイがそのゲートウェイの冗長グループにない Unified CM サーバにコールを送信した場合、コールは拒否されます。たとえば、図 3-2 の Madison ゲートウェイが .3 サーバにコールを送信した場合、コールは拒否されます。

図 3-2 ダイヤル ピア コンフィギュレーション

図 3-2 の例は理解しやすいものですが、長期間にわたって数百ものリモート サイトを保持する場合は、コンフィギュレーションが困難になることがあります。Cisco Unified CM ゲートキーパーの冗長グループが変更された場合、すべてのリモート H.323 ゲートウェイのダイヤルピア ターゲットを変更して、冗長グループに追加されたサーバの新しい IP アドレスに合わせる必要があります。ゲートキーパーは、この問題を軽減するのに役立ちます。

コンフィギュレーションにゲートキーパーを使用した場合、H.323 ゲートウェイはゲートキーパーに対してコールの送信先 IP アドレスについて Registration Admission Status（RAS）要求を行います。ゲートキーパーは、ゲートキーパー トランクの冗長グループに定義されている Unified CM サーバ アドレスの 1 つを使用して自動的に応答します。冗長グループが変更された場合、Unified CM をゲートキーパーに再登録する必要があります。ただし、リモート ゲートウェイでのそれ以上のコンフィギュレーションは不要です。