解決合作邊緣最常見的問題

簡介

本文檔介紹如何解決您在部署階段遇到的最常見的Collaboration Edge問題。

背景資訊

移動和遠端訪問(MRA)是虛擬專用無網路(VPN) Jabber功能的部署解決方案。此解決方案允許終端使用者從世界任何地方連線到內部企業資源。撰寫本指南的目的是讓排查Collaboration Edge解決方案疑難問題的工程師能夠快速辨識並解決您在部署階段遇到的最常見問題。

必要條件

需求

思科建議您瞭解以下主題：

• 思科整合通訊管理員(CUCM)
• Cisco Expressway核心
• Cisco Expressway邊緣
• Cisco IM and Presence (IM&P)
• Windows版Cisco Jabber
• Mac版Cisco Jabber
• Cisco Jabber for Android
• Cisco iOS®版Jabber
• 安全證書
• 網域名稱系統(DNS)

採用元件

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

• Expressway版本X8.1.1或更高版本
• CUCM版本9.1(2)SU1或更高版本以及IM&P版本9.1(1)或更高版本
• Cisco Jabber 9.7或更高版本

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

登入問題

Jabber無法通過MRA登入

此症狀可能由多種問題引起，其中一些問題在此概述。

1. 未建立合作邊緣服務記錄(SRV)和/或無法連線埠8443

要使Jabber客戶端能夠使用MRA成功登入，必須建立特定合作邊緣SRV記錄並且可從外部訪問。最初啟動Jabber客戶端時，它會進行DNS SRV查詢：

1. _cisco-uds：使用此SRV記錄可確定CUCM伺服器是否可用。
   
   
2. _cuplogin：此SRV記錄用於確定是否有IM&P伺服器。
   
   
3. _collab-edge：使用此SRV記錄可確定MRA是否可用。
   
   

如果Jabber客戶端已啟動，但未收到_cisco-uds和_cuplogin的SRV應答，且未收到_collab-edge的應答，則客戶端會使用此應答嘗試聯絡SRV應答中列出的Expressway E。

_collab-edge SRV記錄指向帶有埠8443的Expressway E的完全限定域名(FQDN)。如果沒有建立_collab-edge SRV，或者該SRV從外部不可用，或者該埠可用，但無法訪問埠8443，則Jabber客戶端無法登入。

您可以使用合作解決方案分析器(CSA)中的「SRV檢查器」確認_collab-edge SRV記錄是否可以解析，以及TCP埠8443是否可以訪問。

如果連線埠8443無法連線，可能是因為安全裝置（防火牆）封鎖連線埠，或Exp-E中的預設閘道(GW)或靜態路由組態錯誤。

2. VCS Expressway上的證書不可接受或不可用

在Jabber客戶端收到_collab-edge的應答後，它會透過埠8443與Expressway聯絡，嘗試從Expressway檢索證書，以設定TLS來進行Jabber客戶端和Expressway之間的通訊。

如果Expressway沒有包含Expressway的FQDN或域的有效簽名證書，則此操作會失敗，並且Jabber客戶端無法登入。

如果出現此問題，請在Expressway上使用證書簽名請求(CSR)工具，該工具會自動將Expressway的FQDN作為備用主體名稱(SAN)。

注意：MRA要求Expressway C與Expressway E之間以及Expressway E與外部終端之間進行安全通訊。

下表列出了每個功能的Expressway證書要求，請參閱MRA部署指南：

3. 在邊緣配置中找不到UDS伺服器

Jabber客戶端成功與Expressway E建立安全連線後，會請求其邊緣配置(get_edge_config)。此邊緣配置包含_cuplogin和_cisco-uds的SRV記錄。如果在邊緣配置中未返回_cisco-uds SRV記錄，則Jabber客戶端將無法繼續登入。

要解決此問題，請確保_cisco-uds SRV記錄已在內部建立，並且可以由Expressway-C解析。

有關DNS SRV記錄的詳細資訊，請參閱X8.11的MRA部署指南。

如果您處於雙域中，這也是一個常見症狀。如果您在雙域中運行並且發現Jabber客戶端未返回任何使用者資料服務(UDS)，則必須確認在帶有外部域的內部DNS中建立_cisco-uds SRV記錄。

注意：在Expressway版本X12.5之後，不再需要將_cisco-UDS SRV記錄增加到內部DNS。有關此增強功能的詳細資訊，請參閱透過Cisco Expressway的移動和遠端訪問部署指南(X12.5)。

