コメントありがとうございます。
ローカル ゲートウェイを移行する
フィードバックがある場合この新しいインフラストラクチャの改善点には次のものが含まれます。
-
通話処理のパフォーマンスを改善し、ローカル ゲートウェイの登録ごとに最大 250 件のセッションを同時に実行できるようになりました。
-
デスクフォン、Webex アプリ、ローカル ゲートウェイ間の通話に Webex Calling Media Optimization の使用をサポートします。
機能と仕様
-
新しいプロキシ アドレスのリストがリリースされました。プロキシ アドレスはローカル ゲートウェイのオンボーディング プロセス中に 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 | |
| 2 |
。 |
| 3 |
お使いの PSTN 接続を選択し、[ローカル ゲートウェイ] の下の [編集] をクリックします。 |
| 4 |
[管理] をクリックして、ローカル ゲートウェイの構成にアクセスします。 |
| 5 |
発信プロキシ アドレスをコピーします。 組織内に多くのローカル ゲートウェイがある場合、上記のタスクを異なるローカル ゲートウェイに対して実行すると、Control Hub から異なる発信プロキシ アドレスが取得される可能性があります。構成する各ローカル ゲートウェイの発信プロキシ アドレスを Control Hub からコピーしておいてください。冗長性やトラフィックの負荷分散のため、特定のアドレスを選択することが重要です。  |
ローカル ゲートウェイの構成の更新はサービスに影響し、アクティブな通話に影響を与えるおそれがあります。
以下の例では、テナント 201 が Webex Calling に接続するテナントです。構成の際には適切なテナントを入力してください。
#show running-config | s voice class tenant 201
voice class tenant 201
registrar dns:lgw2.killarney.cisco.com scheme sips expires 240 refresh-ratio 50 tcp tls
credentials number TRUNK_GROUP_24740_LGU username TRUNK_GROUP_29959_LGU password 6 K]W]ZP`PSZRKWE^WXXIPG\^_adSTbLMHV realm BroadWorks
authentication username TRUNK_GROUP_29959_LGU password 7 xxxxxxxx realm BroadWorks
authentication username TRUNK_GROUP_29959_LGU password 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
outbound-proxy dns:lgwrestest.killarney.cisco.com
| 1 |
これで、ローカル ゲートウェイは Webex Calling の登録を削除します。 |
| 2 |
ローカル ゲートウェイが Webex Calling に登録されていないことを、以下のコマンドを入力して確認します。 |
| 3 |
Control Hub からコピーした新しいアドレスを追加し、上記のレジストラの行を戻します。以下の例では、OBPは ローカル ゲートウェイが新しい 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 への通話をテストします。
