Borde de la Colaboración la mayoría de los problemas frecuentes

Introducción

El móvil y el Acceso Remoto (MRA) es una solución del despliegue para la capacidad privada virtual del Jabber de la red-menos (VPN). Esta solución permite que los usuarios finales conecten con los recursos internos de la empresa desde cualquier lugar del mundo. Esta guía se ha escrito para dar a los ingenieros que resuelven problemas la solución límite de la Colaboración la capacidad para identificar rápidamente y resolver a los clientes de los problemas más comunes haga frente durante la frase del despliegue.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Cisco Unified Communications Manager (CUCM)
• Base de Cisco Expressway
• Borde de Cisco Expressway
• Cisco IM y presencia (IM&P)
• Jabber de Cisco para Windows
• Cisco Jabber para Mac
• Cisco Jabber para Android
• Jabber de Cisco para el IOS
• Certificados de la 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 X8.1.1 de Expressway o más adelante
• Versión 9.1(2)SU1 CUCM o más adelante y versión 9.1(1) o posterior IM&P
• Versión 9.7 o posterior del Jabber de Cisco

Problemas de la clave

Jabber incapaz de ingresar con MRA

Este síntoma se puede causar por una amplia gama de problemas, algunos cuyo se resumen aquí.

1. Registro de servicio del borde de la Colaboración (SRV) no creado y/o puerto 8443 inalcanzable

Para que un cliente del Jabber pueda abrirse una sesión con éxito con MRA, un expediente específico del borde SRV de la Colaboración debe ser creado y accesible externamente. Cuando comienzan a un cliente del Jabber inicialmente, hace las interrogaciones DNS SRV:

1. _cisco-uds: Este expediente SRV se utiliza para determinar si un servidor CUCM está disponible.
   
   
2. _cuplogin: Este expediente SRV se utiliza para determinar si un servidor IM&P está disponible.
   
   
3. _collab-edge: Este expediente SRV se utiliza para determinar si MRA está disponible.
   
   

Si comienzan y no recibe una respuesta SRV para los _cisco-uds y el _cuplogin y recibe al cliente del Jabber una respuesta para el _collab-edge, después utiliza esta respuesta para intentar entrar en contacto con Expressway-e enumerado en la respuesta SRV.

El expediente del _collab-edge SRV debe señalar al nombre de dominio completo (FQDN) de Expressway-e con el puerto 8443. Si el _collab-edge SRV no se crea, o no está externamente disponible, o si es disponible, pero el puerto 8443 no es accesible, después el cliente del Jabber no puede abrirse una sesión.

Usted puede confirmar si el expediente del _collab-edge SRV es el puerto resoluble y TCP 8443 accesible usando el inspector SRV en el analizador de las soluciones de la Colaboración (CSA).

Si el puerto 8443 no es accesible, esto podría ser debido a un dispositivo de seguridad (Firewall) que bloqueaba el puerto o un misconfiguration del gateway de valor por defecto (GW) o de las Static rutas en el Exp-e.

2. Certificado inaceptable o ningún disponible en el VCS Expressway

Después de que el cliente del Jabber haya recibido una respuesta para el _collab-edge, entonces entra en contacto con Expressway con Transport Layer Security (TLS) sobre el puerto 8443 para intentar extraer el certificado de Expressway para poner TLS para la comunicación entre el cliente del Jabber y Expressway.

Si Expressway no tiene un certificado firmado válido que contenga el FQDN o el dominio de Expressway, después éste falla y el cliente del Jabber no puede abrirse una sesión.

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

Nota: MRA requiere la comunicación segura entre Expressway-C y Expressway-e, y entre Expressway-e y las puntos finales externas.

La tabla siguiente con los requisitos del certificado de Expressway por la característica se puede encontrar en el Guía de despliegue MRA:

3. Ningunos servidores UDS encontrados en la configuración del borde

Después de que el cliente del Jabber establezca con éxito una conexión segura con Expressway-e, pide su configuración del borde (get_edge_config). Esta configuración del borde contiene los expedientes SRV para el _cuplogin y los _cisco-uds. Si los expedientes de los _cisco-uds SRV no se vuelven en la configuración del borde, después el cliente del Jabber no puede proceder con la clave.

Para fijar esto, asegúrese de que los expedientes de los _cisco-uds SRV son creados internamente y resoluble por Expressway-C.

Más información sobre los expedientes DNS SRV se puede encontrar en el Guía de despliegue MRA para X8.11.

Esto es también un síntoma común si usted está en un dominio dual. Si usted se ejecuta en un dominio dual y encuentra que no están volviendo al cliente del Jabber ningún servicio de datos del usuario (UDS), usted debe confirmar que los expedientes de los _cisco-uds SRV están creados en el DNS interno con el dominio externo.

Nota: Después de la versión X12.5 de Expressway, es no más un requisito agregar un expediente del _cisco-UDS SRV al DNS interno. Para más información sobre esta mejora, vea el móvil y el Acceso Remoto a través del Guía de despliegue de Cisco Expressway (X12.5).

4. Los registros de Expressway-C muestran este error: XCP_JABBERD Detail= " incapaz de conectar para recibir “el %IP%”, conexión del puerto 7400:(111) rechazada”

Si el regulador del interfaz de red de Expressway-e (NIC) se configura incorrectamente, éste puede hacer el servidor extensible de la plataforma de las comunicaciones (XCP) no ser actualizado. Si Expressway-e cumple estos criterios, después usted encontrará probablemente este problema:

1. Utiliza un solo NIC.
2. La clave avanzada de la opción de interconexión de redes está instalada.
3. La opción de interfaces dual de red del uso se fija a sí.

Para corregir este problema, cambie la opción de interfaces dual de red del uso a no.

La razón que esto es un problema es porque Expressway-e está atenta la sesión XCP sobre el interfaz de red incorrecto, que causa fallar/descanso de la conexión. Expressway-e escucha en el puerto 7400 TCP la sesión XCP. Usted puede verificar esto si usted utilizanetstat el comando del VCS como raíz.

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

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]

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 

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"

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

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

disable-early-media 180