Merci pour votre commentaire.

PROBLÈME
Lorsque vous rejoignez une réunion Webex avec un périphérique vidéo enregistré sur CUCM, l’appel se déconnecte exactement 15 minutes.

RÉSOLUTION
Examinez les étapes ci-dessous :

1. Ouvrez Cisco Unified Communications Manager Administration du site (CM).
2. Cliquez sur Système > Paramètres du service.
3. Sous Sélectionner le serveur et le service, dans la case Liste déroulante service, sélectionnez Gestionnaire d’appels Cisco (Actif) :

4. Recherchez le délai d’expiration de la session SIP :

Tous les périphériques enregistrés sur CUCM utilisent ce timer. Lorsque le périphérique est en cours d’appel avec un autre périphérique distant, l’une des parties doit actualiser la session et envoyer un nouveau message d’INVITATION ou de MISE À JOUR. Cette actualisation doit être envoyée avant l’expiration de la moitié du minuteur de la session (1800/2 = 900 secondes = 15 minutes). S’il n’y a aucun message actualiser reçu, l’appel est déconnecté (e).

Cocher pour la durée de session dans l’invitation initiale. Une actualisation (inviter / mettre à jour) doit être reçu avant l’expiration de cette période :


En fonction de la négociation initiale User Agent Client/User Agent Server (UAC/UAS), l'un des périphériques actualise la session lorsqu'il envoie un message Re-INVITE. Si l’actualisation est UAC, l’initiateur de l’appel a la responsabilité d’actualiser la session. Si l’actualisation est AUSS, le serveur doit actualiser la session. Collecter les journaux de débogage SIP à partir de deux points de terminaison et de vérifier ces éléments :

Exemple: Appel effectué de la partie A vers CUCM vers la partie B. Si l’actualisation est UAC sur la partie A et UAS sur la partie B :

1.     La partie A doit envoyer la réinvitation/MISE À JOUR au CUCM.
2.     CUCM doit envoyer une nouvelle INVITATION/MISE À JOUR à la partie B.
3.     La partie B reçoit la réinvitation et répond à ce message par un 200 OK.
4.     CUCM doit envoyer 200 OK à la partie A.

Si un périphérique envoie le message re-INVITE au CUCM, CUCM envoie une re-INVITE à l'autre Partie. Cependant, si ce n’est pas reçu par le site distant alors ceci peut être en raison de certains périphériques du réseau entre les deux. Il est fortement possible que la re-INVITE/réponse n’est pas à l’un des deux côtés en raison des paramètres réseau ou inspection SIP.
Si les périphériques ne lancent pas la réinvite, cela peut être un problème avec le périphérique. Impliquer le Centre d’assistance technique Cisco (CAT) afin d’enquêter davantage.
 
Sur la liste des choses à essayer [si cela ne l'a pas déjà fait] dans la zone de configuration avancée de la zone allant sur Webex :
Activez le mode de filtrage SIP UDP/IX sur activé [pas la valeur par défaut] :

Et vérifiez également les minuteurs de session SIP sur VCS-e.
 
Notre valeur par défaut est 1800 [30 minutes], ce qui est standard et vous devez vous assurer que le minuteur TCP sur votre pare-feu correspond également ici, mais vous pouvez augmenter un peu ce paramètre pour voir si cela a également un effet sur votre VCS.

Ceci est sous Configuration > Protocoles > SIP :


Notez que l'intervalle d'actualisation de session (en secondes) est défini sur la valeur par défaut. Vous pouvez essayer 3600. Mais la racine réelle du problème ici est lorsque le FW pense qu’une session n’est plus en cours d’utilisation [cas 1], lorsque VCS pense que tout est ok et que la session est toujours en cours mais qu’il ne reçoit pas de FIN/fermeture sur cette session/port et tente de la ré-utiliser et que le dies de l’appel. [case 2] est le FW ferme correctement la connexion et envoie une FIN/Fermeture et VCS enregistre une drop/clearing d’appel normale et l’appel est également transmettre. Modifier le timer de session ici contrôle uniquement quand VCS abandonnera une session après avoir échoué à recevoir des ACK pour toute tentative de communication concernant le statut de l’appel.
 
Cela peut cependant nous aider à mieux identifier le problème. Il est également possible que nous devons réduire cette valeur en fonction du paramètre FW pour ce timer.

CAUSE
Lorsque les appels vidéo sont déconnectés exactement 15 minutes, le problème courant est que le délai d'expiration TCP configuré sur le réseau (pare-feu/routeurs) est inférieur au délai d'expiration de la session SIP. Par défaut sur CallManager, le minuteur d’expiration SIP Session est défini sur 1800 secondes.