Problemas más comunes en el perímetro de la colaboración

Introducción

Mobile & Remote Access (MRA) es una solución de implementación para la capacidad Jabber de red privada virtual (VPN). Esta solución permite a los usuarios finales conectarse a recursos empresariales internos desde cualquier lugar del mundo. Esta guía se ha escrito para ofrecer a los ingenieros que solucionan problemas de la solución Collaboration Edge la capacidad de identificar y resolver rápidamente los problemas más comunes a los que se enfrentan los clientes durante la frase de implementación.

prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Cisco Unified Communications Manager (CUCM)
• Núcleo de Cisco Expressway
• Perímetro de Cisco Expressway
• Cisco IM and Presence (IM&P)
• Cisco Jabber para Windows
• Cisco Jabber para MAC
• Cisco Jabber para Android
• Cisco Jabber para iOS
• Certificados de seguridad
• Sistema de nombres de dominio (DNS)

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Versión de Expressway X8.1.1 o posterior
• CUCM versión 9.1(2)SU1 o posterior y IM&P versión 9.1(1) o posterior
• Cisco Jabber versión 9.7 o posterior

Problemas de inicio de sesión

Jabber no puede iniciar sesión a través de MRA

Este síntoma puede ser causado por una amplia gama de problemas, algunos de los cuales se describen aquí.

1. Registro de servicios de Collaboration Edge (SRV) no creado o puerto 8443 inalcanzable

Para que un cliente Jabber pueda iniciar sesión correctamente con MRA, se debe crear un registro SRV de la frontera de colaboración específico y se debe tener acceso a él externamente. Cuando se inicia un cliente Jabber inicialmente, realiza consultas DNS SRV:

1. _cisco-uds: Este registro SRV se utiliza para determinar si hay un servidor CUCM disponible.
   
   
2. _cuplogin: Este registro SRV se utiliza para determinar si hay un servidor IM&P disponible.
   
   
3. _borde del laboratorio: Este registro SRV se utiliza para determinar si MRA está disponible.
   
   

Si el cliente Jabber se inicia y no recibe una respuesta SRV para _cisco-uds y _cuplogin y recibe una respuesta para _collab-edge, utiliza esta respuesta para intentar ponerse en contacto con Expressway-E que se enumera en la respuesta SRV.

El registro SRV _collab-edge debe indicar el nombre de dominio completamente calificado (FQDN) de Expressway-E con el puerto 8443. Si el SRV _collab-edge no se crea, o no está disponible externamente, o si está disponible, pero el puerto 8443 no es accesible, entonces el cliente Jabber no puede iniciar sesión.

Puede confirmar si el registro SRV_de borde de Collaboration es resoluble y el puerto TCP 8443 se puede alcanzar mediante el verificador SRV en Collaboration Solutions Analyzer (CSA).

Si el puerto 8443 no es accesible, esto podría deberse a un dispositivo de seguridad (Firewall) que bloquea el puerto o a una configuración incorrecta de la puerta de enlace predeterminada (GW) o de las rutas estáticas en Exp-E.

2. No aceptable o no hay certificado disponible en VCS Expressway

Después de que el cliente Jabber haya recibido una respuesta para _collab-edge, se pone en contacto con Expressway con Transport Layer Security (TLS) a través del puerto 8443 para intentar recuperar el certificado de Expressway para configurar TLS para la comunicación entre el cliente Jabber y Expressway.

Si Expressway no tiene un certificado firmado válido que contenga el FQDN o el dominio de Expressway, esto falla y el cliente Jabber no puede iniciar sesión.

Si se produce este problema, el cliente debe utilizar la herramienta Solicitud de firma de certificados (CSR) en Expressway, que incluye automáticamente el FQDN de Expressway como nombre alternativo del sujeto (SAN).

Nota: MRA requiere una comunicación segura entre Expressway-C y Expressway-E, y entre Expressway-E y los terminales externos.

