コメントありがとうございます。
ローカルゲートウェイを移行してください
フィードバックがある場合この新しいインフラストラクチャの改善点は次のとおりです。
-
コール処理パフォーマンスが向上し、ローカルゲートウェイ登録ごとに最大250の同時セッションが可能になりました。
-
デスクフォン、Webex アプリ、Webex Callingローカルゲートウェイ間の通話でのメディア最適化の使用をサポートします。
仕様:
-
プロキシアドレスの新しいリストがリリースされました。 プロキシアドレスは、ローカルゲートウェイのオンボーディングプロセス中にControl Hubから取得され、ゲートウェイを登録するためにローカルゲートウェイのテナント設定で設定される静的DNSレコードです。
-
Webex Callingクラウド運用では、古いプロキシアドレスを使用するローカルゲートウェイを移行するよう顧客に求めています。 詳細は次のセクションで概説されています。
ローカルゲートウェイに、Webex Calling以下に示す新しいプロキシアドレス範囲に含まれないアウトバウンドプロキシアドレスがある場合は、組織の都合に合わせて手動で移行してください。 Control Hubに記載されているアドレスは、以下の新しいアドレスの1つです。ただし、ローカルゲートウェイは現在古いアドレスで構成されている可能性があり、移行が必要です。
この移行には10〜15分もかからないはずです。 ただし、移行中、ローカルゲートウェイはクラウドに再登録され、サービスに影響します。 そのため、このアクティビティはメンテナンスの時間帯に行うことをお勧めします。
US
カナダ
ヨーロッパ
日本
オーストラリア
シンガポール
2020年12月以降に導入された新しいローカルゲートウェイデバイスは、このインフラストラクチャを使用するように自動的に設定されるため、何もする必要はありません。 上記のリストを参照して、移行が必要なローカルゲートウェイがあるかどうかを確認し、必要な場合は、以下のガイドラインに従って移行を実行することをお勧めします。
ローカルゲートウェイのいずれかに移行が必要かどうかを理解するには、「ローカルゲートウェイの移行を始める」セクションを参照してください。
Control Hub、CUBEの設定手順、およびアウトバウンドプロキシアドレスの設定画面は、組織の場所とローカルゲートウェイによって異なります。 以下に示す手順に記載されている詳細は一例に過ぎません。
始める前に
-
CUBEのアクセス制御リストの更新-セッション・ボーダー・コントローラー（SBC）Webex CallingのIPアドレスの範囲が更新されました。接続している組織内のすべてのCUBEに信頼できるリストとして適用する必要があるかもしれません。Webex Calling Webex Callingポートリファレンスガイドの最新のIP範囲を確認して、すでに適用されているかどうかを確認してください。適用されていない場合は、「ローカルゲートウェイの登録」Webex Calling のステップ1の設定手順を参照して、この更新を実行してください。 CUBEに最新の「信頼できるIPアドレス」があることは必須要件であり、更新しないと通話が失敗します。
-
外部ファイアウォールで、CUBEからこれらのIPアドレスにアクセスできるようにしてください。外部ファイアウォールがCUBEがアクセスできるIPアドレスをフィルタリングしている場合は、ローカルゲートウェイがクラウドに接続できるようにこれも更新する必要があります。 詳細については、ポートリファレンス情報ガイドを参照してください。
-
「リファレンスプラットフォーム設定の実行」のステップ5に従って、CUBEのトラストアンカーが更新されていることを確認してください。
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サポートに連絡してください。
移行後、サービスが通常どおり動作していることを確認することが重要です。 移行が完了したら、必ずサービスをテストしてください。 Webex Callingデバイスから電話番号に電話をかけたり、と組み合わせて使用される任意のSBCへの通話をテストしたりして、サービスをテストできます。Webex Calling
