相互 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」を入力できます。

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

• 既存の 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 です。

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

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

• コーデックの設定を確認します。

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

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

  • ビデオ—H.264

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

• 影響を受けるユーザーにおける、ホームの Cisco Unified Communications Manager クラスタにて、[システム] > [エンタープライズ パラメータ]を選択します。そして、[クラスタ全体のドメイン設定 (Clusterwide Domain Configuration)] にて、完全修飾ドメイン名 (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 エントリが上記の要件を満たさない場合、新しい要素をハイブリッド通話のクラスター FQDN 設定の最初に追加できます。 たとえば、Cisco Unified Communications Manager における既存の FQDN が *.example.com *.example.org である場合、固有で、ワイルドカード以外のエントリをフィールドの最初に追加します。 「cluster1.example.com *.example.com *.example.org」