La siguiente tabla con los requisitos de certificado de Expressway por función se puede encontrar en la Guía de implementación de MRA:

3. No se han encontrado servidores UDS en la configuración perimetral

Después de que el cliente Jabber establezca correctamente una conexión segura con Expressway-E, solicita su configuración de borde (get_edge_config). Esta configuración de borde contiene los registros SRV para _cuplogin y _cisco-uds. Si los registros SRV _cisco-uds no se devuelven en la configuración de borde, el cliente Jabber no puede continuar con el inicio de sesión.

Para corregir esto, asegúrese de que Expressway-C cree registros SRV _cisco-uds internamente y pueda resolverlos.

Puede encontrar más información sobre los registros DNS SRV en la Guía de implementación de MRA para X8.11.

Este es también un síntoma común si se encuentra en un dominio dual. Si se ejecuta en un dominio doble y encuentra que el cliente Jabber no está siendo devuelto ningún servicio de datos de usuario (UDS), debe confirmar que los registros SRV _cisco-uds se crean en el DNS interno con el dominio externo.

Nota: Después de la versión X12.5 de Expressway, ya no es necesario agregar un registro SRV _cisco-UDS al DNS interno. Para obtener más información sobre esta mejora, consulte la Guía de implementación de acceso remoto y móvil a través de Cisco Expressway (X12.5).

4. Los Registros De Expressway-C Muestran Este Error: XCP_JABBERD Detail="No se puede conectar con el host '%IP%', puerto 7400:(111) Conexión rechazada"

Si el controlador de interfaz de red (NIC) de Expressway-E está configurado incorrectamente, esto puede hacer que el servidor de la plataforma de comunicaciones extensible (XCP) no se actualice. Si Expressway-E cumple estos criterios, probablemente se encuentre con este problema:

1. Utiliza una única NIC.
2. La clave de opción de red avanzada está instalada.
3. La opción Use Dual Network Interfaces (Utilizar interfaces de red duales) está establecida en Yes.

Para corregir este problema, cambie la opción Use Dual Network Interfaces a No.

La razón por la que esto es un problema es que Expressway-E escucha la sesión XCP en la interfaz de red incorrecta, lo que hace que la conexión falle/se agote el tiempo de espera. Expressway-E escucha en el puerto TCP 7400 para la sesión XCP. Puede verificar esto si utiliza el netstatdesde el VCS como root.

5. El nombre de host/nombre de dominio del servidor de Expressway-E no coincide con lo que está configurado en el SRV _collab-edge

Si el nombre de host/dominio del servidor Expressway-E en la configuración de la página DNS no coincide con lo recibido en la respuesta SRV _collab-edge, el cliente Jabber no puede comunicarse con Expressway-E. El cliente Jabber utiliza el elemento xmppEdgeServer/Address en la respuesta get_edge_config para establecer la conexión XMPP a Expressway-E.

Este es un ejemplo de cómo se ve xmppEdgeServer/Address en la respuesta get_edge_config de Expressway-E al cliente Jabber:

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

Para evitar esto, asegúrese de que el registro _collab-edge SRV coincida con el nombre de host/nombre de dominio de Expressway-E. Para esto se ha registrado el Id. de error de Cisco CSCuo83458 y se agregó soporte parcial en el Id. de error de Cisco CSCuo82526.

6. No se puede iniciar sesión debido a una suscripción WebEx Connect existente

Los registros de Jabber para Windows muestran lo siguiente:

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]

Los intentos de inicio de sesión se dirigen a WebEx Connect.

Para obtener una resolución permanente, debe ponerse en contacto con WebEx para que el sitio se cierre.

Solución Aternativa

A corto plazo, puede utilizar una de estas opciones para excluirla de la búsqueda.

• Agregue este parámetro a jabber-config.xml. A continuación, cargue el archivo jabber-config.xml en el servidor TFTP en CUCM. Requiere que el cliente inicie sesión internamente primero.
  
  

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

