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

Apelurile mele video către întâlnirile activate pentru dispozitive video scad după 15 minute (sau după orice moment specific).

Conexiunile prin apeluri video la Întâlnirile Cisco Webex activate pentru dispozitive video se deconectează după 15 minute.

Apelurile SIP sunt în scădere după un interval de timp stabilit.

Conexiunile la întâlnirile cu dispozitiv video activate se deconectează după 15 minute.

Apelurile video scad după 15 minute.

 

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

Soluție:

Pentru a verifica acestlucru:

  1. Deschideți Cisco Unified Communications Manager (CM) Administration.
  1. Faceți clic pe Parametrii de serviciu > de sistem.
  2. Sub Selectare server și serviciu , în caseta listă verticală Serviciu, selectați Cisco Call Manager (Activ):
Imagine adăugată de utilizator
  1. Uita-te pentru sesiunea SIP expirăCronometrul:
Imagine adăugată de utilizator

Toate dispozitivele înregistrate la CUCM utilizează acest cronometru. Atunci când dispozitivul este într-un apel cu un alt dispozitiv la distanță, una dintre părți trebuie să reîmprospăteze sesiunea și trimite o re-INVITAre sau ACTUALIZARE. Această reîmprospătare trebuie trimisă înainte de jumătate din cronometrul de expirare a sesiunii ( 1800/2 = 900 secunde = 15 minute). Dacă nu se primește niciun mesaj de reîmprospătare, apelul este deconectat.

Verificați cronometrul sesiunii în INVITAȚIA inițială. O reîmprospătare (INVITE / UPDATE) ar trebui să fie primită înainte de expirarea acestui moment:
Imagine adăugată de utilizator

Pe baza negocierii inițiale User Agent Client /User Agent Server (UAC/UAS), unul dintre dispozitive reîmprospătează sesiunea atunci când trimite o re-INVITAȚIE. 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 făcut de la partea A la CUCM la partidul B. Dacă reîmprospătarea este UAC pe Partidul A și UAS pe Partidul B:

1.     Partea A trebuie să trimită re-INVITAREA / ACTUALIZAREA la CUCM.
2.     CUCM trebuie să trimită o re-INVITARE / ACTUALIZARE la partea B.
3.     Partidul B primește invitația din nou și răspunde la acel mesaj cu un 200 OK.
4.     CUCM trebuie să trimită 200 OK la partea A.

Dacă un dispozitiv trimite mesajul de re-INVITAȚIE la CUCM, CUCM trimite o re-INVITAre celeilalte părți. Cu toate acestea, dacă acest lucru nu este primit de partea de la distanță, atunci acest lucru ar putea fi din cauza unor dispozitive de rețea între ele. Este foarte posibil ca re-INVITA / răspuns nu ajunge la una dintre părți din cauza inspecției SIP sau setările de rețea.
Dacă dispozitivele nu inițiază re-INVITAREA, ar putea fi o problemă cu dispozitivul. Implicați Cisco Technical Assistance Center (TAC) pentru a investiga în continuare.
 
Pe lista de lucruri pentru a încerca [dacă acest lucru nu a fost deja] în zona de configurare avansată a zonei care merge la Webex:
Porniți modul de filtrare SIP UDP / IX la activat [nu implicit]:
Imagine adăugată de utilizator
Și verificați cronometrele sesiunii SIP pe VCS-e, de asemenea.
 
Valoarea noastră implicită este de 1800s [15 minute], care este standard și veți dori să vă asigurați că cronometrul TCP de pe Firewall se potrivește și aici, dar ați putea să faceți acest lucru puțin pentru a vedea dacă are un efect și asupra VCS-ului dvs.

Aceasta se află sub 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 încerca 3600. But the actual root of the problem here is when the FW thinks that a session is no longer in use [case 1], when VCS actually think it's ok and that the session is still up but doesn't receive a FIN/close on that session/port and attempts to re-use it and the call dies. [cazul 2] este FW închide în mod corespunzător conexiunea și trimite un FIN / închidere și VCS înregistrează o picătură / compensare a apelului normal și apelul, de asemenea, moare. Modificarea cronometrului de sesiune aici doar controlează atunci când VCS va renunța la o sesiune după ce nu a reușit să primească niciun ASC pentru orice încercare de comunicare cu privire la starea apelului.
 
Aceasta ne poate ajuta să identifice problema un pic mai bine, totuși. De asemenea, este posibil să reducem această valoare în funcție de setarea FW pentru acest cronometru.

A fost util acest articol?