Colaboração Borda Problemas Mais Comuns

Introduction

O Acesso Móvel e Remoto (MRA) é uma solução de implantação para o recurso Jabber VPN (Virtual Private Network-less). Essa solução permite que os usuários finais se conectem a recursos internos da empresa em qualquer lugar do mundo. Este guia foi criado para dar aos engenheiros que solucionam problemas da solução Collaboration Edge a capacidade de identificar e resolver rapidamente os problemas mais comuns enfrentados pelos clientes durante a frase de implantação.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Cisco Unified Communications Manager (CUCM)
• Cisco Expressway Core
• Borda do Cisco Expressway
• Mensagens instantâneas e presença da Cisco (IM&P)
• Cisco Jabber para Windows
• Cisco Jabber para MAC
• Cisco Jabber para Android
• Cisco Jabber para iOS
• Certificados de segurança
• Domain Name System (DNS)

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Expressway versão X8.1.1 ou posterior
• CUCM Versão 9.1(2)SU1 ou posterior e IM&P Versão 9.1(1) ou posterior
• Cisco Jabber versão 9.7 ou posterior

Problemas de login

O Jabber não consegue iniciar sessão através do MRA

Esse sintoma pode ser causado por uma grande variedade de problemas, alguns dos quais estão descritos aqui.

1. Registro de serviço de borda de colaboração (SRV) não criado e/ou porta 8443 inalcançável

Para que um cliente Jabber possa fazer login com êxito com o MRA, um registro SRV de borda de colaboração específico deve ser criado e acessível externamente. Quando um cliente Jabber é iniciado inicialmente, ele faz consultas DNS SRV:

1. _cisco-uds: Esse registro SRV é usado para determinar se um servidor CUCM está disponível.
   
   
2. _cuplogin: Esse registro SRV é usado para determinar se um servidor IM&P está disponível.
   
   
3. _collab-edge: Este registro SRV é usado para determinar se o MRA está disponível.
   
   

Se o cliente Jabber for iniciado e não receber uma resposta SRV para _cisco-uds e _cuplogin e _collab-edge, então ele usará essa resposta para tentar entrar em contato com o Expressway-E listado na resposta SRV.

O registro SRV _collab-edge deve apontar para o FQDN (Fully Qualified Domain Name, nome de domínio totalmente qualificado) do Expressway-E com a porta 8443. Se o SRV _collab-edge não for criado, ou não estiver disponível externamente, ou se estiver disponível, mas a porta 8443 não puder ser alcançada, o cliente Jabber falhará ao fazer login.

Você pode confirmar se o registro SRV _collab-edge é resolvível e a porta TCP 8443 pode ser alcançada usando o verificador SRV no Collaboration Solutions Analyzer (CSA).

Se a porta 8443 não for alcançável, isso pode ser devido a um dispositivo de segurança (Firewall) bloqueando a porta ou a uma configuração incorreta do Gateway padrão (GW) ou das rotas estáticas no Exp-E.

2. Inaceitável ou sem certificado disponível no VCS Expressway

Depois que o cliente Jabber receber uma resposta para _collab-edge, ele entra em contato com o Expressway com o Transport Layer Security (TLS) pela porta 8443 para tentar recuperar o certificado do Expressway para configurar o TLS para comunicação entre o cliente Jabber e o Expressway.

Se o Expressway não tiver um certificado assinado válido que contenha o FQDN ou o domínio do Expressway, isso falhará e o cliente Jabber falhará ao fazer logon.

Se esse problema ocorrer, o cliente deve usar a ferramenta de Solicitação de Assinatura de Certificado (CSR - Certificate Signing Request) no Expressway, que inclui automaticamente o FQDN do Expressway como um Nome Alternativo de Assunto (SAN - Subject Alternative Name).

Nota: O MRA exige comunicação segura entre o Expressway-C e o Expressway-E e entre o Expressway-E e os endpoints externos.

