Voz y Comunicaciones unificadas : Cisco Unified Communications Manager (CallManager)

Problemas de la integración del Troubleshooting HTTPS entre el conductor y el CUCM

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe un problema que se encuentre con la integración HTTPS entre el conductor y el administrador de las Comunicaciones unificadas de Cisco (CUCM) de Cisco.

Contribuido por Kristof Van Coillie y Philip Smeuninx, ingenieros de Cisco TAC.

Problema

La integración HTTPS entre el conductor y el CUCM para los conferencia Ad-Hoc falla. Hay dos síntomas principales cuando ocurre este problema:

  • El estado de registro para el Bridge de conferencia del conductor en el CUCM muestra según lo desregistrado.

  • Tentativas de crear un fall del conferencia Ad-Hoc.

Las secciones que siguen explican estos dos síntomas en el detalle adicional.

Demostraciones del estado de registro desregistradas

Este síntoma se observa en estos dos escenarios:

  • El destino del trunk del SORBO de la invalidación como dirección HTTP casilla de verificación se desmarca en la página de configuración del conductor, y el trunk asociado del Session Initiation Protocol (SIP) para el Bridge de conferencia del conductor tiene una dirección destino que se configure como una dirección IP o nombre de dominio completo (FQDN).

    Consejo: Para más información sobre el escenario del trunk del SORBO FQDN, refiera al trunk del SORBO configurado con la sección FQDN de este documento.

  • El destino del trunk del SORBO de la invalidación como dirección HTTP casilla de verificación se comprueba la página de configuración del conductor y se configura como dirección IP.

Estas imágenes muestran el estado de registro para ambos escenarios:

La causa raíz para esta falla en la inscripción es la biblioteca que se utiliza para HTTPS/Transport Layer Security (TLS). La entrada en contacto TLS falla con una alerta cifrada porque la biblioteca no soporta los Identificadores de recurso uniforme (URI) en el formato de IP Address para HTTPS/TLS.

En un nivel elevado, la entrada en contacto TLS ocurre similar a esto:

  1. El CUCM envía un mensaje de los saludos del cliente de TLS al conductor.

  2. El conductor envía un mensaje de los saludos del servidor y una información del certificado al CUCM.

  3. El conductor envía los saludos del servidor hechos y los mensajes de intercambio de la clave del servidor al CUCM.

  4. El CUCM envía el intercambio de claves del cliente, espec. de la cifra del cambio, y los mensajes cifrados del apretón de manos al conductor.

  5. El conductor envía espec. de la cifra del cambio y los mensajes cifrados del apretón de manos al CUCM.

  6. El CUCM envía una alerta cifrada al conductor.

La creación del conferencia Ad-Hoc falla

Se observa este síntoma cuando una solución alternativa es aplicada para el síntoma ya mencionado, que hace la creación de los conferencia Ad-Hoc fallar:

La causa raíz para este síntoma es el conductor, que no puede procesar la llamada de la interfaz de programación de aplicaciones (API) conference.create del CUCM cuando URI se construye con un FQDN.

El conductor entonces registra este evento:

Event="An API request could not be processed." Command="conference.create"
Conference_name="001035060001" Detail="<Fault 201:
'Request received  to a non ad-hoc IP address'>

Nota: El valor de Conference_name es diferente para cada llamada.

Solución

Para que la integración HTTPS y la creación del conferencia Ad-Hoc funcionen correctamente entre el CUCM y el conductor, un arreglo se requiere para el Id. de bug Cisco CSCut22572. Este arreglo debe permitir que configuren a la dirección destino HTTPS como FQDN.

Nota: El FQDN debe resolver al IP virtual (VIP) que se asocia a la ubicación ad hoc del conductor y se debe incluir como atributo alternativo sujeto del nombre (SAN) en el certificado del conductor.

