Cisco Webex混合呼叫服務連線故障排除指南

簡介

本文檔介紹思科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（聯結器主機） — 有關當前支援的版本，請參閱適用於Cisco Webex混合服務的Expressway聯結器主機支援

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• 思科整合通訊管理員
• 高速公路
• Windows版Webex
• Webexfor Mac
• Webexfor iOS
• Android版Webex
• 思科協同合作端點
• 協同合作案頭終端
• IP電話
• 軟體使用者端
  
  

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

該解決方案提供以下功能：

• 將Webex應用用作音訊和影片呼叫的移動軟客戶端
• 使用該應用從任何地方發出和接收呼叫，就像他們在辦公室一樣
• 使用Webex、Cisco Jabber或其案頭電話進行呼叫，無需擔心使用哪個選項
• 解鎖本地電話中的呼叫歷史記錄，並將該歷史記錄整合到Webex中

本指南涵蓋混合呼叫服務連線獨有的問題。由於混合呼叫服務連線與其他解決方案（如移動和遠端訪問以及企業到企業呼叫）運行在同一個Expressway E & C對上，因此其他解決方案的問題可能會影響混合呼叫服務連線。對於部署Expressway對以與呼叫服務連線配合使用的客戶和合作夥伴，在嘗試部署混合呼叫服務連線之前，必須參考Cisco VCS Expressway和VCS控制基本配置指南。本故障排除指南在附錄3和4中介紹了防火牆/NAT注意事項以及Expressway設計。請詳細閱讀此文檔。此外，本文檔還假設Expressway聯結器主機和混合呼叫服務啟用已完成。 

呼叫建立問題

相互TLS握手失敗

混合呼叫服務連線在Cisco Webex和Expressway-E之間使用相互傳輸層安全（相互TLS）進行身份驗證。這表示Expressway-E和Cisco Webex都會檢查並檢查彼此存在的證書。由於Expressway伺服器的新部署以及混合呼叫服務連線等解決方案的啟用期間普遍存在相互TLS問題，因此本節提供有用的資訊和提示，用於排除Expressway和Cisco Webex之間的證書問題。

Expressway-E檢查什麼？

• Cisco Webex證書是否由Expressway-E Trusted CA清單中列出的公共CA簽署？
• callservice.ciscospark.com是否在Cisco Webex證書的Subject Alternate Name欄位中？

Cisco Webex會檢查什麼？