• Desde la perspectiva de una aplicación, ejecute lo siguiente:
  msiexec.exe /i CiscoJabberSetup.msi /quiet CLEAR=1 AUTHENTICATOR=CUP EXCLUDED_SERVICES=WEBEX

Nota: La segunda opción no funciona para los dispositivos móviles.

• Cree una URL en la que se pueda hacer clic y que excluya el servicio WEBEX:
  ciscojabber://provision?ServiceDiscoveryExcludedServices=WEBEX

Puede encontrar más detalles sobre la detección de servicios de UC y cómo excluir algunos servicios en Implementación in situ para Cisco Jabber 12.8.

7. El servidor de Expressway-C muestra el mensaje de error: "Configurado pero con errores. Servidor de aprovisionamiento: Esperando la información del servidor transversal".

Si desplaza a Status > Unified Communications y ve el mensaje de error, "Configured but with errors. Provisioning server: Waiting for traversal server info."  para los registros de Unified CM y el servicio IM&P, los servidores DNS internos configurados en Expressway-C tienen dos registros A DNS para Expressway-E. La razón detrás de varios registros DNS A para Expressway-E podría ser que el usuario afectado se mudara de una sola NIC con NAT estática habilitada en Expressway-E a una NIC dual con NAT estática activada, o viceversa, y se olvidó de eliminar el registro DNS A apropiado en los servidores DNS internos. Por lo tanto, cuando utilice la utilidad de búsqueda de DNS en Expressway-C y resuelva el FQDN de Expressway-E, observará dos registros A de DNS.

Solución

Si la NIC de Expressway-E está configurada para una sola NIC con NAT estática:

1. Elimine el registro DNS A para la dirección IP interna de Expressway-E en los servidores DNS configurados en Expressway-C.
2. Vaciar la caché DNS en Expressway-C y el PC del usuario a través de CMD (ipconfig /flushdns).
3. Reinicie el servidor de Expressway-C.

Si la NIC de Expressway-E está configurada para NIC dual con NAT estática habilitada:

1. Elimine el registro A de DNS para la dirección IP externa de Expressway-E en los servidores DNS configurados en Expressway-C.
2. Vaciar la caché DNS en Expressway-C y el PC del usuario a través de CMD (ipconfig /flushdns).
3. Reinicie el servidor de Expressway-C.

8. Microsoft DirectAccess instalado

El cliente puede utilizar Microsoft DirectAccess en el mismo equipo que el cliente Jabber. Cuando intenta iniciar sesión de forma remota, esto puede interrumpir el MRA. DirectAccess obligará a las consultas DNS a tunelizarse en la red interna como si el PC estuviera utilizando una VPN.

Nota: Jabber sobre MRA no admite Microsoft DirectAccess. Cualquier solución de problemas es el mejor esfuerzo. La configuración de DirectAccess es responsabilidad del administrador de la red.

Algunos clientes han tenido éxito al bloquear todos los registros DNS en la tabla de directivas de resolución de nombres de Microsoft DirectAccess. DirectAccess no debe procesar estos registros (Jabber debe poder resolverlos a través de DNS público cuando utiliza MRA):

• registro SRV para _cisco-uds
• registro SRV para _cuplogin
• registro SRV para _collab-edge
• Un registro para todas las Es de Expressway

9. Falla en las búsquedas de DNS inversas de Expressway

A partir de la versión X8.8, Expressway/VCS requiere la creación de entradas DNS inversas y de reenvío para ExpE, ExpC y todos los nodos CUCM. 

Para conocer todos los requisitos, vea Prerrequisitos y Dependencias de Software en las Notas de Versión x8.8 y Registros DNS para Acceso Remoto y Móvil.

Si no hay registros DNS internos, es posible que vea un error en los registros de Expressway que hacen referencia 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"

Expressway-C sólo debe recibir un FQDN al consultar el registro PTR para la IP de Expressway-E. Si recibe un FQDN incorrecto de DNS, mostrará esta línea en los registros y fallará:

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

