Le videochiamate personali alle riunioni abilitate per dispositivi video vengono perse dopo 15 minuti (o dopo un'ora specifica)

Le chiamate video alle riunioni abilitate per dispositivi video vengono perse dopo 15 minuti (o dopo un'ora specifica).

Le connessioni delle chiamate video Cisco Webex alle riunioni abilitate per dispositivi video vengono disconnesse dopo 15 minuti.

Le chiamate SIP vengono perse dopo un intervallo di tempo impostato.

Le connessioni alle riunioni abilitate per dispositivi video vengono disconnesse dopo 15 minuti.

Le videochiamate vengono perse dopo 15 minuti.

 

Causa: Quando le videochiamate si disconnettono esattamente a 15 minuti, il problema comune è che il timeout TCP configurato sulla rete (firewall/router) è inferiore al timer di scadenza della sessione SIP. Per impostazione predefinita in CallManager, il timer di scadenza sessione SIP è impostato su 1800 secondi.

Soluzione:

Per verificare:

  1. Aprire Cisco Unified Communications Manager amministrazione sito (CM).
  1. Fare clic su Impostazioni > dei servizi.
  2. Nella casella Server e servizioselezionati, elenco a discesa servizio, selezionare Cisco Call Manager (attivo):
Immagine aggiunta dall'utente
  1. Ricercare il timer della sessione SIP:
Immagine aggiunta dall'utente

Tutti i dispositivi registrati in CUCM utilizzano questo timer. Quando il dispositivo è in chiamata con un altro dispositivo remoto, una delle parti deve aggiornare la sessione e inviare un nuovo INVITO o AGGIORNAMENTO. Questo aggiornamento deve essere inviato prima della metà del timer di scadenza sessione (1800/2 = 900 secondi = 15 minuti). Se non si riceve alcun messaggio di aggiornamento, la chiamata viene disconnessa.

Controllare il timer della sessione nell'INVITO iniziale. È necessario ricevere un aggiornamento (INVITE/UPDATE) prima della scadenza di questo periodo:
Immagine aggiunta dall'utente

In base alla negoziazione iniziale del client agente utente/server agente utente (UAC/UAS), uno dei dispositivi aggiorna la sessione quando invia un nuovo invito. Se l'aggiornamento è UAC, l'iniziatore della chiamata ha la responsabilità di aggiornare la sessione. Se l'aggiornamento è UAS, il server deve aggiornare la sessione. Raccogliere i registri di debug SIP da entrambi gli endpoint e controllare questi elementi:

Esempio: Chiamata effettuata da Parte A a CUCM a Parte B. Se l'aggiornamento è UAC sulla Parte A e UAS sulla parte B:

1.     La Parte A deve inviare la nuova invito/aggiornamento a CUCM.
2.     CUCM deve inviare un nuovo INVITO/AGGIORNAMENTO alla parte B.
3.     Il Gruppo B riceve il nuovo INVITO e risponde a tale messaggio con un OK di 200 partecipanti.
4.     CUCM deve inviare 200 OK alla Parte A.

Se un dispositivo invia il messaggio di nuova invito a CUCM, CUCM invia un nuovo INVITO all'altra parte. Tuttavia, se non viene ricevuta dal lato remoto, ciò potrebbe essere dovuto a alcuni dispositivi di rete tra. È altamente possibile che la richiesta di re-INVITE/risposta non apporti uno dei lati a causa del controllo SIP o delle impostazioni di rete.
Se i dispositivi non avviano il nuovo INVITO, si potrebbe verificare un problema con il dispositivo. Coinvolgere il Centro assistenza tecnica Cisco (TAC) per approfondire la ricerca di ulteriori informazioni.
 
Nell'elenco di operazioni da provare [se ancora non è ancora stato] nell'area di configurazione avanzata della zona andando a Webex:
Attivare la modalità filtro SIP UDP/IX su [non predefinito]:
Immagine aggiunta dall'utenteE controllare anche i timer delle sessioni SIP su VCS-e.

 
Il nostro valore predefinito è 1800s [15 min], che è standard e si desidera accertarsi che anche il timer TCP sul firewall corrisponda qui, ma si potrebbe verificare un po' di più questo problema per vedere se ha un effetto anche su VCS.

Questa opzione è in Configurazione > protocolli > SIP:
Immagine aggiunta dall'utente

Tenere presente che l'intervallo di aggiornamento sessione (secondi) è impostato sul valore predefinito. È possibile provare a 3600. Tuttavia, la radice effettiva del problema qui è quando L'FW pensa che una sessione non sia più in uso [caso 1], quando VCS in realtà pensa che sia ok e che la sessione è ancora attiva, ma non riceve una FIN/chiusa su tale sessione/porta e tenta di utilizzarla nuovamente e la chiamata viene disa. [caso 2] è che FW chiude correttamente la connessione e invia un FIN/close e VCS registra una normale chiamata drop/clearing e anche la chiamata viene disa. Modificando il timer della sessione qui si controlla solo quando VCS si registrerà una sessione in seguito alla ricezione di eventuali ACL per qualsiasi comunicazione tentata di comunicazione relativa allo stato della chiamata.
 
Tuttavia, può aiutare a individuare meglio il problema. È anche possibile che sia necessario ridurre questo valore in base all'impostazione FW per questo timer.

Questo articolo è stato utile?