A Webex -értekezletre érkező videohívások kapcsolata 15 perc elteltével bontható

A CUCM/VCS-rendszergazdák áttekinthetik ezt az útmutatót, és megtalálhatják annak a problémának a megoldását, hogy a videóeszközök a Webex- Webex-értekezlet való csatlakozás után pontosan 15 perccel bontják a kapcsolatot.

PROBLÉMA
Amikor CUCM videóeszköz - hez, a hívás pontosan 15 perc múlva bontja a kapcsolatot.

FELHÍVÁS
Tekintse át az alábbi lépéseket:

  1. Nyissa meg a Cisco Unified Communications Manager (CM) felügyeletet.
  2. Kattintson a lehetőségre Rendszer elemre > Szolgáltatási paraméterek .
  3. Alatt Válassza a Kiszolgáló és szolgáltatás lehetőséget , a Szolgáltatás lehetőségre legördülőlista-mező válassza ki a lehetőséget Cisco Call Manager (aktív) :
Felhasználó által hozzáadott kép
  1. Keresse meg a SIP munkamenet lejárati időzítő :
Felhasználó által hozzáadott kép

A CUCM -hez regisztrált összes eszköz használja ezt az időzítőt. Amikor az eszköz egy másik távoli eszköz éppen hívást folytat, az egyik félnek frissítenie kell a munkamenetet, és újra MEGHÍVÓ vagy FRISSÍTÉS üzenetet kell küldenie. Ezt a frissítést a Munkamenet lejárta időzítőjének fele előtt el kell küldeni ( 1800/2 = 900 másodperc = 15 perc). Ha nem érkezett frissítési üzenet, a hívás megszakad.

Ellenőrizze a munkamenet-időzítőt a kezdeti INVITE-ben. A következő idő lejárta előtt meg kell érkeznie egy frissítésnek (MEGHÍVÓ/FRISSÍTÉS):
Felhasználó által hozzáadott kép

A kezdeti Felhasználói ügynök ügyfél/Felhasználói ügynök kiszolgáló (UAC/UAS) egyeztetés alapján az egyik eszköz frissíti a munkamenetet, amikor újra meghívást 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óit mindkét végpontról, és ellenőrizze az alábbi elemeket:

Példa : Hívás A féltől a CUCM felé B fél felé. Ha a frissítő UAC az A félnél és UAS a B félnél:

1.     Az A félnek el kell küldenie az újra HÍVÓ/FRISSÍTÉS üzenetet a CUCM-nek.
2.     A CUCM -nek ismételt MEGHÍVÓ/FRISSÍTÉS üzenetet kell küldenie a B félnek.
3.     B fél megkapja az ismételt MEGHÍVÓ üzenetet, és 200 OK-val válaszol az üzenetre.
4.     A CUCM -nek 200 OK -t kell kü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Ó üzenetet küld a másik félnek. Ha azonban ezt nem kapja meg a távoli oldal, akkor ennek az lehet az oka, hogy egyes hálózati eszközök vannak közöttük. Nagy a valószínűsége annak, hogy az újraINVITE/válasz nem érkezik meg az egyik oldalra a SIP ellenőrzés vagy a hálózati beállítások miatt.
Ha az eszközök nem kezdeményezik az ismételt MEGHÍVÓT, akkor az eszközzel lehet probléma. Vegye fel a kapcsolatot a Cisco Technical Assistance Center (TAC) vállalattal a további vizsgálat érdekében.
 
A kipróbálandó dolgok listáján [ha még nem tette volna meg] a Webex vezető zóna speciális konfigurációs területén:
Forgassa el a SIP UDP/IX szűrő mód hogy on [nem az alapértelmezett]:
Felhasználó által hozzáadott kép
És ellenőrizze a VCS-e SIP munkamenet-időzítőit is.
 
Az alapértelmezett beállításunk az 1800s [30 perc], ami szabványos, és ellenőriznie kell, hogy a tűzfalon lévő TCP -időzítő itt is egyezik-e, de ezt egy kicsit felpörgetheti, hogy megnézze, van-e hatással a tűzfalára VCS.

Ez alatt van Konfiguráció > Protokollok lehetőségre > SIP :
Felhasználó által hozzáadott kép

Ne feledje, a munkamenet-frissítési időköz (másodperc) az alapértelmezett érték van állítva. Esetleg próbáld ki a 3600-at. A probléma gyökere azonban az, amikor az FW úgy gondolja, hogy egy munkamenet már nincs használatban [1. eset], amikor a VCS valójában úgy gondolja, hogy ez rendben van, és a munkamenet még működik, de nem kap FIN/close üzenetet session/port, és megpróbálja újra használni, és a hívás megszűnik. [2. eset] az FW megfelelően lezárja a kapcsolatot, és küld egy FIN/close és a VCS rekordok egy normál hívás megszakadás/clearing, és a hívás is elhal. A munkamenet időzítő itt történő módosítása csak azt szabályozza, hogy a VCS mikor ad fel egy munkamenetet, miután az nem kapott ACK-t a hívás állapotával kapcsolatos kommunikációs kísérletekre.
 
Ez azonban segíthet a probléma pontosabb meghatározásában. Az is előfordulhat, 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 perccel szakadnak meg, a közös probléma az, hogy a hálózaton (tűzfal/útválasztó) konfigurált TCP -időtúllépés kisebb, mint a SIP munkamenet lejárati időzítője. A CallManager alapértelmezés szerint a SIP munkamenet lejárati időzítő beállítása 1800 másodperc.

Hasznos volt ez a cikk?