Cisco Webex ハイブリッド コール サービス接続のトラブルシューティング ガイド

概要

このドキュメントでは、既存の Cisco 呼制御インフラストラクチャから Cisco Collaboration Cloud に接続して相互の連携を可能にする Cisco Webex ハイブリッド コール サービス接続のソリューションについて説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Cisco Webex オファーの知識
• Expressway ソリューション（B2B）の知識
• Cisco Unified Communications Manager（Unified CM）および Expressway との統合の知識
• Unified CM 10.5(2) SU5以降。
• Expressway（B2B）バージョン X8.7.1 以降（X8.9.1 を推奨）
• Expressway（コネクタホスト）：現在サポートされているバージョンについては、「Expressway Connector Host Support for Cisco Webex Hybrid Services」を参照してください

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• Cisco Unified Communications Manager
• Expressway
• Webex for Windows
• Mac用WebEx
• Webexfor iOS
• Webex for Android
• シスコ コラボレーション エンドポイント
• コラボレーション デスク エンドポイント
• IP フォン
• ソフトウェア クライアント
  
  

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

このソリューションには、次の機能があります。

• Webexアプリを音声およびビデオ通話のモバイルソフトクライアントとして使用する
• アプリを使用してオフィスにいる場合とまったく同様に任意の場所から通話を発着信
• Webex、Cisco Jabber、またはそのデスクフォンを使用して通話を発信できます。使用するオプションを心配する必要はありません
• オンプレミスの電話機で通話履歴をロック解除し、その履歴をWebexに統合

このガイドでは、ハイブリッド コール サービス接続に固有の問題について説明します。ハイブリッドコールサービス接続は、モバイルおよびリモートアクセスやBusiness to Business(B2B)コールなどの他のソリューションと同じExpressway E & Cペアで実行されるため、他のソリューションの問題がハイブリッドコールサービス接続に影響する可能性があります。コール サービス接続での使用を目的として Expressway ペアを導入しているお客様やパートナーは、ハイブリッド コール サービス接続の導入を試みる前に、必ず『Cisco VCS Expressway および VCS Control 基本設定ガイド』を参照してください。このトラブルシューティング ガイドでは、付録 3 と 4 の両方で、Expressway の設計とともにファイアウォール/NAT に関する考慮事項について説明します。 このドキュメントに十分目を通してください。また、このドキュメントでは、Expressway コネクタ ホストとハイブリッド コール サービスのアクティベーションが完了していることを前提としています。 

コールのセットアップの問題

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

ハイブリッド コール サービス接続では、Cisco Webex と Expressway-E 間の認証に相互 Transport Layer Security（TLS）が使用されます。そのため、Expressway-E と Cisco Webex の両方が、互いに提示する証明書を確認し検査します。Expresswayサーバの新規導入時には相互TLSの問題が非常に多く、Hybrid Call Service Connectなどのソリューションを有効にしているため、このセクションではExpresswayとCisco Webexの間の証明書ベースの問題をトラブルシューティングする際説明します。

Expressway-E は何を確認するか。

• Cisco Webex 証明書は、Expressway-E の信頼済み CA リストに記載されているパブリック CA によって署名されたか。
• callservice.ciscospark.comは、Cisco Webex証明書の[Subject Alternate Name]フィールドに存在しますか。

Cisco Webex は何を確認するか。

• Expressway-E証明書は、Webexが信頼するパブリックCAのいずれかによって署名されていますか。（Cisco Webex の信頼済み CA リスト）
• Expressway-Eが公開署名付き証明書を使用していない場合、Expressway証明書は、Cisco Webex Control Hub(https://admin.ciscospark.com)にアップロードされたルート証明書および中間証明書と一緒にありますか。

これは図のように説明されます。

相互 TLS のトラブルシューティングに役立つヒント

1.相互TLSハンドシェイクのデコード

デフォルトでは、Wireshark は SIP TLS トラフィックをポート 5061 としてマークします。つまり、ポート5062で発生する（相互の）TLSハンドシェイクを分析する場合、Wiresharkはトラフィックを正しくデコードする方法を認識しません。ポート 5062 経由で発生している相互 TLS ハンドシェイクの例を次の図に示します。

ご覧のように、Wireshark でのデフォルト設定ではハンドシェイクはこのようになります。パケット番号 175 は、Expressway から Cisco Webex に送信される証明書です。ただし、復号化しようとするトラフィックがなければそのことを判断できません。2 つの方法を使用してこのトラフィックを復号化でき、証明書の情報や発生するエラー メッセージをもっと簡単に確認できます。

1a.ストリームを SSL として復号化します。

a.相互TLSハンドシェイクを分析すると、最初にキャプチャをtcp.port==5062でフィルタします。その後、ストリーム内の最初のパケットを右クリックし、Decode As...を選択します。 図に示すように

b.[復号化（Decode As...）] オプションを選択するとリストが表示され、選択したストリームの復号化方法を選択できます。リストから[SSL]を選択し、[Apply]をクリックしてウィンドウを閉じます。この時点では、図のようにストリーム全体で、ハンドシェイクの時点で交換される証明書とエラー メッセージを示しています。

1b.SIP TLS ポートを調整します。

Wireshark の設定で SIP TLS ポートを 5062 に調整するときは、ハンドシェイクに関連するすべての詳細を表示できます。これには証明書も含まれます。この変更を加えるには次の操作を行います。

• Wireshark を開きます。
• [編集（Edit）] > [設定（Preferences）] に移動します。
• プロトコルを展開し、[SIP] を選択します。
• SIP TLS ポートを 5062 に設定し、[適用（Apply）] をクリックします。
• 図に示すように、解析が完了したら、値を5061に戻します。

ここで同じキャプチャを分析すると、パケット 169 ～ 175 が復号化されていることがわかります。パケット 175 は Expressway-E 証明書を示しており、パケットをドリルダウンすると、図のようにすべての証明書の詳細を表示できます。

2. Wiresharkフィルタリング

パケット キャプチャを分析するときは、特定のキャプチャで観察されるパケットの量が膨大になり、目標を見失いがちです。Wireshark でフィルタ処理を行って目的のトラフィックのみを表示できるように、どのようなトラフィック タイプが最も必要かを理解しておくことが重要です。相互 TLS ハンドシェイクに関する詳細情報を取得するためによく使用する Wireshark フィルタを次に示します。

• tcp ポート = = 5062
• ssl && tcp.port==5062
• ssl.handshake.certificate && tcp.port==5062

3. Pcapからの証明書の抽出

時々、証明書（サーバ、ルート、または中間）のコピーを取得する必要がある場合があります。 証明書をどこで検索すればよいかがわからない場合は、パケット キャプチャから直接抽出できます。相互 TLS ハンドシェイクで提示される Cisco Webex 証明書を抽出する方法の手順を次に説明します。

1. ssl.handshake.certificate && tcp.port==5062 を使用してパケット キャプチャをフィルタ処理します。
2. Webex サーバ アドレスを送信元とし、証明書が [情報（Info）] セクションに出力されているパケットを見つけます。
3. パケットの詳細で、[Secure Socket Layer] > [TLS Certificate] > [Handshake Protocol] > [Certificates]を展開します。

   注：チェーンの一番下/最後の証明書はルート CA です。

4. 目的の証明書を右クリックし、図のように [選択したパケット バイトをエクスポート（Export Selected Packet Bytes...）] を選択します。

5.ファイルを.cerとして保存します。

6.図に示すように、保存したファイルをダブルクリックして証明書を開きます。

4. Expresswayのログレベルを調整する

2 つのロギング モジュールを Expressway で使用できます。これらは、証明書を分析する際に Expressway でどのようなロジックが実行されているのかについて理解を深めるのに役立ちます。

• developer.ssl
• developer.zone.zonemg
  
  

デフォルトでは、これらのロギング モジュールは INFO レベルに設定されています。DEBUG レベルに設定すると、実行される証明書のインスペクションについての情報や、どのゾーン トラフィックがマッピングされるのかがわかるようになります。これらの機能はどちらもハイブリッド コール サービスに関連するものです。 

Cisco Webex のサーバ証明書の SAN インスペクションを実行する Expressway-E の例です。

2017-09-22T11:11:19.485-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,485" Module="developer.ssl" Level="INFO" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1974)" Method="::ttssl_continueHandshake" Thread="0x7f576cbee700":  Detail="Handshake in progress" Reason="want read/write"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1960)" Method="::ttssl_continueHandshake" Thread="0x7f576cbee700":  Detail="Handshake succeeded"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1629)" Method="::TTSSL_retrieveCommonName" Thread="0x7f576cbee700":  Detail="Found common name in peer certificate" CommonName="l2sip-cfa-01.ciscospark.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="l2sip-cfa-01.ciscospark.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="l2sip-cfa-01.wbx2.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="l2sip-cfa-01-web.wbx2.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="l2sip-cfa-web.wbx2.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="callservice.ciscospark.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="callservice.call.ciscospark.com"

Expressway-EがMTLS接続をCisco WebexハイブリッドDNSゾーンにマッピングする例：

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(1226)" Method="ZoneManager::getDNSZoneByTLSVerifySubjectName" Thread="0x7f577f0a0700":  this="0x56408ff81220" getDNSZoneByTLSVerifySubjectName classified subject name callservice.ciscospark.com into DNS zone Hybrid Call Services DNS
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(1183)" Method="ZoneManager::getDNSZoneByTLSVerifySubjectNameList" Thread="0x7f577f0a0700":  this="0x56408ff81220"  Detail="Searched for DNS Zones by Subject Name" Found="True" Candidates="l2sip-cfa-01.ciscospark.coml2sip-cfa-01.ciscospark.coml2sip-cfa-01.wbx2.coml2sip-cfa-01-web.wbx2.coml2sip-cfa-web.wbx2.comcallservice.ciscospark.com" MatchedZone="Hybrid Call Services DNS" MatchedIdentity="callservice.ciscospark.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(1054)" Method="ZoneManager::getZoneByIdentities" Thread="0x7f577f0a0700":  this="0x56408ff81220"  Detail="getZoneByIdentities, match complete" Identitites="{CN: l2sip-cfa-01.ciscospark.com, Alt-DNS: l2sip-cfa-01.ciscospark.com, Alt-DNS: l2sip-cfa-01.wbx2.com, Alt-DNS: l2sip-cfa-01-web.wbx2.com, Alt-DNS: l2sip-cfa-web.wbx2.com, Alt-DNS: callservice.ciscospark.com, Alt-DNS: callservice.call.ciscospark.com, Alt-DNS: l2sip-a-Webexcall.ciscospark.com, Alt-DNS: l2sip-prod-11-dfw-public.wbx2.com, Alt-DNS: l2sip-prod-12-dfw-public.wbx2.com, Alt-DNS: l2sip-l2sipproda1-294-riad-public.wbx2.com, Alt-DNS: l2sip-l2sipproda1-817-riad-public.wbx2.com, Alt-DNS: l2sip-l2sip-prod-wpsjc-web.ciscospark.com, Alt-DNS: l2sip-l2sip-prod-wpsjc-web.wbx2.com, Alt-DNS: l2sip-l2sip-prod-wpdfw-web.ciscospark.com, Alt-DNS: l2sip-l2sip-prod-wpdfw-web.wbx2.com, Alt-DNS: l2sip-cfa-02.wbx2.com, Alt-DNS: Webexcmr-wpa.ciscospark.com, Alt-DNS: Webexcmr-wpb.ciscospark.com, Alt-DNS: Webexcmr-wpc.ciscospark.com, Alt-DNS: l2sip-wpa-01.wbx2.com, Alt-DNS: l2sip-wpa-02.wbx2.com, Alt-DNS: l2sip-wpb-01.wbx2.com, Alt-DNS: l2sip-wpb-02.wbx2.com, Alt-DNS: l2sip-wpc-01.wbx2.com, Alt-DNS: l2sip-wpc-02.wbx2.com}" MatchMechanism="DNSZoneMatch" MatchedZone="Hybrid Call Services DNS"

Expressway-E と Cisco Webex 間での相互 TLS の障害に関連してよく発生する問題を次のリストに示します。 

問題1: Expressway-EがCisco Webex証明書に署名した認証局(CA)を信頼しない

Expressway-E と直接通信する Cisco Webex サーバのことを、L2SIP サーバと呼びます。このL2SIPサーバは、Hydant SSL ICA G2という共通名で中間サーバによって署名されます。図に示すように、中間サーバはQuoVadis Root CA 2という共通名のルート認証局によって署名されます。

注：この仕組みは変更される場合があります。

Expressway の診断の観点からこのトラフィックを分析するため、最初のステップとして TCP Connecting を検索します。TCP Connecting を検索したら、Dst-port=5062 という値を探します。ログ内で、この接続が試行され確立された領域を特定したら、TLS ハンドシェイクを探すことができます。これは通常、進行中のハンドシェイクを示すログ エントリによって示されます。

2017-09-20T10:49:18.427-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:49:18,426" Module="developer.ssl" Level="INFO" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1974)" Method="::ttssl_continueHandshake" Thread="0x7f29ddefa700":  Detail="Handshake in progress" Reason="want read/write"

Expressway-E が、Cisco Webex による署名の証明書を信頼していない場合は、ハンドシェイク完了直後に Expressway-E が証明書を拒否している可能性があると予想できます。このことは、Expressway-E ロギングにある次のログ エントリで特定できます。 

2017-09-20T10:49:18.724-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.73" Src-port="58531" Dst-ip="172.16.2.2" Dst-port="5062" Detail="self signed certificate in certificate chain" Protocol="TLS" Level="1" UTCTime="2017-09-20 14:49:18,724"
2017-09-20T10:49:18.724-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:49:18,724" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)" Method="::TTSSLErrorOutput" Thread="0x7f29ddefa700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="-1" error="1" bServer="true" localAddress="['IPv4''TCP''172.16.2.2:5062']" remoteAddress="['IPv4''TCP''146.20.193.73:58531']" ssl_error_reason="error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed"
2017-09-20T10:49:18.724-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:49:18,724" Module="network.tcp" Level="DEBUG": Src-ip="146.20.193.73" Src-port="58531" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="self signed certificate in certificate chain"

Expresswayのエラーメッセージは、証明書チェーン内の自己署名証明書を参照しているため、やや誤った可能性があります。Wiresharkを使用すると、交換を詳しく見ることができます。Wiresharkパケットキャプチャ分析の観点から見ると、Webex環境がその証明書を提示した後、Expresswayが振り返り、図に示すように不明なCAエラーを含む証明書で拒否されていることがわかります。

ソリューション：

この状況を解決するには、Expressway-E が Cisco Webex の認証局を信頼するようにする必要があります。これらの証明書を単純に Wireshark のトレースから抽出して、Expressway 上の信頼済み CA 証明書ストアにアップロードすることもできますが、Expressway ではもっと簡単な方法が提供されています。

• Expressway-E にログインします。
• [Applications] > [Cloud Certificate management]に移動します
• 図のように、[証明書を取得（Get Certificatesoption）] オプションを選択します。

この時点で、Cisco Webex の証明書の認証局が Expressway-E の信頼済み CA ストアにアップロードされます（[メンテナンス（Maintenance）] > [セキュリティ（Security）] > [信頼済み CA 証明書（Trusted CA certificate）]）。

問題 2： Expressway-E Cisco Webex ハイブリッド DNS ゾーンの TLS サブジェクト検証名の名前が正しくない 

相互 TLS ハンドシェイクの一部として、ハイブリッド コール サービス接続で TLS 検証が使用されます。つまり、ExpresswayはCisco Webex CA証明書を信頼するだけでなく、提示された証明書のサブジェクト代替名(SAN)フィールドをチェックして証明書を検証し、callservice.ciscospark.comなどの値が存在することを確認します。この値が存在しない場合、着信コールは失敗します。 

この特定のシナリオでは、Cisco WebexサーバからExpressway-Eに証明書が提示されます。実際には、証明書には 25 の異なる SAN が存在します。Expressway-Eがcallservice.ciscospark.com SANの証明書をチェックするが、見つからない場合を検討します。この条件が満たされると、診断ログ内で次のようなエラーを見つけることができます。

2017-09-20T11:17:42.701-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.45" Src-port="46049" Dst-ip="172.16.2.2" Dst-port="5062" Detail="Peer's TLS certificate identity was unacceptable" Protocol="TLS" Level="1" UTCTime="2017-09-20 15:17:42,700"
2017-09-20T11:17:42.701-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 15:17:42,700" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="46049" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Peer's TLS certificate identity was unacceptable"

Wireshark を使用してこの証明書ハンドシェイクを分析すると、図のように、Cisco Webex が自身の証明書を提示した後ですぐに、Expressway が接続を RST していることがわかります。

この値の設定を確認するには、ソリューション用に設定された Webex ハイブリッド DNS ゾーンに移動します。Expressway-E の xConfiguration が存在すれば、「ゾーン設定（Zone configuration）」セクションを探して TLS 検証サブジェクト名がどのように設定されたかを調べることができます。xConfiguration では、ゾーンが「ゾーン 1」を先頭に並んでいることに注意してください。前述のとおりに分析した問題のある環境の xConfiguration を次に示します。

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Mode: "On"
*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Subject Name: "calllservice.ciscospark.com"

この例で示すように、[TLS Verify Subject Name]は、callservice.ciscospark.comではなくcalllservice.ciscospark.comに設定されています。（追加の「l」に注意してください）。

ソリューション：

この問題を解決するには 、TLS 検証サブジェクト名を変更する必要があります。

• Expressway-E にログインします。
• [設定（Configuration）] > [ゾーン（Zones）] > [ゾーン（Zones）] に移動します。
• [Webex ハイブリッド サービス DNS ゾーン（Webex Hybrid Services DNS Zone）] を選択します。
• TLS検証サブジェクト名をcallservice.ciscospark.comに設定します
• [保存（Save）] を選択します。

