Ok: Ha a videohívások pontosan 15 percnél szakadnak meg, a gyakori probléma az, hogy a hálózaton konfigurált TCP időtúllépés (tűzfal/útválasztók) kevesebb, mint a SIP munkamenet lejárati ideje. A CallManager alapértelmezés szerint 1800 másodpercre állítja a SIP munkamenet lejárati idejét.

Megoldás:

Ennek ellenőrzéséhez:

1. Nyissa meg a Cisco Unified Communications Manager (CM) adminisztrációt.

2. Kattintson a System (Rendszer) > Service Parameters (Szervizparaméterek) elemre.
3. A Select Server and Service (Kiszolgáló és szolgáltatás kiválasztása) legördülő listából válassza a Cisco Call Manager (Aktív) lehetőséget:

4. Keresd meg a SIP munkamenet lejárati idejét:

A CUCM-ben regisztrált összes eszköz ezt az időzítőt használja. Ha az eszköz egy másik távoli eszközzel hívásban van, az egyik félnek frissítenie kell a munkamenetet, és újra kell küldenie az adatokat, vagy FRISSÍTENIE kell azokat. Ezt a frissítést a munkamenet lejárati idejének fele előtt kell elküldeni (1800/2 = 900 másodperc = 15 perc). Ha nem érkezik frissítő üzenet, a hívás megszakad.

Ellenőrizze a munkamenet-időzítőt a kezdeti MEGHÍVÓBAN. Frissítést (MEGHÍVÁST / FRISSÍTÉST) kell kapnia, mielőtt ez az idő lejár:


Alapján a kezdeti User Agent Client /User Agent Server (UAC/UAS) tárgyalás, az egyik eszköz frissíti a munkamenet, amikor elküldi a Re-INVITE. Ha a frissítés UAC, a hívás kezdeményezője felelős a munkamenet frissítéséért. Ha a frissítés UAS, a kiszolgálónak frissítenie kell a munkamenetet. Gyűjtse össze a SIP hibakeresési naplókat mindkét végpontról, és ellenőrizze ezeket a tételeket:

Példa: Az A. fél által a CUCM-nek a B. félhez intézett hívás. Ha az emlékeztető az A. fél UAC és a B. fél UAS-e:

1.     Az „A” félnek el kell küldenie a re-INVITE/ FRISSÍTÉST a CUCM részére.
2.     A CUCM köteles újra elküldeni / FRISSÍTENI a B
3.     A B fél megkapja az újra-INVITE-et, és 200-as OK-val válaszol az üzenetre.
4.     A CUCM köteles 200 OK-t küldeni az "A" félnek.

Ha az egyik eszköz a re-INVITE üzenetet küldi a CUCM-nek, a CUCM egy re-INVITE üzenetet küld a másik félnek. Ha azonban ez nem érkezik meg a távoli oldalról, akkor ennek oka lehet néhány hálózati eszköz között. Nagyon valószínű, hogy az újra-INVITE/válasz nem jut el az egyik oldalra a SIPS ellenőrzése vagy a hálózati beállítások miatt.
Ha a készülékek nem indítják el az újraindítást, akkor probléma lehet a készülékkel. A Cisco Technikai Segítségnyújtási Központ (TAC) bevonása a további vizsgálatokba.
 
A Webex felé haladó zóna speciális konfigurációs területén [ha ez még nem történt meg] kipróbálandó dolgok listáján:
Kapcsolja a SIP UDP/IX szűrőmódot [nem az alapértelmezett] állásba:

És ellenőrizze a VCS-e SIP munkamenet-időzítőit is.
 
Az alapértelmezésünk 1800s [15 perc], ami alapfelszereltség, és érdemes meggyőződni arról, hogy a tűzfalon található TCP időzítő is egyezik, de ezt egy kicsit feljebb tehetjük, hogy lássuk, van-e hatása a VCS-re is.

Ez a Konfiguráció > Protokollok > SIP:


Megjegyzés: a Munkamenet-frissítési időköz (másodperc) az alapértelmezett értékre van állítva. Megpróbálhatnád a 3600-at. De a probléma gyökere itt az, amikor az FW úgy gondolja, hogy egy munkamenet már nincs használatban [1. eset], amikor a VCS valóban úgy gondolja, hogy ez rendben van, és a munkamenet még mindig működik, de nem kap FIN/close értéket az adott munkamenetre/portra, és megpróbálja újra felhasználni, és a hívás leáll. [2. eset] az FW megfelelően lezárja a kapcsolatot és FIN/close üzenetet küld, és a VCS rögzít egy normál hívásesést/törlést, és a hívás is leáll. A munkamenet-időzítő itt történő módosítása csak azt szabályozza, hogy a VCS mikor adja fel a munkamenetet, miután nem kapott semmilyen ACK-t a hívás állapotával kapcsolatos bármilyen kommunikációs kísérletért.
 
Ez segíthet nekünk, hogy egy kicsit jobban meghatározzuk a problémát. Az is lehetséges, hogy csökkentenünk kell ezt az értéket az időzítő FW beállításától függően.