このセクションでは、処分に関するさまざまなトラブルシューティング ソースとツールについて説明しています。 Cisco Webex Control Hub からまたは Expressway コネクタ ホストでこれらのトラブルシューティング ソースにアクセスできます。

関連記事から既知の問題にもアクセスできます。

Cisco Webex Control Hub からハイブリッド接続テスト ツールにアクセスすることができます。 https://admin.webex.com の顧客ビューから、[サービス] に移動し、ハイブリッド通話カードの [設定の編集] をクリックして、[通話サービス接続] までスクロールしてから、入力した SIP 宛先の隣にある [テスト] をクリックします。

この表では、ハイブリッド通話の SIP 接続先アドレスをテストした後に表示される共通のエラーをリストします。 表では、トラブルシューティングに関する次のステップをいくつか載せています。これには、「ハイブリッド通話サービス トラブルシューティング ガイド」の関連する詳細へのリンクを含みます。をクリックします。

エラー

キーワード

詳細とトラブルシューティング ステップ

DNSアドレスが見つかりません

DNS SRV

DNS ルックアップに失敗しました。 SIP 宛先のための DNS または SRV レコードが存在していることを確認し、1 つまたは複数の正しい IP アドレスに変換されるように設定してください。

詳細については、トラブルシューティング ガイドの「Expressway-E DNS SRV/ホスト名を解決できない」を参照してください。

接続が時間切れになりました

ソケットの失敗

ネットワークおよび 相互 TLS 接続がタイムアウトしました。 ネットワーク接続性、ネットワーク速度、ファイアウォール構成、相互 TLS 構成を確認します。

詳細については、トラブルシューティング ガイドのこれらのセクションを参照してください:

TLS 失敗

相互 TLS ハンドシェイクの失敗

相互 TLS エラー: Expressway と https://admin.webex.com の両方で相互 TLS の構成を確認して、両方の場所に相互 TLS 証明書が存在し、有効であることを確認してください。

詳細については、トラブルシューティング ガイドの Mutual TLS Handshake Failures を参照してください。

接続失敗

ソケットの失敗

TCP 接続失敗: ネットワーク接続、接続速度、および/またはファイアウォールの構成を確認してください。

詳細については、トラブルシューティング ガイドのこれらのセクションを参照してください:

TCP 読み取り/書き込み失敗

ソケットの失敗

TCP 読み取り/書き込み失敗: もう一度試してください。 引き続きエラーが発生する場合は、ネットワーク接続、ファイアウォールの構成、相互 TLS の構成を確認してください。

詳細については、トラブルシューティング ガイドのこれらのセクションを参照してください:

TCP 失敗

ソケットの失敗

TCP 失敗: TCP 読み取り/書き込み失敗: もう一度試してください。 引き続きエラーが発生する場合は、ネットワーク接続、ファイアウォールの構成、相互 TLS の構成を確認してください。

詳細については、トラブルシューティング ガイドのこれらのセクションを参照してください:

Cisco Webex Control Hub のユーザー ステータス履歴にアクセスできます。 https://admin.webex.com の顧客ビューから [ユーザー] に進み、ユーザーをクリックして概要ペインを開き、[通話サービス][Aware] の順にクリックし、ステータスの隣にある [履歴の表示] をクリックします。

Cisco Webex Control Hub のステータス履歴には、次のことが含まれます。

  • ユーザーに関連するアラームとその他のステータス メッセージを表示します

  • ユーザーにステータス イベントが生成されたクラスターとノードを示します

  • ユーザーに最新の履歴イベントを 20 個提供します

Cisco Webex Control Hub のユーザー ステータス履歴にアクセスできます。 https://admin.webex.com の顧客ビューから、[サービス] に進み、ハイブリッド通話カードから [設定の編集] を選択して、[ユーザー ステータス レポート] をクリックします。

ユーザー ステータス レポートは、どのユーザーにサービス エラーが発生しているか、そしてその理由を表示します。 レポートを CSV ファイルにエクスポートすることができます。

Expressway コネクタ ホストからユーザー検証チェックにアクセスできます。 [アプリケーション] >[ハイブリッド サービス] >[通話サービス] >[Unified CM Servers] に進み、チェックする登録済みの Cisco Unified Communications Manager を選択します。