注：ロギングの基本的な動作については、を参照してください。この項では、Expressway による証明書の検証と Webex ハイブリッド DNS ゾーンへのマッピングを示しています。

注：Expresswayコードx12.5以降では、新しい「Webex」ゾーンがリリースされています。このWebexゾーンは、Webexへの通信に必要なゾーンの設定を事前に入力します。つまり、TLSサブジェクト検証モードとTLS検証サブジェクト名を設定する必要がなくなります。設定を簡素化するには、Expresswayコードのx12.5以降を実行している場合は、Webexゾーンを利用することをお勧めします。 

問題 3： Expressway-E が Cisco Webex に完全な証明書チェーンを送信しない

相互 TLS ハンドシェイクの一部として、Cisco Webex は Expressway-E 証明書を信頼する必要があります。Cisco Webex には、自身が信頼しているパブリック CA の全リストがあります。通常は、Expressway-E 証明書が、Cisco Webex がサポートしているパブリック CA によって署名されていれば、TLS ハンドシェイクは成功します。設計上、Expressway-Eは、パブリックCAによって署名されているにもかかわらず、TLSハンドシェイク中にのみ証明書を送信します。証明書の完全なチェーン（ルートおよび中間）を送信するには、これらの証明書をExpressway-E自体の信頼できるCA証明書ストアに追加する必要があります。

この条件が満たされていない場合、Cisco Webex は Expressway-E 証明書を拒否します。この問題に適合する状況をトラブルシューティングするときは、Expressway-E の診断ログと tcpdump を使用できます。Expressway-E の診断ログを分析すると、次のようなエラーが見つかります。

2017-09-19T11:12:09.721-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.45" Src-port="33441" Dst-ip="172.16.2.2" Dst-port="5062" Detail="sslv3 alert certificate unknown" Protocol="TLS" Level="1" UTCTime="2017-09-19 15:12:09,721"
2017-09-19T11:12:09.721-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 15:12:09,721" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)" Method="::TTSSLErrorOutput" Thread="0x7fc67c6ec700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="0" error="1" bServer="true" localAddress="['IPv4''TCP''172.16.2.2:5062']" remoteAddress="['IPv4''TCP''146.20.193.45:33441']" ssl_error_reason="error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown"
2017-09-19T11:12:09.721-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 15:12:09,721" Module="network.tcp" Level="DEBUG": Src-ip="146.20.193.45" Src-port="33441" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

これを Wireshark の観点から分析すると、Expressway-E が自身の証明書を提示していることがわかります。パケットを展開すると、サーバ証明書しか送信されていないことがわかります。図に示すように、その後、Cisco Webex は不明な CA エラー メッセージでこの TLS ハンドシェイクを拒否します。

ソリューション：

このシナリオの問題に対処するためには、Expressway-E 証明書の署名に関与している中間 CA とルート CA を信頼済み CA 証明書ストアにアップロードする必要があります。

ステップ 1： Expressway-E にログインします。
ステップ 2： [メンテナンス（Maintenance）] > [セキュリティ（Security）] > [信頼済み CA 証明書（Trusted CA certificate）] に移動します。
ステップ 3： UI の下部近くにある [アップロード（Upload）] メニューで、[ファイルを選択（Choose File）] を選択します。
ステップ 4： Expressway-E の署名に関与した CA 証明書を選択します。
ステップ 5： [CA 証明書の追加（Append CA certificate）] を選択します。
ステップ 6： Expressway-E 証明書の署名に関与したすべての CA 証明書（中間、ルート）について手順を繰り返します。
ステップ 7： [CA 証明書の追加（Append CA certificate）] を選択します。

この手順が完了すると、Expressway-E サーバ証明書の署名に関与した証明書の完全なチェーンがキー交換に含まれることがわかります。Wireshark でパケット キャプチャを分析した場合の表示の例を次に示します。

問題 4： ファイアウォールによって相互 TLS ハンドシェイクが終了する

Expresswayソリューションは通常、ファイアウォールとインターフェイスします。多くの場合、ソリューションのインライン ファイアウォールでは何らかのタイプのアプリケーション層インスペクションが実行されます。多くの場合、Expresswayソリューションでは、ファイアウォールでアプリケーション層インスペクションが実行されると、望ましくない結果が管理者に表示されます。この特定の問題は、どのような場合にファイアウォールのアプリケーション層インスペクションによって接続が突然終了するのかを明らかにするのに役立ちます。

Expressway の診断ログを使用して、試行された相互 TLS ハンドシェイクを探すことができます。このハンドシェイクは、前述のように、ポート 5062 経由で TCP 接続が確立されたすぐ後に行われます。このシナリオでは、ファイアウォールによって接続が終了すると、次のエラーが診断ログ内に表示されます。

Thread="0x7f6496669700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="-1" error="5" bServer="false" localAddress="['IPv4''TCP''172.17.31.10:28351']"
2017-06-13T13:31:38.760-05:00 vcse tvcs: Event="Outbound TLS Negotiation Error" Service="SIP" Src-ip="172.17.31.10" Src-port="28351" Dst-ip="198.101.251.5" Dst-port="5062" Detail="No SSL error available, probably remote disconnect" Protocol="TLS" Common-name="callservice.ciscospark.com" Level="1" UTCTime="2017-06-13 18:31:38,758"
2017-06-13T13:31:38.760-05:00 vcse tvcs: UTCTime="2017-06-13 18:31:38,758" Module="network.tcp" Level="DEBUG":  Src-ip="172.17.31.10" Src-port="28351" Dst-ip="198.101.251.5" Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

パケット キャプチャの観点から見た場合、Expressway-E が自身の証明書を Cisco Webex に提示していることがわかります。図に示すように、TCP RST は Cisco Webex の方向から来ています。 

一見すると、Expressway-E 証明書に問題があるように見えます。この問題をトラブルシューティングするには、最初に次の問いへの答えを調べる必要があります。