4. Expressway-C日誌顯示此錯誤： XCP_JABBERD Detail=Unable to connect to host「%IP%」，埠7400：(111)連線被拒絕

如果Expressway E網路介面控制器(NIC)配置不正確，則可能導致可擴展通訊平台(XCP)伺服器無法更新。如果Expressway E滿足這些標準，則您可能會遇到此問題：

1. 使用單一NIC。
2. 已安裝「進階網路選項」金鑰。
3. Use Dual Network Interfaces選項設定為Yes。

要解決此問題，請將「Use Dual Network Interfaces」選項更改為No。

出現此問題的原因是Expressway E在錯誤的網路介面上監聽XCP會話，從而導致連線失敗/超時。Expressway-E在TCP埠7400上偵聽XCP會話。如果從VCS作為root使用者使用netstat 命令，則可以驗證這一點。

5. Expressway E伺服器主機名/域名與_collab-edge SRV中的配置不匹配

如果DNS頁面配置中的Expressway E伺服器主機名/域與_collab-edge SRV應答中收到的內容不匹配，Jabber客戶端將無法與Expressway E通訊。Jabber客戶端使用get_edge_config響應中的xmppEdgeServer/Address元素建立到Expressway E的XMPP連線。

下面是Expressway-E到Jabber客戶端的get_edge_config響應中xmppEdgeServer/地址外觀的示例：

<xmppEdgeServer>
<server>
<address>examplelab-vcse1.example URL</address>
<tlsPort>5222</tlsPort>
</server>
</xmppEdgeServer>

為了避免出現這種情況，請確保_collab-edge SRV記錄與Expressway E主機名/域名匹配。我們已為此檔案記錄了思科漏洞ID CSCuo83458，並且已在思科漏洞ID CSCuo82526上增加了部分支援。

6. 由於當前的WebEx Connect訂用，無法登入

Windows版Jabber日誌顯示：