A próxima tabela com os requisitos de certificado do Expressway por recurso pode ser encontrada no Guia de Implantação do MRA:

3. Nenhum servidor UDS encontrado na configuração de borda

Depois que o cliente Jabber estabelece com êxito uma conexão segura com o Expressway-E, ele solicita sua configuração de borda (get_edge_config). Esta configuração de borda contém os registros SRV para _cuplogin e _cisco-uds. Se os registros SRV _cisco-uds não forem retornados na configuração de borda, o cliente Jabber não poderá prosseguir com o login.

Para corrigir isso, certifique-se de que os registros SRV _cisco-uds sejam criados internamente e resolvidos pelo Expressway-C.

Mais informações sobre os registros SRV de DNS podem ser encontradas no Guia de implantação de MRA para X8.11.

Esse também é um sintoma comum se você estiver em um domínio duplo. Se você executar em um domínio duplo e descobrir que o cliente Jabber não está sendo retornado em nenhum UDS (User Data Service, serviço de dados do usuário), confirme se os registros SRV _cisco-uds foram criados no DNS interno com o domínio externo.

Nota: Depois da versão X12.5 do Expressway, não é mais necessário adicionar um registro SRV _cisco-UDS ao DNS interno. Para obter mais informações sobre esse aprimoramento, consulte o Guia de implantação do Mobile and Remote Access Through Cisco Expressway (X12.5).

4. Os Logs Do Expressway-C Mostram Este Erro: Detalhe de XCP_JABBERD="Não é possível conectar ao host '%IP%', porta 7400:(111) Conexão recusada"

Se a NIC (Network Interface Controller, Controlador de Interface de Rede) do Expressway-E estiver configurada incorretamente, isso pode fazer com que o servidor da XCP (Extensible Communications Platform, Plataforma de Comunicações Extensíveis) não seja atualizado. Se o Expressway-E atender a esses critérios, você provavelmente encontrará esse problema:

1. Usa uma única placa de rede.
2. A chave de opção de rede avançada está instalada.
3. A opção Usar interfaces de rede duplas está definida como Sim.

Para corrigir esse problema, altere a opção Usar interfaces de rede duplas para Não.

O motivo disso é que o Expressway-E escuta a sessão XCP na interface de rede errada, o que faz com que a conexão falhe/timeout. O Expressway-E escuta na porta TCP 7400 para a sessão XCP. Você pode verificar isso se usar o comando netstatdo VCS como raiz.

5. O nome de host/domínio do servidor Expressway-E não corresponde ao que está configurado no SRV _collab-edge

Se o nome de host/domínio do servidor Expressway-E na configuração da página DNS não corresponder ao que foi recebido na resposta SRV _collab-edge, o cliente Jabber não consegue se comunicar com o Expressway-E. O cliente Jabber usa o elemento xmppEdgeServer/Address na resposta get_edge_config para estabelecer a conexão XMPP com o Expressway-E.

Este é um exemplo de como é o xmppEdgeServer/Address na resposta get_edge_config do Expressway-E para o cliente Jabber:

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

Para evitar isso, certifique-se de que o registro SRV _collab-edge corresponda ao nome de host/nome de domínio do Expressway-E. A ID de bug da Cisco CSCuo83458 foi arquivada para isso e o suporte parcial foi adicionado na ID de bug CSCuo82526 da Cisco.

6. Não é possível fazer logon devido a uma assinatura do WebEx Connect existente

Os registros do Jabber para Windows mostram o seguinte:

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]

As tentativas de login são direcionadas para o WebEx Connect.

Para obter uma resolução permanente, você deve entrar em contato com o WebEx para que o site seja desativado.

Solução

A curto prazo, você pode utilizar uma dessas opções para excluí-la da pesquisa.

• Adicione esse parâmetro ao jabber-config.xml. Em seguida, faça o upload do arquivo jabber-config.xml para o servidor TFTP no CUCM. Exige que o cliente faça login internamente primeiro.
  
  

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