• Expressway-E證書是否由Webex信任的一個公共CA簽署？(Cisco Webex受信任CA清單)
• 如果Expressway-E不使用公開簽名的證書，Expressway證書是否與任何根證書和中間證書一起上傳到Cisco Webex控制中心(https://admin.ciscospark.com)?

如下圖所示，對此進行解釋。

有用的雙向TLS故障排除提示

1.解碼雙向TLS握手

預設情況下，Wireshark將SIP TLS流量標籤為埠5061。這意味著，無論何時您想要分析在埠5062上發生的（相互）TLS握手，Wireshark都不會知道如何正確解碼流量。以下是發生於連線埠5062上的相互TLS握手的範例，如下圖所示。

您可以看到，這就是握手在Wireshark中預設設定的顯示方式。資料包編號175是Expressway傳送到Cisco Webex的證書。但是，如果沒有對流量進行解碼，則無法確定這一點。可以使用兩種方法解碼此流量，以便您更容易看到證書資訊和出現的任何錯誤消息。

1a。將流解碼為SSL

a.分析相互TLS握手時，首先按tcp.port==5062過濾捕獲。然後，按一下右鍵流中的第一個資料包，然後選擇解碼為…… 如下圖所示。

b.選擇解碼為……選項後，您會看到一個清單，您可以在其中選擇如何解碼您選擇的流。從清單中選擇SSL，然後按一下Apply並關閉視窗。此時，整個流顯示握手時交換的證書和錯誤消息，如下圖所示。

1b。調整SIP TLS埠

當您在Wireshark首選項中將SIP TLS埠調整為5062時，您可以看到握手的所有詳細資訊，包括證書。若要進行此更改：

• 開啟Wireshark
• 導航到「編輯」>「首選項」
• 展開協定並選擇SIP
• 將SIP TLS埠設定為5062，然後按一下Apply
• 分析完成時將值設回5061，如下圖所示。

如果現在分析相同的捕獲，您會看到資料包169到175已解碼。封包175顯示Expressway-E憑證，如果對封包進行向下鑽取，可以參閱圖中所示的所有憑證詳細資訊。

2. Wireshark過濾

當您分析資料包捕獲時，在給定捕獲中觀察到的資料包數量之多很容易丟失。瞭解您最感興趣的流量型別是非常重要的，這樣您就可以過濾Wireshark來顯示該流量。以下是一些常用的Wireshark過濾器，可用於獲取關於雙方TLS握手的詳細資訊：

• tcp.port==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伺服器地址並在「資訊」部分中列印了證書的資料包。
3. 在資料包詳細資訊中，展開安全套接字層> TLS證書>握手協定>證書。

   附註：鏈中的底部/最後一個憑證是根CA。

4. 按一下右鍵感興趣的證書，然後選擇Export Selected Packet Bytes...（匯出選定的資料包位元組……），如下圖所示。

5.將檔案儲存為.cer。

6.按兩下儲存的檔案以開啟證書，如下圖所示。

4.調整Expressway日誌記錄級別

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連線。搜尋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 Certificates選項，如下圖所示。

此時，Cisco Webex證書頒發機構上傳到Expressway-E受信任CA儲存(維護>安全>受信任CA證書)。

問題2. Expressway-E Cisco Webex混合DNS區域上的TLS主體驗證名稱不正確 

作為雙向TLS握手的一部分，混合呼叫服務連線使用TLS驗證。這意味著除了信任Cisco Webex CA證書外，Expressway還會通過檢查所顯示的證書的Subject Alternate Name(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，則可以查詢「區域配置」部分以確定如何配置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驗證主題名稱設定為callservice.ciscospark.com，而不是callservice.ciscospark.com。（注意額外的「l」）。

解決方案：

為了解決此問題，必須修改TLS驗證使用者名稱：

• 登入Expressway-E
• 導航到Configuration > Zones > Zones
• 選擇Webex Hybrid Services DNS Zone
• 將TLS驗證主題名稱設定為callservice.ciscospark.com
• 選擇儲存

附註：有關基線日誌記錄行為，請參閱。本節顯示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在TLS握手期間僅傳送其證書，儘管其證書是由公共CA簽名的。為了傳送完整的憑證鏈結（根憑證和中間憑證），必須在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會拒絕此TLS握手，並顯示「未知CA」錯誤訊息，如下圖所示。

解決方案：

為了解決此案例中的問題，您必須將簽署Expressway-E證書所涉及的中間和根CA上傳到受信任CA證書庫：

步驟1.登入Expressway-E。
步驟2.導覽至Maintenance > Security > Trusted CA certificate。
步驟3.選擇UI底部附近Upload選單下的Choose File。
步驟4.選擇簽署Expressway-E時涉及的CA證書。
步驟5.選擇附加CA憑證。
步驟6.對簽署Expressway-E證書時涉及的所有CA證書（中間、根）重複步驟。
步驟7.選擇附加CA憑證。

完成此過程後，您會看到在金鑰交換中包含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出示了證書。您可以看到來自Cisco Webex方向的TCP RST，如下圖所示。 

乍一看，您可能會認為Expressway-E證書存在問題。若要解決此問題，您必須首先確定這些問題的答案：

• Expressway-E是否由Cisco Webex信任的公共CA簽署？
• Expressway-E證書和簽署Expressway-E證書涉及的任何證書是否手動上傳到Cisco Webex控制中心(https://admin.ciscospark.com)? 

在此特定情況下，解決方案不是使用Cisco Webex控制中心來管理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控制和Expressway部署指南》的附錄4說明建議客戶關閉此功能的原因。

問題5. Expressway-E由公共CA簽署，但Cisco Webex控制中心載入了備用證書

當您從頭開始部署Expressway解決方案，並且最初沒有公共CA簽名的Expressway-E證書時，經常會發生此特殊情況。在此場景中，您將Expressway-E伺服器證書（已在內部簽名）上傳到Cisco Webex控制中心，以便成功完成雙方TLS協商。之後，您最終會獲得由公共CA簽名的Expressway-E證書，但是您忘記從Cisco Webex控制中心移除伺服器證書。必須瞭解的是，如果將證書上傳到Cisco Webex控制中心，該證書將優先於Expressway在TLS握手期間顯示的證書和鏈。

從Expressway-E診斷日誌記錄角度來看，此問題可能類似於在Cisco Webex不信任Expressway-E證書時遇到的日誌記錄簽名，例如Expressway-E未傳送其完整鏈或Expressway-E證書未由Cisco Webex信任的公共CA簽名的情況。以下是您在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傳送的證書資料包，則可以展開證書資訊以確定Expressway-E

1.由Cisco Webex信任的公共CA簽署，且

2.把整個鍊子加在簽名中

在這種情況下，滿足這兩個條件。這表明Expressway-E證書沒有錯誤。

解決方案

步驟1.登入Cisco Webex Control Hub。
步驟2.從左窗格中選擇Services。

步驟3.在混合呼叫卡下選擇Settings。

步驟4.滾動到Call Service Connect部分，檢視Certificates for Encrypted SIP Calls下方，檢視是否列出了不需要的證書。如果是，請按一下證書旁邊的垃圾桶圖示。

步驟5.選擇Remove。

附註：執行分析非常重要，確定客戶在刪除之前不使用上傳到Webex控制中心的證書。

有關在Cisco Webex控制中心中上傳Expressway-E證書的詳細資訊，請檢視混合呼叫部署指南的此部分。

問題6. Expressway未將入站呼叫對映到Cisco Webex混合DNS區域

入站TLS對映功能與TLS驗證主題名稱配合使用，兩者均在混合呼叫DNS區域上配置。此場景說明了x12.5之前的Expressway所觀察到的問題和挑戰。在x12及更高版本中，實施了一種稱為「Webex」區域的新區域型別。該區域預填充與Webex整合所需的所有配置。如果您正在運行x12.5並部署Webex混合呼叫，建議使用Webex Zone型別，以便自動配置混合呼叫服務域(callservice.webex.com)。此值與雙向TLS握手期間提供的Webex證書的「主體替代名稱」相匹配，並允許成功連線到Expressway和入站對映。 

如果您使用的是x12.5以下的任何代碼版本，或者沒有使用Webex區域，則您需要繼續下面的說明，演示如何識別和糾正Expressway未將入站呼叫對映到Webex混合DNS區域的問題。 

該功能分為三個步驟：

1. Expressway-E接受Cisco Webex證書。
2. Expressway-E檢查Cisco Webex證書以確定是否存在與TLS驗證使用者名稱匹配的使用者替代名稱：callservice.ciscospark.com。
3. Expressway-E通過Cisco Webex混合DNS區域對映入站連線。

如果驗證不成功，則表示憑證驗證失敗。如果在Expressway-E上配置了Business-to-business，則呼叫進入預設區域，並根據為Business-to-Business方案提供的搜尋規則進行路由。

與其他情況一樣，您必須同時使用診斷日誌記錄和資料包捕獲來確定此故障的樣子，然後使用資料包捕獲來檢視哪一端正在傳送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的情況。否則，您會看到類似「憑證鏈結中的自簽署憑證」的錯誤。 您可以挖掘封包詳細資訊，如圖所示。

按一下Webex伺服器憑證並將其展開以檢視使用者替代名稱(dnsName)，可以驗證以確保已列出callservice.ciscospark.com。

導航至Wireshark:Certificate > Extension > General Names > GeneralName > dNSName:callservice.ciscospark.com 

這完全證實Webex憑證看起來正常。

您現在可以確認TLS驗證使用者名稱是正確的。如上所述，如果您有xConfiguration，則可以查詢「區域配置」部分以確定如何配置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驗證入站分類。如本示例所示，值設定為Off。

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

如果此值設定為「關閉」，這意味著阻止VCS嘗試將入站TLS連線對映到此區域。因此，呼叫將進入預設區域，並且如果在Expressway E上配置了「企業到企業」，則將根據為「企業到企業」方案提供的搜尋規則進行檢查和路由。

解決方案

為了解決此問題，您需要將混合呼叫DNS區域上的TLS驗證入站對映設定為「開」。以下是完成此操作的步驟。

1. 登入Expressway-E
2. 導航到Configuration > Zones > Zones
3. 選擇混合呼叫DNS區域
4. 對於TLS驗證入站對映，請選擇On
5. 選擇儲存

附註：有關基線日誌記錄行為，請參閱。本節顯示Expressway執行憑證驗證以及到Webex混合DNS區域的對應。

問題7. Expressway-E使用預設自簽名證書

在一些新的混合呼叫服務連線部署中，Expressway-E證書的簽名被忽略，或者認為可以使用預設伺服器證書。有些人認為，這是可能的，因為Cisco Webex控制中心允許您將自定義證書載入到門戶中。(Services > Settings(在Hybrid Call Card下)> Upload(在Certificates for Encrypted Calls下))

如果您密切注意加密SIP呼叫的證書的措辭，您將看到：'使用思科合作預設信任清單提供的證書或上傳您自己的證書。如果使用自己的名稱，請確保主機名位於已驗證的域中。' 該語句的關鍵部分是「確保主機名位於已驗證的域中。」 

對符合此情況的問題進行故障排除時，請記住，症狀取決於呼叫方向。如果呼叫是由本地電話發起的，則您預計思科Webex應用不會振鈴。此外，如果您嘗試從Expressway搜尋歷史記錄中跟蹤呼叫，您會發現該呼叫將到達Expressway-E並在此停止。如果呼叫來自Cisco Webex應用並且目的地為本地，則本地電話不會響起。在這種情況下，Expressway-E和Expressway-C搜尋歷史記錄不會顯示任何內容。

在此特定情況下，呼叫源自本地電話。使用Expressway-E搜尋歷史記錄，可以確定呼叫是否到達伺服器。此時，您可以深入瞭解診斷日誌記錄以確定發生了什麼情況。要開始此分析，首先檢視是否嘗試並通過埠5062建立TCP連線。通過在Expressway-E診斷日誌中搜尋「TCP連線」，並搜尋帶有「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診斷日誌記錄提供的資料包捕獲，可以看到Certificate Unknown錯誤源自Cisco Webex方向，如下圖所示。

如果您檢查來自Expressway-E的預設伺服器證書，可以看到「常用名稱」和「使用者替代名稱」不包含「已驗證的域」(rtp.ciscotac.net)。 然後您就可以找到導致此問題的原因，如下圖所示。 

此時，您確定Expressway-E伺服器證書需要由公共CA或內部CA簽名。 

解決方案

為了解決此問題，您有兩個選項：

1. 使Expressway-E證書由Cisco Webex信任的公共CA簽署。
   
   1. 登入到Expressway。
   2. 導航到維護>安全>伺服器證書。
   3. 選擇Generate CSR。
   4. 輸入所需的證書資訊，並確保Additional alternative names欄位包含Webex Control Hub中列出的Verified Domain。
   5. 按一下「Generate CSR」。
   6. 將CSR提供給第三方公共CA進行簽名。
   7. 返回證書後，導航到維護>安全>伺服器證書。
   8. 在Select the server certificate file旁邊的Upload New Certificate部分中，選擇Choose File，然後選擇簽名證書。
   9. 選擇Upload server certificate data。
   10. 導覽至Maintenance > Security > Trusted CA certificate。
   11. 在選擇包含受信任CA證書的檔案旁邊的上傳部分，選擇選擇檔案。
   12. 選擇公共CA提供的任何根和中間CA證書。
   13. 選擇Append CA certificate。
   14. 重新啟動Expressway-E。
2. 讓內部CA簽署Expressway-E證書，然後將內部CA和Expressway-E上傳到Cisco Webex控制中心。
   
   1. 登入到Expressway
   2. 導航到維護>安全>伺服器證書。
   3. 選擇產生CSR
   4. 輸入所需的證書資訊，以確保Additional alternative names欄位包含Webex Control Hub中列出的Verified Domain
   5. 按一下「Generate CSR」
   6. 將CSR提供給第三方公共CA進行簽名
   7. 返回證書後，導航到維護>安全>伺服器證書
   8. 在Select the server certificate file旁邊的Upload New Certificate部分，選擇Choose File，然後選擇已簽名的證書
   9. 選擇上傳伺服器證書資料
   10. 導覽至Maintenance > Security > Trusted CA certificate
   11. 在選擇包含受信任CA證書的檔案旁邊的上傳部分，選擇選擇檔案。
   12. 選擇公共CA提供的任何根和中間CA證書。
   13. 選擇Append CA certificate。
   14. 重新啟動Expressway-E。

 2a。將內部CA和Expressway-E證書上傳到Cisco Webex控制中心
       1.以管理員身份登入Cisco Webex控制中心。
       2.選擇服務。
       3.選擇混合呼叫服務卡下的設定。
       4.在Certificates for Encrypted SIP Calls部分中選擇Upload。
       5.選擇內部CA和Expressway-E證書。

入站：思科Webex到本地

幾乎每個入站思科Webex到本地的故障都會導致相同的故障症狀：「當我從我的Cisco Webex應用呼叫另一位同事的應用時，同事的應用響起，但本地電話卻不響。」 為了排除此故障，您會發現瞭解進行此類呼叫時出現的呼叫流程和邏輯都很有幫助。

高級邏輯流

1. Cisco Webex應用呼叫方發起呼叫
2. 被叫方的應用振鈴
3. 呼叫被分流到Cisco Webex環境
4. Cisco Webex環境必須根據客戶在Cisco Webex控制中心中配置的SIP目標執行DNS查詢
5. Cisco Webex環境嘗試通過埠5062連線到Expressway
6. Cisco Webex環境嘗試執行雙向TLS握手
7. Cisco Webex環境向Expressway傳送SIP INVITE，該SIP INVITE向下傳遞到本地合作終端/IP電話
8. Cisco Webex與企業完成SIP協商
9. Cisco Webex和企業開始傳送和接收媒體。

呼叫流

導覽至Cisco Webex app > Cisco Webex environment > Expressway-E > Expressway-C > On-Premises Collaboration Endpoint/IP Phone，如下圖所示。

以下是從Webex到本地基礎設施的入站呼叫觀察到的一些常見問題。

問題1. Cisco Webex無法解析Expressway-E DNS SRV/主機名

在考慮思科Webex到本地呼叫流程時，思科Webex的第一個邏輯步驟是如何聯絡本地Expressway。如上所述，Cisco Webex將嘗試根據在Cisco Webex控制中心的混合呼叫服務設定頁中列出的已配置SIP目標執行SRV查詢，以連線到本地Expressway。 

如果您嘗試從Expressway-E診斷日誌角度對此情況進行故障排除，則不會看到來自Cisco Webex的任何流量。如果您嘗試搜尋TCP連線，您將看不到Dst-port=5062，也不會看到來自Cisco Webex的任何後續的MTLS握手或SIP Invite。 

如果發生這種情況，您必須檢查SIP目的地在Cisco Webex控制中心中的配置方式。您還可以使用混合連線測試工具來幫助進行故障排除。混合連線測試工具會檢查是否存在有效的DNS地址、Cisco Webex是否可以連線到SRV查詢中返回的埠，以及本地Expressway是否具有Cisco Webex信任的有效證書。 

1. 登入Cisco Webex Control Hub
2. 選擇服務
3. 選擇Hybrid Call card中的SettingsLink。
4. 在「呼叫服務連線」部分中，驗證SIP Destinationfield中用於公共SIP SRV地址的域。 
5. 如果輸入的記錄正確，請按一下測試以檢視記錄是否有效。
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命令被啟動，然後伺服器被設定為8.8.8.8，這是公共Google DNS伺服器。最後，您將設定記錄型別以查詢SRV記錄。此時，您可以發佈要查詢的完整SRV記錄。最終結果是請求最終超時。 

解決方案

1. 在用於承載公共域名的站點上為Expressway-E配置公共SIP SRV地址。 
2. 配置將解析為Expressway-E的公共IP地址的主機名
3. 配置SIP目標以列出用於步驟1中建立的SIP SRV地址的域。
   1. 登入Cisco Webex Control Hub
   2. 選擇服務
   3. 選擇混合呼叫卡中的Settings連結
   4. 在Call Service Connect部分，在SIP Destination欄位中輸入用於公共SIP SRV地址的域。 
   5. 選擇儲存

附註：如果您想要使用的SIP SRV記錄已被用於企業到企業通訊，我們建議在Cisco Webex Control Hub中指定企業域的子域作為SIP發現地址，然後指定公共DNS SRV記錄，如下所示：

服務和協定：_sips._tcp.mtls.example.com
優先順序機制:1
重量:10
埠號：5062
目標：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. 選擇混合呼叫卡中的Settings連結
   4. 在「呼叫服務連線」部分的「SIP Destination」欄位中輸入%Expressway_Pub_IP%:5062。 
   5. 選擇儲存

有關必須設定的SIP目標地址和/或SRV記錄的詳細資訊。請參閱《Cisco Webex混合呼叫服務部署指南》或《Cisco Webex混合設計手冊》的為您的組織啟用混合呼叫服務連線部分。

問題2.套接字故障：埠5062被阻止入站到Expressway

DNS解析完成後，Cisco Webex環境嘗試通過埠5062建立到DNS查詢過程中返回的IP地址的TCP連線。此IP地址將成為本地Expressway-E的公共IP地址。如果Cisco Webex環境無法建立此TCP連線，則隨後對內部部署的入站呼叫將失敗。此特定情況的症狀與幾乎所有其他思科Webex入站呼叫故障相同：本地電話不響。

如果使用Expressway診斷日誌對此問題進行故障排除，您將不會看到來自Cisco Webex的任何流量。如果您嘗試搜尋TCP連線，您將看不到Dst-port=5062的任何連線嘗試，也不會看到來自Cisco Webex的任何後續的MTLS握手或SIP Invite。由於Expressway-E診斷日誌記錄在此情況下沒有用處，因此可以使用以下幾種驗證方法：

1. 從防火牆的外部介面獲取資料包捕獲
2. 利用埠檢查實用程式
3. 使用混合連線測試工具

由於混合連線測試工具直接內建於Cisco Webex控制中心，並模擬嘗試連線到本地Expressway的Cisco Webex環境，因此它是可用的最理想的驗證方法。測試到組織的TCP連線：

1. 登入Cisco Webex Control Hub
2. 選擇服務
3. 選擇混合呼叫卡中的SettingsLink
4. 在「呼叫服務連線」部分中，確保在SIP目標中輸入的值正確
5. 按一下「Test」，如下圖所示。

  6.由於測試失敗，您可以按一下檢視測試結果連結檢查詳細資訊，如下圖所示。

如上圖所示，您可以看到在嘗試連線到64.102.241.236:5062時Socket測試失敗。除了Expressway診斷日誌/資料包外，此資料未顯示任何連線嘗試，因此您現在有足夠的證據來調查防火牆ACL/NAT/路由配置。 

解決方案

由於此特定問題不是由Cisco Webex環境或本地合作裝置引起的，因此您需要將重點放在防火牆配置上。由於您不一定能預測要連線的防火牆型別，因此您需要依賴熟悉裝置的人員。此問題可能與防火牆ACL、NAT或路由配置錯誤有關。 

問題3.套接字故障：Expressway-E未在埠5062上偵聽

這種特殊情況經常被診斷為錯誤的。很多情況下，假設防火牆是導致通過埠5062的流量被阻止的原因。要對此特殊情況進行故障排除，您可以使用上述「埠5062被阻止入站到Expressway」場景中的技術。您會發現混合連線測試工具和用於檢查埠連線的任何其他工具都將失敗。第一個假設是防火牆正在阻止流量。然後，大多數人會再次檢查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中，您可以看到Expressway E在初始TCP SYN資料包到達後立即傳送RST。使用此資訊，您可以斷定問題與Expressway-E接收資料包無關；您必須從Expressway-E的角度對問題進行故障排除。根據證據，考慮為什麼Expressway-E會拒絕資料包的可能原因。可歸因於此行為的兩種可能性：

1. Expressway-E設定了一些可能阻止流量的防火牆規則

2. Expressway-E未偵聽相互TLS流量和/或未偵聽通過埠5062的流量。

Expressway-E的防火牆功能位於System > Protection > Firewall rules > Configuration下。在此環境中檢查此配置時，不存在防火牆配置。 

有多種方法可以檢驗Expressway-E是否正在偵聽埠5062上的相互TLS流量。您可以通過Web介面或CLI以超級使用者身份執行此操作。 

如果發出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 UU不會顯示「本地入站埠」下列出的雙方TLS埠

通過此資料，您可以斷定Expressway-E沒有偵聽相互TLS流量。

解決方案

為了解決此問題，您必須確保啟用相互TLS模式並在Expressway-E上將相互TLS埠設定為5062:

1. 登入Expressway-E
2. 導覽至Configuration > Protocols > SIP
3. 確保「相互TLS」模式設定為「開啟」
4. 確保雙向TLS埠設定為5062
5. 按一下「Save」，如下圖所示。

問題4. Expressway-E或C不支援預載入的SIP路由報頭

使用混合呼叫服務連線，呼叫路由基於路由報頭完成。路由報頭是根據解決方案的呼叫服務感知（Expressway聯結器）部分向Cisco Webex提供的資訊填充的。Expressway聯結器主機將查詢Unified CM以查詢已啟用呼叫服務的使用者，並提取其Directory 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。
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-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上的區域（遍歷伺服器、遍歷客戶端、鄰居）中開啟或關閉。

現在，您可以使用xConfiguration檢視Expressway-E遍歷伺服器和Expressway-C客戶端區域上的配置，特別是針對混合呼叫服務連線設定的那些區域。除了Zone配置之外，您還可以分析配置為將此呼叫從一個區域傳遞到另一個區域的搜尋規則。您還知道Expressway-E確實將呼叫傳遞到Expressway-C，因此遍歷伺服器區域配置很可能正確設定。

為了對此進行細分，下面的xConfig告訴我們此區域的名稱稱為混合呼叫服務遍歷。它屬於TraversalServer區域型別。它通過SIP TCP埠7003與Expressway-C進行通訊。

混合呼叫服務的關鍵部分是，必須啟用預載入SIP路由支援。Expressway Web介面呼叫此值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 Hybrid的遍歷客戶端區域開始。查詢該埠的一種簡單方法是搜尋您從Expressway-E xConfiguration(SIP Port:「7003」)。 這有助於您快速確定xConfiguration中的正確區域。

與以前一樣，您可以瞭解區域名稱（混合呼叫服務遍歷）、型別（遍歷客戶端）以及為SIP PreloadedSipRoutes Accept（預載入SIP路由支援）配置的內容。 從此xConfiguration中可以看到，該值設定為Off。根據Cisco Webex混合呼叫服務部署指南，此值應設定為On。

此外，如果檢查預載入SIP路由支援的定義，我們可以清楚地看到，如果此值設定為Off且INVITe包含路由報頭，則Expressway-C應拒絕消息："如果希望區域拒絕包含此報頭的SIP INVITE請求，則切換預載入SIP路由支援關閉。"

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路由支援切換為On。

解決方案

要正確設定預載入SIP路由支援，請執行以下操作：

1. 登入Expressway-C
2. 導航到Configuration > Zones > Zones
3. 選擇混合呼叫服務遍歷客戶端區域（命名因客戶而異）
4. 將Preloaded SIP routs support設定為On
5. 選擇儲存

附註：雖然此場景演示了Expressway-C上的故障，但是如果Webex混合呼叫遍歷伺服器區域上的預載入SIP路由支援關閉，則在Expressway-E上可以觀察到相同的診斷日誌記錄錯誤。在這種情況下，您永遠看不到呼叫到達Expressway-C，而Expressway-E將負責拒絕呼叫並傳送404 Not Found。

問題5. Cisco Webex應用正在接收兩個呼叫通知（廣播）

此特定問題碰巧是唯一不會導致呼叫丟棄的入站呼叫方案。對於此問題，接收呼叫的人（被叫方）在Cisco Webex應用中接收來自發出呼叫的人（主叫方）的兩條通知（通知）。 第一個通知由Cisco Webex生成，第二個通知由內部基礎設施生成。以下為圖中所示的兩個收到的通知的示例。

第一個通知(toast)來自從Cisco Webex端發起呼叫的人員（主叫方）。此例項中的呼叫ID是發起該呼叫的使用者的顯示名稱。第二個通知(toast)來自本地CTI或Cisco Webex RD，分配給進行呼叫的使用者。起初，這種行為似乎有些奇怪。但是，如果您檢視入站呼叫圖表（來自Cisco Webex混合呼叫設計手冊），則行為會更有意義，如下圖所示。

從圖中，您可以看到Alice正在通過其Cisco Webex應用呼叫Bob，並且呼叫被分流到本地。此呼叫應與分配給Bob電話的目錄URI匹配。問題在於，在此設計中，目錄URI也分配給他的CTI-RD或Cisco Webex RD。因此，當呼叫被提供給CTI-RD或Cisco Webex RD時，該呼叫將傳送回Cisco Webex，因為裝置已為bob@example.call.ciscospark.com配置了遠端目標。Cisco Webex處理此情況的方式是取消特定呼叫段。 

為使Cisco Webex正確取消呼叫段，Cisco Webex最初需要在SIP報頭中放置一個引數，它會查詢該引數以取消該給定段。Cisco Webex插入到SIP INVITE中的引數稱為"call-type=squared"，該值輸入到Contact報頭中。如果從消息中刪除此值，Cisco Webex不瞭解如何取消呼叫。 

使用此資訊，您可以重新檢視先前顯示的場景，即當思科Webex使用者Jonathan Robb進行呼叫時，使用者的Cisco Webex應用收到兩個通知（廣播）。若要解決此類問題，您始終需要收集Expressway-C和Expressway-E的診斷日誌記錄。作為起點，您可以檢視Expressway-E日誌，確定SIP INVITE實際上在入站傳送的初始Cisco Webex INVITE的Contact標頭中確實存在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: 
      
        , 
        
       
     

Contact報頭存在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時，請注意Contact報頭缺少call-type=squared。需要指出的另一點是，在第4行中，您可以看到出口區域等於HybridCallServiceTraversal。現在您可以斷定，Cisco Webex應用在被撥號時收到第二個通知(toast)的原因是Expressway-E從SIP INVITE Contact標頭中去除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預載入SIP路由接受：於
• SIP引數保留模式：Off

使用任何Expressway的Web介面，您可以檢視這些值的定義及其用途。

預載入SIP路由支援

Switch Preloaded SIP routs support On（交換機預載入的SIP路由支援On），使該區域能夠處理包含路由報頭的SIP INVITE請求。

如果希望區域拒絕包含此報頭的SIP INVITE請求，則切換預載入SIP路由支援關閉。

SIP引數保留

出站：內部部署至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可用的思科Webex應用
11. 使用者B的可用思科Webex應用開始振鈴。

呼叫流

導覽至使用者B on-prem phone > Unified CM > CTI-RD/Webex-RD > Expressway-C > Expressway-E > Cisco Webex environment > Cisco Webex app，如下圖所示。

附註：影象已從Cisco Webex混合設計手冊中提取。

日誌分析提示

如果您正在排查到Cisco Webex的出站分叉呼叫失敗的情況，您需要收集Unified CM、Expressway-C和Expressway-E日誌。通過這些日誌集，您可以檢視呼叫是如何通過環境的。要瞭解呼叫在本地環境中到達的距離，另一個快速方法是使用Expressway「搜尋歷史記錄」。 通過Expressway搜尋歷史記錄，您可以快速檢視對Cisco Webex的分支呼叫是否到達Expressway-C或E。

要使用搜尋歷史記錄，您可以執行以下操作：

1. 登入Expressway-E
   發出測試呼叫
   導航到狀態>搜尋歷史記錄
   驗證您是否看到具有應呼叫的Webex SIP URI的目標地址的呼叫(user@example.call.ciscospark.com)
   如果搜尋歷史記錄未顯示按Expressway-E搜尋歷史記錄進行的呼叫，請在Expressway-C上重複此過程

分析Expressway上的診斷日誌之前，請考慮如何識別此呼叫：

1. SIP請求URI將是Cisco Webex使用者的SIP地址
2. SIP FROM欄位的格式將設定為將主叫方列為「名字姓氏」<sip:Alias@Domain>

使用此資訊，您可以按主叫方的目錄URI、主叫方的名字和姓氏或被叫方的Cisco Webex SIP地址搜尋診斷日誌。如果您沒有以上任何資訊，您可以搜尋「INVITE SIP:」，這將找到通過Expressway運行的所有SIP呼叫。識別出出站呼叫的SIP INVITE後，您可以找到並複製SIP Call-ID。執行此操作後，您只需根據Call-ID搜尋診斷日誌即可檢視與此呼叫段相關的所有消息。

以下是在對已啟用呼叫服務連線的使用者進行呼叫時，觀察到從Unified CM註冊電話到Cisco Webex環境的出站呼叫的一些最常見問題。

問題1. Expressway無法解析callservice.ciscospark.com地址

Expressway DNS區域的標準操作過程是根據請求URI右側顯示的域執行DNS查詢。要解釋這一點，請考慮一個示例。如果DNS區域將接收請求URI為pstojano-test@dmzlab.call.ciscospark.com的呼叫，則典型的Expressway DNS區域將在dmzlab.call.ciscospark.com（請求URI的右側）上執行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記錄響應提供伺服器地址和埠5061，而不是5062。

這意味著不會在埠5062上發生相互TLS握手，並且在Expressway和Cisco Webex之間使用單獨的埠進行信令。此問題的難點在於，《Cisco Webex混合呼叫服務部署指南》沒有明確指出使用埠5061，因為某些環境不允許企業對企業進行呼叫。

在Expressway上通過此標準DNS區域SRV查詢邏輯的工作方式是配置Expressway，使其根據您提供的值執行顯式搜尋。

現在，分析此特定呼叫時，您可以重點關注Expressway-E，因為您確定（使用搜尋歷史記錄）該呼叫已到達此程度。從進入Expressway-E的第一個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 Robb" <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通過四個搜尋規則進行了解析，但是隻考慮了一個(Webex Hybrid — 到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查詢，並且已解析為主機名of l2sip-cfa-01.wbx2.com和埠5061。hostname 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正在嘗試連線到IP 146.20.193.64，該地址以前通過TCP埠5061解析，但此連線完全失敗。從收集的資料包捕獲中也可以看到相同的情況。 

根據這些結果，可以清楚地看到，埠5061上的流量無法成功。但是，混合呼叫服務連線應使用TCP埠5062，而不是5061。因此，您需要考慮為什麼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。基於此xConfiguration，DNSOverride Override設定為Off，因此DNSOverride Name不會生效。為了更好地瞭解這些值的用途，您可以使用Expressway Web UI查詢這些值的定義。

修改DNS請求(在xConfig中轉換為DnsOverride Override)

將出站SIP呼叫從此區域路由到手動指定的SIP域，而不是撥號目標中的域。此選項主要用於Cisco Webex通話服務。請參閱www.cisco.com/go/hybrid-services。

要搜尋的域(在xConfig中轉換為DnsOverride名稱)

輸入要在DNS中查詢的FQDN，而不是在出站SIP URI上搜尋域。原始SIP URI不受影響。

現在您已經有了這些定義，很顯然，如果設定正確，這些值與我們的DNS查詢邏輯完全相關。如果將此選項與Cisco Webex混合呼叫服務部署指南中的語句相結合，您會發現修改DNS請求必須設定為On，而要搜尋的域應設定為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請求設定為On
5. 將「域」設定為callservice.ciscospark.com
6. 儲存更改

附註：如果Expressway上只使用一個DNS區域，則應配置一個單獨的DNS區域，以便與可以利用這些值的混合呼叫服務一起使用。

問題2.埠5062被阻止出站到Cisco Webex

思科Webex的分叉出站呼叫失敗的一個獨特之處在於，被叫方的Cisco Webex應用將在他們的應用上顯示「加入」按鈕，儘管客戶端從不振鈴。與上面的情況一樣，對於此問題，您將需要再次使用相同的工具和日誌記錄，以更好地瞭解故障所在。有關隔離呼叫問題和分析日誌的提示，請參見本文如圖所示的部分。

顯示的「連線」按鈕的圖示

與「撥出呼叫問題#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接收正常。這是「已接收」操作，來自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通過四個搜尋規則進行了解析，但只有一個搜尋規則 （Webex Hybrid — 至Webex Cloud） 都考慮過了。搜尋規則的優先順序為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記錄已解析。響應是四個不同的有效記錄，全部使用埠5062。這是正常行為。此時，您現在可以分析接下來應發生的TCP握手。如本文檔前面所述，您可以搜尋診斷日誌中的「TCP連線」，並查詢列出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搜尋規則配置錯誤

搜尋規則配置錯誤是Expressway上最大的配置相關問題之一。搜尋規則配置問題可以是雙向的，因為您需要入站呼叫的搜尋規則，並且您需要出站呼叫的搜尋規則。瀏覽此問題時，您會發現，儘管Expressway上的正規表示式問題非常常見，但它們並不總是搜尋規則問題的原因。在此特定網段中，您將處理失敗的出站呼叫。與我們所有其它出站分叉呼叫場景一樣，症狀保持不變：

• 被叫使用者的Cisco Webex應用顯示「加入」按鈕
• 主叫電話正在回鈴
• 被叫使用者的本地電話正在振鈴
• 被叫使用者的Cisco Webex應用從未響起

與所有其他方案一樣，您還需要利用CUCM SDL跟蹤以及Expressway-C和E診斷日誌。與以前一樣，您應該參考以利用搜尋歷史和提示來識別診斷日誌中的呼叫。與以前一樣，使用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時，可以看到Expressway-E立即向Expressway-C傳送404 Not Found。 

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