• Expressway-E が、Cisco Webex が信頼するパブリック CA によって署名されているか。
• Expressway-E証明書およびExpressway-E証明書の署名に関係する証明書は、Cisco Webex Control Hub(https://admin.ciscospark.com)に手動でアップロードされますか。 

こうした特定の条件では、Cisco Webex Control Hub を使用して Expressway-E を管理することは解決策になりませんでした。つまり、Expressway-E 証明書を、Cisco Webex が信頼するパブリック CA によって署名する必要があります。Wireshark のキャプチャで証明書パケットを選択すると（前の図を参照）、証明書がパブリック CA によって署名され、完全なチェーンが Cisco Webex に送信されたことを確認できます。したがって、問題は Expressway-E 証明書には関連していません。

この時点でさらに分離を必要とする場合は、ファイアウォールの外部インターフェイスからパケット キャプチャを取り除くことができます。ただし、診断ログに SSL エラーが欠けていることは重要なデータ ポイントになります。前述の「問題 3」から、Cisco Webex が Expressway-E 証明書を信頼していない場合は、必ず何らかのタイプの SSL 切断理由が示されます。この状態では、使用できる SSL エラーはありませんでした。

注：仮にファイアウォールの外部インターフェイスからパケット キャプチャを取得した場合、Cisco Webex 環境から着信する TCP RST を確認できなくなります。

解決方法

この特定のソリューションについては、パートナーまたはお客様としてセキュリティ チームに頼ることが必要になります。チームでは、Expressway ソリューションで何らかの種類のアプリケーション層インスペクションを使用していないかを調べる必要があり、使用している場合は無効にする必要があります。『VCS Control および Expressway 導入ガイド』の「付録 4」では、お客様がこの機能をオフにすることを勧める理由について説明しています。

問題 5： Expressway-E がパブリック CA によって署名されているが、Cisco Webex Control Hub に代替証明書がロードされている

この特定の状況は、多くの場合 Expressway ソリューションを新規に導入して、最初に Expressway-E 証明書をパブリック CA によって署名していないときに生じます。このシナリオでは、相互 TLS のネゴシエーションを正常に完了できるように、Expressway-E サーバ証明書（内部的に署名済み）を Cisco Webex Control Hub にアップロードします。その後、最終的に Expressway-E 証明書をパブリック CA によって署名しますが、Cisco Webex Control Hub からサーバ証明書を削除するのを忘れてしまいます。証明書が Cisco Webex Control Hub にアップロードされると、その証明書は、Expressway が TLS ハンドシェイク中に提示する証明書およびチェーンよりも優先されるので注意してください。

Expressway-E診断ロギングの観点からは、この問題は、Cisco WebexがExpressway-E証明書を信頼しない場合に発生するログシグニチャに似ている可能性があります。たとえば、Expressway-Eがチェーン全体を送信していない場合です。TLS ハンドシェイク中に Expressway-E ロギングで予期される内容の例を次に示します。

2017-09-20T10:22:13.669-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.45" Src-port="48520" Dst-ip="172.16.2.2" Dst-port="5062" Detail="sslv3 alert certificate unknown" Protocol="TLS" Level="1" UTCTime="2017-09-20 14:22:13,668"
2017-09-20T10:22:13.669-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:22:13,668" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)" Method="::TTSSLErrorOutput" Thread="0x7f4a2c16f700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="0" error="1" bServer="true" localAddress="['IPv4''TCP''172.16.2.2:5062']" remoteAddress="['IPv4''TCP''146.20.193.45:48520']" ssl_error_reason="error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown"
2017-09-20T10:22:13.669-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:22:13,668" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="48520" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

Wiresharkの観点からこれを見ると、Expressway-Eが品目175でその証明書を提示していることがわかります。数行後の品目については、図に示すように、Cisco Webex環境が証明書不明エラーで証明書を拒否します。

Expressway-E が送信する証明書パケットを選択すると、証明書の情報を展開して次のことを調べることができます。

1. Expressway-E が、Cisco Webex が信頼するパブリック CA によって署名されているか。および、

2.Expressway-E が、署名に関与した自身の完全なチェーンを含めているか。

この状況では、これら両方の条件が満たされています。つまり、Expressway-E 証明書にはまったく問題がないことになります。

解決方法

ステップ 1： Cisco Webex Control Hub にログインします。
ステップ 2： 左側のペインで [サービス（Services）] を選択します。

ステップ 3： [ハイブリッド コール（Hybrid Call）] カードで [設定（Settings）] を選択します。

ステップ 4： [コール サービス接続（Call Service Connect）] セクションまでスクロールし、[暗号化された SIP コールの証明書（Certificates for Encrypted SIP Calls）] の下で、望ましくない証明書がリストされているかどうかを調べます。望ましくない証明書がリストされている場合は、証明書の横にあるごみ箱アイコンをクリックします。

ステップ 5： [削除（Remove）] を選択します。

注：分析を行い、Webex Control Hub にアップロードされた証明書を使用していないことを確かめてから削除することが重要です。

Cisco Webex Control Hub での Expressway-E 証明書のアップロードの詳細については、『ハイブリッド コール導入ガイド』のこの項を参照してください。

問題 6： Expressway が着信コールを Cisco Webex ハイブリッド DNS ゾーンにマッピングしていない

着信 TLS マッピングは TLS 検証サブジェクト名と連携して機能し、どちらもハイブリッド コール DNS ゾーンで設定されます。このシナリオでは、x12.5より前のExpresswayで観察された問題と課題について説明します。x12以降では、「Webex」ゾーンと呼ばれる新しいゾーンタイプが実装されました。このゾーンは、Webexとの統合に必要なすべての設定を事前に入力します。x12.5を実行し、Webexハイブリッドコールを展開する場合は、ハイブリッドコールサービスドメイン(callservice.webex.com)が自動的に設定されるように、Webexゾーンの種類を使用することをお勧めします。この値は、相互TLSハンドシェイク中に提示されるWebex証明書のサブジェクト代替名(SAN)と一致し、Expresswayへの接続と着信のマッピングが成功することを許可します。 

x12.5より前のコードバージョンを使用している場合、またはWebexゾーンを使用していない場合は、次の説明に進みます。この説明は、Expresswayが着信コールをWebexハイブリッドDNSゾーンにマッピングしていない問題を識別し、修正するするする方法です。 

この機能は 3 ステップのプロセスに分かれます。

1. Expressway-E は、C isco Webex 証明書を受諾します。
2. Expressway-E は Cisco Webex 証明書を検査し、次の TLS 検証サブジェクト名に一致するサブジェクトの別名が存在するかどうかを確かめます。callservice.ciscospark.com
3. Expressway-E は、Cisco Webex ハイブリッド DNS ゾーンを経由して着信接続をマッピングします。

認証が成功しない場合は、証明書の検証が失敗したことを意味します。コールがデフォルト ゾーンに入り、Expressway-E で B2B を設定している場合は、B2B のシナリオで提供した検索ルールに従ってルーティングされます。

他のシナリオと同様に、診断ログとパケット キャプチャの両方を使用してこの障害の状況を調べ、パケット キャプチャを使用してどちら側が RST を送信しているかを調べる必要があります。試行後に確立されている TCP 接続の例を次に示します。 

2017-09-22T10:09:56.471-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 14:09:56,471" Module="network.tcp" Level="DEBUG":  Src-ip="148.62.40.52" Src-port="44205" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connecting"
2017-09-22T10:09:56.471-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 14:09:56,471" Module="network.tcp" Level="DEBUG":  Src-ip="148.62.40.52" Src-port="44205" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Established"

TCP 接続が確立されたので、続いて TLS ハンドシェイクを実行できます。ハンドシェイクが開始したすぐ後にエラーが発生していることがわかります。  

2017-09-22T10:09:57.044-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 14:09:57,044" Module="developer.ssl" Level="INFO" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1974)" Method="::ttssl_continueHandshake" Thread="0x7f044e7cc700":  Detail="Handshake in progress" Reason="want read/write"
2017-09-22T10:09:57.123-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="148.62.40.52" Src-port="44205" Dst-ip="172.16.2.2" Dst-port="5062" Detail="Peer's TLS certificate identity was unacceptable" Protocol="TLS" Level="1" UTCTime="2017-09-22 14:09:57,123"
2017-09-22T10:09:57.123-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 14:09:57,123" Module="network.tcp" Level="DEBUG":  Src-ip="148.62.40.52" Src-port="44205" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Peer's TLS certificate identity was unacceptable"

この状況を pcap の観点から見ると、次のことを詳しく把握できます。

• 誰が RST を送信しているか。
• 証明書が正しいかどうかを判断するためにどの証明書が渡されようとしているか。

この特定のキャプチャを分析すると、Expressway-E が RST を送信していることがわかります。渡される Cisco Webex 証明書を調べてみると、完全なチェーンを送信していることがわかります。さらに、診断ログのエラー メッセージから、結論として、Expressway-E が Cisco Webex のパブリック CA を信頼していないというシナリオを除外することができます。除外できないのであれば、「証明書チェーン内の自己署名証明書（self signed certificate in certificate chain）」のようなエラーが表示されます。 図に示すように、パケットの詳細を調べることができます。

Webexサーバ証明書をクリックして展開し、サブジェクト代替名(dnsName)を表示することで、callservice.ciscospark.comがリストされていることを確認できます。

[Wireshark：][証明書（Certificate）] > [拡張（Extension）] > [一般名（General Names）] > [GeneralName] > [dNSName：]callservice.ciscospark.com 

これで、Webex 証明書には問題がないことが完全に確認されます。

今度は、TLS 検証サブジェクト名が正しいことを確認できます。すでに説明したように、xConfiguration があれば、「ゾーン設定（Zone configuration）」セクションを探して TLS 検証サブジェクト名がどのように設定されたかを調べることができます。xConfiguration では、ゾーンが「ゾーン 1」を先頭に並んでいることに注意してください。前述のとおりに分析した問題のある環境の xConfiguration を次に示します。明らかに、TLS 検証サブジェクト名にもまったく問題はありません。

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Mode: "On"
*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Subject Name: "callservice.ciscospark.com"

次に調べる必要があるのは、TLS 検証着信マッピングです。ここでは、TLS 接続を Webex ハイブリッド DNS ゾーンに正しくマッピングしているかどうかを確認します。この分析には xConfiguration も利用できます。xConfiguration では、TLS 検証着信マッピングは DNS ZIP TLS Verify InboundClassification という名前になっています。この例でわかったように、値はオフに設定されています。

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify InboundClassification: "Off"
*c xConfiguration Zones Zone 6 Name: "Hybrid Call Services DNS"

この値がOffに設定されている場合、VCSがこのゾーンへの着信TLS接続をマッピングしようとするのを防ぎます。コールはデフォルトゾーンに入り、Expressway-EでBusiness-to-Businessが設定されている場合は、Business-to-Businessのシナリオに検索ルールににに従従でチェックされます。

解決方法

これに対処するには、ハイブリッドコールDNSゾーンのTLS検証着信マッピングを[オン(On)]に設定する必要があります。これを完了する手順は次のとおりです。

1. Expressway-E にログインします。
2. [設定（Configuration）] > [ゾーン（Zones）] > [ゾーン（Zones）] に移動します。
3. [ハイブリッド コール DNS ゾーン（Hybrid Call DNS Zone）] を選択します。
4. [TLS 検証着信マッピング] で、[オン（On）] を選択します。
5. [保存（Save）] を選択します。

注：ロギングのベースライン動作については、を参照してください。この項では、Expressway による証明書の検証と Webex ハイブリッド DNS ゾーンへのマッピングを示しています。

問題 7： Expressway-E でデフォルトの自己署名証明書が使用されている

ハイブリッド コール サービス接続の一部の新規導入では、Expressway-E 証明書の署名が見過ごされていたり、デフォルト サーバ証明書を使用できるという認識があったりします。Cisco Webex Control Hub ではカスタムの証明書をポータルにロードできるので（[サービス（Services）] > [設定（Settings）]（[ハイブリッド コール（Hybrid Call）] カードの下）> [アップロード（Upload）]（[暗号化されたコールの証明書（Certificates for Encrypted Calls）] カードの下））、そうしたことが可能だと考えられています。

[暗号化された SIP コールの証明書（Certificates for Encrypted SIP Calls）] という表現に注目してみると、次のように説明されています。「シスコ コラボレーションのデフォルト信頼リストから提供されている証明書を使用するか、または独自の証明書をアップロードします。独自の証明書を使用する場合は、ホスト名が検証済みのドメイン上にあることを確認してください。」 ここで重要なのは「ホスト名が検証済みのドメイン上にあることを確認する」の部分です。 

この条件に一致する問題をトラブルシューティングするときは、症状がコールの方向に依存していることに注意してください。コールがオンプレミス電話機から発信している場合は、Cisco Webex アプリの着信音が鳴らないと予想できます。また、Expressway の検索履歴からコールのトレースを試みれば、Expressway-E へのコールが成功してそこで停止することがわかります。コールが Cisco Webex アプリから発信していて、宛先がオンプレミスになっていた場合、オンプレミス電話機の着信音は鳴りません。そうした例では、Expressway-E と Expressway-C の検索履歴には何も示されません。

この特定のシナリオでは、コールはオンプレミス電話機から発信されています。Expressway-E の検索履歴を使用すると、サーバへのコールが成功したことを確認できます。この時点では、何が起きたかを判断するために診断ログを調べることができます。この分析を始めるには、最初に、TCP 接続が試行されてポート 5062 経由で確立されたかどうかを確認します。Expressway-E の診断ログで「TCP Connecting」を探し、「Dst-port=5062」というタグのある行項目を検索することで、接続が確立されているかどうかを判断できます。 

2017-09-26T08:18:08.428-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,426" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="59720" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connecting"
2017-09-26T08:18:08.428-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,426" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="59720" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Established"

TCP 接続が確立されていることを確認したので、直後に行われる相互 TLS ハンドシェイクを分析できます。次のスニペットからわかるように、ハンドシェイクは失敗していて証明書は不明になっています（Detail="sslv3 alert certificate unknown"）。

2017-09-26T08:18:08.441-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,441" Module="developer.ssl" Level="INFO" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1974)" Method="::ttssl_continueHandshake" Thread="0x7f930adab700":  Detail="Handshake in progress" Reason="want read/write"
2017-09-26T08:18:08.455-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.45" Src-port="59720" Dst-ip="172.16.2.2" Dst-port="5062" Detail="sslv3 alert certificate unknown" Protocol="TLS" Level="1" UTCTime="2017-09-26 12:18:08,455"
2017-09-26T08:18:08.455-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,455" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1997)" Method="::ttssl_continueHandshake" Thread="0x7f930adab700":  Detail="Handshake Failed" Reason="want error ssl"
2017-09-26T08:18:08.455-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,455" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)" Method="::TTSSLErrorOutput" Thread="0x7f930adab700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="0" error="1" bServer="true" localAddress="['IPv4''TCP''172.16.2.2:5062']" remoteAddress="['IPv4''TCP''146.20.193.45:59720']" ssl_error_reason="error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown"

2017-09-26T08:18:08.455-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,455" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="59720" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

Expressway-E で提供されたパケット キャプチャを詳しく調べてみると、図のように、証明書不明エラーが Cisco Webex の方向から発生していることがわかります。

Expressway-E からのデフォルト サーバ証明書を調べてみると、「共通名（Common Name）」と「サブジェクトの別名（Subject Alternate Names）」に「検証済みドメイン（Verified Domain）」（rtp.ciscotac.net）が含まれていないことがわかります。 これで、図に示すように、何がこの問題の原因なのかについて証拠が得られます。 

この時点で、Expressway-E サーバ証明書をパブリック CA または内部 CA によって署名する必要があると判断しました。 

解決方法

この問題を解決するには、2 つのオプションを選択できます。

1. Expressway-E 証明書が、Cisco Webex が信頼するパブリック CA によって署名されるようにします。
   
   1. Expressway にログインします。
   2. [メンテナンス（Maintenance）] > [セキュリティ（Security）] > [サーバ証明書（Server certificate）] に移動します。
   3. [CSR の作成（Generate CSR）] を選択します。
   4. 必要な証明書情報を入力し、[追加の別名（Additional alternative names）] フィールドに、Webex Control Hub にリストされている [検証済みドメイン（Verified Domain）] が含まれていることを確認します。
   5. [Generate CSR] をクリックします。
   6. サードパーティのパブリック CA に署名用の CSR を提供します。
   7. 証明書に戻り、[メンテナンス（Maintenance）] > [セキュリティ（Security）] > [サーバ証明書（Server certificates）] に移動します。
   8. [サーバ証明書ファイルを選択（Select the server certificate file）] の隣にある [新しい証明書のアップロード（Upload New Certificate）] セクションで、[ファイルを選択（Choose File）] を選択し、署名済みの証明書を選択します。
   9. [サーバ証明書データのアップロード（Upload server certificate data）] を選択します。
   10. [メンテナンス（Maintenance）] > [セキュリティ（Security）] > [信頼済み CA 証明書（Trusted CA certificate）] に移動します。
   11. [信頼済み CA 証明書が含まれているファイルを選択（Select the file containing trusted CA certificates）] の隣にある [アップロード（Upload）] セクションで、[ファイルを選択（Choose File）] を選択します。
   12. パブリック CA によって提供されるすべてのルートおよび中間 CA 証明書を選択します。
   13. [CA 証明書の追加（Append CA certificate）] を選択します。
   14. Expressway-E を再起動します。
2. Expressway-E 証明書が内部 CA によって署名されるようにし、内部 CA および Expressway-E 証明書を Cisco Webex Control Hub にアップロードします。
   
   1. Expressway にログインします。
   2. [メンテナンス（Maintenance）] > [セキュリティ（Security）] > [サーバ証明書（Server certificate）] に移動します。
   3. [CSR の作成（Generate CSR）] を選択します。
   4. 必要な証明書情報を入力し、[追加の別名（Additional alternative names）] フィールドに、Webex Control Hub にリストされている [検証済みドメイン（Verified Domain）] が含まれていることを確認します。
   5. [CSR の生成（Generate CSR）] をクリックします。
   6. サードパーティのパブリック CA に署名用の CSR を提供します。
   7. 証明書に戻り、[メンテナンス（Maintenance）] > [セキュリティ（Security）] > [サーバ証明書（Server certificates）] に移動します。
   8. [サーバ証明書ファイルを選択（Select the server certificate file）] の隣にある [新しい証明書のアップロード（Upload New Certificate）] セクションで、[ファイルを選択（Choose File）] を選択し、署名済みの証明書を選択します。
   9. [サーバ証明書データのアップロード（Upload server certificate data）] を選択します。
   10. [メンテナンス（Maintenance）] > [セキュリティ（Security）] > [信頼済み CA 証明書（Trusted CA certificate）] に移動します。
   11. [信頼済み CA 証明書が含まれているファイルを選択（Select the file containing trusted CA certificates）] の隣にある [アップロード（Upload）] セクションで、[ファイルを選択（Choose File）] を選択します。
   12. パブリック CA によって提供されるすべてのルートおよび中間 CA 証明書を選択します。
   13. [CA 証明書の追加（Append CA certificate）] を選択します。
   14. Expressway-E を再起動します。

 2a.内部 CA および Expressway-E 証明書を Cisco Webex Control Hub にアップロードします。
       1. 管理者として Cisco Webex Control Hub にログインします。
       2. [サービス] を選択します。
       3. [ハイブリッド コール サービス（Hybrid Call Service）] カードで [設定（Settings）] を選択します。
       4. [Certificates for Encrypted SIP Calls]セクションで、[Upload]を選択します。
       5. 内部 CA および Expressway-E 証明書を選択します。

インバウンド:Cisco Webex からオンプレミスへ

Cisco Webex からオンプレミスへの着信障害では、ほとんどすべての場合に同じ症状が報告されています。たとえば、「自分の Cisco Webex アプリから別の同僚のアプリに電話をかけると、同僚のアプリの着信音は鳴るがオンプレミス電話の着信音は鳴らない」などです。 このシナリオをトラブルシューティングするためには、この種のコールで発生するコールのフローとロジックの両方について理解しておくと役立ちます。

全体的なロジック フロー

1. Cisco Webex アプリの発信側がコールを開始します。
2. 着信側のアプリの着信音が鳴ります。
3. コールが Cisco Webex 環境にフォークされます。
4. Cisco Webex 環境では、顧客が Cisco Webex Control Hub で設定した SIP 宛先に基づいて DNS ルックアップを実行する必要があります。
5. Cisco Webex 環境が、ポート 5062 を介して Expressway への接続を試みます。
6. Cisco Webex 環境が、相互 TLS ハンドシェイクの実行を試みます。
7. Cisco Webex 環境が、SIP INVITE を Expressway に送信し、オンプレミス コラボレーション エンドポイント/IP フォンにまで渡されます。
8. Cisco Webex と会社が SIP ネゴシエーションを完了します。
9. Cisco Webex と会社がメディアの送受信を開始します。

コールフロー

図のように、[Cisco Webex アプリ（Cisco Webex app）] > [Cisco Webex 環境（Cisco Webex environment）] > [Expressway-E] > [Expressway-C] > [オンプレミス コラボレーション エンドポイント/IP フォン（On-Premises Collaboration Endpoint/IP Phone）] に移動します。

Webex からオンプレミス インフラストラクチャへの着信コールでよく見られるいくつかの問題を次に示します。

問題 1： Cisco Webex が Expressway-E DNS SRV/ホスト名を解決できない

Cisco Webex からオンプレミスへのコール フローについて考えるとき、Cisco Webex の最初の論理的なステップとなるのは、オンプレミスの Expressway へのコンタクト方法です。前述のように、Cisco Webex はオンプレミス Expressway への接続を試みるため、Cisco Webex Control Hub の [ハイブリッド コール サービスの設定（Hybrid Call Service Settings）] ページにリストされている設定済みの [SIP 宛先（SIP Destination）] に基づいて、SRV ルックアップを実行します。 

Expressway-E 診断ログの観点からこの状況をトラブルシューティングしようとすると、Cisco Webex からのトラフィックがまったく確認できません。TCP 接続（TCP Connecting）を検索しようとしても、Dst-port=5062 を確認できず、その後の MTLS ハンドシェイクも Cisco Webex からの SIP Invite も確認できません。 

こうした状況では、Cisco Webex Control Hub で [SIP 宛先（SIP Destination）] がどのように設定されていたかを調べる必要があります。また、ハイブリッド接続テスト ツールを利用してトラブルシューティングに役立てることもできます。ハイブリッド接続テスト ツールは、有効な DNS アドレスが存在するかどうか、Cisco Webex が SRV ルックアップで返されたポートに接続できるかどうか、および、Cisco Webex が信頼する有効な証明書がオンプレミスの Expressway に存在するかどうかをチェックします。 

1. Cisco Webex Control Hub にログインします。
2. [サービス（Services）] を選択します。
3. [ハイブリッド コール（Hybrid Call）] カードで [設定（Settings）] リンクを選択します。
4. [コール サービス接続（Call Service Connect）] セクションで、パブリック SIP の SRV アドレスの指定に使用されるドメインを [SIP 宛先（SIP Destination）] フィールドで確認します。 
5. レコードが正しく入力されている場合は、[テスト（Test）] をクリックしてレコードが有効かどうかを確かめます。
6. 下の図に示すように、明らかに、パブリック ドメインに対応する SIP SRV レコードが関連付けられていないことがわかります。 

[テスト結果を表示（View test results）] を選択すると、図のように、失敗した内容について詳細を表示できます。 

別の方法として、nslookupを使用してSRVレコードを検索することもできます。次に、SIP宛先が存在するかどうかを確認するために実行できるコマンドを示します。

C:\Users\pstojano>nslookup
> server 8.8.8.8
Default Server: google-public-dns-a.google.com
Address: 8.8.8.8
> set type=SRV
> _sips._tcp.mtls.rtp.ciscotac.net
Server: google-public-dns-a.google.com
Address: 8.8.8.8
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to google-public-dns-a.google.com timed-out

このコード ブロックでわかるように、nslookup コマンドが開始された後で、サーバがパブリック Google DNS サーバである 8.8.8.8 に設定されています。最後に、SRV レコードを検索するレコード タイプを設定しています。この時点で、検索する完全な SRV レコードを発行できます。結果として、最終的には要求がタイムアウトになります。 

解決方法

1. それらがパブリック ドメイン名のホストに使用するサイトで、Expressway-E のパブリック SIP の SRV アドレスを設定します。 
2. Expressway-E のパブリック IP アドレスに解決されるホスト名を設定します。
3. ステップ 1 で作成した SIP の SRV アドレスに使用するドメインをリストするように、SIP 宛先を設定します。
   1. Cisco Webex Control Hub にログインします。
   2. サービスの選択
   3. [ハイブリッド コール（Hybrid Call）] カードで [設定（Settings）] リンクを選択します。
   4. [コール サービス接続（Call Service Connect）] セクションで、パブリック SIP の SRV アドレスに使用されるドメインを [SIP 宛先（SIP Destination）] フィールドに入力します。 
   5. [保存（Save）] を選択します。

注：使用したい SIP SRV レコードがすでに B2B 通信に利用されている場合は、次のようにして、SIP 検出アドレスとして会社ドメインのサブドメインを Cisco Webex Control Hub で指定し、結果としてパブリック DNS SRV レコードにすることをお勧めします。

サービスとプロトコル（Service and protocol）：_sips._tcp.mtls.example.com
Priority:1
重量：10
ポート番号（Port number）：5062
Target:us-expe1.example.com

これらの推奨値は『Cisco Webex ハイブリッド設計ガイド』から直接引用したものです。

代替策

SIP SRV レコードを持っていない（作成する予定がない）場合は、代わりにサフィックスを「: 5062」とする Expressway パブリック IP アドレスをリストできます。 これにより、Webex環境はSRVルックアップを試行せず、%Expressway_Pub_IP%:5062に直接接続します(例：64.102.241.236:5062）

1. SIPの宛先を%Expressway_Pub_IP%:5062形式に設定します(例： 64.102.241.236:5062)
   1. Cisco Webex Control Hub にログインします。
   2. サービスの選択
   3. [ハイブリッド コール（Hybrid Call）] カードで [設定（Settings）] リンクを選択します。
   4. [コール サービス接続（Call Service Connect）] セクションで、[SIP 宛先（SIP Destination）] フィールドに「%Expressway_Pub_IP%:5062」と入力します。 
   5. [保存（Save）] を選択します。

設定を必要とする SIP 宛先アドレスや SRV レコードの詳細については、『Cisco Webex ハイブリッド コール サービス導入ガイド』の「組織でハイブリッド コール サービス接続を有効にする」の項、または『Cisco Webex ハイブリッド設計ガイド』を参照してください。

問題 2： ソケット障害：ポート 5062 で Expressway への着信がブロックされる

DNS 解決の完了後、Cisco Webex 環境は、DNS ルックアップ中に返された IP アドレスへのポート 5062 経由の TCP 接続を確立しようとします。この IP アドレスが、オンプレミスの Expressway-E のパブリック IP アドレスになります。Cisco Webex 環境がこの TCP 接続を確立できない場合、後続のオンプレミスへの着信コールは失敗します。この特定の状況では、他のほぼすべての Cisco Webex 着信コール障害と同じである、「オンプレミス電話機の着信音が鳴らない」という症状が現れます。

Expressway 診断ログを使用してこの問題をトラブルシューティングしても、Cisco Webex からのトラフィックはまったく確認できません。TCP 接続（TCP Connecting）を検索しようとしても、Dst-port=5062 の接続試行を確認できず、その後の MTLS ハンドシェイクも Cisco Webex からの SIP Invite も確認できません。この状況では Expressway-E 診断ログが役に立たないため、いくつかの方法で検証を行います。

1. ファイアウォールの外部インターフェイスからパケット キャプチャを取得します。
2. ポート チェック ユーティリティを利用します。
3. ハイブリッド接続テスト ツールを使用します。

ハイブリッド接続テスト ツールは Cisco Webex Control Hub に組み込まれているもので、Cisco Webex 環境からオンプレミスの Expressway への接続試行をシミュレートします。そのため、最も理想的な検証方法として使用できます。組織への TCP 接続をテストするには、次の操作を行います。

1. Cisco Webex Control Hub にログインします。
2. [サービス（Services）] を選択します。
3. [ハイブリッド コール（Hybrid Call）] カードで [設定（Settings）] リンクを選択します。
4. [コール サービス接続（Call Service Connect）] セクションで、[SIP 宛先（SIP Destination）] に入力した値が正しいことを確認します。
5. 図に示すように、[テスト（Test）] をクリックします。

  6.テストが失敗したため、[テスト結果の表示]リンクをクリックして、図に示すように詳細を確認できます。

前の図に示すように、64.102.241.236:5062 への接続を試みたときにソケット テストが失敗したことがわかります。Expressway 診断ログ/pcap に加えてこのデータも接続試行を示していないことから、ファイアウォールの ACL/NAT/ルーティングの設定を調べる十分な根拠が得られました。 

解決方法

この特定の問題については、Cisco Webex 環境やオンプレミスのコラボレーションの機器が原因ではないため、ファイアウォールの設定に注目する必要があります。インターフェイスとなるファイアウォールのタイプを予測することは必ずしもできないため、デバイスに詳しい担当者の協力を求める必要があります。問題が、ファイアウォールの ACL、NAT、またはルーティング設定のミスに関連している可能性があります。 

問題 3： ソケット障害：Expressway-E がポート 5062 をリッスンしていない

この特定の状況については、正しい診断がされていないケースが多く見られます。多くの場合、ポート 5062 経由のトラフィックがブロックされている理由として、ファイアウォールがその原因と見なされます。この特定の状況をトラブルシューティングするには、前述の「Expressway への着信でポート 5062 がブロックされる」のシナリオで紹介した手法を使用できます。ハイブリッド接続テスト ツールや、ポート接続の確認に使用する他のツールは失敗します。最初の仮説として考えられるのは、「ファイアウォールがトラフィックをブロックしている」です。ほとんどの人が、Expressway-E の診断ログを調べて、TCP 接続を確立しようとしているかどうかを判断します。ログ全体を眺めて、図に示すようなログ行項目を探します。

2017-09-19T14:01:46.462-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 18:01:46,461" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.73" Src-port="40342" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connecting"

この状況では、前述のような特定のログ エントリは存在しません。そのため、多くの人が誤った診断をして、ファイアウォールが原因だと仮定します。

パケット キャプチャが診断ログと一緒に含まれていれば、ファイアウォールが原因でないことを確認できます。次に示すのは、Expressway-E がポート 5062 経由でリッスンしていないシナリオで出現したパケット キャプチャの例です。このキャプチャは、図に示すように、適用フィルタとして tcp.port==5062 を使用してフィルタ処理したものです。 

Expressway-E から取得したパケット キャプチャからわかるように、tcp ポート 5062 経由のトラフィックはファイアウォールによってブロックされておらず、実際に着信しています。パケット番号 56 では、最初の TCP SYN パケットが到着した直後に、Expressway-E から RST が送信されていることがわかります。こうした情報から、パケットを受信している Expressway-E については問題から分離することができ、問題を Expressway-E の観点からトラブルシューティングする必要があると結論付けることができます。得られた根拠を前提として、なぜ Expressway-E がパケットを RST するのか、その理由の候補を考えてみます。この動作の原因として次の 2 つの可能性が考えられます。

1. Expressway-Eには、トラフィックをブロックしている可能性のある、ある種のファイアウォールルールが設定されています

2. Expressway-Eが相互TLSトラフィックをリッスンしていない、またはポート5062を介したトラフィックをリッスンしていない。

Expressway-E のファイアウォール機能は、[システム（System）] > [保護（Protection）] > [ファイアウォール ルール（Firewall rules）] > [設定（Configuration）] にあります。この環境でこのことを確認した時点では、ファイアウォールの設定は存在しませんでした。 

いくつかの方法で、Expressway-E がポート 5062 経由の相互 TLS トラフィックをリッスンしているかどうかを確認できます。この確認には、Web インターフェイスを使用するか、CLI をルート ユーザとして使用できます。 

Expressway のルートから、netstat-an | grep ':5062'を実行すると、次のような出力が表示されます。 

~ # netstat -an | grep ':5062'
tcp        0      0 172.16.2.2:5062         0.0.0.0:*               LISTEN  <-- Outside Interface
tcp        0      0 192.168.1.6:5062        0.0.0.0:*               LISTEN  <-- Inside Interface
tcp        0      0 127.0.0.1:5062          0.0.0.0:*               LISTEN
tcp        0      0 ::1:5062                :::*                    LISTEN

これらの情報は Expressway-E の Web インターフェイスを使用してキャプチャすることもできます。これらの情報を収集するには、次の手順を参照してください。

1. Expressway-Eにログインします

2. 「メンテナンス・ツール」>「ポートの使用」>「ローカル着信ポート」に移動します

3.タイプSIPおよびIPポート5062を検索します（図に示すように赤で強調表示）。

確認すべき内容がわかったので、現在の環境と比較できます。CLI の観点から、netstat-an | grep ':5062'の出力は次のようになります。

~ # netstat -an | grep ':5062'
tcp        0      0 127.0.0.1:5062          0.0.0.0:*               LISTEN
tcp        0      0 ::1:5062                :::*                    LISTEN
~ #

さらに、Web UI ではローカルの着信ポートの下に相互 TLS ポートが表示されません。

こうしたデータから、Expressway-E が相互 TLS トラフィックをリッスンしていないと判断できます。

解決方法

この問題を解決するには、相互 TLS モードが有効になっていることと、Expressway-E で相互 TLS ポートが 5062 に設定されていることを確認する必要があります。

1. Expressway-E にログインします。
2. [設定（Configuration）] > [プロトコル（Protocols）] > [SIP] に移動します。
3. 相互 TLS モードが [オン（On）] に設定されていることを確認します。
4. 相互 TLS ポートが [5062] に設定されていることを確認します。
5. 図に示すように、[保存（Save）] をクリックします。

問題 4： Expressway-E または C がプリロード済み SIP ルート ヘッダーをサポートしていない

ハイブリッド コール サービス接続では、コールのルーティングはルート ヘッダーに基づいて行われます。ルート ヘッダーは、ソリューションのコール サービス認識（Expressway コネクタ）部分から Cisco Webex に配信される情報に基づいて設定されます。Expressway コネクタ ホストは Unified CM に対して、コール サービスが有効になっているユーザが誰かをクエリし、それらのユーザのディレクトリ URI と、ユーザの Unified CM ホーム クラスタのクラスタ FQDN の両方を抽出します。たとえば、Alice と Bob を使用した次の例を参照してください。

Alice または Bob がコールを行うと、コールは彼らのオンプレミスの Unified CM にルーティングされます。そのため、着信側のユーザにルーティングする前に彼らの Cisco WebexRD に固定することができます。

Alice が Bob にコールした場合、コールは Alice の Unified CM ホーム クラスタの FQDN（us-cucm.example.com）にルーティングされます。 Cisco Webex が Expressway-E への着信に送信する SIP INVITE を分析すると、SIP ヘッダーの中で次の情報が見つかります。

Expresswayの観点から見ると、検索ルールは、要求URIではなくルートヘッダ(us-cucm.example.com) – を使用してコールをルーティングするように設定されます。この場合はAliceのUnified CMホームクラスタです。

こうした基本的な情報から、Expressway が誤って設定され、前述のロジックが機能しなくなるトラブルシューティングの状況を理解することができます。他のほとんどすべての着信ハイブリッド コール サービ接続のコール セットアップ障害と同じように、オンプレミス電話機で着信音が鳴らないという症状が現れます。

Expressway で診断ログを分析する前に、このコールを特定する方法について考えてみましょう。

1. SIP 要求 URI は、着信側のディレクトリ URI（Directory URI）になります。
2. [SIP FROM]フィールドは、[First Name Last Name] <sip:WebexDisplayName@subdomain.call.ciscospark.com>と表示される[発呼側]でフォーマットされます

これらの情報を使用して、着信側のディレクトリ URI、発信側の名と姓、または発信側の Cisco Webex SIP アドレスで診断ログを検索できます。この情報がない場合は、「INVITE SIP:」を検索して、Expresswayで実行されているすべてのSIPコールを検索できます。着信コールの SIP INVITE が特定されたら、SIP コール ID を探してコピーできます。この値がわかったら、後はコール ID に基づいて診断ログを検索するだけで、このコール レッグに関連するすべてのメッセージを表示できます。

また、コールが会社にたどり着くまでの距離を調べることもルーティングの問題の分離に役立ちます。前述に示した情報を Expressway-C で検索してみて、コールがそこからルーティングされたものかどうかを調べることができます。コールが Expressway-C からルーティングされている場合は、そこから調査を始める可能性が高くなります。

このシナリオでは、Expressway-C が Expressway-E から INVITE を受信したことがわかります。

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,830" Module="network.sip" Level="DEBUG": Action="Received" Local-ip="192.168.1.5" Local-port="26847" Src-ip="192.168.1.6" Src-port="7003" Msg-Hash="11449260850208794722"
SIPMSG:
|INVITE sip:jorobb@rtp.ciscotac.net SIP/2.0
Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKc81c6c4dddef7ed6be5bdce9868fb019913;proxy-call-id=a82052ef-6fd7-4506-8173-e73af6655b5d;rport
Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bKb0eba6d700dfdf761a8ad97fff3c240124;x-cisco-local-service=nettle;received=192.168.1.6;rport=43119;ingress-zone=DefaultZone
Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK6fe399bae58fb0d70c9d69b8e37e13e5912.4248943487bff4af6f649b586c7696bb;proxy-call-id=f2d15853-c81f-462f-b3e5-c08124f344a3;received=172.16.2.2;rport=25016
Via: SIP/2.0/TLS 192.168.5.66:5062;branch=z9hG4bK0f455ca79cf1b0af5637333aa5286436;received=146.20.193.45;rport=35464;ingress-zone=HybridCallServicesDNS
Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-383039-8f0d64025c04d23b6d5e1d5142db46ec;rport=52706
Call-ID: 9062bca7eca2afe71b4a225048ed5101@127.0.0.1
CSeq: 1 INVITE
Contact: <sip:192.168.1.6:5073;transport=tls>;call-type=squared
From: "pstojano test" 
     
     ;tag=872524918
To: <sip:jorobb@rtp.ciscotac.net>
Max-Forwards: 15
Route: 
     
     
Record-Route: <sip:proxy-call-id=a82052ef-6fd7-4506-8173-e73af6655b5d@192.168.1.6:7003;transport=tls;lr>
Record-Route: <sip:proxy-call-id=a82052ef-6fd7-4506-8173-e73af6655b5d@192.168.1.6:5061;transport=tls;lr>

ここで重要なのは、ルート ヘッダー（クラスタ FQDN）がまだそのままであることです。ただし、ルート ヘッダー（クラスタ FQDN） cucm.rtp.ciscotac.net に基づいて実行されている検索ロジックはありません。そうではなく、メッセージがすぐに 404 Not Found で拒否されています。

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Call Attempted" Service="SIP" Src-ip="192.168.1.6" Src-port="7003" Src-alias-type="SIP" Src-alias="sip:pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Protocol="TLS" Auth="NO" Level="1" UTCTime="2017-09-19 18:16:15,832"
2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Detail="searchtype:INVITE" Level="1" UTCTime="2017-09-19 18:16:15,834"
2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Search Completed" Reason="Not Found" Service="SIP" Src-alias-type="SIP" Src-alias="pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Detail="found:false, searchtype:INVITE, Info:Policy Response" Level="1" UTCTime="2017-09-19 18:16:15,835"
2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Call Rejected" Service="SIP" Src-ip="192.168.1.6" Src-port="7003" Src-alias-type="SIP" Src-alias="sip:pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Detail="Not Found" Protocol="TLS" Response-code="404" Level="1" UTCTime="2017-09-19 18:16:15,835"
2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,830" Module="network.sip" Level="INFO": Action="Received" Local-ip="192.168.1.5" Local-port="26847" Src-ip="192.168.1.6" Src-port="7003" Detail="Receive Request Method=INVITE, CSeq=1, Request-URI=sip:jorobb@rtp.ciscotac.net, Call-ID=9062bca7eca2afe71b4a225048ed5101@127.0.0.1, From-Tag=872524918, To-Tag=, Msg-Hash=11449260850208794722, Local-SessionID=daf7c278732bb5a557fb57925dffcbf7, Remote-SessionID=00000000000000000000000000000000"
2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,836" Module="network.sip" Level="INFO": Action="Sent" Local-ip="192.168.1.5" Local-port="26847" Dst-ip="192.168.1.6" Dst-port="7003" Detail="Sending Response Code=404, Method=INVITE, CSeq=1, To=sip:jorobb@rtp.ciscotac.net, Call-ID=9062bca7eca2afe71b4a225048ed5101@127.0.0.1, From-Tag=872524918, To-Tag=96b9a0eaf669a590, Msg-Hash=254718822158415175, Local-SessionID=00000000000000000000000000000000, Remote-SessionID=daf7c278732bb5a557fb57925dffcbf7"

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,836" Module="network.sip" Level="DEBUG": Action="Sent" Local-ip="192.168.1.5" Local-port="26847" Dst-ip="192.168.1.6" Dst-port="7003" Msg-Hash="254718822158415175"
SIPMSG:
|SIP/2.0 404 Not Found
Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKc81c6c4dddef7ed6be5bdce9868fb019913;proxy-call-id=a82052ef-6fd7-4506-8173-e73af6655b5d;received=192.168.1.6;rport=7003;ingress-zone=HybridCallServiceTraversal
Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bKb0eba6d700dfdf761a8ad97fff3c240124;x-cisco-local-service=nettle;received=192.168.1.6;rport=43119;ingress-zone=DefaultZone
Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK6fe399bae58fb0d70c9d69b8e37e13e5912.4248943487bff4af6f649b586c7696bb;proxy-call-id=f2d15853-c81f-462f-b3e5-c08124f344a3;received=172.16.2.2;rport=25016
Via: SIP/2.0/TLS 192.168.5.66:5062;branch=z9hG4bK0f455ca79cf1b0af5637333aa5286436;received=146.20.193.45;rport=35464;ingress-zone=HybridCallServicesDNS
Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-383039-8f0d64025c04d23b6d5e1d5142db46ec;rport=52706
Call-ID: 9062bca7eca2afe71b4a225048ed5101@127.0.0.1
CSeq: 1 INVITE
From: "pstojano test" 
     
     ;tag=872524918
To: <sip:jorobb@rtp.ciscotac.net>;tag=96b9a0eaf669a590
Server: TANDBERG/4135 (X8.10.2)
Warning: 399 192.168.1.5:5061 "Policy Response"
Session-ID: 00000000000000000000000000000000;remote=daf7c278732bb5a557fb57925dffcbf7
Content-Length: 0

作業シナリオと比較してみると、作業シナリオでは検索ロジックがルータのヘッダー（クラスタ FQDN）に基づいて実行されていることがわかります。

2017-09-22T13:56:02.215-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="17aa8dc7-422c-42ef-bdd9-b9750fbd0edf" Tag="8bd936da-f2ab-4412-96df-d64558f7597b" Detail="searchtype:INVITE" Level="1" UTCTime="2017-09-22 17:56:02,215"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,217" Module="network.cpl" Level="DEBUG": Remote-ip="192.168.1.6" Remote-port="7003" Detail="CPL: <routed> "
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.cpl" Level="DEBUG": Remote-ip="192.168.1.6" Remote-port="7003" Detail="CPL: <location clear="yes" url="sip:cucm.rtp.ciscotac.net;lr" diversion="" dest-url-for-message="sip:jorobb@rtp.ciscotac.net" sip-route-set="" dest-service=""> added sip:cucm.rtp.ciscotac.net;lr to location set "
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.cpl" Level="DEBUG": Remote-ip="192.168.1.6" Remote-port="7003" Detail="CPL: <proxy stop-on-busy="no" timeout="0"/> "
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'Inbound MS to CMS' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'multiway' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'WebEx Search Rule' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'ISDN Inbound' ignored due to source filtering"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'recalls into CMS' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'CEtcp-rtp12-tpdmz-118-ucmpub' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'Conference Factory' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,219" Module="network.search" Level="DEBUG": Detail="Search rule 'Inbound B2B Calling' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,219" Module="network.search" Level="DEBUG": Detail="Search rule 'Calls to Cisco Webex' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,219" Module="network.search" Level="DEBUG": Detail="Considering search rule 'as is local' towards target 'LocalZone' at priority '1' with alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.219-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,219" Module="network.search" Level="DEBUG": Detail="Considering search rule 'Hybrid Call Service Inbound Routing' towards target 'CUCM11' at priority '2' with alias 'cucm.rtp.ciscotac.net;lr'"

その後、Expressway-C がコールを Unified CM（192.168.1.21）に正しく転送していることがわかります。

2017-09-22T13:56:02.232-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,232" Module="network.sip" Level="DEBUG": Action="Sent" Local-ip="192.168.1.5" Local-port="25606" Dst-ip="192.168.1.21" Dst-port="5065" Msg-Hash="866788495063340574"
SIPMSG:
|INVITE sip:jorobb@rtp.ciscotac.net SIP/2.0
Via: SIP/2.0/TCP 192.168.1.5:5060;egress-zone=CUCM11;branch=z9hG4bK251d6daf044e635607cc13d244b9ea45138220.69ccb8de20a0e853c1313782077f77b5;proxy-call-id=17aa8dc7-422c-42ef-bdd9-b9750fbd0edf;rport
Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKba323da436b2bc288200d56d11f02d4d272;proxy-call-id=32c76cef-e73c-4911-98d0-e2d2bb6fec77;received=192.168.1.6;rport=7003;ingress-zone=HybridCallServiceTraversal
Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bK06cde3f662d53a210b5b4b11b85500c19;x-cisco-local-service=nettle;received=192.168.1.6;rport=42533;ingress-zone=DefaultZone
Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK297799f31d0785ff7449e1d7dbe3595b271.2ed90cbed5b79c6cffad9ecd84cc8337;proxy-call-id=3be87d96-d2e6-4489-b936-8f9cb5ccaa5f;received=172.16.2.2;rport=25005
Via: SIP/2.0/TLS 192.168.4.146:5062;branch=z9hG4bK043ca6360f253c6abed9b23fbeff9819;received=148.62.40.64;rport=36149;ingress-zone=HybridCallServicesDNS
Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-353038-8c648a16c2c5d7b85fa5c759d59aa190;rport=47732
Call-ID: daa1a6fa546ce76591fc464f0a50ee32@127.0.0.1
CSeq: 1 INVITE
Contact: <sip:192.168.1.6:5073;transport=tls>;call-type=squared
From: "pstojano test" <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=567490631
To: <sip:jorobb@rtp.ciscotac.net>
Max-Forwards: 14
Route: 
     
     
Record-Route: <sip:proxy-call-id=17aa8dc7-422c-42ef-bdd9-b9750fbd0edf@192.168.1.5:5060;transport=tcp;lr>
Record-Route: <sip:proxy-call-id=17aa8dc7-422c-42ef-bdd9-b9750fbd0edf@192.168.1.5:5061;transport=tls;lr>
Record-Route: <sip:proxy-call-id=32c76cef-e73c-4911-98d0-e2d2bb6fec77@192.168.1.6:7003;transport=tls;lr>
Record-Route: <sip:proxy-call-id=32c76cef-e73c-4911-98d0-e2d2bb6fec77@192.168.1.6:5061;transport=tls;lr>
Allow: INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY
User-Agent: TANDBERG/4352 (X8.10.2-b2bua-1.0)

診断ログを分析し、問題を Expressway-C と特定のエラー（404 Not Found）に分離したので、この種の動作を引き起こしている原因の究明に集中することができます。次のことについて考慮する必要があります。

1. コールは、検索ルールを介して Expressway のゾーンを流入出しています。
2. Expressway では、「プリロード済み SIP ルートのサポート」と呼ばれるロジックが使用されます。このロジックは、ルータのヘッダーが含まれている SIP INVITE 要求を処理します。この値を、Expressway-C と Expressway-E の両方の [ゾーン（Zones）] （トラバーサル サーバ、トラバーサル クライアント、ネイバー）でオンまたはオフにすることができます。

これで xConfiguration を使用して、Expressway-E トラバーサル サーバ ゾーンと Expressway-C クライアント ゾーンの両方で、特にハイブリッド コール サービス接続用に設定されているものについて設定を表示できます。ゾーンの設定に加えて、このコールをゾーン間で通過するよう設定されている検索ルールを分析することができます。また、Expressway-E から Expressway-C にコールが渡されたこともわかっているので、トラバーサル サーバ ゾーンの設定が正しい可能性が非常に高くなります。

具体的には、次の xConfig ではこのゾーンがハイブリッド コール サービス トラバーサル（Hybrid Call Service Traversal）という名前であることがわかります。これは TraversalServer というゾーン タイプです。このゾーンは、SIP TCP ポート 7003 を経由して Expressway-C への通信を行います。

ハイブリッド コール サービスで重要なのは、プリロード済み SIP ルートのサポートをオンにしている必要があることです。Expressway の Webインターフェイスでは、この値はプリロード済み SIP ルートのサポート（Preloaded SIP routes support）と呼ばれていますが、xConfiguration では SIP PreloadedSipRoutes Accept と表示されます。

Expressway-E
*c xConfiguration Zones Zone 7 Name: "Hybrid Call Service Traversal"
*c xConfiguration Zones Zone 7 TraversalServer Authentication Mode: "DoNotCheckCredentials"
*c xConfiguration Zones Zone 7 TraversalServer Authentication UserName: "hybridauth"
*c xConfiguration Zones Zone 7 TraversalServer Collaboration Edge: "Off"
*c xConfiguration Zones Zone 7 TraversalServer H323 H46019 Demultiplexing Mode: "Off"
*c xConfiguration Zones Zone 7 TraversalServer H323 Port: "6007"
*c xConfiguration Zones Zone 7 TraversalServer H323 Protocol: "Assent"
*c xConfiguration Zones Zone 7 TraversalServer Registrations: "Allow"
*c xConfiguration Zones Zone 7 TraversalServer SIP Media AesGcm Support: "Off"
*c xConfiguration Zones Zone 7 TraversalServer SIP Media Encryption Mode: "Auto"
*c xConfiguration Zones Zone 7 TraversalServer SIP Media ICE Support: "Off"
*c xConfiguration Zones Zone 7 TraversalServer SIP Multistream Mode: "On"
*c xConfiguration Zones Zone 7 TraversalServer SIP ParameterPreservation Mode: "On"
*c xConfiguration Zones Zone 7 TraversalServer SIP Poison Mode: "Off"
*c xConfiguration Zones Zone 7 TraversalServer SIP Port: "7003"
*c xConfiguration Zones Zone 7 TraversalServer SIP PreloadedSipRoutes Accept: "On"
*c xConfiguration Zones Zone 7 TraversalServer SIP Protocol: "Assent"
*c xConfiguration Zones Zone 7 TraversalServer SIP TLS Verify Mode: "On"
*c xConfiguration Zones Zone 7 TraversalServer SIP TLS Verify Subject Name: "rtp12-tpdmz-118-VCSC.rtp.ciscotac.net"
*c xConfiguration Zones Zone 7 TraversalServer SIP Transport: "TLS"
*c xConfiguration Zones Zone 7 TraversalServer TCPProbe KeepAliveInterval: "20"
*c xConfiguration Zones Zone 7 TraversalServer TCPProbe RetryCount: "5"
*c xConfiguration Zones Zone 7 TraversalServer TCPProbe RetryInterval: "2"
*c xConfiguration Zones Zone 7 TraversalServer UDPProbe KeepAliveInterval: "20"
*c xConfiguration Zones Zone 7 TraversalServer UDPProbe RetryCount: "5"
*c xConfiguration Zones Zone 7 TraversalServer UDPProbe RetryInterval: "2"
*c xConfiguration Zones Zone 7 Type: "TraversalServer"

また、このゾーンには検索ルール 3（Webex ハイブリッド）が結び付けられていることも判断できます。基本的には、検索ルールはハイブリッド コール サービスの DNS ゾーンを経由して着信する「すべての」エイリアスを送信し、前述のゾーン「ハイブリッド コール サービス トラバーサル」に渡しています。予想されたとおり、Expressway-E の検索ルールもトラバーサル サーバ ゾーンも正しく設定されています。

*c xConfiguration Zones Policy SearchRules Rule 3 Authentication: "No"
*c xConfiguration Zones Policy SearchRules Rule 3 Description: "Calls to VCS-C"
*c xConfiguration Zones Policy SearchRules Rule 3 Mode: "AnyAlias"
*c xConfiguration Zones Policy SearchRules Rule 3 Name: "Webex Hybrid"
*c xConfiguration Zones Policy SearchRules Rule 3 Pattern Behavior: "Strip"
*c xConfiguration Zones Policy SearchRules Rule 3 Pattern Replace: 
*c xConfiguration Zones Policy SearchRules Rule 3 Pattern String: 
*c xConfiguration Zones Policy SearchRules Rule 3 Pattern Type: "Prefix"
*c xConfiguration Zones Policy SearchRules Rule 3 Priority: "15"
*c xConfiguration Zones Policy SearchRules Rule 3 Progress: "Stop"
*c xConfiguration Zones Policy SearchRules Rule 3 Protocol: "SIP"
*c xConfiguration Zones Policy SearchRules Rule 3 SIPTrafficType: "Any"
*c xConfiguration Zones Policy SearchRules Rule 3 Source Mode: "Named"
*c xConfiguration Zones Policy SearchRules Rule 3 Source Name: "Hybrid Call Services DNS"
*c xConfiguration Zones Policy SearchRules Rule 3 State: "Enabled"
*c xConfiguration Zones Policy SearchRules Rule 3 SystemGenerated: "No"
*c xConfiguration Zones Policy SearchRules Rule 3 Target Name: "Hybrid Call Service Traversal"
*c xConfiguration Zones Policy SearchRules Rule 3 Target SIPVariant: "Any"
*c xConfiguration Zones Policy SearchRules Rule 3 Target Type: "Zone"

Expressway-C の xConfiguration に注目した場合は、最初に Webex ハイブリッドのトラバーサル クライアント ゾーンを探すことができます。簡単に見つける方法の 1 つとして、Expressway-E の xConfiguration からわかったポート番号（SIP ポート："7003"）で検索します。 これを利用して、xConfiguration で正しいゾーンをすぐに探すことができます。

また前述のように、[ゾーン名（Zone Name）] として「ハイブリッド コール サービス トラバーサル（Hybrid Call Service Traversal）、[タイプ（Type）] として「トラバーサル クライアント（Traversal Client）」、および SIP PreloadedSipRoutes Accept の設定内容がわかります。 この xConfiguration から、この値はオフに設定されていることがわかります。『Cisco Webex ハイブリッド コール サービス導入ガイド』によれば、この値はオンに設定する必要があります。

さらに、プリロード済み SIP ルートのサポートの定義を調べてみると、この値をオフに設定し、なおかつ INVITE にルート ヘッダーが含まれている場合は、明らかに、Expressway-C がメッセージを「拒否」することがわかります。「このヘッダーが含まれている SIP INVITE 要求をゾーンで拒否するようにするには、[プリロード済み SIP ルートのサポート（Preloaded SIP routes support）] を [オフ（Off）] に切り替えます。」

Expressway-C
*c xConfiguration Zones Zone 6 Name: "Hybrid Call Service Traversal"
*c xConfiguration Zones Zone 6 TraversalClient Accept Delegated Credential Checks: "Off"
*c xConfiguration Zones Zone 6 TraversalClient Authentication Mode: "DoNotCheckCredentials"
*c xConfiguration Zones Zone 6 TraversalClient Authentication Password: "{cipher}qeh8eq+fuVY1GHGgRLder/1lYDd76O/6KrHGA7g8bJs="
*c xConfiguration Zones Zone 6 TraversalClient Authentication UserName: "hybridauth"
*c xConfiguration Zones Zone 6 TraversalClient Collaboration Edge: "Off"
*c xConfiguration Zones Zone 6 TraversalClient H323 Port: "1719"
*c xConfiguration Zones Zone 6 TraversalClient H323 Protocol: "Assent"
*c xConfiguration Zones Zone 6 TraversalClient Peer 1 Address: "amer-expressway01.ciscotac.net"
*c xConfiguration Zones Zone 6 TraversalClient Peer 2 Address: 
*c xConfiguration Zones Zone 6 TraversalClient Peer 3 Address: 
*c xConfiguration Zones Zone 6 TraversalClient Peer 4 Address: 
*c xConfiguration Zones Zone 6 TraversalClient Peer 5 Address: 
*c xConfiguration Zones Zone 6 TraversalClient Peer 6 Address: 
*c xConfiguration Zones Zone 6 TraversalClient Registrations: "Allow"
*c xConfiguration Zones Zone 6 TraversalClient RetryInterval: "120"
*c xConfiguration Zones Zone 6 TraversalClient SIP Media AesGcm Support: "Off"
*c xConfiguration Zones Zone 6 TraversalClient SIP Media Encryption Mode: "Auto"
*c xConfiguration Zones Zone 6 TraversalClient SIP Media ICE Support: "Off"
*c xConfiguration Zones Zone 6 TraversalClient SIP Multistream Mode: "On"
*c xConfiguration Zones Zone 6 TraversalClient SIP ParameterPreservation Mode: "On"
*c xConfiguration Zones Zone 6 TraversalClient SIP Poison Mode: "Off"
*c xConfiguration Zones Zone 6 TraversalClient SIP Port: "7003"
*c xConfiguration Zones Zone 6 TraversalClient SIP PreloadedSipRoutes Accept: "Off"
*c xConfiguration Zones Zone 6 TraversalClient SIP Protocol: "Assent"
*c xConfiguration Zones Zone 6 TraversalClient SIP TLS Verify Mode: "On"
*c xConfiguration Zones Zone 6 TraversalClient SIP TURN Server Address: 
*c xConfiguration Zones Zone 6 TraversalClient SIP TURN Server Port: 
*c xConfiguration Zones Zone 6 TraversalClient SIP Transport: "TLS"
*c xConfiguration Zones Zone 6 Type: "TraversalClient"

この時点で、問題が Expressway-C のトラバーサル クライアント ゾーンの設定ミスへと分離されました。[プリロード済み SIP ルートのサポート（Preloaded SIP routes support）] を [オン（On）] に切り替える必要があります。

解決方法

プリロード済み SIP ルートのサポートを正しく設定するには、次の操作を行います。

1. Expressway-C にログインします。
2. [設定（Configuration）] > [ゾーン（Zones）] > [ゾーン（Zones）] に移動します。
3. [ハイブリッド コール サービス トラバーサル クライアント ゾーン（Hybrid Call Service Traversal client zone）] を選択します（名前付けはお客様ごとに異なります）。
4. [プリロード済み SIP ルートのサポート（Preloaded SIP routes support）] を [オン（On）] に設定します。
5. [保存（Save）] を選択します。

注：このシナリオは Expressway-C での障害例を示していますが、Webex ハイブリッド コール トラバーサル サーバ ゾーンで [プリロード済み SIP ルートのサポート（Preloaded SIP routes support）] が [オフ（Off）] になっている場合は、Expressway-E でも同じ診断ログ エラーが見つかる可能性があります。その場合は、コールが Expressway-C に到達することは決して確認されず、Expressway-E がコール拒否および 404 Not Found を送信する役割を担っていたことになります。

問題 5： Cisco Webex アプリで 2 つのコール通知（トースト）を受信している

この特定の問題は、コールのドロップとならない着信コールのシナリオでのみ、偶発的に発生します。この問題では、コールを受信している人（着信側）がコールを発信した人（発信側）から 2 つの通知（トースト）を Cisco Webex アプリで受信しています。 1 つ目の通知は Cisco Webex から生成されていて、2 つ目の通知はオンプレミス インフラストラクチャから生成されています。次の図は、受信した 2 つの通知の例です。

1 つ目の通知（トースト）は、Cisco Webex 側からコールを開始している人物（発信側）です。この例では、発信者 ID は、そのコールを開始しているユーザの表示名（Display Name）です。2 つ目の通知（トースト）は、オンプレミスの CTI から、またはコールを発信しているユーザに割り当てられた Cisco Webex RD から送信されています。一見すると、この動作は不自然に思われます。しかし、Cisco Webex ハイブリッド コール設計ガイドの着信コールの図を見てみると、図に示すように、動作について理解を深めることができます。

この図から、Alice は 自分の Cisco Webex アプリから Bob をコールしていて、コールがオンプレミスまでフォークされていることがわかります。このコールは、Bob の電話機に割り当てられているディレクトリ URI（Directory URI）と一致します。問題となるのは、この設計ではディレクトリ URI が Bob の CTI RD または Cisco Webex RD にも割り当てられていることです。したがって、コールが CTI-RD または Cisco Webex RD に提示されたとき、そのコールは Cisco Webex に送り返されます。これは、デバイスのリモート宛先（Remote Destination）が bob@example.call.ciscospark.com 用に設定されているためです。この状況に対処するため、Cisco Webex は特定のコール レッグをキャンセルします。 

コール レッグを正常にキャンセルするため、Cisco Webex は最初に SIP ヘッダーにパラメータを設定する必要がありましたが、与えられたレッグをキャンセルする目的で SIP ヘッダーを探すことになります。Cisco Webex が SIP INVITE に挿入するパラメータは call-type=squared と呼ばれるもので、この値がコンタクト（Contact）ヘッダーに入力されます。この値がメッセージから欠落した場合、Cisco Webex はコールをキャンセルする方法を認識できません。 

こうした情報から、前に示したシナリオを再び参照することができます。前のシナリオでは、Cisco Webex ユーザの Jonathan Robb がコールを発信したときに、ユーザの Cisco Webex アプリで 2 つの通知（トースト）を受信していました。この種の問題をトラブルシューティングするには、常に Expressway-C と Expressway-E から診断ログを収集する必要があります。まず、Expressway-E のログを調べて、SIP INVITE において最初にインバウント送信された Cisco Webex INVITE のコンタクト ヘッダーに、実際に call-type=squared の値が存在することを確かめることができます。これにより、ファイアウォールがメッセージをまったく操作していないことが確かめられます。次に示すのは、このシナリオにおける Expressway-E への着信 INVITE のスニペット例です。

2017-09-19T14:01:48.140-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 18:01:48,140" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="172.16.2.2" Local-port="5062" Src-ip="146.20.193.73" Src-port="40342" Msg-Hash="11658696457333185909"
 SIPMSG:
 |INVITE sip:pstojano-test@rtp.ciscotac.net SIP/2.0
 Via: SIP/2.0/TLS 192.168.5.164:5062;branch=z9hG4bK564cd36d87f3417513c9b559dc666f71,SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-3237-5c5060d07ecc546a0bb861ef52a5f507;rport=43306
 Call-ID: 6bc0ca8210c0b48df69f38057ec1e48b@127.0.0.1
 CSeq: 1 INVITE
 Contact: "l2sip-UA" <sip:l2sip-UA@l2sip-cfa-01.wbx2.com:5062;transport=tls>;call-type=squared   <-- Webex inserted value
 From: "Jonathan Robb" 
     
     ;tag=540300020
 To: 
     
      
      
 Max-Forwards: 70 
      
 Route: 
      
        , 
        
       
     

コンタクト ヘッダーに call-type=squared の値が存在します。この時点では、コールで Expressway を介したルーティングを行う必要があり、コールを Webex ハイブリッド トラバーサル サーバ ゾーンから送信する必要があります。Expressway-E のログを検索して、コールが Expressway-E からどのように送信されたのかを調べることができます。その結果から、Expressway-E が何らかの方法で INVITE を操作しているかどうかを推測します。 

2017-09-19T14:01:48.468-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 18:01:48,468" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="192.168.1.6" Local-port="7003" Dst-ip="192.168.1.5" Dst-port="26686" Msg-Hash="1847271284712495612"
SIPMSG:
INVITE sip:pstojano-test@rtp.ciscotac.net SIP/2.0
Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKec916b02b6d469abad0a30b93753f4b0859;proxy-call-id=d7372034-85d1-41f8-af84-dffed6d1a9a9;rport
Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bKd91699370129b4c10d09e269525de00c2;x-cisco-local-service=nettle;received=192.168.1.6;rport=43119;ingress-zone=DefaultZone
Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK52aac9a181192566e01b98ae0280bdff858.0e65cdfe078cabb269eecb6bce1328be;proxy-call-id=ec51e8da-e1a3-4210-95c9-494d12debcd8;received=172.16.2.2;rport=25016
Via: SIP/2.0/TLS 192.168.5.164:5062;branch=z9hG4bK564cd36d87f3417513c9b559dc666f71;received=146.20.193.73;rport=40342;ingress-zone=HybridCallServicesDNS
Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-3237-5c5060d07ecc546a0bb861ef52a5f507;rport=43306
Call-ID: 6bc0ca8210c0b48df69f38057ec1e48b@127.0.0.1
CSeq: 1 INVITE
Contact: <sip:192.168.1.6:5073;transport=tls>     <-- Webex inserted value is now missing
From: "Jonathan Robb" 
     
     ;tag=540300020
To: 
     
     
Max-Forwards: 15
Route: <sip:cucm.rtp.ciscotac.net;lr>

Expressway-E から Expressway-C に送信されているこの SIP INVITE を調べてみると、コンタクト ヘッダーに call-type=squared がないことがわかります。また、行項目 4 を見ると、出力ゾーン（egress-zone）が HybridCallServiceTraversal に等しくなっていることもわかります。結論として、ダイヤル時に Cisco Webex アプリが 2 つ目の通知（トースト）を受信しているのは、Expressway-E において SIP INVITE のコンタクト ヘッダーから call-type=squared タグが欠落しているからだと判断できます。つまり、このヘッダーの欠落を引き起こしている原因を突き止める必要があります。

コールは、Expressway でセットアップしたハイブリッド コール サービス トラバーサルを経由してルーティングする必要があります。そのため、そこから調査を始めるのが適切です。xConfiguration がある場合は、このゾーンがどのように設定されたのかを確認できます。xConfiguration でゾーンを特定するには、ログに出力される Via 行に記録された名前を使用します。前の例では egress-zone=HybridCallServiceTraversal という名前になっていました。この名前が SIP ヘッダーの Via 行に出力されるときは、スペースが削除されます。xConfiguration の観点から見た実際のゾーン名には、スペースがあり、ハイブリッド コール サービス トラバーサルでフォーマットが設定されています。 

*c xConfiguration Zones Zone 7 TraversalServer Authentication Mode: "DoNotCheckCredentials"
*c xConfiguration Zones Zone 7 TraversalServer Authentication UserName: "hybridauth"
*c xConfiguration Zones Zone 7 TraversalServer Collaboration Edge: "Off"
*c xConfiguration Zones Zone 7 TraversalServer H323 H46019 Demultiplexing Mode: "Off"
*c xConfiguration Zones Zone 7 TraversalServer H323 Port: "6007"
*c xConfiguration Zones Zone 7 TraversalServer H323 Protocol: "Assent"
*c xConfiguration Zones Zone 7 TraversalServer Registrations: "Allow"
*c xConfiguration Zones Zone 7 TraversalServer SIP Media AesGcm Support: "Off"
*c xConfiguration Zones Zone 7 TraversalServer SIP Media Encryption Mode: "Auto"
*c xConfiguration Zones Zone 7 TraversalServer SIP Media ICE Support: "Off"
*c xConfiguration Zones Zone 7 TraversalServer SIP Multistream Mode: "On"
*c xConfiguration Zones Zone 7 TraversalServer SIP ParameterPreservation Mode: "Off" <-- Possible Suspect Value
*c xConfiguration Zones Zone 7 TraversalServer SIP Poison Mode: "Off"
*c xConfiguration Zones Zone 7 TraversalServer SIP Port: "7003"
*c xConfiguration Zones Zone 7 TraversalServer SIP PreloadedSipRoutes Accept: "On"   <-- Possible Suspect Value
*c xConfiguration Zones Zone 7 TraversalServer SIP Protocol: "Assent"
*c xConfiguration Zones Zone 7 TraversalServer SIP TLS Verify Mode: "On"
*c xConfiguration Zones Zone 7 TraversalServer SIP TLS Verify Subject Name: "rtp12-tpdmz-118-VCSC.rtp.ciscotac.net"
*c xConfiguration Zones Zone 7 TraversalServer SIP Transport: "TLS"
*c xConfiguration Zones Zone 7 TraversalServer TCPProbe KeepAliveInterval: "20"
*c xConfiguration Zones Zone 7 TraversalServer TCPProbe RetryCount: "5"
*c xConfiguration Zones Zone 7 TraversalServer TCPProbe RetryInterval: "2"
*c xConfiguration Zones Zone 7 TraversalServer UDPProbe KeepAliveInterval: "20"
*c xConfiguration Zones Zone 7 TraversalServer UDPProbe RetryCount: "5"
*c xConfiguration Zones Zone 7 TraversalServer UDPProbe RetryInterval: "2"
*c xConfiguration Zones Zone 7 Name: "Hybrid Call Service Traversal"

設定がハイブリッド コール サービス トラバーサルのものであることが明らかになったので、次のような目立った設定の候補を探すことができます。

• SIP PreloadedSIPRoutes Accept：オン
• SIP ParameterPreservatoin Mode：オフ

任意の Expressway の Web インターフェイスを使用して、これらの値の定義と動作の内容を確認できます。

プリロード済み SIP ルートのサポート（Preloaded SIP routes support）

ルート ヘッダーが含まれている SIP INVITE 要求をこのゾーンで処理できるようにするには、[プリロード済み SIP ルートのサポート（Preloaded SIP routes support）] を [オン（On）] に切り替えます。

このヘッダーが含まれている SIP INVITE 要求をゾーンで拒否するようにするには、[プリロード済み SIP ルートのサポート（Preloaded SIP routes support）] を [オフ（Off）] に切り替えます。

SIP パラメータの保持（SIP parameter preservation）

アウトバウンド:オンプレミスから Cisco Webex へ

オンプレミスから Cisco Webex への発信障害では、ほとんどすべての場合に同じ症状が報告されています。たとえば、「Unified CM に登録した自分の電話機から、コール サービス接続で有効になっている他のユーザに電話をかけると、相手のオンプレミス電話機では着信音が鳴るが、相手の Cisco Webex アプリでは着信音が鳴らない」などです。 このシナリオをトラブルシューティングするためには、この種のコールで発生するコールのフローとロジックの両方について理解しておくことが重要です。

全体的なロジック フロー

1. ユーザ A が自分のオンプレミス電話機から、ユーザ B のディレクトリ URI に電話をかけます。
2. ユーザ B のオンプレミス電話機と CTI RD/Webex RD がコールを受け付けます。
3. ユーザ B のオンプレミス電話で着信音が鳴り始めます。
4. ユーザ B の CTI-RD/Webex-RD によって、このコールが UserB@example.call.ciscospark.com という宛先にフォークされます。
5. Unified CM がこのコールを Expressway-C に渡します。
6. Expressway-C がコールを Expressway-E に送信します。
7. Expressway-Eは、callservice.ciscospark.comドメインでDNSルックアップを実行します
8. Expressway-E が、ポート 5062 を経由した Cisco Webex 環境への接続を試みます。
9. Expressway-E と Cisco Webex 環境の間で相互ハンドシェイクが開始されます。
10. Cisco Webex 環境が、ユーザ B の使用可能な Cisco Webex アプリにコールを渡します。
11. ユーザ B が使用できる Cisco Webex アプリで着信音が鳴り始めます。

コールフロー

図のように、[ユーザ B のオンプレミス電話（User B on-prem phone）] > [Unified CM] > [CTI-RD/Webex-RD] > [Expressway-C] > [Expressway-E] > [Cisco Webex 環境（Cisco Webex environment）] > [Cisco Webex アプリ（Cisco Webex apps）] に移動します。

注：図は『Cisco Webex ハイブリッド設計ガイド』からの抜粋です。

ログ分析のヒント

Cisco Webex へのフォークされた発信コールが失敗している状況をトラブルシューティングする場合は、Unified CM、Expressway-C、Expressway-E の各ログを収集します。これらの一連のログを調べることで、コールがどのようにして環境を通過しているのかを確認できます。コールがオンプレミス環境内でどのくらいの距離から達しているのかを手早く理解する別の方法として、Expressway の「検索履歴」を使用できます。 Expressway の検索履歴では、Cisco Webex 宛てのフォークされたコールが Expressway-C または E に達しているかどうかを速やかに調べることができます。

検索履歴を使用するには、次の操作を行います。

1. Expressway-E にログインします。
   テスト コールを発信します。
   [ステータス（Status）]> [検索履歴（Search history）] に移動します。
   コールを受ける必要がある Webex SIP URI の宛先アドレス（user@example.call.ciscospark.com）がコールに存在するかどうかを確かめます。
   Expressway-E に達しているコールが検索履歴に表示されない場合は、Expressway-C についてこの手順を繰り返します。

Expressway で診断ログを分析する前に、このコールを特定する方法について考えてみましょう。

1. SIP 要求 URI は、Cisco Webex ユーザの SIP アドレスになります。
2. [SIP FROM]フィールドは、[Calling Party]が[First Name Last Name] <sip:Alias@Domain>としてリストされるようにフォーマットされます

これらの情報を使用して、発信側のディレクトリ URI、発信側の名と姓、または着信側の Cisco Webex SIP アドレスで診断ログを検索できます。この情報がない場合は、「INVITE SIP:」で検索を行い、Expresswayで実行されているすべてのSIPコールを検索できます。発信コールの SIP INVITE が特定されたら、SIP コール ID（Call-ID）を探してコピーできます。この値がわかったら、後はコール ID に基づいて診断ログを検索するだけで、このコール レッグに関連するすべてのメッセージを表示できます。

以下では、コール サービス接続で有効になっているユーザに電話をかけたときに、Unified CM に登録された電話から Cisco Webex 環境への発信コールでよく発生する問題をいくつか紹介します。

問題1: Expresswayがcallservice.ciscospark.comアドレスを解決できない

Expressway DNS ゾーンの標準の操作手順として、要求 URI の右側に表示されるドメインに基づいて DNS ルックアップを実行します。このことを説明するために、例を考えてみましょう。DNSゾーンが要求URIがpstojano-test@dmzlab.call.ciscospark.comのコールを受信する場合、一般的なExpressway DNSゾーンは、要求URIの右側であるdmzlab.call.ciscospark.comでDNS SRVルックアップロジックを実行します。Expressway がこの処理を行うとすれば、次のルックアップと応答が発生すると予想できます。

_sips._tcp.dmzlab.call.ciscospark.com.
Response: 5 10 5061 l2sip-cfa-01.wbx2.com.
l2sip-cfa-01.wbx2.com
Response: 146.20.193.64

詳しく調べてみると、SRV レコードの応答から、サーバのアドレスと、ポート 5062 ではなく ポート 5061 が提供されていることがわかります。

つまり、ポート 5062 経由で発生する相互 TLS ハンドシェイクが実行されず、Expressway と Cisco Webex 間のシグナリングに別のポートが使用されます。ここで問題となるのは、『Cisco Webex ハイブリッド コール サービス導入ガイド』ではポート 5061 の使用を明確に指示していないことです。これは、一部の環境で B2B 通話が許可されていないためです。

Expressway におけるこうした標準の DNS ゾーン SRV ルックアップ ロジックを回避する方法として、指定した値に基づいて明示的に検索するように Expressway を設定します。

この特定のコールを分析する際は、（検索履歴を使用して）コールがここまで達していると判断したので、Expressway-E に注目することができます。まず、Expressway-E に着信している 1 つ目の SIP INVITE を調べて、どのゾーンを経由して着信したのか、どの検索ルールが使用されているのか、どのゾーンからコールが送出しているのか、そして、DNS ゾーンに正しく送信されている場合にどのような DNS ルックアップ ロジックが発生しているのかを明らかにします。 

2017-09-19T13:18:50.562-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,556" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26686" Msg-Hash="4341754241544006348"
 SIPMSG:
 |INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK6d734eaf7a6d733bd1e79705b7445ebb46175.1d33be65c99c56898f85df813f1db3a7;proxy-call-id=47454c92-2b30-414a-b7fe-aff531296bcf;rport
 Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK13187594dd412;received=192.168.1.21;ingress-zone=CUCM11
 Call-ID: 991f7e80-9c11517a-130ac-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
 Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off
 Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio
 From: "Jonathan Robb" 
     
     ;tag=332677~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106860
 To: 
     
     
 Max-Forwards: 15
 Record-Route: <sip:proxy-call-id=47454c92-2b30-414a-b7fe-aff531296bcf@192.168.1.5:5061;transport=tls;lr>
 Record-Route: <sip:proxy-call-id=47454c92-2b30-414a-b7fe-aff531296bcf@192.168.1.5:5060;transport=tcp;lr>
 Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
 User-Agent: Cisco-CUCM11.5
 Expires: 180
 Date: Tue, 19 Sep 2017 17:18:50 GMT
 Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,X-cisco-original-called
 Session-Expires: 1800
 Min-SE: 1800
 Allow-Events: presence
 X-TAATag: 2272025a-ce36-49d0-8d93-cb6a5e90ffe0
 Session-ID: 75957d4fb66a13e835c10737aa332675;remote=00000000000000000000000000000000
 Cisco-Guid: 2568978048-0000065536-0000000148-0352430272
 Content-Type: application/sdp
 Content-Length: 714

<SDP Omitted>

このSIP INVITEでは、要求URI(pstojano-test@dmzlab.call.ciscospark.com)、Call-ID(991f7e80-9c11517a-130ac-1501a8c0)、From("Jonathan Rob " <sip:5010@rtp.ciscotac.net>)、To(sip:pstojano-test@dmzlab.call.ciscospark.com)、およびUser-Agent(Cisco-CUCM11.5)。 この INVITE の受信後、Expressway はロジックを決定して、コールを別のゾーンにルーティングできるかどうかを判断する必要があります。Expressway は検索ルールに基づいてこの判断を実行します。

2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Search rule 'B2B calls to VCS-C' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Search rule 'Webex Hybrid' ignored due to source filtering"
2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Search rule 'Calls to Webex' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Considering search rule 'Webex Hybrid - to Webex Cloud' towards target 'Hybrid Call Services DNS' at priority '90' with alias 'pstojano-test@dmzlab.call.ciscospark.com'"

前述のログ スニペットから、Expressway-E は 4 つの検索ルールを使用して解析を行ったものの、1 つ（Webex Hybrid - to Webex Cloud）しか考慮しなかったことがわかります。検索ルールには 90 の優先順位があり、ハイブリッド コール サービス DNS ゾーンに送ることを目的としていました。コールが DNS ゾーンに送信されているので、Expressway-E で発生している DNS SRV ルックアップを確認できます。

2017-09-19T13:18:50.565-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,565" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="dmzlab.call.ciscospark.com" Type="NAPTR (IPv4 and IPv6)"
2017-09-19T13:18:50.718-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,718" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sips._tcp.dmzlab.call.ciscospark.com" Type="SRV (IPv4 and IPv6)"
2017-09-19T13:18:50.795-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,795" Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:  ['IPv4''TCP''146.20.193.64:5061'] (A/AAAA)  Hostname:'l2sip-cfa-01.wbx2.com' Port:'5061' Priority:'5' TTL:'300' Weight:'10' (SRV) Number of relevant records retrieved: 2"

上記のスニペットでは、Expressway-Eが要求URI(_sips._tcp.dmzlab.call.ciscospark.com)の右側に基づいてSRVルックアップを実行し、l2cfa-01.wbx2.comとポート5061に解決されています。ホスト名l2sip-cfa-01.wbx2.comは146.20.193.64に解決されます。この情報を使用して、Expresswayが実行する次の論理的な手順は、TCP SYNパケットを146.20.193.64に送信し、コールのセットアップを試行することです。Expressway-E のログから、このことが起きているかどうかを確認できます。

2017-09-19T13:18:51.145-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:51,145" Module="network.tcp" Level="DEBUG":  Src-ip="172.16.2.2" Src-port="25010" Dst-ip="146.20.193.64" Dst-port="5061" Detail="TCP Connecting"
2017-09-19T13:19:01.295-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:19:01,289" Module="network.tcp" Level="ERROR":  Src-ip="172.16.2.2" Src-port="25010" Dst-ip="146.20.193.64" Dst-port="5061" Detail="TCP Connection Failed"

前述の Expressway-E の診断ログ スニペットでは、Expressway-E は前に TCP ポート 5061 経由で解決された IP 146.20.193.64 への接続を試みていますが、この接続は完全に失敗していることがわかります。同じことは、収集したパケット キャプチャからも確認できます。 

これらの結果から、ポート 5061 経由のトラフィックが成功していないことは明らかです。ただし、ハイブリッド コール サービス接続は TCP ポート 5061 ではなくポート 5062 の使用を意図していました。したがって、Expressway-E がポート 5062 を返す SRV レコードを解決していない理由について考える必要があります。その答えを見つけるため、Expressway-E の Webex ハイブリッド DNS ゾーンで起こりうる設定の問題を調べることができます。 

*c xConfiguration Zones Zone 6 Name: "Hybrid Call Services DNS"
*c xConfiguration Zones Zone 6 DNS SIP Authentication Trust Mode: "Off"
*c xConfiguration Zones Zone 6 DNS SIP Default Transport: "TLS"
*c xConfiguration Zones Zone 6 DNS SIP DnsOverride Name: "ciscospark.com"
*c xConfiguration Zones Zone 6 DNS SIP DnsOverride Override: "Off"
*c xConfiguration Zones Zone 6 DNS SIP Media AesGcm Support: "Off"
*c xConfiguration Zones Zone 6 DNS SIP Media Encryption Mode: "On"
*c xConfiguration Zones Zone 6 DNS SIP Media ICE Support: "Off"
*c xConfiguration Zones Zone 6 DNS SIP ParameterPreservation Mode: "Off"
*c xConfiguration Zones Zone 6 DNS SIP Poison Mode: "Off"
*c xConfiguration Zones Zone 6 DNS SIP PreloadedSipRoutes Accept: "On"
*c xConfiguration Zones Zone 6 DNS SIP Record Route Address Type: "IP"
*c xConfiguration Zones Zone 6 DNS SIP SearchAutoResponse: "Off"
*c xConfiguration Zones Zone 6 DNS SIP TLS Verify InboundClassification: "On"
*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Mode: "On"
*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Subject Name: "callservice.ciscospark.com"
*c xConfiguration Zones Zone 6 DNS SIP UDP BFCP Filter Mode: "Off"
*c xConfiguration Zones Zone 6 DNS SIP UDP IX Filter Mode: "Off"

Expressway-E の xConfiguration には、DNS ルックアップに関連する値として、DNSOverride Name と DNSOverride Override という 2 つの注目すべき値があります。この xConfiguration によると、DNSOverride Override はオフに設定されており、したがって DNSOverride Name は有効になっていません。これらの値の動作について理解を深めるため、Expressway Web UI を使用して値の定義を調べることができます。

DNS 要求の変更（Modify DNS request）（xConfig の DnsOverride Override に対応）

このゾーンからの発信 SIP コールをダイヤルした宛先内のドメインではなく、手動で指定した SIP ドメインにルーティングします。このオプションは、主に Cisco Webex サービスでの使用を目的としています。www.cisco.com/go/hybrid-services を参照してください。

検索するドメイン（Domain to search for）（xConfig の DnsOverride Name に対応）

発信 SIP URI についてドメインを検索する代わりに DNS で検索する FQDN を入力します。元の SIP URI には影響しません。

以上の定義から、これらの値は正しく設定されている場合に DNS ルックアップ ロジックに完全に適合することは明らかです。これをCisco Webexハイブリッドコールサービス導入ガイドの文と組み合わせると、[Modify DNS Request]を[On]に設定し、[Domain to search]を[callservice.ciscospark.com]に設定する必要があります。これらの値を変更して正しい情報を指定すれば、DNS SRV ルックアップ ロジックはまったく異なるものになります。Expressway-E 診断ログの観点から予想できるスニペットを次に示します。

2017-09-19T10:18:35.048-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,048" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sips._tcp.callservice.ciscospark.com" Type="SRV (IPv4 and IPv6)"
2017-09-19T10:18:35.126-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,126" Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:  ['IPv4''TCP''146.20.193.70:5062'] (A/AAAA)  ['IPv4''TCP''146.20.193.64:5062'] (A/AAAA)  Hostname:'l2sip-cfa-02.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV)  Hostname:'l2sip-cfa-01.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV) Number of relevant records retrieved: 4"

解決方法

1. Expressway-E にログインします。
2. [設定（Configuration）] > [ゾーン（Zones）] > [ゾーン（Zones）] に移動します。
3. 設定済みの Webex ハイブリッド DNS ゾーンを選択します。
4. [DNS 要求の変更（Modify DNS request）] を [オン（On）] に設定します。
5. 値を検索するドメインをcallservice.ciscospark.comに設定します
6. 変更を保存

注：Expressway で使用されている DNS ゾーンが 1 つしかない場合は、別の DNS ゾーンをハイブリッド コール サービスで使用するように設定して、これらの値を利用できるようにする必要があります。

問題 2： ポート 5062 で Cisco Webex への発信がブロックされる

Cisco Webex へのフォークされた発信コールの障害に関する固有な問題は、クライアントで着信音が鳴らないにもかかわらず着信側の Cisco Webex アプリで [参加（Join）] ボタンが表示されることです。前述のシナリオと同様に、この問題でも同じツールとログを使用して障害の存在箇所を的確に理解する必要があります。コールの問題の分離やログの分析に関するヒントについては、図に示しているこの記事の項を参照してください。

[参加（Join）] ボタンが表示されている図

発信コールの問題 1 と同様に、Expressway-E の診断ログで分析を始めることができます。これは、Expressway で検索履歴を使用して、コールがそこまで達していると判断したためです。前と同様に、Expressway-CからExpressway-Eに着信する最初のINVITEから開始します。検索する内容は次のとおりです。

1. Expressway-E が INVITE を受信しているかどうか。
2. 検索ルール ロジックによってコールがハイブリッド DNS ゾーンを通過しているかどうか
3. DNS ゾーンが DNS ルックアップを実行しているかどうか、正しいドメインで実行しているかどうか
4. システムによってポート 5062 の TCP ハンドシェイクが試行され正しく確立されたかどうか
5. 相互 TLS ハンドシェイクが成功したかどうか

2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,017" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26513" Msg-Hash="3732376649380137405"
 SIPMSG:
 |INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK57d8d5c823824bcddfd62f6ff7e09f9939482.899441b6d60c444e4ed58951d07b5224;proxy-call-id=696f6f1c-9abe-47f3-96a4-e26f649fb76f;rport
 Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12d4b77c97a64;received=192.168.1.21;ingress-zone=CUCM11
 Call-ID: 6a48de80-9c11273a-12d08-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
 Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off
 Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio
 From: "Jonathan Robb" 
     
     ;tag=328867~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106829
 To: 
     
     
 Max-Forwards: 15
 Record-Route: <sip:proxy-call-id=696f6f1c-9abe-47f3-96a4-e26f649fb76f@192.168.1.5:5061;transport=tls;lr>
 Record-Route: <sip:proxy-call-id=696f6f1c-9abe-47f3-96a4-e26f649fb76f@192.168.1.5:5060;transport=tcp;lr>
 Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
 User-Agent: Cisco-CUCM11.5
 Expires: 180
 Date: Tue, 19 Sep 2017 14:18:34 GMT
 Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,X-cisco-original-called
 Session-Expires: 1800
 Min-SE: 1800
 Allow-Events: presence
 X-TAATag: b2967a3b-93fb-4ca4-b0d7-131f75335684
 Session-ID: 75957d4fb66a13e835c10737aa328865;remote=00000000000000000000000000000000
 Cisco-Guid: 1783160448-0000065536-0000000126-0352430272
 Content-Type: application/sdp
 Content-Length: 714
<SDP Omitted>

前の INVITE でわかるように、INVITE は正常に受信されています。これは「着信」の動作であり、Expressway-C の IP アドレスから送られてきています。次に、検索ルール ロジックを見てみましょう。

2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Search rule 'B2B calls to VCS-C' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Search rule 'Webex Hybrid' ignored due to source filtering"
2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Search rule 'Calls to Webex' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Considering search rule 'Webex Hybrid - to Webex Cloud' towards target 'Hybrid Call Services DNS' at priority '90' with alias 'pstojano-test@dmzlab.call.ciscospark.com'"

上記のログスニペットから、Expressway-Eは4つの検索ルールを使用して解析しましたが、1つだけが解析されていることがわかります （Webexハイブリッド – Webexクラウドへ） が考慮された検索ルールのプライオリティは90で、 ハイブリッドコールサービスDNSゾーン.コールが DNS ゾーンに送信されているので、Expressway-E で発生している DNS SRV ルックアップを確認できます。以上はすべて、完全に正常です。続いて、DNS ルックアップ ロジックに注目してみましょう。

2017-09-19T10:18:35.048-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,048" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sips._tcp.callservice.ciscospark.com" Type="SRV (IPv4 and IPv6)"
2017-09-19T10:18:35.126-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,126" Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:  ['IPv4''TCP''146.20.193.70:5062'] (A/AAAA)  ['IPv4''TCP''146.20.193.64:5062'] (A/AAAA)  Hostname:'l2sip-cfa-02.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV)  Hostname:'l2sip-cfa-01.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV) Number of relevant records retrieved: 4"

この例では、callservice.ciscospark.com SRVレコードが解決されていることがわかります。その応答は 4 つの異なる有効なレコードであり、すべてがポート 5062 を使用しています。これは正常な動作です。この時点で、次に来るべき TCP ハンドシェイクを分析できます。このドキュメントですでに説明したように、診断ログで「TCP 接続（TCP Connecting）」を検索し、Dst-port="5062" がリストされている行項目を探すことができます。 このシナリオで明らかになる内容の例を次に示します。

2017-09-19T10:18:35.474-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,474" Module="network.tcp" Level="DEBUG":  Src-ip="172.16.2.2" Src-port="25026" Dst-ip="146.20.193.70" Dst-port="5062" Detail="TCP Connecting"
2017-09-19T10:28:35.295-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:28:35,289" Module="network.tcp" Level="ERROR":  Src-ip="172.16.2.2" Src-port="25026" Dst-ip="146.20.193.70" Dst-port="5062" Detail="TCP Connection Failed"

また、図に示すように、診断ログ バンドルに含まれていた tcpdump を使用して、TCP ハンドシェイクについての詳細情報をいくつか得ることもできます。

この時点で、Expressway-E がコールを正しくルーティングしていると判断できます。このシナリオで問題となるのは、Webex 環境で TCP 接続を確立できないことです。その原因として、Webex 環境が TCP SYN パケットに応答していないことが考えられますが、接続を処理しているサーバが多数の顧客間で共有されていることを考慮すると、その可能性は小さいと考えられます。このシナリオで可能性の高い原因として考えられるのは、何らかのタイプの中間デバイス（ファイアウォール、IPS など）で発信トラフィックが許可されていないことです。 

解決方法

問題を分離したので、このデータをお客様のネットワーク管理者に提供する必要があります。また、お客様がより詳しい情報を必要としている場合は、さらに証明を裏付けるために、エッジ デバイスやファイアウォールの外部インターフェイスからキャプチャを取得することができます。Expressway の観点から見た場合、この問題はそのデバイスには存在しないため、これ以上必要な作業はありません。 

問題 3： Expressway-E の検索ルールが正しく設定されていない

検索ルールの設定の誤りは、Expressway の設定に関連する一番大きな問題の 1 つです。検索ルールの設定の問題は双方向になる可能性があります。これは、着信コールの検索ルールが必要であり、発信コールの検索ルールが必要だからです。この問題を調べていくと、Expressway では正規表現の問題がよく発生しますが、それらが必ずしも検索ルールの問題の原因だとは限らないことがわかります。ここでは特に、失敗している発信コールについて詳しく説明します。他のすべてのフォークされた発信コールのシナリオと同様に、症状は同じです。

• 着信ユーザの Cisco Webex アプリに [参加（Join）] ボタンが表示された
• 発信側の電話に着信音が送り返されていた
• 着信ユーザのオンプレミス電話機では着信音が鳴っていた
• 着信ユーザの Cisco Webex アプリでは着信音が鳴らなかった

他のすべてのシナリオと同様に、Expressway-C および E の診断ログに加えて CUCM SDL トレースを利用することもできます。前と同様に、検索履歴の活用のヒントや、診断ログでコールを特定するためのヒントを参照してください。前と同様に、Expressway-E の検索履歴を使用した結果、このコールはそこから発信していて失敗していると判断されました。次に示すのは分析の最初の部分です。この部分について、Expressway-C から Expressway-E に送られている最初の SIP INVITE を調べることができます。

2017-09-25T11:26:02.959-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,959" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="25675" Msg-Hash="1536984498381728689"
 SIPMSG:
 |INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK1c7bf93ff08014ca5e00bb0b5f8b184b272412.a81f2992e3863ac202a000a3dd599763;proxy-call-id=f79b8631-947b-46d4-a888-911bf0150bfe;rport
 Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1c8c419938648;received=192.168.1.21;ingress-zone=CUCM11
 Call-ID: d58f2680-9c91200a-1c7ba-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
 Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off
 Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio
 From: "Jonathan Robb" 
     
     
       ; 
     tag=505817~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106972
 To: 
     
     
 Max-Forwards: 15
 Record-Route: <sip:proxy-call-id=f79b8631-947b-46d4-a888-911bf0150bfe@192.168.1.5:5061;transport=tls;lr>
 Record-Route: <sip:proxy-call-id=f79b8631-947b-46d4-a888-911bf0150bfe@192.168.1.5:5060;transport=tcp;lr>
 Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
 User-Agent: Cisco-CUCM11.5
 Expires: 180
 Date: Mon, 25 Sep 2017 15:26:02 GMT
 Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,X-cisco-original-called
 Session-Expires: 1800
 Min-SE: 1800
 Allow-Events: presence
 X-TAATag: 8e8c014d-5d01-4581-8108-5cb096778fc5
 Session-ID: 75957d4fb66a13e835c10737aa505813;remote=00000000000000000000000000000000
 Cisco-Guid: 3582928512-0000065536-0000000240-0352430272
 Content-Type: application/sdp
 Content-Length: 714
 
<SDP Omitted>

SIPヘッダーのコールID(d58f2680-9c91200a-1c7ba-1501a8c0)を使用すると、このダイアログに関連するすべてのメッセージをすばやく検索できます。コール ID のログで 3 つ目のヒット箇所を見てみると、Expressway-E から即座に 404 Not Found が Expressway-C に送信されていることがわかります。 

2017-09-25T11:26:13.286-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:13,286" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="192.168.1.6" Local-port="7003" Dst-ip="192.168.1.5" Dst-port="25675" Msg-Hash="12372154521012287279"
 SIPMSG:
 |SIP/2.0 404 Not Found
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK1c7bf93ff08014ca5e00bb0b5f8b184b272412.a81f2992e3863ac202a000a3dd599763;proxy-call-id=f79b8631-947b-46d4-a888-911bf0150bfe;received=192.168.1.5;rport=25675;ingress-zone=HybridCallServiceTraversal
 Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1c8c419938648;received=192.168.1.21;ingress-zone=CUCM11
 Call-ID: d58f2680-9c91200a-1c7ba-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 From: "Jonathan Robb" 
     
     ;tag=505817~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106972
 To: 
     
     
       >;tag=10d2cfbc45e4373f 
       Server: TANDBERG/4135 (X8.10.2) Warning: 399 192.168.1.6:7003 "Policy Response" Session-ID: 00000000000000000000000000000000;remote=75957d4fb66a13e835c10737aa505813 Content-Length: 0 
     

*c xConfiguration Zones Policy SearchRules Rule 6 Authentication: "No"
*c xConfiguration Zones Policy SearchRules Rule 6 Description: "Outbound calls to Webex"
*c xConfiguration Zones Policy SearchRules Rule 6 Mode: "AliasPatternMatch"
*c xConfiguration Zones Policy SearchRules Rule 6 Name: "Webex Hybrid - to Webex Cloud"
*c xConfiguration Zones Policy SearchRules Rule 6 Pattern Behavior: "Leave"
*c xConfiguration Zones Policy SearchRules Rule 6 Pattern Replace: 
*c xConfiguration Zones Policy SearchRules Rule 6 Pattern String: ".*@.*\.ciscospark\.com"
*c xConfiguration Zones Policy SearchRules Rule 6 Pattern Type: "Regex"
*c xConfiguration Zones Policy SearchRules Rule 6 Priority: "101"
*c xConfiguration Zones Policy SearchRules Rule 6 Progress: "Stop"
*c xConfiguration Zones Policy SearchRules Rule 6 Protocol: "SIP"
*c xConfiguration Zones Policy SearchRules Rule 6 SIPTrafficType: "Any"
*c xConfiguration Zones Policy SearchRules Rule 6 Source Mode: "Named"
*c xConfiguration Zones Policy SearchRules Rule 6 Source Name: "Hybrid Call Service Traversal"
*c xConfiguration Zones Policy SearchRules Rule 6 State: "Enabled"
*c xConfiguration Zones Policy SearchRules Rule 6 SystemGenerated: "No"
*c xConfiguration Zones Policy SearchRules Rule 6 Target Name: "Hybrid Call Services DNS"
*c xConfiguration Zones Policy SearchRules Rule 6 Target SIPVariant: "Any"
*c xConfiguration Zones Policy SearchRules Rule 6 Target Type: "Zone"

2017-09-25T11:26:02.966-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,966" Module="network.search" Level="DEBUG":  Detail="Search rule 'B2B calls to VCS-C' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-25T11:26:02.966-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,966" Module="network.search" Level="DEBUG":  Detail="Search rule 'Webex Hybrid' ignored due to source filtering"
2017-09-25T11:26:02.966-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,966" Module="network.search" Level="DEBUG":  Detail="Search rule 'Calls to Webex' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-25T11:26:02.967-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,967" Module="network.search" Level="DEBUG":  Detail="Considering search rule 'to DNS' towards target 'DNS' at priority '100' with alias 'pstojano-test@dmzlab.call.ciscospark.com'"

2017-09-25T11:26:02.968-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,968" Module="network.dns" Level="DEBUG": Detail="Sending DNS query" Name="dmzlab.call.ciscospark.com" Type="NAPTR (IPv4 and IPv6)"
2017-09-25T11:26:02.982-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,982" Module="network.dns" Level="DEBUG": Detail="Could not resolve hostname"
2017-09-25T11:26:02.982-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,982" Module="network.dns" Level="DEBUG": Detail="Sending DNS query" Name="_sips._tcp.dmzlab.call.ciscospark.com" Type="SRV (IPv4 and IPv6)"

*c xConfiguration Zones Policy SearchRules Rule 1 Authentication: "No"
*c xConfiguration Zones Policy SearchRules Rule 1 Description: 
*c xConfiguration Zones Policy SearchRules Rule 1 Mode: "AliasPatternMatch"
*c xConfiguration Zones Policy SearchRules Rule 1 Name: "to DNS"
*c xConfiguration Zones Policy SearchRules Rule 1 Pattern Behavior: "Leave"
*c xConfiguration Zones Policy SearchRules Rule 1 Pattern Replace: 
*c xConfiguration Zones Policy SearchRules Rule 1 Pattern String: "(?!.*@%localdomains%.*$).*"
*c xConfiguration Zones Policy SearchRules Rule 1 Pattern Type: "Regex"
*c xConfiguration Zones Policy SearchRules Rule 1 Priority: "100"
*c xConfiguration Zones Policy SearchRules Rule 1 Progress: "Stop"
*c xConfiguration Zones Policy SearchRules Rule 1 Protocol: "Any"
*c xConfiguration Zones Policy SearchRules Rule 1 SIPTrafficType: "Any"
*c xConfiguration Zones Policy SearchRules Rule 1 Source Mode: "Any"
*c xConfiguration Zones Policy SearchRules Rule 1 Source Name: "Please Select"
*c xConfiguration Zones Policy SearchRules Rule 1 State: "Enabled"
*c xConfiguration Zones Policy SearchRules Rule 1 SystemGenerated: "No"
*c xConfiguration Zones Policy SearchRules Rule 1 Target Name: "DNS"
*c xConfiguration Zones Policy SearchRules Rule 1 Target SIPVariant: "Any"
*c xConfiguration Zones Policy SearchRules Rule 1 Target Type: "Zone"

*c xConfiguration Zones Policy SearchRules Rule 1 Name: "to DNS"
*c xConfiguration Zones Policy SearchRules Rule 1 Priority: "100"
*c xConfiguration Zones Policy SearchRules Rule 1 Progress: "Stop"

*c xConfiguration Zones Policy SearchRules Rule 6 Name: "Webex Hybrid - to Webex Cloud"
*c xConfiguration Zones Policy SearchRules Rule 6 Priority: "101"
*c xConfiguration Zones Policy SearchRules Rule 6 Progress: "Stop"

2017-09-25T16:54:43.722-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,722" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26404" Msg-Hash="17204952472509519266"
 SIPMSG:
 |INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK781a130d234ed9aaec86834368739430283256.34216c32a0de36e16590bae36df388b6;proxy-call-id=3bbbf94a-082e-4088-8f5a-5ea7e82f8aac;rport
 Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1cf344a8b117e;received=192.168.1.21;ingress-zone=CUCM11
 Call-ID: c030f100-9c916d13-1cdcb-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
 Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off
 Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio
 From: "Jonathan Robb" 
      
      ;tag=512579~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30107000
 To: 
      
      
 Max-Forwards: 15
 Record-Route: <sip:proxy-call-id=3bbbf94a-082e-4088-8f5a-5ea7e82f8aac@192.168.1.5:5061;transport=tls;lr>
 Record-Route: <sip:proxy-call-id=3bbbf94a-082e-4088-8f5a-5ea7e82f8aac@192.168.1.5:5060;transport=tcp;lr>
 Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
 User-Agent: Cisco-CUCM11.5
 Expires: 180
 Date: Mon, 25 Sep 2017 20:54:43 GMT
 Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,X-cisco-original-called
 Session-Expires: 1800
 Min-SE: 1800
 Allow-Events: presence
 X-TAATag: 4fffefed-0512-4067-ac8c-35828f0a1150
 Session-ID: 75957d4fb66a13e835c10737aa512577;remote=00000000000000000000000000000000
 Cisco-Guid: 3224432896-0000065536-0000000264-0352430272
 Content-Type: application/sdp
 Content-Length: 714

<SDP Omitted>

2017-09-25T16:54:43.727-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,727" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="192.168.1.6" Local-port="7003" Dst-ip="192.168.1.5" Dst-port="26404" Msg-Hash="9195436101110134622"
 SIPMSG:
 |SIP/2.0 403 Forbidden
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK781a130d234ed9aaec86834368739430283256.34216c32a0de36e16590bae36df388b6;proxy-call-id=3bbbf94a-082e-4088-8f5a-5ea7e82f8aac;received=192.168.1.5;rport=26404;ingress-zone=HybridCallServiceTraversal
 Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1cf344a8b117e;received=192.168.1.21;ingress-zone=CUCM11
 Call-ID: c030f100-9c916d13-1cdcb-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 From: "Jonathan Robb" 
      
      ;tag=512579~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30107000
 To: 
      
      ;tag=64fe7f9eab37029d
 Server: TANDBERG/4135 (X8.10.2)
 Warning: 399 192.168.1.6:7003 "Policy Response"
 Session-ID: 00000000000000000000000000000000;remote=75957d4fb66a13e835c10737aa512577
 Content-Length: 0

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,725" Module="network.cpl" Level="DEBUG":  Remote-ip="192.168.1.5" Remote-port="26404" Detail="CPL: 
      
      
        " 
      
2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,725" Module="network.cpl" Level="DEBUG":  Remote-ip="192.168.1.5" Remote-port="26404" Detail="CPL: 
      
      
        " 
      
2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,726" Module="network.cpl" Level="DEBUG":  Remote-ip="192.168.1.5" Remote-port="26404" Detail="CPL: 
      
      
        matched " 
      
2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,726" Module="network.cpl" Level="DEBUG":  Remote-ip="192.168.1.5" Remote-port="26404" Detail="CPL: 
      
       "

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: Event="Search Completed" Reason="Forbidden" Service="SIP" Src-alias-type="SIP" Src-alias="5010@rtp.ciscotac.net" Dst-alias-type="SIP" Dst-alias="sip:pstojano-test@dmzlab.call.ciscospark.com" Call-serial-number="48c80582-ec79-4d89-82e2-e5546f35703c" Tag="4fffefed-0512-4067-ac8c-35828f0a1150" Detail="found:false, searchtype:INVITE, Info:Policy Response" Level="1" UTCTime="2017-09-25 20:54:43,726"
2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: Event="Call Rejected" Service="SIP" Src-ip="192.168.1.5" Src-port="26404" Src-alias-type="SIP" 

*c xConfiguration Policy AdministratorPolicy Mode: "LocalCPL"

2017-09-19T10:46:10.488-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:46:10,488" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="172.16.2.2" Local-port="25034" Dst-ip="146.20.193.64" Dst-port="5062" Msg-Hash="4309505007645007056"
SIPMSG:
INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
Via: SIP/2.0/TLS 64.102.241.236:5062;egress-zone=HybridCallServicesDNS;branch=z9hG4bK323e6b15ad0cbbf409751f67848136fa1115;proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2;rport
Via: SIP/2.0/TLS 172.16.2.2:5073;branch=z9hG4bK350703fe46645f0acddef05b35adc5c157;x-cisco-local-service=nettle;received=172.16.2.2;rport=41511;ingress-zone=DefaultZone
Via: SIP/2.0/TLS 192.168.1.6:5061;egress-zone=DefaultZone;branch=z9hG4bKf71f2bf47233d6ca52b579364594ac6c1114.a402e3f25603f5a77b60b17ea47dbf72;proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb;received=192.168.1.6;rport=25025
Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKfcf4cfd09d213a88bd2331cef0bc82b540559.494a140082bd66357134b9eed4335df8;proxy-call-id=d4d4e950-babc-45d5-a4a7-c60a8b17a8bd;received=192.168.1.5;rport=26513;ingress-zone=HybridCallServiceTraversal
Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12dd82194c4f7;received=192.168.1.21;ingress-zone=CUCM11
Call-ID: 44bdd400-9c112db1-12d95-1501a8c0@192.168.1.21
CSeq: 101 INVITE
Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;privacy=off;screen=no;party=calling
Contact: <sip:172.16.2.2:5073;transport=tls>;video;audio
From: "Jonathan Robb" 
      
      
        ;tag=329447~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106833 To: 
        
      
Max-Forwards: 14
Record-Route: <sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2@64.102.241.236:5062;transport=tls;lr>
Record-Route: <sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2@172.16.2.2:5061;transport=tls;lr>
Allow: INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY
User-Agent: TANDBERG/4352 (X8.10.2-b2bua-1.0)
Supported: X-cisco-srtp-fallback,replaces,timer
Session-Expires: 1800;refresher=uac
Min-SE: 500
X-TAATag: 14a0bd87-1825-4ecf-9f3d-4a23cfa69725
Session-ID: 75957d4fb66a13e835c10737aa329445;remote=00000000000000000000000000000000
Content-Type: application/sdp
Content-Length: 1407

v=0
o=tandberg 0 1 IN IP4 64.102.241.236
s=-
c=IN IP4 64.102.241.236
b=AS:384
t=0 0
m=audio 52668 RTP/SAVP 18 101  <-- CUCM is only supporting G.729 for this call
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:.............................................
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:............................................. UNENCRYPTED_SRTCP
a=crypto:3 AES_CM_128_HMAC_SHA1_32 inline:.............................................
a=crypto:4 AES_CM_128_HMAC_SHA1_32 inline:............................................. UNENCRYPTED_SRTCP
a=sendrecv
a=rtcp:52669 IN IP4 64.102.241.236
m=video 52670 RTP/SAVP 126 97
b=TIAS:384000
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=42801e;packetization-mode=1;level-asymmetry-allowed=1
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801e;packetization-mode=0;level-asymmetry-allowed=1
a=rtcp-fb:* nack pli
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:.............................................
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:............................................. UNENCRYPTED_SRTCP
a=crypto:3 AES_CM_128_HMAC_SHA1_32 inline:.............................................
a=crypto:4 AES_CM_128_HMAC_SHA1_32 inline:............................................. UNENCRYPTED_SRTCP
a=sendrecv
a=content:main
a=label:11
a=rtcp:52671 IN IP4 64.102.241.236

2017-09-19T10:46:27.073-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:46:27,072" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="172.16.2.2" Local-port="25034" Src-ip="146.20.193.64" Src-port="5062" Msg-Hash="5236578200712291002"
SIPMSG:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 64.102.241.236:5062;egress-zone=HybridCallServicesDNS;branch=z9hG4bK323e6b15ad0cbbf409751f67848136fa1115;proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2;rport=38245;received=192.168.5.26,SIP/2.0/TLS 172.16.2.2:5073;branch=z9hG4bK350703fe46645f0acddef05b35adc5c157;x-cisco-local-service=nettle;received=172.16.2.2;rport=41511;ingress-zone=DefaultZone,SIP/2.0/TLS 192.168.1.6:5061;egress-zone=DefaultZone;branch=z9hG4bKf71f2bf47233d6ca52b579364594ac6c1114.a402e3f25603f5a77b60b17ea47dbf72;proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb;received=192.168.1.6;rport=25025,SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKfcf4cfd09d213a88bd2331cef0bc82b540559.494a140082bd66357134b9eed4335df8;proxy-call-id=d4d4e950-babc-45d5-a4a7-c60a8b17a8bd;received=192.168.1.5;rport=26513;ingress-zone=HybridCallServiceTraversal,SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12dd82194c4f7;received=192.168.1.21;ingress-zone=CUCM11
Call-ID: 44bdd400-9c112db1-12d95-1501a8c0@192.168.1.21
CSeq: 101 INVITE
Contact: "l2sip-UA" <sip:l2sip-UA@l2sip-cfa-01.wbx2.com:5062;transport=tls>
From: "Jonathan Robb" 
      
      
        ;tag=329447~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106833 To: 
       
         ;tag=1311451760 
        
      
Record-Route: <sip:l2sip-cfa-01.wbx2.com:5062;transport=tls;lr>,<sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2@64.102.241.236:5062;transport=tls;lr>,<sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2@172.16.2.2:5061;transport=tls;lr>
Allow: INVITE,ACK,CANCEL,BYE,REFER,INFO,OPTIONS,NOTIFY,SUBSCRIBE
User-Agent: Cisco-L2SIP
Supported: replaces
Accept: application/sdp
Allow-Events: kpml
Session-ID: ed35426ed3ade6fdc3b058792333df2b;remote=75957d4fb66a13e835c10737aa329445
Locus: 4711a33f-9d49-11e7-9bf6-dea12d0f2127
Locus-Type: CALL
Content-Type: application/sdp
Content-Length: 503

v=0
o=linus 0 1 IN IP4 146.20.193.109
s=-
c=IN IP4 146.20.193.109
b=TIAS:384000
t=0 0
m=audio 0 RTP/SAVP *      <-- Webex is zeroing this port out
m=video 33512 RTP/SAVP 108
c=IN IP4 146.20.193.109
b=TIAS:384000
a=content:main
a=sendrecv
a=rtpmap:108 H264/90000
a=fmtp:108 profile-level-id=42001E;packetization-mode=1;max-mbps=40500;max-fs=1620;max-fps=3000;max-br=10000;max-dpb=3037;level-asymmetry-allowed=1
a=rtcp-fb:* nack pli
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:........................................
a=label:200

2017-09-19T10:46:27.175-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:46:27,175" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26513" Msg-Hash="237943800593485079"
SIPMSG:
BYE sip:192.168.1.6:5071;transport=tls SIP/2.0
Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK90a666b3461356f8cd605cec91e4538240575.494a140082bd66357134b9eed4335df8;proxy-call-id=d4d4e950-babc-45d5-a4a7-c60a8b17a8bd;rport
Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12ddd10269d39;received=192.168.1.21;ingress-zone=CUCM11
Call-ID: 44bdd400-9c112db1-12d95-1501a8c0@192.168.1.21
CSeq: 102 BYE
From: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;tag=329447~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106833
To: <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=f3734601fb0eb541
Max-Forwards: 69
Route: <sip:proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb@192.168.1.6:7003;transport=tls;lr>,<sip:proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb@192.168.1.6:5061;transport=tls;lr>
User-Agent: Cisco-CUCM11.5
Date: Tue, 19 Sep 2017 14:46:09 GMT
X-TAATag: 14a0bd87-1825-4ecf-9f3d-4a23cfa69725
Reason: Q.850 ;cause=47
Session-ID: 75957d4fb66a13e835c10737aa329445;remote=ed35426ed3ade6fdc3b058792333df2b
Content-Length: 0

CUCM Traces
53138762.000 |09:05:19.762 |AppInfo  |SIPSocketProtocol(5,100,14,707326)::handleReadComplete send SdlReadRsp: size 5000
53138763.000 |09:05:19.762 |SdlSig   |SdlReadRsp                             |wait                           |SIPTcp(5,100,71,1)               |SdlTCPConnection(5,100,14,707326) |5,100,14,707326.4^10.36.100.140^*        |*TraceFlagOverrode
53138763.001 |09:05:19.762 |AppInfo  |SIPTcp - SdlRead bufferLen=5000
53138763.002 |09:05:19.762 |AppInfo  |//SIP/Stack/Error/0x0/httpish_cache_header_val: DROPPING unregistered header Locus: c904ecb1-d286-11e6-bfdf-b60ed914549d
53138763.003 |09:05:19.762 |AppInfo  |//SIP/Stack/Info/0x0/httpish_msg_process_network_msg: Content Length 4068, Bytes Remaining 3804
53138763.004 |09:05:19.762 |AppInfo  |//SIP/Stack/Info/0x0/ccsip_process_network_message: process_network_msg: not complete
53138763.005 |09:05:19.762 |AppInfo  |SIPTcp - Ignoring large message from %Expressway-C_IP%:[5060]. Only allow up to 5000 bytes. Resetting connection.

Expressway-E Traces
2017-01-04T09:05:40.645-05:00 vcs-expressway tvcs: UTCTime="2017-01-04 14:05:40,645" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="%Exp-E%" Local-port="25150" Src-ip="%Webex_IP%" Src-port="5062" Msg-Hash="2483073756671246315"
SIPMSG:
SIP/2.0 603 Decline

 SIPMSG:
 |INVITE sip:jorobb@rtp.ciscotac.net SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKcac6d95278590991a2b516cf57e75827371;proxy-call-id=abcba873-eaae-4d64-83b4-c4541d4e620c;rport
 Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bK837b03f2cd91b6b19be4fc58edb251bf12;x-cisco-local-service=nettle;received=192.168.1.6;rport=41913;ingress-zone=DefaultZone
 Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK524f89592d00ffc45b7b53000271676c370.88b5177ac4d7cfcae1eb8f8be78da055;proxy-call-id=2db939b2-a49b-4307-8d96-23716a2c090b;received=172.16.2.2;rport=25010
 Via: SIP/2.0/TLS 192.168.4.150:5062;branch=z9hG4bK92f9ef952712e6610c3e6b72770c1230;received=148.62.40.63;rport=39986;ingress-zone=HybridCallServicesDNS
 Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-313634-3d27a6f914badee6420287903c9c6a45;rport=45939
 Call-ID: 3e613afb185751cdf019b056285eb574@127.0.0.1
 CSeq: 1 INVITE
 Contact: <sip:192.168.1.6:5073;transport=tls>
 From: "pstojano test" <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=145765215
 To: <sip:jorobb@rtp.ciscotac.net>
 Max-Forwards: 15
 Route: 
      
      

Search (1)
State: Completed
Found: True
Type: SIP (OPTIONS)
SIPVariant: Standards-based
CallRouted: True
CallSerial Number: ae73fb64-c305-457a-b7b3-59ea9688c630
Tag: 473a5b19-9a37-40bf-bbee-6f7bc94e7c77
Source (1)
Authenticated: True
Aliases (1)
Alias (1)
Type: Url
Origin: Unknown
Value: xcom-locate
Zone (1)
Name: Hybrid Call Service Traversal
Type: TraversalClient
Path (1)
Hop (1)
Address: 127.0.0.1
Destination (1)
Alias (1)
Type: Url
Origin: Unknown
Value: sip:cucm.rtp.ciscotac.net
StartTime: 2017-09-24 09:51:18
Duration: 0.01
SubSearch (1)
Type: Transforms
Action: Not Transformed
ResultAlias (1)
Type: Url
Origin: Unknown
Value: cucm.rtp.ciscotac.net
SubSearch (1)
Type: Admin Policy
Action: Proxy
ResultAlias (1)
Type: Url
Origin: Unknown
Value: cucm.rtp.ciscotac.net
SubSearch (1)
Type: FindMe
Action: Proxy
ResultAlias (1)
Type: Url
Origin: Unknown
Value: cucm.rtp.ciscotac.net
SubSearch (1)
Type: Search Rules
SearchRule (1)
Name: as is local
Zone (1)
Name: LocalZone
Type: Local
Protocol: SIP
Found: False
Reason: Not Found
StartTime: 2017-09-24 09:51:18
Duration: 0
Gatekeeper (1)
Address: 192.168.1.5:0
Alias (1)
Type: Url
Origin: Unknown
Value: cucm.rtp.ciscotac.net
Zone (2)
Name: LocalZone
Type: Local
Protocol: H323
Found: False
Reason: Not Found
StartTime: 2017-09-24 09:51:18
Duration: 0
Gatekeeper (1)
Address: 192.168.1.5:0
Alias (1)
Type: Url
Origin: Unknown
Value: cucm.rtp.ciscotac.net
SearchRule (2)
Name: Hybrid Call Service Inbound Routing
Zone (1)
Name: CUCM11
Type: Neighbor
Protocol: SIP
Found: True
StartTime: 2017-09-24 09:51:18
Duration: 0
Gatekeeper (1)
Address: 192.168.1.21:5065
Alias (1)
Type: Url
Origin: Unknown
Value: cucm.rtp.ciscotac.net