Hasznos volt ez a cikk?
Köszönjük visszajelzését.
A Webex-értekezletre indított videohívások kapcsolata 15 perc elteltével megszakad
Visszajelzés?A CUCM/VCS-rendszergazdák áttekinthetik ezt az útmutatót az azon probléma megoldásának lépéseiről, amely miatt a videoeszközök pontosan 15 perccel a Webex-értekezlethez való csatlakozás után leválnak.
PROBLÉMA
Amikor CUCM-regisztrációjú videoeszközzel csatlakozik egy Webex-értekezlethez, a hívás pontosan 15 percnél megszakad.
FELBONTÁS
Tekintse át az alábbi lépéseket:
- Nyissa meg a Cisco Unified Communications Manager (CM) adminisztrációt.
- Kattintson a System (Rendszer) > Service Parameters (Szervizparaméterek) elemre.
- 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:
- 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 nincs fogadott frissítési üzenet, a hívás megszakad.
Ellenőrizze a munkamenet időzítőt a kezdeti MEGHÍVÓBAN. Frissítés (MEGHÍVÁS/FRISSÍTÉS) érkezzen ezen idő lejárta előtt:
A kezdeti User Agent Client/User Agent Server (UAC/UAS) egyeztetés alapján az egyik eszköz frissíti a munkamenetet, amikor újra Meghívót KÜLD. 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 az alábbi elemeket:
Példa: Hívás az „A” féltől a CUCM-re a „B” félbe. Ha a frissítő UAC az „A” félen és UAS a „B” félen:
1. Az „A” félnek el kell küldenie az ismételt MEGHÍVÁST/FRISSÍTÉST a CUCM-nek.
2.A CUCM-nek újra meghívót/FRISSÍTÉST kell küldenie a B.
3. félnek. B fél kapja az ismételt MEGHÍVÁST, és 200 OK-val válaszol erre az üzenetre.
4.A CUCM 200 OK-t kell elküldenie az „A” félnek.
Ha az egyik eszköz az újra MEGHÍVÓ üzenetet küldi a CUCM-nek, a CUCM újra MEGHÍVÓT 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 lehetséges, hogy az ismételt MEGHÍVÁS/válasz a SIP-ellenőrzés vagy a hálózati beállítások miatt nem érkezik el egyik oldalra.
Ha az eszközök nem kezdeményezik az ÚJRA meghívást, probléma lehet az eszközzel. A Cisco Technikai Segítségnyújtási Központ (TAC) bevonása a további vizsgálatokba.
A [ha még nem tette meg] kipróbálandó dolgok listáján a Webexbe menő zóna speciális konfigurációs területén:
Kapcsolja be a SIP UDP/IX szűrőmódot erre: be [nem az alapértelmezett]:
És ellenőrizze a SIP munkamenet időzítőket a VCS-e-n is.
Az alapértelmezésünk az 1800-as [30 perc], ami szabványos, és itt is meg szeretné győződni arról, hogy a tűzfalon lévő TCP időzítő megfelel-e, de kicsit feldobhatja, hogy lássa, van-e hatással a VCS-re is.
Ez a Konfiguráció > Protokollok > SIP menüpont alatt található:
Ne feledje, hogy a munkamenet frissítési intervalluma (másodpercben) 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.
Segíthet azonban egy kicsit jobban meghatározni 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.
OK
Amikor a videohívások pontosan 15 percnél bontják a kapcsolatot, a gyakori probléma az, hogy a hálózaton (tűzfal/útválasztók) konfigurált TCP időtúllépés kevesebb, mint a SIP-munkamenet lejár időzítője. Alapértelmezés szerint a CallManager a SIP munkamenet lejárati időzítője 1800 másodpercre van beállítva.
Hasznos volt ez a cikk?
