Pesquise defeitos edições da integração HTTPS entre o condutor e o CUCM

Introdução

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).

Problema

A integração HTTPS entre o condutor e o CUCM para Conferências Ad-Hoc falha. Há dois sintomas principais quando este problema ocorre:

• O status de registro para o bridge de conferência do condutor no CUCM mostra como removido registro.
  
  
• Tentativas de criar uma falha da Conferência Ad-Hoc.

As seções que seguem explicam estes dois sintomas em um detalhe mais adicional.

Mostras do status de registro removidas registro

Este sintoma é observado nestas duas encenações:

• O destino do tronco do SORVO da ultrapassagem como a caixa de verificação do endereço HTTP é desmarcado na página de configuração do condutor, e o tronco associado do Session Initiation Protocol (SIP) para o bridge de conferência do condutor tem um endereço de destino que seja configurado como um endereço IP de Um ou Mais Servidores Cisco ICM NT ou um nome de domínio totalmente qualificado (FQDN).
  

  Tip: Para obter mais informações sobre da encenação do tronco do SORVO FQDN, refira o tronco do SORVO configurado com seção FQDN deste documento.

• O destino do tronco do SORVO da ultrapassagem como a caixa de verificação do endereço HTTP é verificado na página de configuração do condutor e configurado como um endereço IP de Um ou Mais Servidores Cisco ICM NT.

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:

1. O CUCM envia uma mensagem dos hellos do cliente TLS ao condutor.
   
   
2. O condutor envia uma mensagem dos servidores hello e uma informação do certificado ao CUCM.
   
   
3. O condutor envia os servidores hello feitos e mensagens de intercâmbio da chave de servidor ao CUCM.
   
   
4. O CUCM envia as trocas de chave do cliente, as especs. da cifra da mudança, e as mensagens cifradas do aperto de mão ao condutor.
   
   
5. O condutor envia as especs. da cifra da mudança e as mensagens cifradas do aperto de mão ao CUCM.
   
   
6. O CUCM envia um alerta cifrado ao condutor.

A criação da Conferência Ad-Hoc falha

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'>

Note: O valor de Conference_name é diferente para cada atendimento.

Solução

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.

Note: O FQDN deve resolver ao IP virtual (VIP) que é associado com o lugar ad hoc do condutor e deve ser incluído como um atributo alternativo sujeito do nome (SAN) no certificado do condutor.

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.

Tronco do SORVO configurado com FQDN

O estado do serviço do tronco do SORVO pode às vezes aparecer como nenhum serviço ou para baixo. Isto ocorre quando:

• O endereço de destino no tronco do SORVO é configurado com um FQDN.
  
  
• O FQDN resolve a um VIP que seja associado com o lugar ad hoc que é indicado na página de configuração do condutor.

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:

Note: A menos que documentada de outra maneira, esta edição é seguida igualmente na identificação de bug Cisco CSCut22572.