Contents

Introduction

Problema

O status do registro mostra não registrado

Falha na criação de conferência ad hoc

Solução

Tronco SIP configurado com FQDN

Introduction

Este documento descreve um problema encontrado com a integração HTTPS entre o Cisco Condutor e o Cisco Unified Communications Manager (CUCM).

Problema

A integração HTTPS entre o Condutor e o CUCM para conferências ad hoc falha. Há dois sintomas principais quando esse problema ocorre:

- O status de registro da ponte de conferência do condutor no CUCM é mostrado como Não registrado.

- Falha na tentativa de criar uma conferência ad hoc.

As seções a seguir explicam esses dois sintomas com mais detalhes.

O status do registro mostra não registrado

Esse sintoma é observado nestes dois cenários:

- A caixa de seleção Substituir o destino do tronco SIP como endereço HTTP está desmarcada na página de configuração do Condutor, e o tronco SIP (Session Initiation Protocol) associado à Ponte da Conferência do Condutor tem um endereço de destino configurado como um endereço IP ou um FQDN (Fully Qualified Domain Name, nome de domínio totalmente qualificado).

Tip: Para obter mais informações sobre o cenário de tronco SIP de FQDN, consulte a seção Tronco SIP Configurado com FQDN deste documento.

- A caixa de seleção Substituir destino do tronco SIP como endereço HTTP está marcada na página de configuração do Condutor e configurada como um endereço IP.

Essas imagens mostram o status de registro para ambos os cenários:

A causa raiz dessa falha de registro é a biblioteca usada para HTTPS/Transport Layer Security (TLS). O handshake TLS falha com um alerta Criptografado porque a biblioteca não oferece suporte a URIs (Uniform Resource Identifiers — Identificadores Uniformes de Recursos) no formato de endereço IP para HTTPS/TLS.

Em um nível alto, o handshake TLS ocorre da mesma forma:

1. O CUCM envia uma mensagem de Hello do cliente TLS ao Condutor.

2. O Condutor envia uma mensagem de Hello do Servidor e informações de certificado para o CUCM.

3. O Condutor envia as mensagens Server Hello Done e Server Key Exchange para o CUCM.

4. O CUCM envia as mensagens Client Key Exchange, Change Cipher Spec e Encrypted Handshake ao Condutor.

5. O Condutor envia as mensagens Change Cipher Spec e Encrypted Handshake para o CUCM.

6. O CUCM envia um alerta Criptografado ao Condutor.

Falha na criação de conferência ad hoc

Esse sintoma é observado quando uma solução alternativa é aplicada para o sintoma mencionado acima, o que faz com que a criação de conferências ad hoc falhe:

A causa raiz desse sintoma é o Condutor, que falha ao processar a conferência.criar chamada API (Application Program Interface) do CUCM quando a URI é criada com um FQDN.

Em seguida, o Condutor 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'>

Note: O valor Conference_name é diferente para cada chamada.

Solução

Para que a integração HTTPS e a criação da conferência ad hoc funcionem corretamente entre o CUCM e o Condutor, é necessária uma correção para o ID de bug da Cisco CSCut22572. Essa correção deve permitir que o endereço de destino HTTPS seja configurado como um FQDN.

Note: O FQDN deve resolver para o IP virtual (VIP) associado ao local ad hoc do Condutor e deve ser incluído como um atributo de Nome alternativo do assunto (SAN) no Certificado do Condutor.

A longo prazo, a melhoria de recurso descrita na ID de bug da Cisco CSCut10254 permitirá que o endereço de destino HTTPS seja configurado com um endereço IP, seja de uma configuração manual/de substituição ou do tronco SIP.

Tronco SIP configurado com FQDN

O estado do serviço de tronco SIP pode, às vezes, aparecer como Sem serviço ou Inativo. Isso ocorre quando:

- O endereço de destino no tronco SIP é configurado com um FQDN.

- O FQDN é resolvido para um VIP associado ao local ad hoc indicado na página de configuração do Condutor.

Aqui está um exemplo:

A causa principal disso é o Condutor, que não responde à mensagem SIP Options que é enviada do CUCM. O URI do SIP é construído com base no endereço de destino, que é um FQDN neste exemplo, e o Condutor espera uma notação de endereço 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."

Isso ocorre mesmo que o condutor possa resolver o FQDN ad hoc:

Note: A menos que documentado de outra forma, esse problema também é rastreado na ID de bug da Cisco CSCut22572.