El largo plazo la mejora de las características que se describe en el Id. de bug Cisco CSCut10254 permitirá que configuren a la dirección destino HTTPS con una dirección IP, de una configuración manual/de la invalidación o del trunk del SORBO.

Trunk del SORBO configurado con el FQDN

El estado de servicio del trunk del SORBO puede aparecer a veces como ningún servicio o abajo. Esto ocurre cuando:

  • Configuran a la dirección destino en el trunk del SORBO con un FQDN.

  • El FQDN resuelve a un VIP que se asocie a la ubicación ad hoc que se indica en la página de configuración del conductor.

Aquí tiene un ejemplo:

La causa raíz para esto es el conductor, que no contesta al mensaje de las opciones del SORBO que se envía del CUCM. El SORBO URI se construye sobre la base de la dirección destino, que es un FQDN en este ejemplo, y el conductor cuenta con una notación de la dirección IP:

2015-03-27T18:00:23+01:00 conductorcucm b2bua[28262]: UTCTime="2015-03-27 17:00:23,269"
Module="network.sip" Level="DEBUG":  Action="Received"  Local-ip="10.48.36.195"
Local-port="5061"  Src-ip="10.48.36.128"  Src-port="40523"
Msg-Hash="17750686918648045057"

 SIPMSG:
 |OPTIONS sip:condcucmadhoc.vngtp.lab:5061 SIP/2.0
 Via: SIP/2.0/TLS 10.48.36.128:5061;branch=z9hG4bK1539977cd7264
 Call-ID: c0a17300-51518ca7-15313-8024300a@10.48.36.128
 CSeq: 101 OPTIONS
 Contact: <sip:10.48.36.128:5061;transport=tls>
 From: <sip:10.48.36.128>;tag=1335522536
 To: <sip:condcucmadhoc.vngtp.lab>
 Max-Forwards: 0
 User-Agent: Cisco-CUCM10.5
 Date: Fri, 27 Mar 2015 17:00:23 GMT
 Content-Length: 0
2015-03-27T18:00:23+01:00 conductorcucm b2bua[28262]: UTCTime="2015-03-27 17:00:23,322"
Module="developer.applicationmanager.search" Level="INFO"
CodeLocation="ppcmains/ivy/search/SearchFsmState_Idle.cpp(82)"
Method="SearchFsmState_Idle::handleRequest" Thread="0x7feea9888700":
AppId="59" LegId="ASide[1]" CurState="SearchFsmState_Idle"
 Detail="Received search" searchContext="mTarget  : sip:condcucmadhoc.vngtp.lab
 mRouteSet:
 "
2015-03-27T18:00:23+01:00 conductorcucm b2bua[28262]: UTCTime="2015-03-27 17:00:23,325"
Module="developer.applicationmanager.search" Level="INFO"
CodeLocation="ppcmains/ivy/search/SearchFsmState_Idle.cpp(96)"
Method="SearchFsmState_Idle::performSearch" Thread="0x7feea9888700":
AppId="59" LegId="BSide[1]" CurState="SearchFsmState_Idle"
 Detail="Initiating search" searchContext="mTarget  : sip:condcucmadhoc.vngtp.lab
 mRouteSet:
 "
2015-03-27T18:00:23+01:00 conductorcucm b2bua[28262]: UTCTime="2015-03-27 17:00:23,344"
Module="developer.modulefactory.threadeddispatcher" Level="ERROR"
CodeLocation="ppcmains/ivy/threadeddispatcher/ThreadedDispatcher.cpp(106)"
Method="ThreadedDispatcher::run" Thread="0x7feea9888700":  Detail="Caught
std::exception" what="DefaultRouteHeaderStrategy::manipulateOutgoingRouteSet:
Policy routing configured, but no outgoing route found."

Esto ocurre aunque el conductor puede resolver el FQDN ad hoc:

Nota: A menos que esté documentado de otra manera, este problema también se siga en el Id. de bug Cisco CSCut22572.



Document ID: 118964