ユーザーのバリデーションチェックによって、Cisco Unified Communications Manager のユーザーがハイブリッド通話について適切に構成されているかどうか確認できます。 メール、ディレクトリ URI、Cisco Spark リモート デバイス設定、ホーム クラスターが有効か、プライマリ ディレクトリ番号にディレクトリ URI があるかなど、テストでは構成の前提条件をチェックします。 チェックは特定の通話コネクタ ノードで、どのユーザーが検出されたかに基づきます。

Cisco Webex ハイブリッド通話サービス展開中または展開後、Cisco Webex Control Hub でエラー メッセージを受け取る可能性があります (アラートを構成している場合は電子メール)。 Expressway コネクタ ホストは、アラームの形式でトラブルシューティング情報を提供できます。Expressway コネクタのアラームはさまざまな理由でトリガされます。
  • コネクタのクラッシュ

  • Webex クラウドまたは Unified CM の接続の問題

  • ユーザー エラー

この情報を使用して問題、可能性のある原因、問題を修正するためのアクションを理解します。

Cisco Webex ハイブリッド通話サービス展開中または展開後、Cisco Webex Control Hub でエラー メッセージを受け取る可能性があります (アラートを構成している場合は電子メール)。 Expressway コネクタ ホストは、アラームの形式でトラブルシューティング情報を提供できます。Expressway コネクタのアラームはさまざまな理由でトリガされます。
  • コネクタのクラッシュ

  • Webex クラウドまたは Unified CM の接続の問題

  • ユーザー エラー

この情報を使用して問題、可能性のある原因、問題を修正するためのアクションを理解します。

原因

ユーザーがハイブリッド通話を有効にしている場合、通話コネクタはユーザーの Cisco Spark-RD の作成を試みます。

  • デバイスがすでに存在しているか、同じ名前のリモート接続先プロファイルを持っているため、リモート デバイスの作成に失敗する場合があります。 重複する名前はサポートされていません。

  • Cisco Spark-RD デバイスは、名前付け規則の SparkRD<username> を使用して作成されます。 この名前が 15 文字を超える場合、システムはユーザー名のみを使用します。 同じユーザー名が付けられた名前の電話またはリモート接続先プロファイルがすでに存在している可能性があります。

解決策—Unified CM, で重複した名前付けの問題を特定し、名前を解決してから、1 日待機して、通話コネクタのキャッシュが Unified CM の変更と同期するか、Expressway UI を介して通話コネクタを再起動できるようにします (Expressway-C から Call Connector を再起動する の手順で使用したコネクタを無効にして再度有効にしします)。 次に、Control Hub のユーザーに対してハイブリッド通話を再び有効にします。

考えられる原因—通話コネクタはユーザーのリモート デバイスを作成していません。 一部の必要な構成が欠けています。

対処方法

  • www.cisco.com/go/hybrid-services-call の「準備と展開」の章で詳しく説明されている、Unified CM で必要なユーザー構成をチェックします。

  • ハイブリッド通話の Webex Teams ユーザーを有効にする前にハイブリッド コールの、ユーザーに関連付けられているディレクトリ番号のアラート名と ACSII アラート名の長さが 30 文字を超えないことを確認してください。 名前には、文字、数字、スペース、および次の特殊文字のみ使用できます。 !#$'()*+,./:;=?@^_

考えられる原因:このエラーは通常、リモート宛先が手動で作成された場合に表示されます。 Cisco Spark Remote デバイスを自動または手動で作成できた場合でも、リモート宛先はすべてのケースで自動的に作成されます。

解決策:手動で作成されたリモート宛先を削除し、通話コネクタを再起動して、Unified CM キャッシュをフラッシュしてからユーザーのアクティべーションを再試行します。

考えられる原因
  • ユーザーは複数の Unified CM クラスターで構成されており、チェックされているホーム クラスター値があります。

  • ユーザーがチェックされているホーム クラスター値を持つ 1 個のクラスターで構成されている場合、Unified CM および参加者が通話コネクタに意図せず追加されてしまいます。 クラスターごとに 1 個の Unified CM ノードのみ必要です。

