Előfordulhat, hogy egyes cikkek tartalma nem következetesen jelenik meg. Egy kis türelmet kérünk, amíg frissítjük az oldalunkat.
cross icon
A Webex-értekezletre indított videohívások kapcsolata 15 perc elteltével megszakad
list-menuVisszajelzé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:

  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:
Felhasználó által hozzáadott kép
  1. Keresd meg a SIP munkamenet lejárati idejét:
Felhasználó által hozzáadott kép

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:
Felhasználó által hozzáadott kép

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]:
Felhasználó által hozzáadott kép
É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ó:
Felhasználó által hozzáadott kép

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?
Hasznos volt ez a cikk?