• Do ponto de vista do aplicativo, execute isto:
  msiexec.exe /i CiscoJabberSetup.msi /quiet CLEAR=1 AUTHENTICATOR=CUP EXCLUDED_SERVICES=WEBEX

Nota: A segunda opção não funciona para dispositivos móveis.

• Crie um URL clicável que exclua o serviço WEBEX:
  ciscojabber://provision?ServiceDiscoveryExcludedServices=WEBEX

Você pode encontrar mais detalhes sobre a descoberta do serviço UC e como excluir alguns serviços na implantação local do Cisco Jabber 12.8.

7. O servidor Expressway-C exibe a mensagem de erro: "Configurado, mas com erros. Servidor de provisionamento: Aguardando informações do servidor de passagem."

Se você navegar para Status > Unified Communications e ver a mensagem de erro, "Configured but with errors. Provisioning server: Waiting for traversal server info."  para os registros do Unified CM e o Serviço IM&P, os servidores DNS internos configurados no Expressway-C têm dois registros DNS A para o Expressway-E. O motivo por trás de vários registros de DNS A para o Expressway-E pode ser o usuário afetado movido de uma única NIC com NAT estático habilitado no Expressway-E para NIC dupla com NAT estático habilitado, ou vice-versa, e esquecido de excluir o registro de DNS A apropriado no(s) servidor(es) DNS interno(s). Portanto, ao usar o utilitário de pesquisa DNS no Expressway-C e resolver o FQDN do Expressway-E, você observará dois registros DNS A.

Solução

Se a placa de rede Expressway-E estiver configurada para uma única placa de rede com NAT estático:

1. Exclua o registro DNS A para o endereço IP interno do Expressway-E nos servidores DNS configurados no Expressway-C.
2. Limpe o cache DNS no Expressway-C e no PC do usuário via CMD (ipconfig /flushdns).
3. Reinicie o servidor Expressway-C.

Se a placa de rede Expressway-E estiver configurada para NIC dupla com NAT estático ativado:

1. Exclua o registro DNS A para o endereço IP externo Expressway-E no(s) servidor(es) DNS configurado(s) no Expressway-C.
2. Limpe o cache DNS no Expressway-C e no PC do usuário via CMD (ipconfig /flushdns).
3. Reinicie o servidor Expressway-C.

8. Microsoft DirectAccess instalado

O cliente pode usar o Microsoft DirectAccess no mesmo PC que o cliente Jabber. Quando você tenta fazer login remotamente, isso pode quebrar o MRA. O DirectAccess forçará consultas DNS a serem encapsuladas na rede interna como se o PC estivesse usando uma VPN.

Nota: O Microsoft DirectAccess não é compatível com Jabber sobre MRA. Qualquer solução de problemas é o melhor esforço. A configuração do DirectAccess é da responsabilidade do administrador da rede.

Alguns clientes obtiveram êxito ao bloquear todos os registros DNS na Tabela de Políticas de Resolução de Nomes do Microsoft DirectAccess. Esses registros não devem ser processados pelo DirectAccess (o Jabber precisa ser capaz de resolvê-los via DNS público ao usar MRA):

• registro SRV para _cisco-uds
• registro SRV para _cuplogin
• registro SRV para _collab-edge
• Um registro para todos os Es do Expressway

9. Falha nas pesquisas de DNS reverso do Expressway

Começando na versão X8.8, o Expressway/VCS exige que entradas de DNS posteriores e revertidas sejam criadas para ExpE, ExpC e todos os nós do CUCM. 

Para obter todos os requisitos, consulte Pré-requisitos e Dependências de Software nas Notas de Versão do x8.8 e Registros DNS para Acesso Móvel e Remoto.

Se os registros DNS internos não estiverem presentes, você poderá ver um erro nos registros do Expressway que se referem a 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"

O Expressway-C deve receber apenas um FQDN ao consultar o registro PTR para o IP do Expressway-E. Se receber um FQDN incorreto do DNS, ele mostrará esta linha nos registros e falhará:

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"

