Dépannage des problèmes d'intégration HTTPS entre le Conductor et CUCM

Introduction

Ce document décrit un problème rencontré avec l'intégration HTTPS entre Cisco Conductor et Cisco Unified Communications Manager (CUCM).

Problème

L'intégration HTTPS entre le Conductor et CUCM pour les conférences ad hoc échoue. Il existe deux symptômes principaux lorsque ce problème se produit :

• L'état d'inscription du pont Conductor Conference Bridge sur CUCM s'affiche comme Non enregistré.
  
  
• Les tentatives de création d'une conférence ad hoc échouent.

Les sections qui suivent expliquent ces deux symptômes en détail.

L'état de l'enregistrement indique Non enregistré

Ce symptôme est observé dans ces deux scénarios :

• La case Remplacer la destination de la liaison SIP par une adresse HTTP n'est pas cochée sur la page de configuration du Conductor, et la liaison SIP associée au pont de conférence du Conductor a une adresse de destination configurée en tant qu'adresse IP ou nom de domaine complet (FQDN).
  

  Astuce : Pour plus d'informations sur le scénario de liaison SIP FQDN, référez-vous à la section Liaison SIP configurée avec nom de domaine complet de ce document.

• La case Remplacer la destination de la liaison SIP par une adresse HTTP est cochée sur la page de configuration du Conductor et est configurée en tant qu'adresse IP.

Ces images indiquent l'état d'enregistrement pour ces deux scénarios :

La cause première de cet échec d'enregistrement est la bibliothèque utilisée pour HTTPS/TLS (Transport Layer Security). La connexion TLS échoue avec une alerte cryptée car la bibliothèque ne prend pas en charge les URI (Uniform Resource Identifiers) au format d'adresse IP pour HTTPS/TLS.

À un niveau élevé, la connexion TLS se produit de la même manière que ceci :

1. CUCM envoie un message Hello du client TLS au Conductor.
   
   
2. Le Conductor envoie un message Hello et des informations de certificat au CUCM.
   
   
3. Le Conductor envoie les messages Hello Done et Server Key Exchange au CUCM.
   
   
4. Le CUCM envoie les messages Client Key Exchange, Change Cipher Spec et Encrypted Handshake au Conductor.
   
   
5. Le Conductor envoie les messages Change Cipher Spec et Encrypted Handshake au CUCM.
   
   
6. Le CUCM envoie une alerte chiffrée au Conductor.

Échec de création de conférence ad hoc

Ce symptôme est observé lorsqu'une solution de contournement est appliquée pour le symptôme susmentionné, ce qui provoque l'échec de la création de conférences ad hoc :

La cause première de ce symptôme est le Conductor, qui ne traite pas l'appel conference.create Application Program Interface (API) de CUCM lorsque l'URI est construit avec un FQDN.

Le Conductor enregistre ensuite cet événement :

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: La valeur Conference_name est différente pour chaque appel.

Solution

Pour que l'intégration HTTPS et la création de conférence ad hoc fonctionnent correctement entre CUCM et le Conductor, une correction est requise pour l'ID de bogue Cisco CSCut22572. Ce correctif doit permettre de configurer l'adresse de destination HTTPS en tant que nom de domaine complet.

Note: Le nom de domaine complet (FQDN) doit être résolu en adresse IP virtuelle (VIP) associée à l'emplacement ad hoc du Conductor et doit être inclus en tant qu'attribut SAN (Subject Alternative Name) dans le certificat du Conductor.

À long terme, l'amélioration des fonctionnalités décrite dans l'ID de bogue Cisco CSCut10254 permettra de configurer l'adresse de destination HTTPS avec une adresse IP, soit à partir d'une configuration manuelle/de remplacement, soit à partir de la ligne principale SIP.

Liaison SIP configurée avec FQDN

L'état du service de liaison SIP peut parfois apparaître comme Aucun service ou Indisponible. Cela se produit lorsque :

• L’adresse de destination dans la ligne principale SIP est configurée avec un nom de domaine complet (FQDN).
  
  
• Le nom de domaine complet (FQDN) est converti en VIP associé à l'emplacement ad hoc indiqué sur la page de configuration du Conductor.

Voici un exemple :

La cause première de cette situation est le Conductor, qui ne répond pas au message Options SIP envoyé par CUCM. L'URI SIP est construit en fonction de l'adresse de destination, qui est un nom de domaine complet dans cet exemple, et le Conductor attend une notation d'adresse 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."

Cela se produit même si le conducteur peut résoudre le FQDN ad hoc :

Note: Sauf indication contraire, ce problème est également suivi dans l'ID de bogue Cisco CSCut22572.

Historique de révision