対処方法
  • Unified CM エンド ユーザー アカウントが単一のホーム クラスターにあることを確認します。

  • 通話コネクタで、AXL およびサービスアビリティ サービスを実行しているクラスターごとに、単一のノードのみ追加します。

このセクションでは、サポートに連絡する前に確認できるトラブルシューティング チェックリストとタスクを説明しています。

Cisco Webex からのあなたの会社への呼び出しが会社の電話を鳴らさない場合、このチェックリストを参照して構成を再確認してください。

これらのトラブルシューティングのチェックポイントを調べる前に、https://status.webex.com を参照してクラウドのシステムダウンに関する最新の情報を調べてください。 そのステータス ページより、通知を購読することもできます。

通話コネクタを無効にし、再度有効にすると、コネクタは、Cisco Webex ハイブリッド通話サービスを展開しながら、Unified CM ユーザーとお客様が設定したデバイス設定変更をキャプチャします。 この再起動のサイクルの間、コネクタは、Cisco Spark リモート デバイス上で、Cisco Webex SIP アドレス付きのリモートの接続先を作成します。 このアドレスは、エンド ユーザー アカウントと対応する Cisco Webex Teams を アカウントに関連付けられています。 問題が発生する場合には、トラブルシューティングの手順としても、この設定をトグルします。

Cisco Webex ハイブリッド サービスおよび Webex Teams を備えた環境に Unified CM をアップグレードするとWebex Teams に、通話コネクタにキャッシュされている情報が古くなる可能性があります。 この場合、影響を受ける項目は、データベース キャッシュの自動同期または新しい Unified CM バージョンを Cisco Webex クラウドにレポートすることです。 通話コネクタの再起動により新しいデータベースの最新情報を選択して、新しい Unified CM バージョン情報を Cisco Webex クラウド サービスに発行します。

始める前に


通話コネクタを起動することで Unified CM パブリッシャーに余計な負荷がかかります。 ピーク時間以外に通話コネクタを再起動することを考えましょう。ピーク時に再起動するとサービス上の問題が発生する可能性があります。

1

[Expressway-C] から [アプリケーション] > [ハイブリッド サービス] > [通話サービス] > [通話サービスの概要]に進み、通話コネクタのステータスを [無効] に変更し、[保存] をクリックします。

2

ステータスを 有効 に戻し、再度保存します。

トラブルシューティングのヒント

後から、Unified CM エンドユーザーまたはデバイスに変更を加える必要がある場合があります。 設定エラーを修正するためにこれを行う場合、通話コネクタの「ユーザー検証テスト」で、そのユーザーが合格するとしても、通話コネクタを再起動する必要があり、それによって設定変更が反映されます。

Unified CM キャッシュの注意点

通話コネクタはユーザーの検出とアクティべーション中に Unified CM ノードに影響するパフォーマンスに AXL リクエストが制限を設けるため、Unified CM データのキャッシュを維持します。

キャッシュされたデータには次が含まれています。

  • ユーザー

  • デバイス (ユーザーの関連付けを含む)

  • ディレクトリ番号 (検出、ユーザー関連付け、URI を含む)

  • リモート宛先

通話コネクタはパブリッシャー ノードの変更通知を使用して新しいユーザー データをプルします。 投票間隔は 2 分ごとです。 Unified CM 変更通知の制限のため、キャッシュは現地時間 11 pm に毎晩再構築されるか、通話コネクタの起動ごとに再構築されます。

相互 TLS 接続および証明書に関連する、これらのトラブルシューティング ポイントを確認してください:

  • Cisco Webex クラウドのルート証明のバンドルを、Expressway-E にてインストールします。

  • Expressway-E にて、専用の相互 TLS ポートを設定します。

  • Expressway-E にて、クラウド向けの DNS ゾーンを設定します。

  • お使いのファイアウォールにて、相互 TLS ポート番号を開きます。これは、デフォルトでは開いていない可能性があります。

  • Cisco Webex クラウド内で、どのルート証明を使用しているか確認します。このオプションは、お使いの Expressway-E の SIP TLS 証明を確認するために使われます。

    • デフォルトのストア — あなたの Expressway-E 証明書は、公共企業体のいずれかによって署名されていますか? 確信がない場合は、カスタム ストアのオプションを使用してください。

    • カスタム ストア — あなたの Expressway-E 証明書、またはその署名者はクラウドにインストールされていますか? 証明書には、認証済みの Expressway-E ホスト名が含まれていますか?