El teléfono basado en software no se puede registrar, no se permite el método SIP/2.0 405

Un registro de diagnóstico de Expressway-C muestra un SIP/2.0 405 Method Not Allowed mensaje en respuesta a la solicitud de registro enviada por el cliente Jabber. Esto probablemente se deba a un enlace troncal existente del protocolo de inicio de sesión (SIP) entre Expressway-C y CUCM mediante el puerto 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 corregir este problema, cambie el puerto SIP en el perfil de seguridad del troncal SIP que se aplica al troncal SIP existente configurado en CUCM y la zona vecina de Expressway-C para CUCM a un puerto diferente como 5065. Esto se explica en este video. A continuación se muestra un resumen de la configuración:

CUCM

1. Cree un nuevo perfil de seguridad de troncal SIP con un puerto de escucha distinto de 5060 (5065).
2. Cree un enlace troncal SIP asociado al perfil de seguridad del enlace troncal SIP y al destino establecido en la dirección IP de Expressway-C, puerto 5060.

Expressway-C

1. Cree una zona vecina a CUCM con un puerto de destino distinto de 5060 (5065) para que coincida con la configuración de CUCM.
2. En Configuración de Expressway-C > Protocolos > SIP, asegúrese de que Expressway-C todavía escucha 5060 para SIP.

El teléfono basado en software no se puede registrar, Motivo="Unknown domain"

Un registro de diagnóstico de Expressway-C muestra 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 corregir este problema, verifique estos puntos:

• ¿Utiliza el cliente Jabber un perfil de seguridad de dispositivo seguro en CUCM cuando la intención es no utilizar un perfil de seguridad de dispositivo no seguro?
  
  
• Si los clientes Jabber deben utilizar un perfil de seguridad de dispositivo seguro, ¿es el nombre del perfil de seguridad en formato FQDN y es ese nombre FQDN configurado en el certificado de Expressway-C como una SAN?
  
  
• Si los clientes Jabber deben utilizar un perfil de seguridad de dispositivo seguro, navegue hasta System > Enterprise Parameters > Security Parameters > Cluster Security Mode y verifique que Cluster Security Mode esté configurado en 1 para verificar que el clúster CUCM se ha protegido. Si el valor es 0, el administrador debe pasar por el procedimiento documentado para proteger el clúster.

El teléfono basado en software no se puede registrar, Motivo "Idle countdown expired"

Cuando revise los registros de Expressway-E durante el período de tiempo que el cliente Jabber envía en un mensaje REGISTER, es posible que encuentre un Idle countdown expired como se indica en el fragmento de código aquí.

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"

Este fragmento de código indica que el firewall tiene el puerto 5061 abierto; sin embargo, no hay tráfico de capa de aplicación que se transmita en una cantidad suficiente de tiempo, por lo que la conexión TCP se cierra.

Si se encuentra con esta situación, existe un alto grado de probabilidad de que el firewall frente a Expressway-E tenga activada la función SIP Inspection/Application Layer Gateway (ALG). Para solucionar este problema, debe desactivar esta funcionalidad. Si no está seguro de cómo hacerlo, debe consultar la documentación del producto de su proveedor de firewalls.

Para obtener más información sobre SIP Inspection/ALG, puede consultar el Apéndice 4 de la Guía de Implementación de Configuración de Cisco Expressway-E y Expressway-C-Basic.

El MRA falla debido al proxy del teléfono configurado en el firmware

Un registro de diagnóstico de Expressway-E muestra una falla de negociación TLS en el puerto 5061, sin embargo, el intercambio de señales SSL se realizó correctamente en el puerto 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"

Registros de 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.

La captura de paquetes de Jabber muestra una negociación SSL con la IP de Expressway E; sin embargo, el certificado enviado no proviene de este servidor:

El firewall tiene configurado Phone Proxy.

Solución:

Confirme que FW ejecute Phone Proxy. Para comprobarlo, introduzca el show run policy-map y le mostrará algo similar a:

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

