ローカル ゲートウェイを移行する
Webex Calling プラットフォームにはアップグレードされたクラウド インフラストラクチャが含まれており、オンプレミスのローカル ゲートウェイはこのインフラストラクチャに接続します。このアップグレードによりサービスが向上し、またローカル ゲートウェイには新機能が追加されます。
この新しいインフラストラクチャの改善点には次のものが含まれます。
-
通話処理のパフォーマンスを改善し、ローカル ゲートウェイの登録ごとに最大 250 件のセッションを同時に実行できるようになりました。
-
卓上電話、Webex アプリ、ローカル ゲートウェイ間の通話に対する Webex Calling メディア最適化 の使用をサポートします。
機能と仕様
-
新しいプロキシ アドレスのリストがリリースされました。プロキシ アドレスはローカル ゲートウェイのオンボーディング プロセス中に Control Hub から取得され、その後、ゲートウェイを登録するためにローカル ゲートウェイのテナント構成で設定される静的 DNS レコードです。
-
Webex Calling クラウド オペレーションでは、古いプロキシ アドレスを使用しているローカル ゲートウェイの移行をお願いしています。詳細は次のセクションで説明します。
ローカル ゲートウェイのいずれかに、以下にリストされている新しい Webex Calling プロキシ アドレス範囲に含まれない発信プロキシ アドレスがある場合、組織の利便性に応じて手動で移行します。Control Hub にリストされているアドレスは、以下の新しいアドレスの 1 つです。ただし、ローカル ゲートウェイは現在、古いアドレスで構成されており、移行が必要な場合があります。
この移行には 10 ～ 15 分以上かかりません。ただし、移行中に、ローカル ゲートウェイはクラウドに再登録され、サービスに影響を与えます。そのため、メンテナンス期間中にこの作業を実行することをおすすめします。
米国
カナダ
ヨーロッパ
日本
オーストラリア
シンガポール
2020 年 12 月以降に導入された新しいローカル ゲートウェイ デバイスでは、このインフラストラクチャを使用するよう自動的にセットアップされるため、操作は必要ありません。上記のリストを参照してローカル ゲートウェイに移行が必要かどうかを確認し、移行が必要な場合は以下のガイドラインに従って実行することをおすすめします。
ローカル ゲートウェイの移行が必要かどうかを判断するには、「ローカル ゲートウェイの移行を開始する」セクションを参照してください。
Control Hub の構成画面、CUBE の構成手順、および発信プロキシ アドレスは、組織の場所とローカル ゲートウェイに応じて異なります。以下の手順に記載されている内容はあくまでも例です。
始める前に
-
CUBE のアクセス コントロール リストを更新する - Webex Calling では、セッション ボーダー コントローラー (SBC) IP アドレスの範囲が更新されました。これは、Webex Calling に接続する組織内のすべての CUBE で信頼リストとして適用する必要がある可能性があります。Webex Calling のポート リファレンス ガイドで最新の IP 範囲を確認し、適用済みかどうかを確認します。まだ適用されていない場合は、「ローカル ゲートウェイを Webex Calling に登録する」の構成手順のステップ 1 を参照して、この更新を実行してください。CUBE に最新の「信頼できる IP アドレス」を適用することは必須要件であり、更新されない場合、通話は失敗します。
-
外部ファイアウォールが CUBE からこれらの IP アドレスへのアクセスを許可していることを確認する - 外部ファイアウォールが IP アドレスを使用して CUBE のアクセスをフィルタリングしている場合、ローカル ゲートウェイがクラウドと通信できるように更新する必要があります。詳細については、「ポート参照情報ガイド」を参照してください。
-
CUBE の信頼アンカーが「参照プラットフォーム構成を実行する」のステップ 5 に従って更新されていることを確認します。
Control Hub から、新しい発信プロキシ アドレスを取得できます。
| 1 |
https://admin.webex.com の顧客ビューから [サービス] に移動し、 を選択します。 |
| 2 |
お使いの PSTN 接続を選択し、[ローカル ゲートウェイ] の下の [編集] をクリックします。 |
| 3 |
[管理] をクリックして、ローカル ゲートウェイの構成にアクセスします。 |
| 4 |
発信プロキシ アドレスをコピーします。 組織内に多くのローカル ゲートウェイがある場合、上記のタスクを異なるローカル ゲートウェイに対して実行すると、Control Hub から異なる発信プロキシ アドレスが取得される可能性があります。構成する各ローカル ゲートウェイの発信プロキシ アドレスを Control Hub からコピーしておいてください。冗長性やトラフィックの負荷分散のため、特定のアドレスを選択することが重要です。  |
ローカル ゲートウェイの構成の更新はサービスに影響し、アクティブな通話に影響を与えるおそれがあります。
以下の例では、テナント 201 が Webex Calling に接続するテナントです。構成の際には適切なテナントを入力してください。
#runConfigを表示 | 音声クラス テナント 201 音声クラス テナント 201 レジストラ dns:lgw2.killarney.cisco.com スキーム sips の失効 240 更新比 50 tcp tls クレデンシャル番号のトランク_グループ_24740年代の日本_LGUユーザー名 トランク_グループ_ハインリヒ2世_LGU パスワード 6 K]W]ZP`PSZRKWE^WXXIPG\^_adSTbLMHV レルム BroadWorks 認証ユーザ名 TRUNK_グループ_ハインリヒ2世_LGU パスワード 7 xxxxxxxx レルム BroadWorks 認証ユーザー名 TRUNK_グループ_ハインリヒ2世_LGU パスワード 6 xxxxxxxx realm lgw2.killarney.cisco.com sip-server dns:lgw2.killarney.cisco.com connection-reuse session transport tcp tls url sips error-passthru bind control source-interface GigabitEthernet1 bind media source-interface GigabitEthernet1 no pass-thru content custom-sdp sip-profiles 201 アウトバウンドプロキシ dns:lgwrestest.killarney.cisco.com | 1 |
これで、ローカル ゲートウェイは Webex Calling の登録を削除します。 |
| 2 |
ローカル ゲートウェイが Webex Calling に登録されていないことを、以下のコマンドを入力して確認します。 |
| 3 |
Control Hub からコピーした新しいアドレスを追加し、上記のレジストラの行を戻します。以下の例では、OBP は ch13.sipconnect-us.bcld.webex.com ローカル ゲートウェイが新しい OBP で登録されます。 |
| 4 |
以下のコマンドで、登録が正常に完了したことを確認してください。 以下のような出力が得られるはずです。 |
次に行うこと
他のローカル ゲートウェイも上記と同じ手順で更新します。
移行に失敗した場合は、以前の発信プロキシ アドレスを再登録します。以下の手順でロールバックし、サービスを復旧します。
voice class tenant 201 no registrar outbound-proxy dns:lgwrestest.killarney.cisco.com registrar dns:lgw2.killarney.cisco.com scheme sips expires 240 refresh-ratio 50 tcp tls ! -
ロールバックしても、Control Hub の設定には新しい発信プロキシ アドレスが表示されます。これは予期された動作です。サービスは引き続き古い発信プロキシ アドレスで動作します。
-
「Control Hub でローカル ゲートウェイを移行する」セクションのステップ 2 を正しく実行し、新しい発信プロキシへのアクセスをブロックしているファイアウォールがないことを確認してください。
-
この問題を解決できない場合は、Cisco Webex Calling Support に連絡してください。
移行後もサービスが正常に動作していることを確認することが重要です。移行が完了したら、必ずサービスをテストしてください。サービスをテストするには、Webex Calling デバイスから電話番号への通話、またはWebex Calling と組み合わせて使用される SBC への通話をテストします。
