Mina videosamtal till videoenhetsaktiverade möten minskar efter 15 minuter (eller efter en viss tid)

Mina videosamtal till videoenhetsaktiverade möten minskar efter 15 minuter (eller efter en viss tid).

Videosamtalsanslutningar till Cisco Webex-videoenhetsaktiverade möten kopplas från efter 15 minuter.

SIP-samtal håller på att släppas efter ett anställt tidsintervall.

Anslutningar till videoenhetsaktiverade möten kopplas från efter 15 minuter.

Videosamtal sänks efter 15 minuter.

 

Orsak: När videosamtal kopplas från vid exakt 15 minuter är det vanliga problemet att TCP-timeouten som är konfigurerad på nätverket (brandväggar/routrar) är mindre än timern för SIP-sessionen upphör att gälla. Som standardinställning i CallManager är tidsräkningen för SIP-sessionen inställd på 1 800 sekunder.

Lösning:

Kontrollera följande:

  1. Öppna Cisco Unified Communications Manager (CM) administration.
  1. Klicka på Systemparametrar > tjänst.
  2. Under Välj server och tjänsti rutan Listruta väljer du Cisco samtalshanterare (aktiv):
Bild tillagd av användare
  1. Leta efter SIP-sessionens utgångstimer:
Bild tillagd av användare

Alla enheter som är registrerade till CUCM använder denna timer. När enheten är i ett samtal med en annan fjärrenhet, måste en av parterna uppdatera sessionen och skicka en ny INBJUDAN eller UPPDATERA. Denna uppdatering måste skickas före hälften av sessionens timer (1800/2 = 900 sekunder = 15 minuter). Om inget uppdateringsmeddelande tas emot kopplas samtalet bort.

Sök efter sessionstimer i den inledande INBJUDAN. En uppdatering (INVITE/UPDATE) bör tas emot innan denna tid går ut:
Bild tillagd av användare

Beroende på den ursprungliga användaragentklienten/användaragentservern (UAC/UAS) kommer en av enheterna att uppdatera mötet när den skickar en ny INBJUDAN. Om uppdateraren är UAC är det samtalets initierare som har ansvaret för att uppdatera mötet. Om uppdateringsservern är UAS måste servern uppdatera sessionen. Samla in SIP-felsökningsloggarna från båda slutpunkterna och markera dessa objekt:

Till exempel: Samtal från part A till CUCM till part B. Om uppdateraren är UAC på part A och UAS på part B:

1.     Part A måste skicka en ny inbjudan/uppdatering till CUCM.
2.     CUCM måste skicka en ny inbjudan/uppdatering till part B.
3.     Part B får den nya INBJUDAN och svarar på det meddelandet med ett 200 OK.
4.     CUCM måste skicka 200 OK till part A.

Om en enhet skickar meddelandet som skickas på nytt till CUCM skickar CUCM en ny INBJUDAN till den andra parten. Men om den här inte tas emot av fjärrsidan kan det vara på grund av att en del nätverksenheter används där mellan. Det är mycket möjligt att den nya INBJUDAN/svaret inte får någon av de bästa på grund av SIP-kontroll eller nätverksinställningar.
Om enheterna inte initierar den nya INBJUDAN kan det vara ett problem med enheten. Be om Ciscos tekniska hjälpcenter (TAC) för att utreda ytterligare.
 
På listan över saker att försöka med [om detta inte redan] i zonens avancerade konfigurationsområde går du till Webex:
Aktivera filterläget för SIP UDP/IX till [inte standard]:Och
Bild tillagd av användarekontrollera SIP-sessionstimererna på VCS-e också.

 
Vår standard är 1800s [15 minuter], som är standard och du kommer att se till att TCP-timern på din brandvägg fungerar här, men du kan få det här att bli lite bättre för att se om det påverkar din VCS.

Detta är under Konfiguration > protokoll > SIP:
Bild tillagd av användare

Observera att sessionens uppdateringsintervall (sekunder) är inställt till standardvärdet. Du kan testa 3600. Men den faktiska roten av problemet här är när FW tror att en session inte längre används [fall 1], när VCS faktiskt tycker att det är ok och att sessionen fortfarande är uppe men inte får någon FIN/stäng på det mötet/porten och försöker omv?rna om det och samtalet. [fall 2] är den FW som stänger anslutningen korrekt och skickar en FIN/stäng och VCS spelar in en normal samtalskoppling/rensning och samtalet fungerar också. Att ändra sessionstimer här styr bara när VCS ger upp en session efter att den inte har tagit emot några ACK:er för eventuellt försök till kommunikation angående samtalsstatusen.
 
Det kan hjälpa oss att precisera problemet lite bättre. Det är också möjligt att vi måste sänka detta värde beroende på FW-inställningen för den här timern.

Var den här artikeln användbar?