Cause : Lorsque les appels vidéo se déconnectent exactement pendant 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 de l’expiration de la session SIP est réglé sur 1800 secondes.

Solution :

Pour vérifier ceci :

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 d’actualisation reçu, l’appel est déconnecté.

Vérifiez le délai de session dans l’INVITATION initiale. Un rafraîchissement (INVITER/UPDATE) doit être reçu avant l’expiration de cette heure :


Selon la négociation initiale Client de l’agent utilisateur/Agent Utilisateur Server (UAC/JOURNÉES), l’un des périphériques actualit la session lorsqu’il envoie un Ré-INVITER. 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. Collectez les journaux de débogage SIP des deux points de terminaison et vérifiez ces éléments :

Exemple : Appel effectué de la partie A au CUCM vers la partie B. Si le rafraîchissement est UAC sur la partie A et l’UCS sur la partie B:

1.     La partie A doit envoyer la ré-INVITATION/MISE À JOUR vers le CUCM.
2.     CUCM doit envoyer une nouvelle INVITATION/MISE À JOUR à la partie B.
3.     Partie B reçoit la nouvelle INVITATION et répond à ce message avec un OK de 200.
4.     CUCM doit envoyer 200 OK à la partie A.

Si un périphérique envoie le message ré-INVITER au CUCM, CUCM envoie une nouvelle INVITATION à l’autre partie. Cependant, si ce n’est pas reçu par le côté distant, cela peut être à cause de certains périphériques réseau entre les deux. Il est hautement possible que la ré-INVITATION/réponse n’arrive pas de l’un des côtés en raison de l’inspection SIP ou des paramètres réseau.
Si les périphériques n’initient pas la ré-INVITATION, le problème peut être 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 ce n’est pas déjà] dans la zone de config avancée de la zone en allant à Webex :
Tournez le mode de filtrage SIP UDP/IX sur [pas la valeur par défaut]:
Et vérifiez les minutes de session SIP sur VCS-e également.

 
Notre paramètre par défaut est les 1800s [15 minutes], qui est standard et vous devez vous assurer que le minuteur TCP sur votre pare-feu correspond également ici, mais vous pouvez filtrer ceci un peu plus pour voir si cela a également un effet sur votre VCS.

Ceci se trouve sous Configuration > Protocoles > SIP :
Notez que l’intervalle d’actualisation de la session (secondes) est réglé 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 nous aider à identifier le problème un peu mieux. Il est également possible que nous devons réduire cette valeur en fonction du paramètre FW pour ce timer.