https://admin.webex.com の顧客ビューから [サービス] > [ハイブリッド通話] > [設定]に進みます。 展開プロセスの段階で設定した SIP 宛先に関連した以下のポイントをチェックします。

  • 値が、あなたの Expressway-E の専用の相互 TLS ポートを指し示しています。

  • IP address:port への接続を試みてください。(SRV を設定した場合は、複数のアドレス。)

  • IP アドレスまたはホスト名を設定した場合は、相互 TLS ポートを特定してください。

  • SRV を使用した場合は、_sips._tcp.SIP の宛先として入力したドメイン> の形式になっていることを確認してください。

  • SRV のセットアップを希望しない場合は、組織の SIP 宛先として IP address:port または hostname:port を入力できます。

  • 同じ組織内における Cisco Webex Teams のユーザー 2 人の間で、テスト通話を実施してください。このテストでは、両方の発信者に Cisco Webex ハイブリッド通話サービスを有効にすることを推奨しています。

  • ユーザーのどちらかが Cisco Webex 通話 (以前の Spark 通話)、通話はお使いの環境にルーティングされません。

  • まずは、企業側からクラウドへの通話のルーティングを試してください。 このテストを行えば、方程式を使って Cisco Webex ルーティングを判断してみなくても、相互 TLS が正常にセットアップされているかどうかを確認することができます。


