Új hozzászólás Aktív témák

• #5365 crok Topikgazda FecoGee #5364

  Új Válasz 2013-12-25 12:19:42 #5365

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  crok

  Topikgazda

  válasz FecoGee #5364 üzenetére

  Inkább a call routing Meg a licenszelés... az undorító. A QOS hibákat kiszűrni
  nem nehéz, csak jelölésellenőrzés kell hop-by-hop, azt a routereken NetFlow-al,
  switcheken kézzel a portokon meg MLS Netflow-al meg lehet nézni gyorsan. Akkor
  cink ha nagyon sok a hop, elvesz némi időt, de ha ésszerűen csinálod (mint egy
  looptest-et E1/T1-en..) akkor hipp-hopp megvan a ludas. Voice-nál a tervezés ha
  jó és nem retardáltak változtatnak a design-on (értsd: nincs eszetlen telepítés,
  nincs eszetlen feature bevezetés, nincs "alátervezve" a sávszél, új eszközök
  bevezetése (pl. bővítés) esetén _mindenhol_ utánaállítják a sávszélességeket,
  et cetera) akkor nem kell hozzányúlni a dolgokhoz tán' sose.. de azért tudok én
  is érdekes eseteket felhozni mindig minden azzal kezdődik, hogy a "CUCM
  és minden kapcsolódó szerver már kétszer le lett ellenőrizve, tuti minden jó,
  tuti hálózati a probléma" Meg ami még cink: a sok call feature használata
  és bevezetése ész nélkül.. extension-öket hunt-groupba teszegetni, de mindet
  különbözőbe.. egyedül Callparking mellett nem configolni timeout-ot se meg
  limitálatlan retry hogy tuti elvesszen a hívás.. After hour call blocking-ban rossz
  patternt megadni jajjjdeimádtam. Overlay vonal esetén rosszul kiosztani az
  agent-ek közt a preference értékeket, így van, aki 100 hívást kap időegység alatt
  más meg 2-t ja, és emellé _nem_ letiltani a huntstop-ot, külön móka, a hívók
  azt hiszik hogy minden vonal foglalt, közben meg 30 agent várja a telefonokat,
  de max. 4 kap hívásokat, 26 egy darabot se Meg a PSTN Gatewayen analóg
  telefonok.. mikor az agent nem akarja, hogy hívást fogadjon és melléteszi a
  kézibeszélőt aztán sokáig nem csinál semmit de timer hiányában a VG nem
  szakítja meg az áramkört és sorban égnek ki az analóg végfokok Meg E1
  PSTN kapcsolat mellett arra rájönni, hogy te úgy tudod, hogy 30 B csatornád
  van 6 számmal, majd rájössz, hogy 4 szám a tied és persze hogy nem esik
  be hozzád hívás meg az se rossz, mikor 24 a max kimenő/bejövő B csatorna
  és sh isdn stat -al meglátod, hogy a szolgáltató letiltott 6-ot és ezért meg a
  megemelkedett hívásszám miatt kapnak az agent-ek a callcenterben busy
  signalt már a kézibeszélő felemelésekor. Persze mind-mind a network guynak
  van jelentve és ő is mondja meg hogy a-aa, nem network, hanem voice a téma
  és ittmegottmegamott kellett _volna_ megnéznetek.. csodás élmények
  [Szerk. I]
  Oh, mégegy ami eszembejut: IP telefonok voice mail gombja csak 12..15 sec
  múlva alszik ki miután a voice mail-t meghallgattad. Persze ez is network issue.
  Aztán mikor már én kérek a telefonokról call statisztikát (persze mobiltelefonnal
  fényképezettet kapok..) és nézem a jitter/loss értékeket hogy hátha van _valami_
  és rájövök, hogy a calltrace a CUCM-ről meg a képen látható idő a telefonon
  nem egyezik, mert a CUCM nincs NTP-vel szinkronban, ám a telefonok a TFTP
  szervernek használt VM-et használják NTP-re is.. és a CUCM a gombok
  beállításait NTP alapján szinkronizálja, tehát lehet, hogy te már a voice mailt
  meghallgattad és a CUCM meg is kapja a notification-t a voice mail szervertől
  hogy xyz sorszámú voice mail meg lett hallgatva, ám a CUCM csak utólag -
  mikor eléri azt az időpontot az órája - fogja a telefont is értesíteni Priceless..
  [Szerk. II]
  lol mégegy: Megnövekedett agent forgalom miatti CUCM memórianövekedés
  és swapolás miatti lassú call routing lejelentve network hibára, hogy egy-egy
  telefonbeszélgetés felépítése 6..8 másodpercbe is beletelik és biztos a call
  signaling csomagok jelölése miatt van ilyen delay - aztán annak aki ebben
  100% biztos magyarázd el, hogy a világban nincs olyan szolgáltatás ami
  ilyen nagy delay-t megeszik gond nélkül (értsd: a hívások felépülnek, a
  telefónia minőségével nincs gond) így a szerver lesz a ludas.. de neeem,
  hajtja az igazát, de amikor megnézi a CUCM VM-jét tátva marad a szája
  hogy 950%-osan átlagostól eltérő a hívásszám és a CPU 89%-on a swapo-
  lással van elfoglalva, a maradék meg call routing folyamat XD

Új hozzászólás Aktív témák