Mijn videogesprekken naar vergaderingen waar videoapparaat is ingeschakeld, vallen na 15 minuten (of na een specifieke tijd) weg.

Mijn videogesprekken naar vergaderingen waar videoapparaat is ingeschakeld, vallen na 15 minuten (of na een bepaalde tijd) weg.

Verbinding met videogesprekken met vergaderingen Cisco Webex vergaderingen ingeschakeld voor videoapparaat worden na 15 minuten verbroken.

SIP-gesprekken worden gepauzeerd na een ingesteld tijdsinterval.

Verbindingen met vergaderingen ingeschakeld voor video-apparaten worden na 15 minuten verbroken.

Videogesprekken worden na 15 minuten weer oproept.

 

Oorzaak: Wanneer de verbinding voor videogesprekken op exact 15 minuten wordt verbroken, is het algemene probleem de TCP-time-out die is geconfigureerd op het netwerk (firewall/routers) minder dan de timer voor de SIP-sessie verloopt. Standaard is de SIP-sessie timer voor het verlopen van de SIP-sessie ingesteld op 1800 seconden.

Oplossing:

Dit verifiëren:

  1. Open Cisco Unified Communications Manager (CM)-beheer.
  1. Klik op Systeem > serviceparameters.
  2. Selecteer in het vak Serviceservice vervolgkeuzelijst De optie Cisco Gespreksbeheer (actief):
Door een gebruiker toegevoegde afbeelding
  1. Zoek naar de SIP-sessie timer verloopt:
Door een gebruiker toegevoegde afbeelding

Alle apparaten die bij CUCM zijn geregistreerd, gebruiken deze timer. Wanneer het apparaat in gesprek is met een ander extern apparaat, moet een van de partijen de sessie vernieuwen en een nieuwe UITNODIGING of update sturen. Deze vernieuwing moet worden verzonden voordat de helft van de sessie timer verloopt (1800/2 = 900 seconden = 15 minuten). Als er geen vernieuwbericht wordt ontvangen, wordt de verbinding met het gesprek verbroken.

Controleer of de sessietimer is in de eerste UITNODIGING. Een vernieuwing (UITNODIGEN/UPDATE) moet worden ontvangen voordat deze tijd verloopt:
Door een gebruiker toegevoegde afbeelding

op basis van de initiële User Agent Client-client/User Agent Server-onderhandeling (UAC/UAS) vernieuwt een van de apparaten de sessie wanneer er een nieuwe UITNODIGING wordt verzendt. Als de vernieuwer UAC is, heeft de initiator van het gesprek de verantwoordelijkheid om de sessie te vernieuwen. Als de vernieuwer UAS is, moet de server de sessie vernieuwen. Verzamel de SIP-foutopsporingslogboeken van beide eindpunten en controleer de volgende items:

Voorbeeld: Oproep van partij A naar CUCM naar partij B. Als de ververser UAC is bij partij A en UAS op partij B:

1.     Partij A moet de nieuwe UITNODIGING/UPDATE verzenden naar de CUCM.
2.     CUCM moet een nieuwe UITNODIGING/UPDATE verzenden naar partij B.
3.     Partij B ontvangt de nieuwe INVITE en reageert op dat bericht met een 200 OK.
4.     CUCM moet 200 OK verzenden naar partij A.

Als een apparaat het nieuwe UITNODIGINGsbericht naar de CUCM verzendt, stuurt CUCM een nieuwe UITNODIGING naar de andere partij. Als dit echter niet wordt ontvangen door de externe kant, kan dit worden veroorzaakt door sommige netwerkapparaten tussen de apparaten. Het is hoogst mogelijk dat de nieuwe INVITE/respons niet aan een van de kanten komt door instellingen voor SIP-inspectie of netwerk.
Als de apparaten de nieuwe INVITE niet starten, kan er een probleem zijn met het apparaat. U hebt Cisco Technical Assistance Center (TAC) nodig om verder te onderzoeken.
 
In de lijst met dingen die u moet proberen [als dit nog niet is] in het geavanceerde configuratiegebied van de zone die naar Webex gaat:
Schakel de filtermodus SIP UDP/IX in op [niet de standaard]:
Door een gebruiker toegevoegde afbeelding
En controleer ook de SIP-sessie timers op VCS-e.
 
Onze standaard is 1800s [15 minuten], wat standaard is en u moet ervoor zorgen dat de TCP-timer op uw firewall ook hier overeenkomt, maar u kunt dit ook wat doen om te zien of deze ook invloed heeft op uw VCS.

Dit is onder Configuratie > Protocollen > SIP:
Door een gebruiker toegevoegde afbeelding

Houd er rekening mee dat het interval voor het vernieuwen van de sessie (seconden) is ingesteld op de standaardwaarde. Probeer 3600 misschien. De werkelijke kern van het probleem is hier wanneer FW denkt dat een sessie niet meer in gebruik is [geval 1], wanneer VCS echt denkt dat het ok is en dat de sessie nog steeds aan de orde is maar geen FIN/close ontvangt op die sessie/poort en probeert deze opnieuw te gebruiken en het gesprek overgaat. [case 2] is dat de FW de verbinding correct sluit en een FIN/close verzendt en VCS een normale gespreks vervolg-/wissen opeenroep opeenroept. Het gesprek gaat ook af. Als u de sessietimer hier wijzigt, bepaalt u alleen wanneer VCS de sessie niet meer ontvangt nadat deze geen ACL's heeft ontvangen voor poging tot communicatie over de status van het gesprek.
 
Het kan ons helpen om het probleem iets beter te maken. Het is ook mogelijk dat we deze waarde moeten verlagen afhankelijk van de FW-instelling voor deze timer.
Vond u dit artikel nuttig?