Mine videoopkald til møder med aktiveret videoenhed droppes efter 15 minutter (eller efter et bestemt tidspunkt)

Mine videoopkald til møder med aktiveret videoenhed falder efter 15 minutter (eller efter et bestemt tidspunkt).

Videoopkaldsforbindelser til Cisco Webex-møder med aktiveret videoenhed afbrydes efter 15 minutter.

SIP-opkald falder efter et bestemt tidsinterval.

Tilslutninger til møder med aktiveret videoenhed afbrydes efter 15 minutter.

Videoopkald falder efter 15 minutter.

 

Årsag: Når videoopkald afbryder ved præcis 15 minutter, er det fælles problem TCP-timeout konfigureret på netværket (firewall/routere) mindre end SIP-sessionens udløber timer. Som standard på CallManager er sip-sessionens udløbstimer indstillet til 1800 sekunder.

Løsning:

For at verificere dette:

  1. Åbn Cisco Unified Communications Manager (CM) administration.
  1. Klik på System > Serviceparametre.
  2. Under Vælg server og tjeneste skal du i feltet Rullegardinmenu vælge Cisco Opkaldsadministrator (Aktiv):
Brugertilføjet billede
  1. Se efter timeren , når SIP-sessionen udløber:
Brugertilføjet billede

Alle enheder registreret til CUCM bruger denne timer. Når enheden er i gang med et opkald med en anden ekstern enhed, er en af parterne nødt til at genindmelde sessionen og sender en invitation eller OPDATERING igen. Denne opdatering skal sendes, inden halvdel af sessionen udløber timer ( 1800/2 = 900 sekunder = 15 minutter). Hvis der ikke modtages en opdateringsmeddelelse, afbrydes opkaldet.

Kontroller for sessionstimer i den indledende INVITATION. En opdatering (INVITE/ UPDATE) bør modtages, inden dette tidsrum udløber:
Brugertilføjet billede

Baseret på den indledende brugeragentklient/brugeragentserver (UAC/UAS) opdateret sessionen, hvor et af enhederne opdaterer sessionen, når den sender en invitation igen. Hvis genindlæseren er UAC, har initiativtageren for opkaldet ansvaret for at genindlæser sessionen. Hvis genindopdateringen er UAS, skal serveren genindfriske sessionen. Indsaml SIP-fejlfindingslogfilerne fra begge slutpunkter, og kontroller disse elementer:

Eksempel: Opkald foretaget fra part A til CUCM til part B. Hvis genindopdateringen er UAC på part A og UAS på part B:

1.     Part A skal sende invitationen/opdateringen igen til CUCM.
2.     CUCM skal sende en invitation/opdatering til part B igen.
3.     Part B modtager invitationen, der skal sendes igen, og svarer på denne meddelelse med en 200 OK.
4.     CUCM skal sende 200 OK til part A.

Hvis én enhed sender gen-INVITEr beskeden til CUCM, sender CUCM en invitation igen til den anden part. Hvis dette ikke modtages af den eksterne side, kan det dog skyldes nogle netværksenheder imellem. Det er meget muligt, at gen-INVITEr/svar ikke kommer til en af siderne på grund af SIP-inspektion eller netværksindstillinger.
Hvis enhederne ikke starter invitationen igen, kan det være et problem med enheden. Involvere Cisco Technical Assistance Center (TAC) for at undersøge yderligere.
 
På listen over ting, du skal prøve [hvis dette ikke allerede] er i området for avanceret config i området, skal du gå til Webex:
Slå SIP UDP/IX-filtertilstand til på [ikke standard]:
Brugertilføjet billedeOg marker også SIP-sessionens timere på VCS-e.

 
Vores standard er 1800s [15 minutter], hvilket er standard, og du vil også sørge for, at TCP-timeren på din Firewall også matcher her, men du kan gøre dette lidt for at se, om det også har en effekt på dine VCS.

Dette sker under Konfiguration > -protokoller > SIP:
Brugertilføjet billede

Bemærk, at sessionsopdateringsintervallet (sekunder) er indstillet til standardværdien. Du kan prøve 3600. Men det egentlige rod af problemet her er, når FW mener, at en session ikke længere er i brug [sag 1], når VCS faktisk mener, at det er ok, og at sessionen stadig er oppe, men ikke modtager en FIN/luk på denne session/port og forsøger at bruge den igen, og opkaldsmapperne. [sag 2] er FW lukker forbindelsen korrekt og sender en FIN/luk, og VCS optager en normal aflevering/clearing af opkald og opkaldet også. Modificering af sessionstimeren her kun kontroller, når VCS vil give op på en session, efter den ikke har modtaget nogen ACKs for enhver forsøgt kommunikation vedrørende status for opkaldet.
 
Det kan hjælpe os med at gøre problemet lidt bedre. Det er også muligt, at vi er nødt til at sænke denne værdi afhængigt af FW-indstillingen for denne timer.

Var denne artikel nyttig?