Este documento descreve um problema que seja encontrado com integração HTTPS entre o maestro de Cisco e o gerente das comunicações unificadas de Cisco (CUCM).
A integração HTTPS entre o condutor e o CUCM para Conferências Ad-Hoc falha. Há dois sintomas principais quando este problema ocorre:
As seções que seguem explicam estes dois sintomas em um detalhe mais adicional.
Este sintoma é observado nestas duas encenações:
Estas imagens mostram o status de registro para both of these encenações:
A causa de raiz para esta falha de registro é a biblioteca que é usada para o Transport Layer Security HTTPS/(TLS). O handshake de TLS falha com um alerta cifrado porque a biblioteca não apoia os identificadores de recurso uniforme (URI) no formato de endereço IP para HTTPS/TLS.
Em um nível alto, o handshake de TLS ocorre similar a este:
Este sintoma é observado quando uma ação alternativa é aplicada para o sintoma acima mencionado, que faz com que a criação das Conferências Ad-Hoc falhe:
A causa de raiz para este sintoma é o condutor, que não processa o atendimento do Application Program Interface conference.create (API) do CUCM quando o URI é construído com um FQDN.
O condutor registra então 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'>
Para que a integração HTTPS e a criação da Conferência Ad-Hoc funcione corretamente entre o CUCM e o condutor, um reparo é exigido para a identificação de bug Cisco CSCut22572. Este reparo deve permitir que o endereço de destino HTTPS seja configurado como um FQDN.
O prazo o aprimoramento de recursos que é descrito na identificação de bug Cisco CSCut10254 permitirá que o endereço de destino HTTPS seja configurado com um endereço IP de Um ou Mais Servidores Cisco ICM NT, de uma configuração manual/ultrapassagem ou do tronco do SORVO.
O estado do serviço do tronco do SORVO pode às vezes aparecer como nenhum serviço ou para baixo. Isto ocorre quando:
Aqui está um exemplo:
A causa de raiz para esta é o condutor, que não responde à mensagem das opções do SORVO que é enviada do CUCM. O SORVO URI é construído com base no endereço de destino, que é um FQDN neste exemplo, e o maestro espera uma notação do endereço IP de Um ou Mais Servidores Cisco ICM NT:
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."
Isto ocorre mesmo que o condutor possa resolver o FQDN ad hoc: