解决协作边缘最常见的问题

简介

本文档介绍如何解决客户在部署阶段遇到的最常见的Collaboration Edge问题。

背景信息

移动和远程访问(MRA)是虚拟专用无网络(VPN)Jabber功能的部署解决方案。此解决方案允许最终用户从全球任何地方连接到内部企业资源。本指南旨在让对Collaboration Edge解决方案进行故障排除的工程师能够快速确定并解决客户在部署阶段面临的最常见问题。

先决条件

要求

Cisco 建议您了解以下主题：

• 思科统一通信管理器 (CUCM)
• Cisco Expressway核心
• Cisco Expressway边缘
• 思科即时消息和在线状态(IM&P)
• 用于Windows的Cisco Jabber
• Mac版Cisco Jabber
• 安卓版Cisco Jabber
• iOS版Cisco 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记录用于确定即时消息和通知服务器是否可用。
   
   
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未创建，或者不是外部可用，或者它可用，但无法访问端口8443，则Jabber客户端无法登录。

您可以确认_collab-edge SRV记录是否可解析，以及是否可以使用协作解决方案分析器(CSA)中的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和外部终端之间的安全通信。

在MRA部署指南中可找到具有Expressway证书要求功能的下一个表：

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之后，不再需要向内部DNS添加_cisco-UDS SRV记录。有关此增强功能的详细信息，请参阅通过Cisco Expressway进行移动和远程访问部署指南(X12.5)。

4. Expressway-C日志显示以下错误： XCP_JABBERD Detail=无法连接到主机“%IP%”，端口7400:(111)连接被拒绝

如果Expressway-E网络接口控制器(NIC)配置不正确，可能会导致无法更新可扩展通信平台(XCP)服务器。如果Expressway-E满足以下条件，则可能会遇到此问题：

1. 使用单个网卡。
2. 高级网络选项密钥已安装。
3. Use Dual Network Interfaces选项设置为Yes。

要解决此问题，请将Use Dual Network Interfaces选项更改为No。

出现此问题的原因是Expressway-E在错误的网络接口上侦听XCP会话，从而导致连接失败/超时。Expressway-E在TCP端口7400上侦听XCP会话。如果使用 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连接。

以下是xmppEdgeServer/Address在从Expressway-E到Jabber客户端的get_edge_config响应中的示例：

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

为避免这种情况，请确保_collab-edge SRV记录与Expressway-E主机名/域名匹配。Cisco Bug ID CSCuo83458已针对此进行了注册，并且在Cisco Bug 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服务器显示错误消息：“已配置但出现错误。设置服务器：正在等待穿越服务器信息。"