2014-11-22 19:55:39,122 INFO  [0x00002808] [very\WebexCasLookupDirectorImpl.cpp(134)]
[service-discovery] [WebexCasLookupDirectorImpl::makeCasLookupWhenNetworkIs
Available] - makeCasLookupForDomain result is  'Code: IS_WEBEX_CUSTOMER; Server: 
http://URL server; 
Url: http://example URL server';;;.2014-11-22 
19:55:39,122 INFO  [0x00002808] [overy\WebexCasLookupDirectorImpl.cpp(67)]
[service-discovery] [WebexCasLookupDirectorImpl::determineIsWebexCustomer] - 
Discovered Webex Result from server. Returning server result.2014-11-22 19:55:39,122 
DEBUG [0x00002808] [ery\WebexCasLookupUrlConfigImpl.cpp(102)]
[service-discovery] [WebexCasLookupUrlConfigImpl::setLastCasUrl] - setting last_cas_
lookup_url : http://example URL server2014-11-22 
19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStoreManager.cpp(286)]
[ConfigStoreManager] [ConfigStoreManager::storeValue] - key : [last_cas_lookup_url]
value : [http://example URL server/cas/FederatedSSO?org=example URL]2014-11-22 
19:55:39,123 DEBUG [0x00002808] [common\processing\TaskDispatcher.cpp(29)]
[TaskDispatcher] [Processing::TaskDispatcher::enqueue] - Enqueue ConfigStore::persist
Values - Queue Size: 02014-11-22 19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStore
Manager.cpp(140)]
[ConfigStoreManager] [ConfigStoreManager::getValue] - key : [last_cas_lookup_url] 
skipLocal : [0]  value: [http://website URL/cas/FederatedSSO?org=example URL]
success: [true] configStoreName: [LocalFileConfigStore]

登入嘗試定向到WebEx Connect。

要獲得永久解決方案，必須聯絡WebEx以便停用該站點。

因應措施

在短期內，您可以使用這些選項之一將其從查詢中排除。

• 將此引數增加到jabber-config.xml。然後將jabber-config.xml檔案上傳到CUCM上的TFTP伺服器。它要求客戶端首先在內部登入。
  
  

  <?xml version="1.0" encoding="utf-8"?>
  <config version="1.0">
  <Policies>
  <ServiceDiscoveryExcludedServices>WEBEX<
  /ServiceDiscoveryExcludedServices>
  </Policies>
  </config>

• 從應用程式的角度來看，執行下列作業：
  msiexec.exe /i CiscoJabberSetup.msi /quiet CLEAR=1 AUTHENTICATOR=CUP EXCLUDED_SERVICES=WEBEX

註：第二個選項不適用於流動裝置。

• 建立一個可點選的URL，其中排除WEBEX服務：
  ciscojabber://provision?ServiceDiscoveryExcludedServices=WEBEX

有關UC服務發現以及如何在Cisco Jabber 12.8本地部署中排除某些服務的詳細資訊。

7. Expressway-C伺服器顯示錯誤消息：「已配置但出現錯誤。布建伺服器：正在等候穿越伺服器資訊。」

如果導航到狀態>統一通訊，然後看到錯誤消息「已配置，但出現錯誤」。調配伺服器：正在等待穿越伺服器資訊。」對於Unified CM註冊和IM&P服務，在Expressway-C上配置的內部DNS伺服器有兩個Expressway-E的DNS A記錄。Expressway-E有多個DNS A記錄的原因可能是受影響的使用者從在Expressway-E上啟用了靜態NAT的單個NIC移動到啟用了靜態NAT的雙個NIC（反之亦然），並且忘記刪除內部DNS伺服器中的適當DNS A記錄。因此，當您在Expressway-C中使用DNS查詢實用程式並解析Expressway-E FQDN時，您會看到兩個DNS A記錄。

解決方案

如果Expressway E NIC配置為使用靜態NAT的單個NIC：

1. 刪除Expressway C中配置的DNS伺服器中Expressway E內部IP地址的DNS A記錄。
2. 透過CMD (ipconfig /flushdns)刷新Expressway-C和使用者PC中的DNS快取。
3. 重新啟動Expressway-C伺服器。

如果Expressway E NIC配置為啟用靜態NAT的雙NIC：

1. 刪除Expressway C中配置的DNS伺服器中Expressway E 外部 IP地址的DNS A記錄。
2. 透過CMD (ipconfig /flushdns)刷新Expressway-C和使用者PC中的DNS快取。
3. 重新啟動Expressway-C伺服器。

8. 已安裝Microsoft DirectAccess

如果您在與Jabber客戶端相同的PC上使用Microsoft DirectAccess，則當您嘗試遠端登入時，可能會中斷MRA。DirectAccess強制DNS查詢透過隧道連線到內部網路，就像使用VPN一樣。

注意：Microsoft DirectAccess不支援MRA上的Jabber。任何故障排除都是盡力而為。DirectAccess的配置由網路管理員負責。

有時，您可以成功阻止Microsoft DirectAccess名稱解析策略表中的所有DNS記錄。DirectAccess不會處理這些記錄（Jabber需要能夠透過MRA的公共DNS解析這些記錄）：

• _cisco-uds的SRV記錄
• _cuplogin的SRV記錄
• _collab-edge的SRV記錄
• 所有Expressway Es的記錄

9. Expressway反向DNS查詢失敗

從X8.8版本開始，Expressway/VCS要求為ExpE、ExpC和所有CUCM節點建立轉發和逆向DNS條目。 

有關完整要求，請參閱x8.8發行版本註釋和移動和遠端訪問的DNS記錄中的前提條件和軟體依賴性。

如果不存在內部DNS記錄，則在Expressway日誌中引用reverseDNSLookup時可能存在錯誤：

2016-07-30T13:58:11.102-06:00 hostname XCP_JABBERD[20026]: UTCTime="2016-07-30 19:58:11,102" ThreadID="139882696623872" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:409" Detail="caught exception: exception in reverseDNSLookup: reverse DNS lookup failed for address=x.x.x.x"

查詢Expressway-E IP的PTR記錄時，Expressway-C僅接收一個FQDN。如果從DNS收到不正確的FQDN，則會在日誌中顯示此行並失敗：

2020-04-03T17:48:43.685-04:00 hostname XCP_JABBERD[10043]: UTCTime="2020-04-03 21:48:43,685" ThreadID="140028119959296" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:601" Detail="Certificate verification failed for host=xx.xx.xx.xx, additional info: Invalid Hostname"

註冊問題

Softphone無法註冊，不允許SIP/2.0 405方法

來自Expressway-C的診斷日誌顯示一條SIP/2.0 405 Method Not Allowed消息，用於響應Jabber客戶端傳送的註冊請求。這可能是由於Expressway-C和CUCM之間當前的會話發起協定(SIP)中繼（埠5060/5061）。

SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/TCP 10.10.40.108:5060;egress-zone=CollabZone;branch=z9hG4bK81e7f5f1c1
ab5450c0b406c91fcbdf181249.81ba6621f0f43eb4f9c0dc0db83fb291;proxy-call-id=da9e25aa-
80de-4523-b9bc-be31ee1328ce;rport,SIP/2.0/TLS 10.10.200.68:7001;egress-zone=Traversal
Zone;branch=z9hG4bK55fc42260aa6a2e3741919177aa84141920.a504aa862a5e99ae796914e85d35
27fe;proxy-call-id=6e43b657-d409-489c-9064-3787fc4919b8;received=10.10.200.68;rport=
7001;ingress-zone=TraversalZone,SIP/2.0/TLS 
192.168.1.162:50784;branch=z9hG4bK3a04bdf3;received=172.18.105.10;rport=50784;
ingress-zone=CollaborationEdgeZone
From: <sip:5151@collabzone>;tag=cb5c78b12b4401ec236e1642-1077593a
To: <sip:5151@collabzone>;tag=981335114
Date: Mon, 19 Jan 2015 21:47:08 GMT
Call-ID: cb5c78b1-2b4401d7-26010f99-0fa7194d@192.168.1.162
Server: Cisco-CUCM10.5
CSeq: 1105 REGISTER
Warning: 399 collabzone "SIP trunk disallows REGISTER"
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0 

要解決此問題，請將應用於CUCM中配置的當前SIP中繼的SIP中繼安全配置檔案中的SIP埠以及CUCM的Expressway-C鄰居區域更改為其他埠，例如5065。這將在此影片中做進一步說明。以下是組態摘要：

CUCM

1. 使用除5060 (5065)之外的偵聽埠建立新的SIP中繼安全配置檔案。
2. 建立與SIP中繼安全配置檔案相關聯的SIP中繼，並將目標設定為Expressway-C IP地址，埠5060。

Expressway C

1. 使用目標埠而不是5060 (5065)來為CUCM建立相鄰區域以匹配CUCM配置。
2. 在Expressway-C 設定>協定> SIP中，確保Expressway-C仍在5060上偵聽SIP。

Softphone無法註冊，原因=「未知域」

來自Expressway-C的診斷日誌顯示Event="Registration Rejected" Reason="Unknown domain" Service="SIP" Src-ip="XXX.XXX.XXX.XXX" Src-port="51601" Protocol="TCP" AOR="sip：XXX.XXX.XXX.XXX"。

若要更正此問題，請檢查以下幾點：

• 如果希望不使用不安全的裝置安全配置檔案，Jabber客戶端是否在CUCM中使用安全裝置安全配置檔案？
  
  
• 如果Jabber客戶端使用安全裝置安全配置檔案，安全配置檔案的名稱是否為FQDN格式，該FQDN名稱是否配置在Expressway-C證書上作為SAN？
  
  
• 如果Jabber客戶端使用的是安全的裝置安全配置檔案，請導航到系統>企業引數>安全引數>集群安全模式，並檢查集群安全模式是否設定為1以驗證CUCM集群已受到保護。如果值為0，則管理員必須完成所記錄的過程才能保護群集。

Softphone無法註冊，原因為「Idle countdown expired」

如果您在Jabber客戶端傳送REGISTER消息的時間範圍內檢視Expressway E日誌，請按照此處代碼片段所示查詢「空閒倒計時超時」錯誤。

2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144" 
Module="network.tcp" Level="DEBUG":  Src-ip="JabberPubIP" Src-port="4211" 
Dst-ip="VCS-E_IP" Dst-port="5061" Detail="TCP Connecting"
2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144" 
Module="network.tcp" Level="DEBUG":  Src-ip="JabberPubIP" Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Established"2015-02-02T19:46:49+01:00 
collabedge tvcs: UTCTime="2015-02-02 18:46:49,606" 
Module="network.tcp" Level="DEBUG":  Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Closed" Reason="Idle 
countdown expired"

此代碼段表示防火牆確實打開了埠5061；但是，在足夠長的時間內沒有傳遞的應用層流量，因此TCP連線關閉。

如果您遇到這種情況，Expressway-E之前的防火牆很可能會啟用SIP檢查/應用層網關(ALG)功能。若要修正此問題，您必須停用此功能。如果您不確定如何執行此操作，請參閱防火牆供應商的產品文檔。

有關SIP檢查/ALG的詳細資訊，請參閱Cisco Expressway E和Expressway C基本配置部署指南附錄4。

由於韌體中配置了電話代理，MRA失敗

來自Expressway-E的診斷日誌在埠5061上顯示TLS協商失敗，但在埠8443上SSL握手成功。

2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,533" Module="network.tcp" Level="DEBUG": Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connecting"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,534" Module="network.tcp" Level="DEBUG": Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Established"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(67)" Method="::TTSSLErrorOutput" Thread="0x7fae4ddb1700": TTSSL_continueHandshake: Failed to establish SSL connection
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="network.tcp" Level="DEBUG":  Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Closed" Reason="Got EOF on socket"
2015-08-04T10:14:23-05:00 expe tvcs: Event="Inbound TLS Negotiation Error" Service="SIP"  Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="No SSL error available, probably remote disconnect" Protocol="TLS" Level="1" UTCTime="2015-08-04 15:14:23,535"

來自Jabber的日誌：

-- 2015-08-04 10:48:04.775 ERROR [ad95000] - [csf.cert.][checkIdentifiers] Verification of identity: 'URL address' failed.
-- 2015-08-04 10:48:04.777 INFO [ad95000] - [csf.cert][handlePlatformVerificationResultSynchronously] Verification result : FAILURE reason : [CN_NO_MATCH UNKNOWN]
-- 2015-08-04 10:48:05.284 WARNING [ad95000] - [csf.ecc.handyiron][ssl_state_callback] SSL alert read:fatal:handshake failure
type=eSIP, isRelevant=true, server=URL server name:5061, connectionState=eFailed, isEncrypted=true, failureReason=eTLSFailure, SSLErrorCode=336151568
type=eSIP, isRelevant=true, server=192.168.102.253:5060, connectionState=eFailed, isEncrypted=false, failureReason=eFailedToConnect, serverType=ePrimary, role=eNone
-- 2015-08-04 10:48:05.287 ERROR [ad95000] - [csf.ecc.handyiron][secSSLIsConnected] SSL_do_handshake() returned : SSL_ERROR_SSL.

來自Jabber的資料包捕獲顯示與Expressway E IP進行SSL協商；但是，傳送的證書並非來自此伺服器：

FW配置了電話代理。

解決方案：

確認FW運行電話代理。為了檢查這一點，請輸入show run policy-map命令，它將顯示與以下類似的內容：

class sec_sip
inspect sip phone-proxy ASA-phone-proxy

停用電話代理以成功連線電話服務。

與呼叫相關的問題

透過MRA呼叫時無介質

以下是在單一和雙NIC部署中可能導致此問題的缺席和不正確配置：

• 在System > Network Interfaces > IP下的Expressway E中未配置靜態NAT。網路層的NAT仍然需要在防火牆中完成，但此設定會轉換應用層的IP。
• 防火牆中的TCP/UDP埠未打開。有關埠清單，請參閱Cisco Expressway IP埠使用配置指南。

不建議使用具有靜態NAT部署的單個NIC。以下是一些防止介質問題的注意事項：

• 在UC遍歷區域，Expressway-C需要指向Expressway-E中配置的公共IP地址。
• 媒體必須「髮夾式」或在外部防火牆中反映出來。有關Cisco ASA防火牆的配置示例，請參閱在ASA上為VCS Expressway網真裝置配置NAT反射。 

有關詳細資訊，請參閱思科Expressway E和Expressway C基本配置部署指南附錄4。

透過MRA呼叫到PSTN時無回鈴

此問題是由於X8.5之前的版本對Expressway的限制。思科漏洞ID CSCua72781描述了Expressway-C如何在183會話進程或穿越區域的180振鈴時轉發早期介質。如果運行版本X8.1.x或X8.2.x，可以升級到版本X8.5，或者執行此處列出的解決方法。

如果建立SIP配置檔案，將183變為180，並將其應用於傳入撥號對等體，則可以在Cisco Unified Border Element (CUBE)上使用解決方法。舉例來說：

voice class sip-profiles 11
response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session Progress" 
"SIP/2.0 180 Ringing"

然後，他們會在sip-ua配置模式下停用CUCM > CUBE的SIP配置檔案或CUBE自身上的180早期媒體。

disable-early-media 180

CUCM和即時消息與門戶問題

ASCII錯誤導致無法增加CUCM 

將CUCM增加到Expressway-C時，會遇到阻止增加CUCM的ASCII錯誤。

當Expressway-C將CUCM增加到其資料庫時，它會運行一系列與get和list函式相關的AXL查詢。這些示例包括getCallManager、listCallManager、listProcessNode、listProcessNodeService和getCCMVersion。運行getCallManager進程後，ExecuteSQLQuery 集將成功檢索所有CUCM Call Manager-trust或tomcat-trust。

CUCM收到查詢並在查詢上執行後，CUCM會報告其所有證書。如果其中一個證書包含非ASCII字元，Expressway會在Web介面中生成類似於「ascii codec cannot decode byte 0xc3 in position 42487： ordinal not in range(128)」的錯誤。

此問題透過思科漏洞ID CSCuo54489跟蹤，並在版本X8.2中解決。

安全部署中5061上從Expressway-C到CUCM的出站TLS故障

當您在CUCM上使用自簽名證書並且Tomcat.pem/CallManager.pem具有同一主題時，會出現此問題。此問題透過思科漏洞ID CSCun30200解決。解決此問題的方法是刪除tomcat.pem，並從Expressway-C上的CUCM配置中停用TLS驗證。

未新增IM&P伺服器且發生錯誤

增加IM&P伺服器時，Expressway-C會報告「此伺服器不是IM and Presence伺服器」或「無法與.AXL查詢HTTP錯誤「HTTPError：500」，這將導致無法增加IM&P伺服器。

作為增加IM&P伺服器的一部分，Expressway-C使用AXL查詢在顯式目錄中查詢IM&P證書。由於思科漏洞ID CSCul05131，證書不在該儲存區中，因此您會遇到false錯誤。

雜項問題

Jabber客戶端上的語音郵件狀態顯示「未連線」

為了使Jabber客戶端語音郵件狀態成功連線，必須在Expressway-C的HTTP允許清單中配置Cisco Unity Connection IP地址或主機名。

要從Expressway-C完成此操作，請執行相關步驟：

X8.1和X8.2版的程式

1. 按一下Configuration > Unified Communications > Configuration > Configure HTTP server allow list。
2. 按一下New > Enter IP/Hostname > Create entry。
3. 註銷Jabber客戶端，然後重新登入。

X8.5版的程式

1. 按一下Configuration > Unified Communications > Unity Connection Servers。
2. 按一下New > Enter IP/Hostname， User account credentials > Add Address。
3. 註銷Jabber客戶端，然後重新登入。

聯絡人照片未通過Expressway顯示在Jabber客戶端上

移動和遠端訪問解決方案僅使用UDS進行聯絡人照片解析。這要求您有可用來儲存像片的Web伺服器。該配置本身是雙重的。

1. 必須修改jabber-config.xml檔案，才能將客戶端定向到Web伺服器以進行聯絡人照片解析。此處的配置實現了此目的。
   
   

   <Directory>
   <DirectoryServerType>UDS</DirectoryServerType>
   <PhotoUriWithToken>http://%IP/Hostname%/photo%%uid%%.jpg<
   /PhotoUriWithToken>
   <UdsServer>%IP%</UdsServer>
   <MinimumCharacterQuery>3</MinimumCharacterQuery>
   </Directory>

2. 1. 按一下Configuration > Unified Communications > Configuration > Configure HTTP server allow list。
   2. 按一下New > Enter IP/Hostname > Create entry。
   3. 註銷Jabber客戶端，然後重新登入。Expressway-C的Web伺服器必須列在HTTP伺服器允許清單中。

   注意：有關UDS聯絡照片解析的詳細資訊，請參閱Jabber聯絡照片文檔。

登入期間，Jabber客戶端會提示接受Expressway E證書

此錯誤消息可能與未由客戶端裝置信任的公共CA簽名的Expressway Edge證書，或者伺服器證書中沒有作為SAN的域有關。

要阻止Jabber客戶端出現Expressway證書接受提示，必須滿足以下兩個條件：

• 運行Jabber客戶端的裝置/電腦必須在其證書信任儲存中列出Expressway E證書的簽名者。
  
  

  注意：如果使用公共證書頒發機構，則很容易實現此目的，因為流動裝置包含一個大型證書信任庫。

• 用於合作邊緣記錄的Unified CM註冊域必須存在於Expressway-E證書的SAN中。Expressway伺服器中的CSR工具為您提供了將Unified CM註冊域作為SAN增加的選項，如果域配置為MRA，則會預先載入該工具。如果簽署憑證的CA不接受網域作為SAN，您也可以使用「CollabEdgeDNS」選項，將首碼「collab-edge」新增到網域：

相關資訊

• Expressway上的移動和遠端訪問指南
• Cisco Expressway證書建立和使用部署指南
• Cisco TelePresence Video Communication Server (Cisco VCS) IP埠使用情況用於防火牆穿越
• Cisco Jabber部署和安裝指南
• 技術支援與文件 - Cisco Systems