概要

Webex Calling 管理者として、重要な要件の 1 つは、ローカル ゲートウェイを設定することです。Control Hub で使用可能な構成検証 オプションを使用すると、構成を検証できます。これは、ユーザーの問題を引き起こす前に、構成の誤りを特定し、修正に関するガイダンスを提供します。この構成の検証を使用すると、エラーがなくなるまで構成を再検証できます。

  • この構成検証を実行するには、管理対象のゲートウェイをControl Hubに登録し、ローカルゲートウェイ をサービスとして割り当てることが必須です。

  • 登録ベースのローカル ゲートウェイの構成検証 のみをサポートします。

Cisco ローカル ゲートウェイの設定を検証する

次の手順を実行して、Cisco ローカル ゲートウェイの設定を検証します。

1

[Calling ] > [管理対象ゲートウェイ ] の順に移動し、ゲートウェイを一覧表示する行をクリックします。

2

ゲートウェイの概要ページで、[構成検証 ]セクションの[検証 ]をクリックして検証を開始します。

検証が進行中であることを確認するメッセージが表示されます。ゲートウェイ カードには、リクエストの詳細も表示されます。

3

[更新 ] をクリックして、検証の最新のステータスを表示します。

継続中の検証が完了した後にのみ、新しい検証をリクエストできます。

4

検証が成功すると、［検証 ］オプションと［結果を表示 ］オプションが表示されます。

5

［結果を表示］ をクリックして、［検証済みの設定 ］ページに構成を表示し、構成に誤りがないか確認します。詳細については、「構成検証結果を確認する」を参照してください。

構成検証の結果は 2 年間保存されます。ただし、ゲートウェイ設定データは、検証アプリケーションを実行するプラットフォームから 8 時間後に削除されます。

6

［閉じる ］をクリックして、［検証済みの設定 ］ページを終了します。ゲートウェイの概要ページが表示されます。

データ保持期間中に、設定検証の結果にアクセスできます。ただし、この期間の投稿は結果を表示 することはできません。

7

検証が失敗した場合は、[検証 ] をクリックして構成の検証を再試行します。結果を表示 できるのは、検証リクエストが成功した場合のみです。

以前の検証が成功しているかどうかにかかわらず、検証を使用してゲートウェイ設定を再検証できます。

構成検証結果を知る

[検証]をクリックすると、ゲートウェイ構成が推奨される構成に対して検証され、問題があるかどうかを分析します。これを実現するために、構成の各セクションは個別に検証され、検証結果も同様に表示されます。

以下は、現在検証されている設定のさまざまなセクションです。

  • Webex Calling クラウドに登録するために使用される音声クラス テナント

  • テナントに関連付けられた音声クラス sip-profile

  • ボイス サービス voip

  • SIP-ua（sip-ua）

  • ネームサーバー と暗号pkiトラストポイント 設定のグローバル設定

  • Webex Calling ダイヤルピア—Webex Calling に対する着信および発信ダイヤルピア

    Webex Calling 側のダイヤルピア設定のみが検証されます。ローカル PBX 側の完全なダイヤル プラン、PSTN、およびダイヤル ピア設定は検証されません。

たとえば、設定にvoice sip profile、sip-ua、またはvoice class tenant セクションが含まれる場合があります。これらの構成はそれぞれ別々のセクションとして分析され、対応する結果が別々に表示されます。また、レポートの日付、検証済みのセクションの合計数、問題のあるセクションの合計数などの詳細がページに表示されます。

検証結果の一部として、次のステータスが表示されます。

  • 問題が見つかりません—検証済みの設定セクションは有効で、そのまま使用できます。

  • Missing:検証済みの設定にギャップまたは手順がありません。ギャップに対処した後、設定を再検証します。

  • Misconfigured:検証済みの設定でエラーが発生しました。エラーを修正した後、設定を再検証します。

  • 注文:検証済みの設定には、すべての手順があります。ただし、実行した順序は推奨されません。設定手順を並べ替えた後、設定を再検証します。

設定が正確であるかどうかにかかわらず、検証済みの各セクションの参照設定を提供します。同じものを参照して、設定を更新することができます。

また、有効な各設定セクションに対してコピー オプションを提供します。これにより、これらの設定をクリップボードにコピーできます。

構成検証と推奨事項の参照として Webex Calling 構成を使用します。設定は、Unified Communications Manager または PSTN トランキング設定に基づいて検証されません。

トラブルシューティング

構成検証 に失敗した場合は、管理者として以下を実行できます。

  • コネクタに関する問題の概要については、Control Hub のイベント履歴 ページを参照してください。

  • オンプレミスのコネクタ管理ページ (https://) に移動して、管理コネクタとテレメトリコネクタが実行 および接続 状態になっていることを確認します。コネクタの状態の詳細については、ゲートウェイコネクタの状態を参照してください。

  • ゲートウェイ デバイスで、コマンド show netconf-yang sessions を使用して NETCONF セッションがアクティブになっていることを確認します。以下は、アクティブな NETCONF セッションのサンプルです。

    Router#show netconf-yangセッション セッション数 : 1 session-id transport username source-host global-lock -------------------------------------------------------------------------------- 32 netconf-ssh lab 10.65.125.133 なし ルーター#

    NETCONF セッションがアクティブでない場合は、ゲートウェイの資格情報 (ユーザー名とパスワード) がコネクタのインストール時に設定したものと同じであることを確認してください。ゲートウェイ クレデンシャルが変更された場合は、TCL スクリプトを実行します。vを選択します。Cloud Connector の設定 を表示および変更し、c: ゲートウェイ クレデンシャル を更新して、変更したクレデンシャルを設定します。

  • それでも問題が解決しない場合は、Cisco TAC サポート チームに連絡してください。以下を収集して共有します。

    • Control Hub からの失敗した Config Validation リクエストのトラッキング ID の詳細。または、コマンドコピーデバッグ情報 を使用して ID の詳細を収集することもできます。

    • コネクタからのログ TCL スクリプトを実行し、以下を選択します。l: ログの収集