Introduction
Ce document décrit les problèmes courants rencontrés lors de la tentative d'enregistrement de Cisco Meeting Server (CMS) en tant que pont de conférence sur Cisco Unified Call Manager (CUCM).
Conditions Préalables
- Vous avez configuré une ligne principale SIP de CUCM à CMS en utilisant le nom de domaine complet de CMS plutôt qu'IP
- Vous avez configuré le pont de conférence CMS sur CUCM, après avoir activé le paramètre Override SIP Trunk Destination comme nom d'hôte d'adresse HTTPS.
1. Incompatibilité de version TLS
Il peut arriver que CUCM utilise TLS 1.0 alors que CMS utilise TLS 1.2
À partir de la version 2.3, Meeting Server utilise un minimum de TLS 1.2 et DTLS 1.2 pour tous les services : SIP, LDAP, HTTPS (connexions entrantes : API, Web Admin et Web Bridge ; connexions sortantes : CDR) et XMPP.
Solution
Si l'interopérabilité avec un logiciel plus ancien qui n'a pas implémenté TLS 1.2 est nécessaire, une version inférieure du protocole peut être définie comme version TLS minimale pour les services SIP, LDAP et HTTPS. Reportez-vous aux commandes tls <service> min-tls-version <chaîne de version minimale> et tls min-dtls-version <chaîne de version minimale> du guide de référence des commandes MMP pour CMS.
Remarque : Un redémarrage du pont d'appel est nécessaire pour que les modifications apportées à la configuration tls soient appliquées.
2. CUCM n’envoie aucun trafic TCP à CMS
Il peut arriver que vous ne voyiez aucun trafic en provenance de CUCM sur CMS.
Solution
La raison pour laquelle cela peut se produire est que CUCM ne peut pas résoudre l'URL pour se connecter à CMS. Assurez-vous que l'URL utilisée dans le champ Override SIP Trunk Destination as HTTPS Address Hostname sur le pont de conférence possède un enregistrement A correspondant sur le DNS que CUCM utilise.
Vous pouvez également vous assurer que le DNS principal de CUCM est capable de résoudre le FQDN de CMS. Le noeud DNS secondaire configuré sur CUCM ne sera pas utilisé à moins que le noeud DNS principal ne soit complètement inaccessible.
Dans les journaux SDL de CUCM, vous verrez ceci :
87042368.004 |15:18:18.129 |AppInfo |ConnectionFailureToPDP - A connection request from Unified CM to the policy decision point failed Policy Decision Point:https://webbridge_test.test.com:445/RPC2/ The cause of the connection failure:Invalid URI App ID:Cisco CallManager Cluster ID:StandAloneCluster Node ID:TPCUCMPUB
87042368.005 |15:18:18.129 |AlarmErr |AlarmClass: CallManager, AlarmName: ConnectionFailureToPDP, AlarmSeverity: Error, AlarmMessage: , AlarmDescription: A connection request from Unified CM to the policy decision point failed, AlarmParameters: PolicyDecisionPoint:https://webbridge.test.com:445/RPC2/, FailedToConnectReason:Invalid URI, AppID:Cisco CallManager, ClusterID:StandAloneCluster, NodeID:TPCUCMPUB,
3. CMS ne s’enregistrant pas en raison de la délivrance du certificat
Vous voyez le trafic TCP qui est échangé entre CUCM et CMS, mais CUCM réinitialise la connexion TCP.
Solution
Au cours de la connexion en 3 étapes pour configurer la connexion TCP entre CMS et CUCM, CMS présente son certificat d'administration Web à CUCM. L'URL utilisée dans le paramètre override doit être présente dans le certificat WebAdmin sous la forme CN ou dans le champ SAN.
Commentaires