Dépannage de l'échec d'inscription de ligne principale SIP basée sur certificat d'appel Webex avec Oracle SBC

Problème

Une liaison SIP basée sur certificat entre Webex Calling et un SBC Oracle tiers ne parvient pas à s'enregistrer et à s'activer. L'état de la liaison est « Impaired » dans le Control Hub. Au cours du dépannage, les problèmes spécifiques suivants ont été identifiés :

• Échecs de connexion TLS liés à la validation de certificat entre la passerelle locale et Webex Calling.

• Les messages SIP OPTIONS envoyés à la passerelle locale ne reçoivent pas de réponses.

• Connexion TCP en trois étapes non terminée - Les paquets SYN et SYN-ACK sont échangés entre 170.72.242.77 et 10.8.100.2 sur le port TCP 5062, mais l'ACK final n'est pas reçu.

• Tentatives de connexion TCP répétées à partir de l'appel Webex vers le SBC Oracle qui ne parviennent pas à établir une session complète.

Environnement

• Appel WebEx avec configuration de ligne principale SIP basée sur certificat.

• Contrôleur de frontière de session Oracle (SBC) tiers

• Chaîne de certificats Oracle SBC contenant des certificats GlobalSign et IdenTrust.

• Mappage de la configuration NAT (Network Address Translation) de l'adresse IP publique 201.221.125.143 vers l'adresse IP interne 10.8.100.2

• Pare-feu et dispositifs de sécurité réseau entre Webex Calling et Oracle SBC.

• Port TCP 5062 utilisé pour la communication SIP.

Résolution

Le problème a été résolu en implémentant une modification de la configuration du pare-feu pour utiliser le mappage NAT direct entre les adresses IP internes et publiques.

Étape 1: Vérifier la compatibilité de la chaîne de certificats

Vérifiez que l'émetteur et la chaîne de certificats Oracle SBC sont pris en charge par Webex Calling en les comparant à la documentation de l'autorité de certification racine prise en charge.

La chaîne de certificats du client comprenait :

• GlobalSign RSA OV SSL CA 2018 (certificat intermédiaire)

• Autorité de certification racine GlobalSign - R3 (certificat racine)

• Certificats IdenTrust dans la chaîne

Étape 2: Analyser les problèmes de connectivité réseau

L’analyse de capture de paquets a révélé que les connexions TCP de 170.72.242.77 à 10.8.100.2 sur le port TCP 5062 ne parvenaient pas à effectuer la connexion en trois étapes. Le SBC répondait avec des paquets SYN-ACK, mais le dernier ACK de Webex Calling n'était pas reçu.

Étape 3: Implémenter la configuration NAT directe

Le client a mis en oeuvre une modification du pare-feu pour configurer le mappage NAT direct entre l'adresse IP interne et l'adresse IP publique. Cette modification a résolu les problèmes d’établissement de session TCP.

Après la modification de la configuration du pare-feu :

• La liaison entre Webex Calling et la SBC est arrivée en ligne.

• Connexion TCP en trois étapes réussie.

• La communication OPTIONS SIP a été établie.

Étape 4: Valider le fonctionnement du service

Après la résolution, le client a effectué des tests de service et une validation pour confirmer que l'inspection du trafic n'a pas d'impact sur la qualité ou la fonctionnalité des appels.

Motif

La cause principale était un problème de configuration réseau où l'implémentation NAT du pare-feu empêchait l'exécution de connexions TCP en trois étapes entre Webex Calling et Oracle SBC. Le pare-feu ne gérait pas correctement le trafic de retour (paquets ACK finaux) de l'appel Webex vers le SBC, ce qui provoquait des échecs d'établissement de connexion TLS et empêchait l'enregistrement de la ligne principale SIP. La configuration du mappage NAT direct a résolu les problèmes de routage asymétrique ou de stratégie de pare-feu qui bloquaient la fin de la session TCP.

Autres informations utiles

• Quelles sont les autorités de certification racine prises en charge pour les appels vers les plates-formes audio et vidéo Cisco Webex ?
• Informations de référence de port pour les appels Webex
• Assistance technique de Cisco et téléchargements

Historique de révision

Révision	Date de publication	Commentaires
1.0	06-Nov-2026	Première publication