Webex Calling プラットフォームにはアップグレードされたクラウド インフラストラクチャが含まれており、オンプレミスのローカル ゲートウェイはこのインフラストラクチャに接続します。 このアップグレードによりサービスが向上し、またローカル ゲートウェイには新機能が追加されます。
この新しいインフラストラクチャの改善点には次のものが含まれます。
通話処理のパフォーマンスを改善し、ローカル ゲートウェイの登録ごとに最大 250 件のセッションを同時に実行できるようになりました。
Webex Calling Media の最適化の使用を、卓上電話、Webex アプリ、およびローカル ゲートウェイ間の通話でサポートします。
機能と仕様
新しいプロキシ アドレスのリストがリリースされました。 プロキシ アドレスはローカル ゲートウェイのオンボーディング プロセス中に Control Hub から取得され、その後、ゲートウェイを登録するためにローカル ゲートウェイのテナント構成で設定される静的 DNS レコードです。
Webex Calling クラウド オペレーションでは、古いプロキシ アドレスを使用しているローカル ゲートウェイの移行をお願いしています。 詳細は次のセクションで説明します。
ローカル ゲートウェイの一部に、以下にリストされている Webex Calling の新しいプロキシ アドレスの範囲に含まれない発信プロキシ アドレスがある場合、組織の利便性に応じて手動で移行する必要があります。 Control Hub のリストに記載されているアドレスは、以下の新しいアドレスのうちの 1 つです。ただし、現在ローカル ゲートウェイが古いアドレスで構成されている場合は、移行が必要です。
この移行作業には 10 ~ 15 分程度かかります。 移行中はローカル ゲートウェイをクラウドに再登録するため、サービスに影響が出ます。 そのため、メンテナンス期間中にこの作業を実行することをおすすめします。
米国
カナダ
ヨーロッパ
日本
オーストラリア
sy03.sipconnect-au.bcld.webex.com ~ sy14.sipconnect-au.bcld.webex.com
me03.sipconnect-au.bcld.webex.com ~ me14.sipconnect-au.bcld.webex.com
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 | 発信プロキシ アドレスをコピーします。
|
ローカル ゲートウェイの構成の更新はサービスに影響し、アクティブな通話に影響を与えるおそれがあります。
次の例では、テナント 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 への通話をテストします。