본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.
Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.
MRA(Mobile & Remote Access)는 VPN(Virtual Private Network-less) Jabber 기능을 위한 구축 솔루션입니다.이 솔루션을 통해 최종 사용자는 전 세계 어디서나 내부 엔터프라이즈 리소스에 연결할 수 있습니다.이 가이드는 Collaboration Edge 솔루션의 문제를 해결하는 엔지니어에게 구축 문구 중에 고객이 직면한 가장 일반적인 문제를 신속하게 파악하고 해결할 수 있는 기능을 제공하기 위해 작성되었습니다.
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
이 증상의 원인은 다양한 문제 때문에 발생할 수 있으며, 그 중 몇 가지는 여기에 설명되어 있습니다.
Jabber 클라이언트가 MRA로 성공적으로 로그인하려면 특정 협업 에지 SRV 레코드를 생성하고 외부에서 액세스할 수 있어야 합니다.Jabber 클라이언트가 처음 시작될 때 DNS SRV 쿼리를 만듭니다.
Jabber 클라이언트가 시작되어 _cisco-uds 및 _cuplogin에 대한 SRV 응답을 받지 못하고_collab-edge에 대한 응답을 수신하지 않으면 이 답을 사용하여 SRV 응답에 나열된 Expressway-E에 연결하려고 시도합니다.
_collab-edge SRV 레코드는 포트 8443의 Expressway-E의 FQDN(Fully Qualified Domain Name)을 가리켜야 합니다._collab-edge SRV가 생성되지 않았거나 외부에서 사용할 수 없거나 사용 가능한 경우 포트 8443에 연결할 수 없는 경우 Jabber 클라이언트가 로그인하지 못합니다.
CSA(Collaboration Solutions Analyzer)에서 SRV 검사기를 사용하여 _collab-edge SRV 레코드를 확인할 수 있으며 TCP 포트 8443에 연결할 수 있는지 확인할 수 있습니다.
포트 8443에 연결할 수 없는 경우 포트를 차단하는 보안 디바이스(방화벽)나 Exp-E에서 GW(Default Gateway) 또는 Static 경로를 잘못 구성했기 때문일 수 있습니다.
Jabber 클라이언트가 _collab-edge에 대한 응답을 받은 후 포트 8443을 통해 Expressway에 연결하여 Jabber 클라이언트와 Expressway 간의 통신을 위해 TLS를 설정하기 위해 Expressway에서 인증서를 검색하려고 시도합니다.
Expressway에 Expressway의 FQDN 또는 도메인을 포함하는 유효한 서명 인증서가 없는 경우 이 오류가 발생하고 Jabber 클라이언트가 로그인하지 못합니다.
이 문제가 발생하면 Expressway의 FQDN을 SAN(Subject Alternative Name)으로 자동으로 포함하는 Expressway에서 CSR(Certificate Signing Request) 툴을 사용해야 합니다.
참고:MRA는 Expressway-C와 Expressway-E 간, 그리고 Expressway-E와 외부 엔드포인트 간의 안전한 통신을 필요로 합니다.
기능별 Expressway 인증서 요구 사항이 있는 다음 표는 MRA 구축 설명서에서 확인할 수 있습니다.
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(User Data Service)가 반환되지 않는 것을 발견한 경우 _cisco-uds SRV 레코드가 외부 도메인이 있는 내부 DNS에 생성되었는지 확인해야 합니다.
참고:Expressway 버전 X12.5 이후에는 더 이상 _cisco-UDS SRV 레코드를 내부 DNS에 추가할 필요가 없습니다.이 개선 사항에 대한 자세한 내용은 Cisco Expressway 구축 설명서(X12.5)를 통한 모바일 및 원격 액세스를 참조하십시오.
Expressway-E NIC(Network Interface Controller)가 잘못 구성된 경우 XCP(Extensible Communications Platform) 서버가 업데이트되지 않을 수 있습니다.Expressway-E가 이러한 조건을 충족하면 다음과 같은 문제가 발생할 수 있습니다.
이 문제를 해결하려면 Use Dual Network Interfaces(듀얼 네트워크 인터페이스 사용) 옵션을 No(아니요)로 변경합니다.
이러한 문제가 발생하는 이유는 Expressway-E가 잘못된 네트워크 인터페이스에서 XCP 세션을 수신 대기하기 때문에 연결이 실패/시간 초과되기 때문입니다.Expressway-E는 XCP 세션을 위해 TCP 포트 7400에서 수신 대기합니다.다음 명령을 사용할 경우 netstat
명령을 VCS에서 root로 실행합니다.
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/Address가 어떻게 표시되는지 보여주는 예입니다.
<xmppEdgeServer>
<server>
<address>examplelab-vcse1.example.com</address>
<tlsPort>5222</tlsPort>
</server>
</xmppEdgeServer>
이를 방지하려면 _collab-edge SRV 레코드가 Expressway-E 호스트 이름/도메인 이름과 일치하는지 확인합니다.Cisco 버그 ID CSCuo83458이 신청되었으며 Cisco 버그 ID CSCuo82526에 부분 지원이 추가되었습니다.
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://loginp.webexconnect.com;
Url: http://loginp.webexconnect.com/cas/FederatedSSO?org=example.com';;;.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://loginp.webexconnect.com/cas/FederatedSSO?org=example.com2014-11-22
19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStoreManager.cpp(286)]
[ConfigStoreManager] [ConfigStoreManager::storeValue] - key : [last_cas_lookup_url]
value : [http://loginp.webexconnect.com/cas/FederatedSSO?org=example.com]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://loginp.webexconnect.com/cas/FederatedSSO?org=example.com]
success: [true] configStoreName: [LocalFileConfigStore]
로그인 시도는 WebEx Connect로 전송됩니다.
영구적인 해결을 위해 사이트를 서비스 해제하려면 WebEx에 문의해야 합니다.
해결 방법
단기적으로는 이러한 옵션 중 하나를 사용하여 조회에서 제외할 수 있습니다.
<?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
참고:두 번째 옵션은 모바일 장치에 대해 작동하지 않습니다.
ciscojabber://provision?ServiceDiscoveryExcludedServices=WEBEX
UC 서비스 검색에 대한 자세한 내용 및 Cisco Jabber 12.8용 온프레미스 구축에서 일부 서비스를 제외하는 방법에 대한 자세한 내용을 확인할 수 있습니다.
Status(상태) > Unified Communications로 이동하고 오류 메시지가 표시되면 "Configured but with errors. Provisioning server: Waiting for traversal server info."
Unified CM 등록 및 IM&P 서비스의 경우 Expressway-C에 구성된 내부 DNS 서버에는 Expressway-E에 대해 2개의 DNS A 레코드가 있습니다.Expressway-E에 대한 여러 DNS A 레코드 뒤에 있는 이유는 영향을 받는 사용자가 Expressway-E에서 고정 NAT가 활성화된 단일 NIC에서 고정 NAT가 활성화된 듀얼 NIC로 또는 그 반대로 이동하고 내부 DNS 서버에서 해당 DNS A 레코드를 삭제하는 것을 잊어버렸을 수 있습니다. 따라서 Expressway-C에서 DNS 조회 유틸리티를 사용하여 Expressway-E FQDN을 확인하면 두 개의 DNS A 레코드를 확인할 수 있습니다.
솔루션
고정 NAT가 있는 단일 NIC에 대해 Expressway-E NIC가 구성된 경우:
ipconfig /flushdns
)를 참조하십시오.고정 NAT가 활성화된 이중 NIC에 대해 Expressway-E NIC가 구성된 경우:
ipconfig /flushdns
)를 참조하십시오.고객은 Jabber 클라이언트와 동일한 PC에서 Microsoft DirectAccess를 사용할 수 있습니다.원격으로 로그인하려고 하면 MRA가 손상될 수 있습니다.DirectAccess는 PC에서 VPN을 사용하는 것처럼 DNS 쿼리를 내부 네트워크로 터널링합니다.
참고:Microsoft DirectAccess는 MRA를 통한 Jabber에서 지원되지 않습니다.모든 트러블슈팅은 최선의 노력입니다.DirectAccess 구성은 네트워크 관리자의 책임입니다.
일부 고객은 Microsoft DirectAccess 이름 확인 정책 테이블의 모든 DNS 레코드를 차단하여 성공했습니다.이러한 레코드는 DirectAccess에서 처리해서는 안 됩니다(Jabber는 MRA를 사용할 때 공용 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-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 host.example.com"
Expressway-C의 진단 로그에 SIP/2.0 405 Method Not Allowed
Jabber 클라이언트에서 보낸 등록 요청에 대한 응답으로 표시되는 메시지입니다.포트 5060/5061을 사용하는 Expressway-C와 CUCM 간의 기존 SIP(Session Initiation Protocol) 트렁크 때문일 수 있습니다.
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
Expressway-C
"Unknown domain"
Expressway-C의 진단 로그에 이벤트="Registration Rejected" Reason="Unknown domain"
Service="SIP" Src-ip="XXX.XXX.XXX.XXX" Src-port="51601" Protocol="TCP" AOR="sip:XXX.XXX.XXX.XXX".
이 문제를 해결하려면 다음 사항을 확인하십시오.
"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-ip="92.90.21.82" 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(Application Layer Gateway) 기능이 설정되어 있을 가능성이 높습니다.이 문제를 해결하려면 이 기능을 비활성화해야 합니다.이 방법을 잘 모르는 경우 방화벽 공급업체의 제품 설명서를 참조해야 합니다.
SIP Inspection/ALG에 대한 자세한 내용은 Cisco Expressway-E 및 Expressway-C-Basic Configuration Deployment Guide의 부록 4를 참조하십시오.
Expressway-E의 진단 로그에 포트 5061에서 TLS 협상 실패가 표시되지만 SSL 핸드셰이크가 포트 8443에서 성공했습니다.
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,533" Module="network.tcp" Level="DEBUG": Src-ip="173.38.117.81" 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-ip="173.38.117.81" 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-ip="173.38.117.81" 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-ip="173.38.117.81" 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: 'expe.korteco.com' 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=expe.korteco.com: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에서 Phone Proxy를 실행하는지 확인합니다.확인하려면 show run policy-map
다음과 비슷한 것을 표시합니다.
class sec_sip
inspect sip phone-proxy ASA-phone-proxy
전화 서비스가 성공적으로 연결되도록 전화 프록시 사용 안 함
다음은 단일 및 이중 NIC 구축에서 이 문제를 일으킬 수 있는 누락되거나 잘못된 컨피그레이션 중 일부입니다.
고정 NAT 구축이 포함된 단일 NIC는 권장되지 않습니다.미디어 문제를 방지하는 몇 가지 고려 사항은 다음과 같습니다.
이에 대한 자세한 내용은 Cisco Expressway-E 및 Expressway-C 기본 구성 구축 설명서의 부록 4를 참조하십시오.
이 문제는 버전 X8.5 이전의 Expressway에 대한 제한 때문에 발생합니다. Cisco 버그 ID CSCua72781은 Expressway-C가 183 Session Progress(183 세션 진행) 또는 180 Ringing(180 벨울림)에서 초기 미디어를 전달하지 않는 방법을 설명합니다.버전 X8.1.x 또는 X8.2.x를 실행하는 경우 버전 X8.5로 업그레이드하거나 여기에 나열된 해결 방법을 수행할 수 있습니다.
183을 180으로 변환하여 수신 다이얼 피어에 적용하는 SIP 프로파일을 만들면 Cisco CUBE(Unified Border Element)에서 해결 방법을 사용할 수 있습니다.예:
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 프로필 또는 SIP 구성 모드 내의 CUBE 자체에서 180 Early Media를 비활성화합니다.
disable-early-media 180
Expressway-C에 CUCM을 추가하면 CUCM을 추가하지 못하게 하는 ASCII 오류가 발생합니다.
Expressway-C가 데이터베이스에 CUCM을 추가하면 get 및 list 기능과 관련된 일련의 AXL 쿼리를 통해 실행됩니다.이러한 예에는 getCallManager, listCallManager, listProcessNode, listProcessNodeService, getCMVersion이 포함됩니다.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 버그 ID CSCuo54489로 추적되며 버전 X8.2에서 해결됩니다.
이 문제는 CUCM 및 Tomcat.pem/CallManager.pem에서 자체 서명 인증서를 사용하는 경우 발생합니다.이 문제는 Cisco 버그 ID CSCun30200으로 해결됩니다. 문제를 해결하려면 tomcat.pem을 삭제하고 Expressway-C의 CUCM 구성에서 TLS 확인을 비활성화하는 것입니다.
IM&P 서버를 추가하면 Expressway-C는 "이 서버는 IM and Presence Server가 아닙니다." 또는 "Unable to communicate with .AXL query HTTP error "HTTPError:500'"(IM&P 서버가 추가되지 않음)을 보고합니다.
IM&P 서버를 추가할 때 Expressway-C는 AXL 쿼리를 사용하여 명시적 디렉토리에서 IM&P 인증서를 찾습니다.Cisco 버그 ID CSCul05131로 인해 인증서가 해당 저장소에 없습니다.따라서 잘못된 오류가 발생합니다.
Jabber 클라이언트 음성 메일 상태가 성공적으로 연결되도록 하려면 Expressway-C의 HTTP 허용 목록 내에서 Cisco Unity Connection IP 주소 또는 호스트 이름을 구성해야 합니다.
Expressway-C에서 이 작업을 완료하려면 다음 절차를 수행합니다.
버전 X8.1 및 X8.2에 대한 절차
버전 X8.5 절차
모바일 및 원격 액세스 솔루션은 연락처 사진 확인을 위해 UDS만 사용합니다.따라서 사진을 저장할 수 있는 웹 서버가 있어야 합니다.구성 자체는 2배입니다.
<Directory>
<DirectoryServerType>UDS</DirectoryServerType>
<PhotoUriWithToken>http://%IP/Hostname%/photo%%uid%%.jpg<
/PhotoUriWithToken>
<UdsServer>%IP%</UdsServer>
<MinimumCharacterQuery>3</MinimumCharacterQuery>
</Directory>
이 오류 메시지는 클라이언트의 디바이스에서 신뢰하는 공용 CA에서 서명하지 않은 Expressway Edge 인증서나 서버 인증서에 SAN으로 도메인이 누락되어 있는 것과 관련될 수 있습니다.
Jabber 클라이언트가 Expressway 인증서를 승인하라는 메시지가 표시되지 않도록 하려면 아래 나열된 두 기준을 충족해야 합니다.
참고:모바일 디바이스에는 대형 인증서 신뢰 저장소가 있으므로 공용 인증 기관을 사용하는 경우 이 작업을 쉽게 수행할 수 있습니다.