Contenido

Introducción

Problema

El Estado Del Registro Muestra No Registrado

La creación de conferencia ad hoc falla

Solución

Troncal SIP configurado con FQDN

Introducción

Este documento describe un problema que se ha encontrado con la integración HTTPS entre Cisco Conductor y Cisco Unified Communications Manager (CUCM).

Problema

La integración HTTPS entre el Conductor y CUCM para conferencias ad hoc falla. Hay dos síntomas principales cuando ocurre este problema:

- El estado de registro del puente de conferencia Conductor en CUCM se muestra como No registrado.

- Los intentos de crear una conferencia ad hoc fallan.

En las secciones siguientes se explican estos dos síntomas con más detalle.

El Estado Del Registro Muestra No Registrado

Este síntoma se observa en estos dos escenarios:

- La casilla de verificación Override SIP trunk destination as HTTP Address no está marcada en la página de configuración de Conductor y el enlace troncal asociado Session Initiation Protocol (SIP) para Conductor Conference Bridge tiene una dirección de destino configurada como dirección IP o un nombre de dominio completo (FQDN).

Consejo: Para obtener más información sobre el escenario de troncal FQDN SIP, consulte la sección Troncal SIP configurado con FQDN de este documento.

- La casilla de verificación Override SIP trunk destination as HTTP Address está marcada en la página de configuración de Conductor y está configurada como dirección IP.

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

La causa raíz de este error de registro es la biblioteca que se utiliza para HTTPS/ seguridad de la capa de transporte (TLS). El intercambio de señales TLS falla con una alerta cifrada porque la biblioteca no admite identificadores uniformes de recursos (URI) en formato de dirección IP para HTTPS/TLS.

En un nivel alto, el intercambio de señales TLS ocurre de manera similar a esto:

1. CUCM envía un mensaje TLS Client Hello al Conductor.

2. Conductor envía un mensaje Server Hello e información de certificado al CUCM.

3. Conductor envía los mensajes Server Hello Done y Server Key Exchange al CUCM.

4. CUCM envía los mensajes Client Key Exchange, Change Cipher espec y Encrypted Handshake al Conductor.

5. Conductor envía los mensajes Cambiar especificación del cifrado y Apretón de manos cifrado al CUCM.

6. CUCM envía una alerta cifrada al Conductor.

La creación de conferencia ad hoc falla

Este síntoma se observa cuando se aplica una solución temporal para el síntoma mencionado, lo que hace que falle la creación de conferencias ad hoc:

La causa raíz de este síntoma es Conductor, que no puede procesar la llamada de la interfaz de conferencia.crear programa de aplicaciones (API) desde CUCM cuando el URI se genera con un FQDN.

A continuación, Conductor 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 Conference_name es diferente para cada llamada.

Solución

Para que la integración HTTPS y la creación de conferencia ad hoc funcionen correctamente entre CUCM y Conductor, se requiere una corrección para el ID de bug Cisco CSCut22572. Esta corrección debe permitir que la dirección de destino HTTPS se configure como un FQDN.

Nota: El FQDN debe resolver la IP virtual (VIP) asociada a la ubicación ad hoc del Conductor y debe incluirse como atributo de nombre alternativo del sujeto (SAN) en el certificado del Conductor.

A largo plazo, la mejora de la función que se describe en el Id. de error de Cisco CSCut10254 permitirá que la dirección de destino HTTPS se configure con una dirección IP, ya sea desde una configuración manual/de reemplazo o desde el troncal SIP.

Troncal SIP configurado con FQDN

El estado del servicio troncal SIP a veces puede aparecer como No Service o Down. Esto ocurre cuando:

- La dirección de destino en el troncal SIP está configurada con un FQDN.

- El FQDN se resuelve en un VIP asociado a la ubicación ad hoc indicada en la página de configuración de Conductor.

Aquí tiene un ejemplo:

La causa raíz de esto es Conductor, que no responde al mensaje Opciones SIP que se envía desde CUCM. El URI de SIP se genera en función de la dirección de destino, que es un FQDN en este ejemplo, y el Conductor espera una notación de 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 pueda resolver el FQDN ad hoc:

Nota: A menos que se documente lo contrario, este problema también se rastrea en el Id. de bug Cisco CSCut22572.