Desactive el proxy del teléfono para que los servicios del teléfono se conecten correctamente.

Problemas de llamada

No hay medios cuando se llama a través de MRA

Estas son algunas de las configuraciones faltantes e incorrectas que pueden causar este problema en las implementaciones NIC únicas y duales:

• La NAT estática no está configurada en Expressway-E en System > Network Interfaces > IP. La NAT en la capa de red aún debe realizarse en el firewall, pero esta configuración traducirá la IP en la capa de aplicación.
• Los puertos TCP/UDP no están abiertos en el firewall. Para obtener una lista de puertos, consulte la Guía de Configuración de Uso de Puertos IP de Cisco Expressway

No se recomienda una única NIC con implementaciones NAT estáticas. Estas son algunas consideraciones para evitar problemas de medios:

• En la zona transversal de UC, Expressway-C debe señalar la dirección IP pública configurada en Expressway-E.
• Los medios deben "hairpin" o reflejarse en el firewall externo. Se puede encontrar un ejemplo de configuración usando un Cisco ASA Firewall en Configure NAT Reflection On The ASA For The VCS Expressway TelePresence Devices. 

Puede encontrar más información al respecto en el Apéndice 4 de la Guía de implementación de configuración básica de Cisco Expressway-E y Expressway-C.

No hay devolución de llamada cuando se realiza una llamada MRA a PSTN

Este problema se debe a una limitación en Expressway anterior a la versión X8.5. El Id. de error de Cisco CSCua72781 describe cómo Expressway-C no reenvía medios tempranos en el progreso de la sesión 183 o el timbre 180 a través de la zona transversal. Si ejecuta las versiones X8.1.x o X8.2.x, puede actualizar a la versión X8.5 o realizar la solución alternativa aquí indicada.

Es posible utilizar una solución alternativa en Cisco Unified Border Element (CUBE) si crea un perfil SIP que convierte el 183 en un 180 y lo aplica en el dial-peer entrante. Por ejemplo:

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

Después desactivarían 180 Early Media en el perfil SIP de CUCM > CUBE o en el propio CUBE dentro del modo de configuración de sip-ua.

disable-early-media 180

Problemas de CUCM e IM&P

Error ASCII que impide agregar CUCM

Cuando agrega CUCM a Expressway-C, se produce un error ASCII que impide que se agregue CUCM.

Cuando Expressway-C agrega CUCM a su base de datos, se ejecuta mediante una serie de consultas AXL relacionadas con las funciones get y list. Algunos ejemplos de estos incluyen getCallManager, listCallManager, listProcessNode, listProcessNodeService y getCCMVersion. Después de ejecutar el proceso getCallManager, se ejecuta sucesivamente con un conjunto ExecuteSQLQuery para recuperar todos los valores de confianza de CUCM Call Manager o tomcat.

Una vez que CUCM recibe la consulta y se ejecuta en ella, CUCM devuelve todos sus certificados. Si uno de los certificados contiene un carácter que no es ASCII, Expressway genera un error en la interfaz web similar a ascii codec can't decode byte 0xc3 in position 42487: ordinal not in range(128).

Este problema se rastrea con el Id. de bug Cisco CSCuo54489 y se resuelve en la Versión X8.2.

Fallas TLS salientes en 5061 de Expressway-C a CUCM en implementaciones seguras

Este problema se produce cuando utiliza certificados autofirmados en CUCM y Tomcat.pem/CallManager.pem tiene el mismo asunto. El problema se aborda con el ID de bug de Cisco CSCun30200. La solución temporal para corregir el problema es eliminar tomcat.pem y deshabilitar la verificación de TLS de la configuración de CUCM en Expressway-C.

Servidor de IM&P no agregado y se encontraron errores

Cuando agrega un servidor de IM&P, Expressway-C informa "Este servidor no es un servidor de IM y presencia" o "No se puede comunicar con el error HTTP de consulta .AXL ''HTTPError:500'", lo que hace que el servidor de IM&P no se agregue.

