Problèmes de coupure audio et de latence côté réception du téléphone de bureau appelant Webex

Problème

Plusieurs utilisateurs de téléphones de bureau Webex Calling ont rencontré des problèmes de coupure audio lors de la prise d'appels. Les symptômes spécifiques comprenaient :

• Les premières secondes d'audio ont été coupées lors de la réponse aux appels

• Délai vocal unidirectionnel intermittent jusqu'à 5-6 secondes entre les participants ext à ext ou les appels ext à messagerie vocale

• Aucun problème avec les médias des téléphones de bureau au cloud

L'analyse de la qualité des appels a révélé des problèmes graves au niveau de la réception des téléphones de bureau, notamment :

• Délai vocal unidirectionnel pouvant atteindre 5 à 6 secondes sur le téléphone de bureau

Le problème était toujours reproductible pour les téléphones VLAN internes lors de l'appel de la messagerie vocale (numéro pilote 8989) et WXCC (4700), alors que les téléphones en réseau externe/distant ne présentaient pas le problème. Les agents softphone WebRTC n'ont pas été affectés par ce problème.

Environnement

• Déploiement de Webex Calling avec téléphones de bureau

• Périphériques affectés: Cisco 8865-3PCC, Cisco 9841, Cisco 9851

• Connexion réseau : Ethernet sur le LAN d'entreprise

• Codec audio : PCMU ou OPUS

• Optimisation du chemin : Aucune optimisation activée

• Infrastructure de pare-feu CheckPoint

• QoS activée sur les ports de commutation et les trunks

• Fréquence des problèmes : Environ 1 appel sur 6 est concerné

Résolution

Le processus de dépannage comprenait une analyse complète des données de qualité d'appel, une étude du chemin réseau et une analyse de capture de paquets afin d'isoler la défaillance du support côté réception.

Étape 1: Analyse de la qualité des appels

Plusieurs rapports d'appels ont été analysés afin de confirmer la tendance de la déficience côté réception. L'analyse a révélé des problèmes constants dans la direction de réception vers les téléphones de bureau, tandis que les mesures de transmission restaient saines.

Étape 2: Network Path Investigation

L'enquête a porté sur l'identification de l'endroit où la déficience auditive a été introduite. Principales conclusions :

• Bonne qualité du média dans le sens de Webex Calling Cloud > org edge/CheckPoint firewall > Caller

• L'analyse de la capture des paquets par le fournisseur du pare-feu CheckPoint a révélé que les paquets étaient initialement traités lors de l'acceptation des appels, suivis d'un délai de traitement d'environ 5 secondes.

Étape 3: Essais Contrôlés

Des tests contrôlés ont été effectués avec des téléphones Cisco 9851 identiques sur différents réseaux :

• Téléphone réseau externe/distant : Les appels vers la messagerie vocale (numéro pilote 8989) étaient toujours bons et le message complet était entendu

• Téléphone réseau interne vers messagerie vocale (numéro pilote 889) : 5 premières secondes du message coupé par intermittence

Les résultats des tests ont confirmé que le problème était isolé sur le chemin réseau entre le pare-feu CheckPoint et l'infrastructure LAN de l'entreprise.

Étape 4: Analyse de capture de paquets

Des captures de paquets simultanées ont été collectées à partir de plusieurs points :

• Port de commutation téléphonique

• Interface LAN du pare-feu

• Interface WAN du pare-feu

L'analyse du fournisseur du pare-feu CheckPoint a observé que les paquets étaient initialement reçus/envoyés lors de l'acceptation de l'appel, suivis d'un délai d'environ 5 secondes avant que d'autres paquets ne soient traités.

Étape 5: Étapes de validation

Ces étapes de validation ont été recommandées pour confirmer la résolution :

1.- Surveillez les compteurs d'interface sur le VLAN et la périphérie WAN du téléphone affecté pour détecter les pertes de file d'attente, de sortie et de régulateur.

2.- Vérifiez que la configuration du pare-feu est conforme aux exigences du port d'appel Cisco Webex.

3.- Recherchez les problèmes d’encombrement ou de mise en mémoire tampon sur le chemin du VLAN voix.

4.- Validez le traitement QoS pour le trafic RTP.

Le dossier a été clos en attendant les résultats de l'analyse du fournisseur du pare-feu CheckPoint, car les preuves indiquaient un problème de chemin réseau entre le pare-feu et l'infrastructure LAN de l'entreprise.

Motif

La cause principale a été identifiée comme une altération du support du chemin de réception affectant le trafic RTP du nuage d'appels Webex vers les téléphones de bureau internes. Le problème se produisait spécifiquement au niveau ou à proximité du périphérique de périphérie Internet de l'entreprise (pare-feu CheckPoint avec IP 192.X.X.X) ou dans le chemin du FAI.

L'analyse a montré que, bien que le trafic de transmission des téléphones affectés soit resté sain, il y avait une dégradation significative du trafic RTP vers les utilisateurs internes. L'analyse de la capture des paquets par le fournisseur du pare-feu CheckPoint a révélé que les paquets étaient initialement traités lors de l'acceptation des appels, suivis d'un délai de traitement d'environ 5 secondes, bien que la cause exacte dans le traitement du pare-feu n'ait pas été déterminée à la fermeture du dossier.

Il s'agit d'un problème d'interopérabilité/compatibilité entre votre infrastructure réseau et le pare-feu CheckPoint, plutôt que d'un problème lié à la plate-forme d'appel Webex.

Autres informations utiles

• Dépannage des appels Webex dans le Control Hub

• Informations de référence de port pour les appels Webex

• Génération manuelle de PRT pour les téléphones MPP enregistrés sur Webex Calling

• Configurer le niveau de débogage dans les téléphones MPP enregistrés pour les appels Webex

• Assistance technique de Cisco et téléchargements

Historique de révision

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