テクニカル サポートの前提条件として、最新の安定したコネクタ リリースにアップグレードすることもできます。 詳細についてはハイブリッド サービスの自動ソフトウェア アップグレードを構成するを参照してください。

  • https://admin.webex.com の顧客ビューから:

    • ハイブリッド通話サービス構成に関連する警告の確認:

      • ハイブリッド通話カードからの設定ページにて、[サービス] タブに進みます。

      • 個別のユーザーの [通話サービス設定] ページで [ユーザー] に進みます。

    • ユーザー アクティベーションにエラーが表示されたら、[サービス] > [ハイブリッド通話] > [設定の編集] > [ユーザー ステータス レポート]よりユーザー ステータス レポートを実行してください。

  • Expressway-C のコネクタのホストより、ユーザー確認チェック を実行し、オンプレミスのユーザー設定に関する問題をすべて確認してください。

  • Expressway-C のコネクタのホストより、次の項目を確認してください:

    • [アプリケーション] > [ハイブリッド サービス] > [通話サービス] > [Unified CM サーバー]で Cisco Unified Communications Manager の接続。

    • [アプリケーション] > [ハイブリッド サービス] > [通話サービス] > [通話コネクタ ステータス] でクラウドとユーザー ステータスへの接続

  • [アプリケーション] > [ハイブリッド サービス] > [コネクタ管理] > [Call Connector]で、ハイブリッド通話サービスのユーザー、またはユーザー アクティベーションに関連する通話コネクタのアラームを確認します。


    ユーザー アクティベーションのステータスは、リアルタイムではありません。ユーザーに対しハイブリッド通話サービス上でトグルをすると、処理に最大 6 分かかることがあります。

  • Cisco Webex より企業へルーティングされる通話に関しては、Expressway-E にて検索履歴とネットワークログを確認してください。 このステップにより、問題をクラウドまたは企業のいずれかに孤立化させることができます。

  • Cisco Webex Teams におけるハイブリッド ユーザー間の通話で、着信側のアプリケーションに 2 つの着信通知が届く場合: SIP パラメータ プリザベーションが Expressways で有効になっていることを確認してください。 この設定は、Cisco Webex がコンタクト ヘッダーに追加するパラメータを伝達し、二重発信の問題を解決するのに必要です。

  • 既存の B2B ゾーンと検索ルールを再度使用する場合、代わりに専用のゾーンおよび検索ルールを作成することもご検討ください。 この設定により、B2B/MRA に対する既存のゾーン設定への干渉やルーティングループを回避し、トラブルシューティングがより容易になります。

  • Expressway-E にて、検索履歴とネットワークのログを確認してください。 クラウドからの SIP INVITE が Expressway-E に到達し、クラウドに設定した DNS ゾーンに一致することを確認してください。

    • 設定されている DNS ゾーンに SIP INVITE が及ばない場合、または一致しない場合は、Cisco Unified Communications Manager への通話のルーティングに従います。 このステップを行うことで、通話がどこで失敗しているか、または失われているかがわかります。

    • 相互 TLS のトラブルシューティング チェックリストをご覧ください。

  • ルーティング ヘッダーを確認します。 Cisco Unified Communications Manager の企業設定および Expressway の検索ルールのもとで設定された、クラスタの完全修飾ドメイン名 (FQDN) の値が含まれていることを確認してください。 ルートのヘッダーおよびハイライトされたクラスター FQDN のこの例をご覧ください:

    • ルート: <sip:[Obfuscated];transport=tls;lr>,<sip:myucmcluster.example.com;lr>

      • この例では、ホーム クラスターは myucmcluster.example.com です。

      • Call Connector はその値を同じ Cisco Unified Communications Manager 上のクラスタの FQDN 設定から引き出し、クラウド内でその値をとらえ、同クラスタへ届けられる必要のあるすべての通話に対して使用します。

  • ハイブリッド ユーザーが Cisco Webex Teams のアプリケーションから電話番号へ発信すると、クラウドはそれをユーザー = 電話の形式で、電話番号 @CFQDN; ユーザー = 電話として Expressway へ送信します。 ルーティング ヘッダー内の CFQDN が、Expressway から Cisco Unified Communications Manager へ到達するまでのパスを決定します。 Cisco Unified Communications Manager は、 ユーザー = 電話の形式と、CFQDN をドメインとして承認します。

  • Cisco Unified Communications Manager におけるメールは、Cisco Webex クラウド 内のメールアドレス (Active Directory またはその他のソースから同期されたもの) と完全に一致する必要があります。

  • ディレクトリ URI は、組織で確認されたドメインすべてと一致する必要があります。

  • コーデックの設定を確認してください。 コーデックの構成についての詳細は、次のドキュメント を参照してください。

    Webex サービスは次のコーデックをサポートしています。

    • 音声—G.711、G.722、AAC-LD

    • ビデオ—H.264


    ユーザーが SIP デバイスから Webex ミーティング、パーソナル会議室ミーティング、Cisco Webex Teams ミーティングに参加する時 G.729 をサポートします。 Cisco Webex Teams から SIP デバイスまたはブリッジへ 1:1 でダイヤルする時 G.729 をサポートしません。

  • 影響を受けるユーザーにおける、ホームの Cisco Unified Communications Manager クラスタにて、[システム] > [エンタープライズ パラメータ]を選択します。そして、[クラスタ全体のドメイン設定 (Clusterwide Domain Configuration)] にて、完全修飾ドメイン名 (FQDN) の設定を確認します。 使用した FQDN 値は、以下のガイドラインに従う必要があります:

    FQDN ガイドライン

    説明と例

    複数クラスター

    エントリは、ハイブリッド通話の各クラスターについて固有である必要があります—たとえば、cluster1.example.comcluster2.example.com などです。

    ワイルドカードなし

    *.example.com または example*.com のようなワイルドカードをもつエントリを使用してはいけません。

    ハイブリッド通話の最初の FQDN エントリ

    複数エントリのリストでは、Cisco Webex クラウドはハイブリッド通話の左側の最初のエントリを使用し、最初のエントリにはワイルドカードを含むことはできません。

    左から右に、次の 3 つの FQDN エントリの例を参照してください (ハイブリッド通話の最初の 1 個)。 cluster1.example.com *.example.com example*.com

    Expressway-E とは異なる

    Expressway-E システム、DNS、およびドメイン名とは異なっている必要があります。 そうしないと、Expressway-E が、ルート ヘッダをストリップします。

    ハイブリッド通話の新規エントリ

    Unified CM で現在お使いの FQDN エントリー Unified CM が上記にリストされている必要条件を満たさない場合、新しいエレメントをハイブリッド通話のクラスター FQDN の設定の初めに追加することができます。ハイブリッド コールの。

    たとえば、Cisco Unified Communications Manager における既存の FQDN が *.example.com *.example.org である場合、固有で、ワイルドカード以外のエントリをフィールドの最初に追加します。 cluster1.example.com *.example.com *.example.org」