この新しいインフラストラクチャの改善点には次のものが含まれます。

  • 通話処理のパフォーマンスを改善し、ローカル ゲートウェイの登録ごとに最大 250 件のセッションを同時に実行できるようになりました。

  • Webex Calling Media の最適化の使用を、卓上電話、Webex アプリ、およびローカル ゲートウェイ間の通話でサポートします。

機能と仕様

  • 新しいプロキシ アドレスのリストがリリースされました。 プロキシ アドレスはローカル ゲートウェイのオンボーディング プロセス中に Control Hub から取得され、その後、ゲートウェイを登録するためにローカル ゲートウェイのテナント構成で設定される静的 DNS レコードです。

  • Webex Calling クラウド オペレーションでは、古いプロキシ アドレスを使用しているローカル ゲートウェイの移行をお願いしています。 詳細は次のセクションで説明します。

ローカル ゲートウェイの移行を開始する

ローカル ゲートウェイの一部に、以下にリストされている Webex Calling の新しいプロキシ アドレスの範囲に含まれない発信プロキシ アドレスがある場合、組織の利便性に応じて手動で移行する必要があります。 Control Hub のリストに記載されているアドレスは、以下の新しいアドレスのうちの 1 つです。ただし、現在ローカル ゲートウェイが古いアドレスで構成されている場合は、移行が必要です。

この移行作業には 10 ～ 15 分程度かかります。 移行中はローカル ゲートウェイをクラウドに再登録するため、サービスに影響が出ます。 そのため、メンテナンス期間中にこの作業を実行することをおすすめします。

米国

カナダ

ヨーロッパ

日本

オーストラリア

2020 年 12 月以降に導入された新しいローカル ゲートウェイ デバイスでは、このインフラストラクチャを使用するよう自動的にセットアップされるため、操作は必要ありません。 上記のリストを参照してローカル ゲートウェイに移行が必要かどうかを確認し、移行が必要な場合は以下のガイドラインに従って実行することをおすすめします。

Control Hub でローカル ゲートウェイを移行する

ローカル ゲートウェイの移行が必要かどうかを判断するには、「ローカル ゲートウェイの移行を開始する」セクションを参照してください。

Control Hub の構成画面、CUBE の構成手順、および発信プロキシ アドレスは、組織の場所とローカル ゲートウェイに応じて異なります。 以下の手順に記載されている内容はあくまでも例です。

始める前に

  1. CUBE のアクセス コントロール リストを更新する - Webex Calling では、セッション ボーダー コントローラー (SBC) IP アドレスの範囲が更新されました。これは、Webex Calling に接続する組織内のすべての CUBE で信頼リストとして適用する必要がある可能性があります。 Webex Calling のポート リファレンス ガイドで最新の IP 範囲を確認し、適用済みかどうかを確認します。まだ適用されていない場合は、「ローカル ゲートウェイを Webex Calling に登録する」の構成手順のステップ 1 を参照して、この更新を実行してください。 CUBE に最新の「信頼できる IP アドレス」を適用することは必須要件であり、更新されない場合、通話は失敗します。

  2. 外部ファイアウォールが CUBE からこれらの IP アドレスへのアクセスを許可していることを確認する - 外部ファイアウォールが IP アドレスを使用して CUBE のアクセスをフィルタリングしている場合、ローカル ゲートウェイがクラウドと通信できるように更新する必要があります。 詳細については、「ポート参照情報ガイド」を参照してください。

  3. CUBE の信頼アンカーが「参照プラットフォーム構成を実行する」のステップ 5 に従って更新されていることを確認します。

Control Hub から、新しい発信プロキシ アドレスを取得できます。

1

https://admin.webex.com の顧客ビューから [サービス] に移動し、[Calling] > [コール ルーティング] を選択します。

2

お使いの PSTN 接続を選択し、[ローカル ゲートウェイ] の下の [編集] をクリックします。
3

[管理] をクリックして、ローカル ゲートウェイの構成にアクセスします。
4

発信プロキシ アドレスをコピーします。


 

組織内に多くのローカル ゲートウェイがある場合、上記のタスクを異なるローカル ゲートウェイに対して実行すると、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

太字の registrar dns:xxxx で始まる行を削除し、後続の作業のために保存しておきます。 また、既存の発信プロキシ アドレスを保存してください。

これで、ローカル ゲートウェイは Webex Calling の登録を削除します。
2

以下のコマンドを入力して、ローカル ゲートウェイが Webex Calling に登録されていないことを確認します。

voice class tenant 201
  no registrar
!
show  sip-ua register status
3

Control Hub からコピーした新しいアドレスを追加し、上記のレジストラの行を戻します。 以下の例では、OBP は ch13.sipconnect-us.bcld.webex.com. 

voice class tenant 201
outbound-proxy dns:hs3.sse.lgw.bcld.webex.com  
registrar dns:lgw2.killarney.cisco.com scheme sips expires 240 refresh-ratio 50 tcp tls
!

ローカル ゲートウェイが新しい OBP で登録されます。
4

以下のコマンドで、登録が正常に完了したことを確認してください。

show sip-ua register status
show sip-ua register status

以下のような出力が得られるはずです。

Tenant:  201
--------------------- Registrar-Index  1 ---------------------
Line                             peer      expires(sec) reg survival  P-Associ-URI
================================ ========= ============ === ========  ============
TRUNK_GROUP_29959_LGU                 -1         7            yes normal

次に行うこと

他のローカル ゲートウェイも上記と同じ手順で更新します。

失敗した移行をロールバックする

移行に失敗した場合は、以前の発信プロキシ アドレスを再登録します。 以下の手順でロールバックし、サービスを復旧します。

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
!

  1. ロールバックしても、Control Hub の設定には新しい発信プロキシ アドレスが表示されます。 これは予期された動作です。 サービスは引き続き古い発信プロキシ アドレスで動作します。

  2. 「Control Hub でローカル ゲートウェイを移行する」セクションのステップ 2 を正しく実行し、新しい発信プロキシへのアクセスをブロックしているファイアウォールがないことを確認してください。

  3. この問題を解決できない場合は、Cisco Webex Calling Support に連絡してください。

移行後の検証

移行後もサービスが正常に動作していることを確認することが重要です。 移行が完了したら、必ずサービスをテストしてください。 サービスをテストするには、Webex Calling デバイスから電話番号への通話、またはWebex Calling と組み合わせて使用される SBC への通話をテストします。