如果导航到Status（状态）> Unified Communications（统一通信）并看到错误消息， "Configured but with errors. Provisioning server: Waiting for traversal server info."  对于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刷新Expressway C和用户PC中的DNS缓存(ipconfig /flushdns影响。
3. 重新启动Expressway-C服务器。

如果Expressway-E NIC配置为启用静态NAT的双NIC:

1. 删除Expressway-C中配置的DNS服务器中Expressway-E 外部IP地址的DNS A记录。
2. 通过CMD刷新Expressway C和用户PC中的DNS缓存(ipconfig /flushdns影响。
3. 重新启动Expressway-C服务器。

8.已安装Microsoft DirectAccess

如果客户在与Jabber客户端相同的PC上使用Microsoft DirectAccess，当您尝试远程登录时，可能会中断MRA。DirectAccess强制DNS查询通过隧道传输到内部网络，就像PC使用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"

注册问题

软件电话无法注册，不允许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 Settings > Protocols > SIP中，确保Expressway-C仍在5060上侦听SIP。

软电话无法注册，原因="Unknown domain"

来自Expressway-C的诊断日志显示Event="Registration Rejected" Reason="Unknown domain" Service="SIP" Src-ip="XXX.XXX.XXX" Src-port="51601" Protocol="TCP" AOR="sip:XXX.XXX.XXX.XXX"。

要解决此问题，请检查以下几点：

• 当目的不是使用非安全设备安全配置文件时，Jabber客户端是否在CUCM中使用安全设备安全配置文件?
  
  
• 如果Jabber客户端使用安全的设备安全配置文件，安全配置文件的名称是否为FQDN格式，以及该FQDN名称是否在Expressway-C证书上配置为SAN?
  
  
• 如果Jabber客户端使用安全的设备安全配置文件，请导航到System > Enterprise Parameters > Security Parameters > Cluster Security Mode，并检查Cluster Security Mode是否设置为1，以验证CUCM集群已受到保护。如果值为0，则管理员必须完成所记录的过程以保护集群。

软件电话无法注册，原因 "Idle countdown expired"

在Jabber客户端发送REGISTER消息的时间范围内查看Expressway E日志时，请查找 Idle countdown expired 如代码片断所示的错误。

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呼叫时无介质

以下是一些缺乏和不正确的配置，可导致单网卡和双网卡部署中出现此问题：

• Expressway-E中的System > Network Interfaces > IP下未配置静态NAT。网络层的NAT仍然需要在防火墙中完成，但是此设置会转换应用层的IP。
• 防火墙中的TCP/UDP端口未打开。有关端口列表，请参阅Cisco Expressway IP端口使用配置指南

建议不要使用单个网卡进行静态NAT部署。以下是一些防止介质问题的注意事项：

issing

• 在UC遍历区域中，Expressway-C需要指向Expressway-E中配置的公共IP地址。
• 介质必须“发夹”或反映在外部防火墙中。有关Cisco ASA防火墙的配置示例，请参阅为VCS Expressway网真设备在ASA上配置NAT反射。 

有关这方面的详细信息，请参阅Cisco Expressway-E和Expressway-C基本配置部署指南的附录4。

通过MRA呼叫PSTN时无回铃

此问题是由于X8.5之前的Expressway受到限制所致。Cisco Bug ID CSCua72781描述了Expressway-C如何在穿越区域的183会话进程或180振铃时不会转发早期媒体。如果运行版本X8.1.x或X8.2.x，可以升级到版本X8.5，或者执行此处列出的解决方法。

如果创建SIP配置文件，将183转换为180并将其应用于传入拨号对等体，则可以使用思科统一边界元素(CUBE)上的解决方法。例如：

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

然后，它们将在CUCM > CUBE的SIP配置文件或CUBE自身在sip-ua配置模式下禁用180早期媒体。

disable-early-media 180

CUCM和IM&P问题

阻止添加CUCM的ASCII错误 

将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会在网络界面中生成错误，类似于 ascii codec can't decode byte 0xc3 in position 42487: ordinal not in range(128).

此问题通过Cisco Bug ID CSCuo5489进行跟踪，并在X8.2版本中已解决。

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

当您在CUCM和Tomcat.pem/CallManager.pem上使用自签名证书时，会出现此问题。此问题通过Cisco Bug 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证书。由于Cisco Bug ID CSCul05131，证书不在该存储区中；因此，您会遇到错误信息。

其他问题

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. 单击新建>输入IP/主机名>创建条目。
3. 注销Jabber客户端，然后重新登录。

X8.5版的程序

1. 单击配置>统一通信> Unity Connection服务器。
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. Expressway-C必须在HTTP服务器允许列表中列出Web服务器。
   
   
   1. 单击Configuration > Unified Communications > Configuration > Configure HTTP server allow list。
   2. 单击新建>输入IP/主机名>创建条目。
   3. 注销Jabber客户端，然后重新登录。
   
   
   

   注意：有关UDS联系人照片解析的详细信息，请参阅Jabber联系人照片文档。

Jabber客户端在登录期间提示接受Expressway-E证书

此错误消息可能与未由客户端设备信任的公共CA签名的Expressway边缘证书或域在服务器证书中作为SAN缺失有关。

要从Expressway证书接受提示中停止Jabber客户端，必须满足下面列出的两个条件：

• 运行Jabber客户端的设备/计算机必须在其证书信任存储中列出Expressway-E证书的签名人。
  
  

  注意：如果您使用公共证书颁发机构，这很容易实现，因为移动设备包含一个大型证书信任库。

  
  
  
• 用于协作边缘记录的Unified CM注册域必须存在于Expressway-E证书的SAN中。Expressway服务器中的CSR工具为您提供将Unified CM注册域添加为SAN的选项，如果该域配置为MRA，则预加载该域。如果签署证书的CA不接受域作为SAN，您还可以使用“CollabEdgeDNS”选项，该选项将前缀“collab-edge”添加到域中：

相关信息

• Expressway上的移动和远程访问指南
• Cisco Expressway证书创建和使用部署指南
• 思科网真视频通信服务器（思科VCS）IP端口用于防火墙穿越
• Cisco Jabber部署和安装指南
• 技术支持和文档 - Cisco Systems