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

简介

本文档介绍如何解决您在部署阶段遇到的最常见的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记录用于确定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，或者它不是外部可用的，或者如果它可用，但端口8443无法访问，则Jabber客户端无法登录。

您可以通过协作解决方案分析器(CSA)中的SRV检查器确认_collab-edge SRV记录是否可以解析以及TCP端口8443是否可以访问。

如果端口8443无法访问，这可能是因为安全设备（防火墙）阻止该端口，或者Exp-E中的默认网关(GW)或静态路由配置错误。

2. VCS Expressway上的证书不可接受或不可用

在Jabber客户端收到_collab-edge的应答后，它会通过端口8443联系具有传输层安全(TLS)的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记录的详细信息，请参阅8.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%'， port 7400：(111) Connection Refused

如果Expressway-E网络接口控制器(NIC)配置不正确，可能会导致可扩展通信平台(XCP)服务器无法更新。如果Expressway-E符合这些标准，则您可能会遇到此问题：

1. 使用一张网卡。
2. 安装高级网络选项密钥。
3. 使用双网络接口选项设置为是。

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

出现此问题的原因是，Expressway-E在错误的网络接口上侦听XCP会话，导致连接失败/超时。Expressway-E在TCP端口7400上侦听XCP会话。从VCS作为根使用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查询通过隧道连接到内部网络，就好像PC使用VPN一样。

注意：Microsoft DirectAccess不支持Jabber over MRA。任何故障排除都是尽力而为的。DirectAccess的配置由网络管理员负责。

有时，您可以成功阻止Microsoft DirectAccess名称解析策略表中的所有DNS记录。DirectAccess无法处理这些记录（Jabber需要能够通过MRA的公共DNS解析这些记录）：

• _cisco-uds的SRV记录
• _cuplogin的SRV记录
• _collab-edge的SRV记录
• 所有Expressway E的记录

9. Expressway反向DNS查找失败

从版本X8.8开始，Expressway/VCS要求为ExpE、ExpC和所有CUCM节点创建转发和逆向DNS条目。 

有关完整要求，请参阅x8.8发行版本注释和移动和远程访问的DNS记录中的前提条件和软件依赖性。

如果内部DNS记录不存在，则在引用reverseDNSLookup的Expressway日志中可能存在错误：

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-C在查询Expressway-E IP的PTR记录时仅收到一个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的诊断日志显示响应Jabber客户端发送的注册请求的SIP/2.0 405 Method Not Allowed消息。这可能是由于Expressway-C和CUCM之间具有端口5060/5061的当前会话发起协议(SIP)中继所致。

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"。

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

• 如果不想使用非安全设备安全配置文件，Jabber客户端是否在CUCM中使用安全设备安全配置文件？
  
  
• 如果Jabber客户端使用安全的设备安全配置文件，安全配置文件的名称是否为FQDN格式，以及该FQDN名称是否作为SAN配置在Expressway-C证书上？
  
  
• 如果Jabber客户端使用安全的设备安全配置文件，请导航到系统>企业参数>安全参数>集群安全模式，并检查集群安全模式是否设置为1以验证CUCM集群已受到保护。如果值为0，则管理员必须完成所记录的过程才能保护集群。

Softphone无法注册，原因是“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的详细信息，请参阅思科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运行电话代理。要检查是否出现了这种情况，请输入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端口未打开。有关端口列表，请参阅思科Expressway IP端口使用配置指南。

不推荐使用单一NIC进行静态NAT部署。以下是防止介质问题的一些注意事项：

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

有关详细信息，请参阅Cisco 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并将其应用于传入的拨号对等体，则可以使用思科统一边界元素(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和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 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具有相同主题时，会发生此问题。通过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（仅限注册用户），证书不在该存储区中，因此您会遇到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必须在HTTP服务器允许列表中列出Web服务器。

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

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

此错误消息可能与未由客户端设备信任的公共CA签名的Expressway Edge证书或域在服务器证书中缺少作为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