Dépannez les questions d'intégration HTTPS entre le conducteur et le CUCM

Introduction

Ce document décrit un problème qui est produit avec l'intégration HTTPS entre le conducteur de Cisco et le Cisco Unified Communications Manager (CUCM).

Problème

L'intégration HTTPS entre le conducteur et le CUCM pour des conférences ad hoc échoue. Il y a deux symptômes principaux quand ce problème se pose :

• L'état d'enregistrement pour la passerelle de conférence de conducteur sur le CUCM affiche comme non enregistrés.
  
  
• Tentatives de créer un échouer ad hoc de conférence.

Les sections qui suivent expliquent ces deux symptômes dans davantage de détail.

L'état d'enregistrement affiche des non enregistrés

On observe ce symptôme dans ces deux scénarios :

• La destination de joncteur réseau de SIP de priorité comme case d'adresse HTTP est décochée à la page de configuration de conducteur, et le joncteur réseau associé de Protocole SIP (Session Initiation Protocol) pour la passerelle de conférence de conducteur a une adresse de destination qui est configurée comme adresse IP ou nom de domaine complet (FQDN).
  

  Conseil : Pour plus d'informations sur le scénario de joncteur réseau de SIP FQDN, référez-vous au joncteur réseau de SIP configuré avec la section FQDN de ce document.

• La destination de joncteur réseau de SIP de priorité comme case d'adresse HTTP est vérifiée la page de configuration de conducteur et est configurée comme adresse IP.

Ces images affichent l'état d'enregistrement pour chacun des deux scénarios :

La cause principale pour cette panne d'enregistrement est la bibliothèque qui est utilisée pour le Transport Layer Security HTTPS/(TLS). La prise de contact de TLS échoue avec une alerte chiffrée parce que la bibliothèque ne prend en charge pas des identifiants de ressource uniforme (URIs) dans le format d'adresse IP pour HTTPS/TLS.

À un haut niveau, la prise de contact de TLS se produit semblable à ceci :

1. Le CUCM envoie un message Hello de client de TLS au conducteur.
   
   
2. Le conducteur envoie des informations de message Hello et de certificat de serveur au CUCM.
   
   
3. Le conducteur envoie le serveur bonjour fait et des messages d'échange de clé de serveur au CUCM.
   
   
4. Le CUCM envoie le Key Exchange de client, la spécification de chiffrement de modification, et les messages chiffrés de prise de contact au conducteur.
   
   
5. Le conducteur envoie la spécification de chiffrement de modification et les messages chiffrés de prise de contact au CUCM.
   
   
6. Le CUCM envoie une alerte chiffrée au conducteur.

La création ad hoc de conférence échoue

On observe ce symptôme quand un contournement est appliqué pour le symptôme mentionné ci-dessus, qui fait échouer la création des conférences ad hoc :

La cause principale pour ce symptôme est le conducteur, qui ne traite pas l'appel de l'interface de programmation conference.create (API) du CUCM quand l'URI est construit avec un FQDN.

Le conducteur se connecte alors 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 de Conference_name est différente pour chaque appel.

Solution

Pour que l'intégration HTTPS et la création ad hoc de conférence fonctionne correctement entre le CUCM et le conducteur, une difficulté est exigée pour l'ID de bogue Cisco CSCut22572. Cette difficulté devrait permettre l'adresse de destination HTTPS à configurer comme FQDN.

Note: Le FQDN doit le résoudre à l'IP virtuel (VIP) qui est associé avec l'emplacement ad hoc de conducteur et doit être inclus comme attribut alternatif soumis du nom (SAN) dans le certificat de conducteur.

Le long terme l'amélioration de caractéristique qui est décrite dans l'ID de bogue Cisco CSCut10254 permettra l'adresse de destination HTTPS à configurer avec une adresse IP, d'une configuration de manuel/priorité ou du joncteur réseau de SIP.

Joncteur réseau de SIP configuré avec le FQDN

L'état de service de joncteur réseau de SIP peut parfois apparaître en tant qu'aucun service ou vers le bas. Ceci se produit quand :

• L'adresse de destination dans le joncteur réseau de SIP est configurée avec un FQDN.
  
  
• Le FQDN le résout à un VIP qui est associé avec l'emplacement ad hoc qui est indiqué à la page de configuration de conducteur.

Voici un exemple :

La cause principale pour ceci est le conducteur, qui ne répond pas au message d'options de SIP qui est envoyé du CUCM. L'URI de SIP est construit a basé sur l'adresse de destination, qui est un FQDN dans cet exemple, et le conducteur 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."

Ceci se produit quoique le conducteur puisse résoudre le FQDN ad hoc :

Note: À moins qu'autrement documentée, cette question est également dépistée dans l'ID de bogue Cisco CSCut22572.