Problemas de registro

O softphone não consegue se registrar, método SIP/2.0 405 não permitido

Um log de diagnóstico do Expressway-C mostra um SIP/2.0 405 Method Not Allowed em resposta à solicitação de registro enviada pelo cliente Jabber. Isso provavelmente se deve a um tronco de Protocolo de Iniciação de Sessão (SIP - Session Initiation Protocol) existente entre o Expressway-C e o CUCM usando a porta 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 

Para corrigir esse problema, altere a porta SIP no Perfil de segurança do tronco SIP que é aplicada ao tronco SIP existente configurado no CUCM e na zona vizinha do Expressway-C para CUCM para uma porta diferente, como 5065. Isto é explicado mais adiante neste vídeo. Aqui está um resumo da configuração:

CUCM

1. Crie um novo perfil de segurança de tronco SIP com uma porta de escuta diferente de 5060 (5065).
2. Crie um tronco SIP associado ao perfil de segurança do tronco SIP e ao destino definidos para o endereço IP do Expressway-C, porta 5060.

Expressway-C

1. Crie uma zona vizinha para CUCM(s) com uma porta de destino diferente de 5060 (5065) para corresponder à configuração do CUCM.
2. Em Expressway-C Settings > Protocols > SIP, certifique-se de que o Expressway-C ainda ouça o 5060 para SIP.

O softphone não consegue se registrar, motivo="Unknown domain"

Um log de diagnóstico do Expressway-C mostra 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".

Para corrigir esse problema, verifique estes pontos:

• O cliente Jabber usa um Secure Device Security Profile no CUCM quando a intenção não é usar um Device Security Profile não seguro?
  
  
• Se os clientes Jabber devem usar um Perfil de segurança de dispositivo seguro, esse é o nome do perfil de segurança no formato FQDN e esse nome FQDN está configurado no certificado Expressway-C como uma SAN?
  
  
• Se os clientes Jabber devem usar um Perfil de segurança de dispositivo seguro, navegue para System > Enterprise Parameters > Security Parameters > Cluster Security Mode e verifique se o modo de segurança de cluster está definido como 1 para verificar se o cluster CUCM foi protegido. Se o valor for 0, o administrador deverá passar pelo procedimento documentado para proteger o cluster.

O softphone não consegue se registrar, motivo "Idle countdown expired"

Ao revisar os logs do Expressway-E durante o período de tempo que o cliente Jabber envia em uma mensagem REGISTER, você pode encontrar um Idle countdown expired erro, conforme indicado no trecho de código aqui.

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"

Esse trecho indica que o firewall tem a porta 5061 aberta; no entanto, não há tráfego da camada de aplicação que seja passado em uma quantidade suficiente de tempo para que a conexão TCP seja fechada.

Se você encontrar essa situação, há um alto grau de probabilidade de que o firewall em frente ao Expressway-E tenha a funcionalidade SIP Inspection/Application Layer Gateway (ALG) ativada. Para corrigir esse problema, você deve desativar essa funcionalidade. Se não tiver certeza de como fazer isso, consulte a documentação do produto do fornecedor do firewall.

Para obter mais informações sobre a inspeção SIP/ALG, consulte o Apêndice 4 do Guia de implantação de configuração básica do Cisco Expressway-E e do Expressway-C.

O MRA falha devido ao proxy do telefone configurado no firmware

Um log de diagnóstico do Expressway-E mostra uma falha de negociação TLS na porta 5061, no entanto, o handshake SSL foi bem-sucedido na porta 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"

Logs do 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.

A captura de pacotes do Jabber mostra uma negociação SSL com o Expressway E IP; no entanto, o certificado enviado não vem deste servidor:

O FW tem proxy de telefone configurado.

Solução:

Confirme se o firmware está executando o proxy do telefone. Para verificar isso, insira o comando show run policy-map e mostrará algo semelhante a:

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

