Pour les partenaires
Vous êtes déjà partenaire?
ConnexionAvez-vous un compte?
Ce document décrit un problème rencontré avec l'intégration HTTPS entre Cisco Conductor et Cisco Unified Communications Manager (CUCM).
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 :
Les sections qui suivent expliquent ces deux symptômes en détail.
Ce symptôme est observé dans ces deux scénarios :
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 :
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'>
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.
À 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.
L'état du service de liaison SIP peut parfois apparaître comme Aucun service ou Indisponible. Cela se produit lorsque :
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 :
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
29-Apr-2015 |
Première publication |