Webex から会社に発信しても会社側で着信音が鳴らない場合は、このチェックリストのポイントを参照して構成を再確認してください。

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

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

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

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

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

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

• 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 を入力することができます。

• Expressway-E からクラウドへの通話が失敗し、手動証明書管理方法を使用している場合は、 Webex ルート CA 証明書の更新 の手順に従って、できるだけ早く IdenTrust 証明書を Expressway デバイスにアップロードしてください。

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

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

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

  • SIP INVITEが届かない場合、または設定済みのDNSゾーンと一致しない場合は、通話経路をたどってUnified Communications Managerにアクセスします。このステップを行うことで、通話がどこで失敗しているか、または失われているかがわかります。

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

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

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

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

• Unified Communications Manager 内のメールは、Webex クラウド内のメール（Active Directory またはその他のソースから同期されたもの）と完全に一致している必要があります。

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

• コーデックの設定を確認してください。

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

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

  • ビデオ—H.264

  当社は、SIPデバイスからWebexミーティング、パーソナルルームミーティング、またはWebexアプリミーティングに参加する際に、G.729をサポートしています。ダイヤルにはG.729をサポートしていません 1:1 WebexアプリからSIPデバイスまたはブリッジへ。

• 影響を受けるユーザーのホーム Unified Communications Manager クラスタで、 システムを選択します。 > エンタープライズパラメータ; クラスター全体のドメイン構成で、クラスターの完全修飾ドメイン名 (FQDN) 設定を確認してください。使用した FQDN 値は、以下のガイドラインに従う必要があります：

  FQDN ガイドライン	説明と例
  複数クラスター	エントリは、ハイブリッド呼び出しを使用する各クラスターごとに一意である必要があります。たとえば、 cluster1.example.com、 cluster2.example.comなどです。
  ワイルドカードなし	*.example.com または example*.com のようなワイルドカードをもつエントリを使用しないでください。
  ハイブリッド通話の最初の FQDN エントリ	複数のエントリのリストでは、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"