Apelurile mele video către întâlnirile cu dispozitive video scad după 15 minute (sau după un anumit timp)

Apelurile mele video către Întâlniri cu dispozitive video scad după 15 minute (sau după orice oră anume).

Conexiunile apelurilor video la întâlnirile activate pentru dispozitive video Cisco Webex se deconectează după 15 minute.

Apelurile SIP scad după un interval de timp stabilit.

Conexiunile la întâlniri cu dispozitive video activate se deconectează după 15 minute.

Apelurile video scade după 15 minute.

 

Cauză: Când apelurile video se deconectează la exact 15 minute, problema comună este că timeout-ul TCP configurat în rețea (firewall/routere) este mai mic decât temporizatorul de expirare a sesiunii SIP. În mod implicit, pe CallManager, temporizatorul de expirare a sesiunii SIP este setat la 1800 de secunde.

Soluție:

Pentru a verifica acest lucru:

  1. Deschideți Cisco Unified Communications Manager (CM) Administration.
  1. Faceţi clic pe System > Service Parameters.
  2. Sub Selectare server și serviciu, în caseta derulantă Serviciu, selectați Manager de apeluri Cisco (activ):
Imagine adăugată de utilizator
  1. Căutați Cronometrul de expirare a sesiunii SIP:
Imagine adăugată de utilizator

Toate dispozitivele înregistrate la CUCM folosesc acest cronometru. Când dispozitivul este într-un apel cu un alt dispozitiv de la distanță, una dintre părți trebuie să reîmprospăteze sesiunea și să trimită o re-INVITARE sau o ACTUALIZARE. Această reîmprospătare trebuie trimisă înainte de jumătatea temporizatorului de expirare a sesiunii (1800/2 = 900 de secunde = 15 minute). Dacă nu este primit niciun mesaj de reîmprospătare, apelul este deconectat.

Verificați cronometrul sesiunii în INVITARE inițială. O reîmprospătare (INVITARE/ACTUALIZARE) ar trebui să fie primită înainte de expirarea acestui timp:
Imagine adăugată de utilizator

Pe baza negocierii inițiale client agent utilizator/server agent utilizator (UAC/UAS), una dintre dispozitivele reîmprospătează sesiunea când trimite o Re-INVITARE. Dacă reîmprospătarea este UAC, inițiatorul apelului are responsabilitatea de a reîmprospăta sesiunea. Dacă reîmprospătarea este UAS, serverul trebuie să reîmprospăteze sesiunea. Colectați jurnalele de depanare SIP de la ambele puncte finale și verificați aceste elemente:

Exemplu: Apel efectuat de la Partea A la CUCM către Partea B. Dacă reîmprospătarea este UAC la Partea A și UAS la Partea B:

1.     Partea A trebuie să trimită CUCM re-INVITAREA/ACTUALIZAREA.
2.     CUCM trebuie să trimită o re-INVITAȚIE/ACTUALIZARE părții B.
3.     Partea B primește re-INVITARE și răspunde la acel mesaj cu 200 OK.
4.     CUCM trebuie să trimită 200 OK părții A.

Dacă un dispozitiv trimite mesajul de re-INVITARE către CUCM, CUCM trimite o re-INVITAȚIE celeilalte părți. Cu toate acestea, dacă acest lucru nu este primit de la distanță, atunci acest lucru ar putea fi din cauza unor dispozitive de rețea între ele. Este foarte posibil ca re-INVITARE/răspunsul să nu ajungă pe una dintre părți din cauza inspecției SIP sau a setărilor de rețea.
Dacă dispozitivele nu inițiază re-INVITARE, ar putea fi o problemă cu dispozitivul. Implicați Centrul de asistență tehnică Cisco (TAC) pentru a investiga în continuare.
 
Pe lista de lucruri de încercat [dacă acest lucru nu a fost deja făcut] în zona de configurare avansată a zonei care merge la Webex:
Activați modul de filtrare SIP UDP/IX la activat [nu este implicit]:
Imagine adăugată de utilizator
Și verificați și cronometrele sesiunii SIP pe VCS-e.
 
Implicit este 1800s [15 minute], care este standard și veți dori să vă asigurați că timer-ul TCP de pe firewall-ul dvs. se potrivește și aici, dar puteți crește puțin acest lucru pentru a vedea dacă are un efect și asupra dvs. VCS.

Acesta se află în Configurare > Protocoale > SIP:
Imagine adăugată de utilizator

Rețineți că intervalul de reîmprospătare a sesiunii (secunde) este setat la valoarea implicită. S-ar putea să încerci 3600. Dar rădăcina reală a problemei aici este atunci când FW crede că o sesiune nu mai este în uz [cazul 1], când VCS de fapt crede că este ok și că sesiunea este încă activă, dar nu primește un FIN/închidere în acest sens. sesiune/port și încearcă să-l reutilizați, iar apelul încetează. [cazul 2] este că FW-ul închide corect conexiunea și trimite un FIN/închidere și VCS înregistrează o oprire/închidere normală a apelului, iar apelul moare. Modificarea temporizatorului sesiunii aici controlează doar când VCS va renunța la o sesiune după ce nu a reușit să primească niciun ACK pentru orice încercare de comunicare cu privire la starea apelului.
 
Totuși, ne poate ajuta să identificăm puțin mai bine problema. De asemenea, este posibil să fie nevoie să reducem această valoare în funcție de setarea FW pentru acest temporizator.
A fost util acest articol?