Desative a ligação do Proxy de Telefone para serviços telefônicos com êxito.

Problemas de chamada

Nenhuma mídia quando você liga através do MRA

Estas são algumas das configurações incorretas e ausentes que podem causar esse problema em implantações de NIC simples e dupla:

• O NAT estático não está configurado no Expressway-E em System > Network Interfaces > IP. O NAT na camada de rede ainda precisa ser feito no firewall, mas essa configuração converterá o IP na camada de aplicação.
• As portas TCP/UDP não estão abertas no firewall. Para obter uma lista de portas, consulte o Guia de Configuração de Uso da Porta IP do Cisco Expressway

NIC única com implantações de NAT estático não é recomendada. Aqui estão algumas considerações para evitar problemas de mídia:

• Na zona de passagem UC, o Expressway-C precisa apontar para o endereço IP público configurado no Expressway-E.
• A mídia deve "hairpin" ou refletir no firewall externo. Um exemplo de configuração usando um firewall Cisco ASA pode ser encontrado em Configurar a Reflexão NAT no ASA para os dispositivos de TelePresença do VCS Expressway. 

Mais informações sobre isso podem ser encontradas no Apêndice 4 do Guia de implantação de configuração básica do Cisco Expressway-E e do Expressway-C.

Sem chamada de volta quando chamada MRA para PSTN

Esse problema é devido a uma limitação no Expressways anterior à versão X8.5. A ID de bug da Cisco CSCua72781 descreve como o Expressway-C não encaminha a mídia no início do 183 Session Progress ou 180 Ringing através da zona de passagem. Se você executar as versões X8.1.x ou X8.2.x, poderá atualizar para a versão X8.5 ou, alternativamente, executar a solução alternativa listada aqui.

É possível usar uma solução alternativa no Cisco Unified Border Element (CUBE) se você criar um perfil SIP que transforma o 183 em um 180 e o aplica no peer de discagem de entrada. Por exemplo:

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

Depois, desabilitariam o 180 Early Media no perfil SIP do CUCM > CUBE ou no próprio CUBE no modo de configuração sip-ua.

disable-early-media 180

Problemas de CUCM e IM&P

Erro ASCII que impede que o CUCM seja adicionado

Ao adicionar CUCM ao Expressway-C, você encontra um erro ASCII que impede que o CUCM seja adicionado.

Quando o Expressway-C adiciona o CUCM ao seu banco de dados, ele executa uma série de consultas AXL relacionadas às funções get e list. Exemplos disso incluem getCallManager, listCallManager, listProcessNode, listProcessNodeService e getCCMVersion. Depois que o processo getCallManager é executado, ele é bem-sucedido por um ExecuteSQLQuery definido para recuperar todas as confiança do CUCM Call Manager ou do tomcat.

Quando o CUCM recebe a consulta e a executa nela, o CUCM reporta todos os seus certificados. Se um dos certificados contiver um caractere não ASCII, o Expressway gerará um erro na interface da Web semelhante a ascii codec can't decode byte 0xc3 in position 42487: ordinal not in range(128).

Esse problema é rastreado com o bug da Cisco ID CSCuo54489 e é resolvido na versão X8.2.

Falhas de TLS de saída no 5061 do Expressway-C para o CUCM em implantações seguras

Esse problema ocorre quando você usa certificados autoassinados no CUCM e no Tomcat.pem/CallManager.pem têm o mesmo assunto. O problema é tratado com o bug da Cisco ID CSCun30200. A solução alternativa para corrigir o problema é excluir o tomcat.pem e desabilitar a Verificação TLS da configuração do CUCM no Expressway-C.

Servidor IM&P não adicionado e erros encontrados

Quando você adiciona um Servidor IM&P, o Expressway-C relata "Este servidor não é um Servidor IM e Presence" ou "Não é possível se comunicar com o erro HTTP da consulta .AXL ''HTTPError:500''", o que faz com que o Servidor IM&P não seja adicionado.