Como parte de la adición de un servidor de IM&P, Expressway-C utiliza una consulta AXL para buscar los certificados de IM&P en un directorio explícito. Debido al Id. de bug Cisco CSCul05131, los certificados no están en ese almacén; por lo tanto, se encuentra con el error false.

Problemas varios

El estado del buzón de voz en el cliente Jabber muestra "No conectado"

Para que el estado del correo de voz del cliente Jabber se conecte correctamente, debe configurar la dirección IP o el nombre de host de Cisco Unity Connection dentro de la lista de permitidos HTTP en Expressway-C.

Para completar esto desde Expressway-C, realice el procedimiento pertinente:

Procedimiento para las versiones X8.1 y X8.2

1. Haga clic en Configuration > Unified Communications > Configuration > Configure HTTP server allow list.
2. Haga clic en Nuevo > Introducir IP/Nombre de host > Crear entrada.
3. Cierre la sesión del cliente Jabber y vuelva a iniciarla.

Procedimiento para la versión X8.5

1. Haga clic en Configuration > Unified Communications > Unity Connection Servers.
2. Haga clic en Nuevo > Introducir nombre de host/IP, credenciales de cuenta de usuario > Agregar dirección.
3. Cierre la sesión del cliente Jabber y vuelva a iniciarla.

Las fotos de contacto no aparecen en los clientes de Jabber a través de Expressway

La solución de acceso remoto y móvil solo utiliza UDS para la resolución de fotos de contacto. Esto requiere que tenga un servidor web disponible para almacenar las fotos. La configuración en sí es doble.

1. El archivo jabber-config.xml se debe modificar para dirigir a los clientes al servidor web para la resolución de la fotografía de contacto. La configuración aquí debe lograr esto.
   
   

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

   
   
   
2. Expressway-C debe tener el servidor web en la lista de permitidos del servidor HTTP.
   
   
   1. Haga clic en Configuration > Unified Communications > Configuration > Configure HTTP server allow list.
   2. Haga clic en Nuevo > Introducir IP/Nombre de host > Crear entrada.
   3. Cierre la sesión del cliente Jabber y vuelva a iniciarla.
   
   
   

   Nota: Para obtener más información sobre la resolución de fotos de contacto de UDS, refiérase a la Documentación de fotos de contacto de Jabber.

Se solicita a los clientes de Jabber que acepten el certificado de Expressway-E durante el inicio de sesión

Este mensaje de error puede estar relacionado con el certificado de borde de Expressway no firmado por una CA pública que sea de confianza para el dispositivo del cliente o que el dominio falte como una SAN en el certificado del servidor.

Para evitar que se pida al cliente Jabber que acepte el certificado de Expressway, debe cumplir los dos criterios enumerados a continuación:

• El dispositivo/equipo que ejecuta el cliente Jabber debe tener el firmante del certificado de Expressway-E incluido en su almacén de confianza de certificados.
  
  

  Nota: Esto se consigue fácilmente si utiliza una autoridad de certificación pública porque los dispositivos móviles contienen un gran almacén de confianza de certificados.

  
  
  
• El dominio de registro de Unified CM utilizado para el registro de la frontera de la colaboración debe estar presente en la SAN del certificado de Expressway-E. La herramienta CSR en el servidor de Expressway le dará la opción de agregar el dominio de registro de Unified CM como una SAN, se precargará si el dominio está configurado para MRA. Si la CA que firma el certificado no acepta un dominio como SAN, también puede utilizar la opción "CollabEdgeDNS", que antepondrá "collab-edge" al dominio:

Información Relacionada

• Guía de acceso móvil y remoto a través de Expressway
• Guía de creación y uso de certificados de Cisco Expressway
• Uso de puertos IP de Cisco TelePresence Video Communication Server (Cisco VCS) para firewall transversal
• Guía de implementación e instalación de Cisco Jabber
• Soporte Técnico y Documentación - Cisco Systems