Como parte da adição de um servidor IM&P, o Expressway-C usa uma consulta AXL para procurar certificados IM&P em um diretório explícito. Devido à ID de bug da Cisco CSCul05131, os certificados não estão nessa loja; portanto, você encontra o erro falso.

Problemas diversos

O status do correio de voz no cliente Jabber mostra "Não conectado"

Para fazer com que o status do correio de voz do cliente Jabber se conecte com êxito, você deve configurar o endereço IP ou o nome do host do Cisco Unity Connection na lista de permissões HTTP no Expressway-C.

Para concluir isso no Expressway-C, execute o procedimento relevante:

Procedimento para as versões X8.1 e X8.2

1. Clique em Configuration > Unified Communications > Configuration > Configure HTTP server allow list.
2. Clique em New > Enter IP/Hostname > Create entry (Novo > Inserir nome de host > Criar entrada).
3. Faça logoff do cliente Jabber e, em seguida, faça logon novamente.

Procedimento para a versão X8.5

1. Clique em Configuration > Unified Communications > Unity Connection Servers.
2. Clique em Novo > Inserir nome de host/IP, credenciais de conta de usuário > Adicionar endereço.
3. Faça logoff do cliente Jabber e, em seguida, faça logon novamente.

Fotos de contato não aparecem em clientes Jabber através de expressways

A solução de acesso remoto e móvel usa apenas UDS para resolução de fotos de contato. Isso exige que você tenha um servidor Web disponível para armazenar as fotos. A configuração em si é dupla.

1. O arquivo jabber-config.xml deve ser modificado para direcionar os clientes ao servidor web para a resolução de Fotos de Contato. A configuração aqui deve conseguir isso.
   
   

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

   
   
   
2. O Expressway-C deve ter o servidor Web listado na Lista de permissões do servidor HTTP.
   
   
   1. Clique em Configuration > Unified Communications > Configuration > Configure HTTP server allow list.
   2. Clique em New > Enter IP/Hostname > Create entry (Novo > Inserir nome de host > Criar entrada).
   3. Faça logoff do cliente Jabber e, em seguida, faça logon novamente.
   
   
   

   Nota: Para obter mais informações sobre a resolução de fotos de contato do UDS, consulte a documentação de fotos de contato do Jabber.

Os clientes Jabber são solicitados a aceitar o certificado Expressway-E durante o login

Essa mensagem de erro pode estar relacionada ao certificado Expressway Edge não assinado por uma CA pública confiável pelo dispositivo do cliente ou que o domínio está ausente como SAN no certificado do servidor.

Para impedir que o cliente Jabber seja solicitado a aceitar o certificado Expressway, você deve atender aos dois critérios listados abaixo:

• O dispositivo/máquina que executa o cliente Jabber deve ter o assinante do certificado Expressway-E listado em seu armazenamento confiável de certificados.
  
  

  Nota: Isso é facilmente obtido se você usar uma autoridade de certificação pública porque os dispositivos móveis contêm um grande repositório de confiança de certificado.

  
  
  
• O domínio de registro do Unified CM usado para o registro de collab-edge deve estar presente na SAN do certificado do Expressway-E. A ferramenta CSR no servidor Expressway fornecerá a você a opção de adicionar o domínio de registro do Unified CM como uma SAN, ele será pré-carregado se o domínio estiver configurado para MRA. Se a CA que assina o certificado não aceitar um domínio como SAN, você também poderá usar a opção "CollabEdgeDNS", que irá prefixar "collab-edge" no domínio:

Informações Relacionadas

• Guia de acesso remoto e móvel sobre Expressways
• Guia de implantação de criação e uso de certificados do Cisco Expressway
• Uso da porta IP do Cisco TelePresence Video Communication Server (Cisco VCS) para passagem de firewall
• Guia de implantação e instalação do Cisco Jabber
• Suporte Técnico e Documentação - Cisco Systems