Alközpont.net

Idén januártól nem csak “vasat” hanem a hazai vezető szolgáltató termékeit is kínáljuk. A bejegyzésből kiderül, hogy miért.

Azt tapasztaltuk, hogy ahol elég igény és pénz van Cisco szintű eszközökre ott valószínűleg magas színvonalú internet és telefon szolgáltatásra is szükség lesz. Telepítés és értékesítési szempontból pedig szerencsés ezt a két dolgot egyen kezelni így legalább nem fordulhat elő olyan, hogy ügyfelünk megrendel valamit amit aztán csak sok munka árán tudunk illeszteni.

Mely termékek értékesítésében veszünk rész?:

IP Sound+ – egységes hang, adat és internet kapcsolat akár több telephelyes cégek részére. Az árazás elég piaci, a kiépítés ideje vállalható, a szolgáltatás pedig elég stabil. Az ár tartalmaz Cisco routert is! Részletek

Szerverhoszting szolgáltatás – az infoparkban lévő adatközpontjuk önmagáért beszél. Ezt a szolgáltatást elsősorban a meglévő ügyfeleknek hoztuk be. A tapasztalat azt mutatja hogy a több tízezer szervert hosztoló ügyfélből évente kevesebb mint 10 mondja fel a szolgáltatást! Részletek

A többi termék is nagyon klassz de elsősorban ebben a kettőben látunk jelenleg olyan értéket ami mögé érdemes odaálljunk. Minden termékről rövidesen jelentkezünk közös webkonferenicával!

Viktor

Korábban már írtam egy cikket hasonló témába. Nem titok, a Cisco és az Opensource közti különbségről beszélek. Miért hozom szóba a témát? Mert a napokban történtek dolgok, melyek kiemelik a különbséget a két technológia között.

A legfontosabb dolog, amit az opensource rendszerekről tudni kell: az alapértelmezett beállítások általában működőképesek, de általában semmi biztonságot nem adnak. A Gencom esetében mi mindig felkonfiguráljuk a rendszert, hogy az biztonságos legyen. Másrészt az ilyen rendszerek mindig tartalmaznak hibákat. Amennyiben szervizszolgáltatással rendelkezik egy ügyfelünk frissítéseink együtt a frissebb biztonsági beállításainkat is telepítjük.

Előfordult az elmúlt egy hétben többször is, hogy a karbantartási szerződéssel nem rendelkező egykori ügyfeleink jelentkeztek, hogy valami nem stimmel a központtal. Annyira egyszerre érkezett több bejelentés, hogy sejtettük, valami nem stimmel. Azonnal kijavítottuk a hibát, befoltoztuk a rést. Az asterisk.org/security oldalon, és máshol a neten sem találtunk arra utaló információt, hogy bármi új biztonsági résre bukkantak volna a programozók. A lényeg itt az, hogy az interneten továbbra sincs megoldás erre a problémára. Mi megoldottuk.

A Cisco mint márka pedig egészen más. Ott egyszerűen ilyenre gondolni sem kell.A Cisco híres a biztonságáról.  Kérünk mindenkit, hogy csak akkor kezdjen éles VoIP rendszert üzemelni, ha nagyon ért hozzá, mi ugyanis ilyen rendszereken nem tudunk segíteni. Köszönjük!

Ebben a bejegyzésben senkit nem szeretnék meggyőzni arról, hogy most azonnal váltson IP telefóniára. Viszont aki már döntött, javaslok pár szempontot, hogy segítsen dönteni, hogy egy adott árajánlatot elfogadjon -e vagy nem.

Miután ajánlatot kért,

• és nem keresték meg telefonon, csak egy írott ajánlatot küldtek, felejtse el a céget. Egy IP telefóniára állás komplex folyamat.
• de nem kérdezték öntől milyen a jelenlegi számítógépes és telefonos hálózata, gondolja meg, lehet, hogy már jópár szükséges eszköze megvan. Ha van márVoIPos eszköze ellenőrizze a kompatibilitást. A legtöbb ilyen eszköz szabványos protokollt használ.
• de az ajánlatban nem szól semmi a terméktámogatásról, garanciáról, nem javasoljuk az ajánlat elfogadását.
• amennyiben SIP szolgáltató mellett döntött, ellenőrizze internetkapcsolata teljesítményét.
• ha távoli mellék van tervbe véve, akkor szükség van fix IP címre (esetleg dyndns szolgáltatásra).

A listát sorolhatnám még tovább…

Az előző bejegyzésemben leírtam, mi a legfőbb előnye a Gencom VoIP-nak, most azonban úgy döntöttem leírom, miként is készültek ezek a rendszerek. Időrendi sorrendben haladok, először a Gencom VoIP PBX-ről, majd a miniről írok.

A 2008 szeptemberében mint Linux szakértő kerültem a Glosterhez. Akkor még azt se gondoltam át, hogy telekomos céghez jövök. Azóta is tartó rohanó életmódomnak köszönhetően kiöltözve nem voltam, és még el is késtem. A cégnél akkor már volt gencom néven voip megoldás, ezt kell átvennem. Az Asteriskről akkoriban csak hírből halottam, tudomásom mindösszesen annyi volt, hogy rengeteg .conf fájl szükséges a beállításához.

• Gencom VoIP PBX:

Az “állásinterjú” után bizonyításképp egy Digium Assterisk Business Edition-t kellett telepítenem, így visszagondolva nem volt nagy kihívás.  Aztán majdnem egy hónapon át nem beszéltünk. Aztán hirtelen sürgős lett a dolog, mikor elődöm végleg távozott. Határozottan emlékszem arra az éjszakára, amikor minden addigi céges belső fejlesztésről telefonon át mondott el az elődöm mindent. Ez időtájt jelent meg az Asterisk NOW!, ezen a vonalon indultunk el. Akkoriban még aranyélet volt, fél éven át lehetett kapni azonos hardverkonfigurációt. Viszonylag hamar belejöttem a dologba, a hardverváltozások követése céljából telepítőlemez képfájlt csináltam, megjavítottam sok nem működő funkciót, köztük az IP Faxot. hangrögzítést. Magyarosítottam a beépített hangfájlokat, amennyire lehetett. A sok ezer revíziókból kerestem és találtam meg az optimális asterisk és linux-kernel verziót.

Közben folyamatosan telepítettük a rendszereket. Időközben egyre jobban épültem be a cégbe, miután egy nem napon barnult illető ellopta magán jellegű mobilomat, kaptam cégeset. Lassan a cég mindennapi életében is részt vettem, ahogy azt időm engedte, sőt manapság mint látjátok a marketingbe is besegítek Viktornak.

• Gencom-mini:

Valamely hosszú nap után jutott eszembe, hogy az akkori otthoni routerem is esetleg alkalmas lehet voip telefonközpontnak. Bár teljesítménye kisebb, de jóval olcsóbb is. Majdnem le is tettem a témáról, mikor eszembe jutott, dehát nincs benne rendes kártyahely, ISDN és analóg oldali bővítésre. Ekkor jutott eszembe, ez IP telefónia! Ekkor már jól értettem a dologhoz, tudtam, hogy a hívásoknál a hang adatfolyammal tulajdonképp ennek az eszköznek semmi dolga, így gyakorlatilag elhárult a rendszer teljesítményére vonatkozó probléma. Az érdekes rész itt kezdődött. Egy olyan grafikus felületet kellett keresni, ami rengeteg konfigurálási opciót ad, nem túl bonyolult a kis hardver számára, és könnyen testere szabható.

Az Asterisk GUI akkori legrissebb, 2.0-ás változata mellett döntöttem, ugyanis annak a logikája javascriptben van írva, ami kliens oldali, így a terhet a konfiguráló személy böngészőjére helyezi. Túl azon, hogy minden egyes opciót kipróbáltam, az egészet lefordítottam magyarra, kiszíneztem, még új funkciókkal is bővítettem. Ezek nagyobbik fele maga a hardverre irányul, mint router (DHCP, WiFi, újraindítás…) de került bele új funkció is, mint a hívásrögzítés, vagy a Cisco telefonok támogatása, mely egy rendkívül összetett feladta volt, mert tftp kiszolgáló kell hozzá, úgy hogy csak akkor csücsüljön a memóriában, ha tényleg szükség van rá, sőt ezt a kiszolgálót dhcp-vel hirdetni kell. Ezek mellett a konfigurációs felületnek xml nyelvű konfigurációs fájlokat kell generálnia. Erre a termékre rendkívül büszke vagyok, nem kis alkotás volt.

Időközben azóta már a jócskán a Cisco irányába haladott a cég, mely teljesen más közönséget céloz, de egyenlőre ezek a “régi “termékek továbbra is megtalálhatóak kínálatunkban. Aki volt tegnap webkonferencián tudja, hogy a Cisco új IP telefon sorozatot mutat be, mely teljesen átértelmezi az IP telefonok lényegét. Az IP telefon mint vékonykliens sokminden másra is alkalmas lehet, ez esetben a Cisco többek között az mp3 lejátszó, és a bluetooth headsetek támogatása mellett döntött. Az XML alkalmazások támogatása továbbra is nagyrészben megmarad.

Én pedig teszem a dolgom, mikor mit kell csinálni, megpróbálkozom vele.

A Tisztelt Olvasóban jogosan merül fel a kérdés, hogy miért árulunk mi Asterisk, tehát ingyenes terméket mi, mikor annyi jó kész megoldás található az interneten? Gondolok én itt a Trixboxra, az Asterisk NOW!-ra és hasonló projektekre. Elmagyarázzuk!

Írhatnám válaszként azt is, hogy ha egy informatikus egy ilyen rendszert feltelepített, és ránéz a kezelőfelületére azt se tudja, hova nyúljon. De ezzel egyrészt nem mondanék igazat, másrészt mint minden mást, ezt is el lehet sajátítani (persze kérdés érdemes -e).

Azt is írhatnám, hogy ehhez terméktámogatás jár, ami részben igaz. Azért csak részben, mert ezt mint szolgáltatás lehet külön mellé vásárolni, igaz a telepítés mellé jár egy kezdeti konfiguráció felállítása.

Az igazi okok a következőek:

• Ezek a rendszerek akárhogy is nézzük nem 100%-ig teszteltek.
• Itt jön be a mi gyakorlatiasságunk. A saját rendszerünket mi ismerjük, tudjuk mire képes, és mit hol kell beállítani.
• Perifériák (Analóg telefonadapter, GSM adapter, és maguk az IP telefonok) csatlakoznak a rendszerhez. Ezek beállításait, és kompatibilitását ismerjük. Ajánlatban csak olyan eszközöket ajánlunk, melyek biztosan működnek a rendszerrel.
• A sok éven át tartó tapasztalatoknak, és fejlesztéseknek köszönhetően rengeteg funkciót megvalósítottunk, vagy megjavítottunk (pl.: fax-email átjáró)

Amire próbálok utalni az az, hogy gyakorlatunk van benne, és hogy a telefónia külön szakma, nem erőszakolható rá az informatikusra (persze örülünk, ha együttműködik velünk).

A fentebb leírtak főleg a nagobb rendszerünkre igaz (Gencom VOIP PBX). A kisebb rendszerünk hez (Gencom-mini) hasonlót sem lehet találni az interneten. Ennek a rendszernek sok előnye van: a teljesen hangtalan működés, kis méret, és energiatakarékosság mellett meg merjük kockáztatni, hogy a piacon jelenleg ez a legolcsóbb kereskedelmi forgalomban kapható IP telefonközpont. Ha jól tudom a központ magában 110 lepedő magasságában van, várjuk a hozzászólásokat, ha esetleg valaki lát valahol olcsóbban.

Kérek minden rendszergazdát, aki úgy gondolta, hogy ő megoldja open-source módon magában ezt a kérdést, nehogy már pénzért adjunk neki valamit ami ingyenes, hogy fontolja előtte meg a fentebb írtakat, elsősorban a saját érdekében.

Zárszóképp megosztanák egy rövid történetet az Olvasókkal: Egyik ügyfelünk nemrégiben kitalálta, hogy egy Trixbox alapú rendszert megpróbál összerakni. Sok óra hosszas munka, próbálgatás, szenvedés után (pl.: nehezen jött rá, hogy a GSM adapter helyezendő SIM kártyáról ki kell kapcsolni előtte a PIN kód kérést) elégedetten hátradőlt, hogy vannak mellékek, és a fővonalak (itt jegyezném meg, hogy ez eddig semmi, amit egy ilyen rendszerrel meg lehet oldani), majd másnap feltörték a gépet, és sokszázezer forintos telefonszámlát csináltak a fővonalakon. Legyen ez egy elrettentő példa.

Köszönöm a figyelmeteket, legyetek ésszel ebben a témában.

Ha minden hálózat tökéletes lenne, sosem lenne benne hiba, avállalatok nem tartanának informatikusat, csak a hálózat létesítésének ideléjére. Ebben a bejegyzésben azt nézzük át röviden, milyen eleveket érdemes szem előtt tartani, mikor hibát kell keresnünk, és megnézünk pár példát is.

Az én tapasztalatom az, hogy a legjobb előre eltervezett folyamatábra, workflow szerint végigmenni egy adott problémán. Tipikus probléma lenne, ha egy hibás számítógép esetét vizsgálnák meg, ezért inkább egy működésképtelen IP telefonét vegyük át, mint példa. Tehát kapok egy belsős e-mail értesítést, hogy a 4. emeleten a 245-ös mellék nem működik. Hogyan állok ehhez a problémához:

• Az üzenet most kaptam nemrég, tehát a hiba “friss”. Átgondolom volt -e valami módosítás, programozás azon a melléken a közelmúltan.
• Megfontolom, hogy a többi telefon működik -e. Én fel  tudom hívni magamat az asztali készülékről, tehát a hiba valószínűleg nem a telefonközpontban lesz.
• Ha már a saját telefonomat nyomkodom, megvizsgálom mi történik, ha felhívom a 245-ös melléket. Semmi, elbont a hívás, tehát tényleg rossz a mellék.
• Mivel IP alapú a telefonközpont, és én úgyis itt ülök a gépem előtt, sőt, még az IP telefóniához is értek, megnézem, hogy a központban nem lett -e semmi elállítva arra a mellékre specifikusan.
• A szerverszoba ott van mellettem, már azon gondolkozom, hogy megnézzem a switchen, hogy linkel -e az a végpont rendesen, majd hamar lebeszélem magam: ha nem linkelne, akkor a telefonra felfűzött PC-ről sem tudott volna nekem e-mailt küldeni, másrészt ezt megnézhetném a menedzselhető switch felületén, harmadrészt, még ha nem is linkelne, a szerverszoba itt van mellettem, és ott nem járt senki azóta, tehát a hiba a zsínór másik végén van.

Lusta informatikus vagyok, de nincs mit  tenni, nem jellemző, hogy a készülékek megjavulnak magától, ezért kikászálódom kényelmes bőrfotelemből, és felmászok a negyedikre. Fontos, hogy megnyugtassam a kollegát, és lássa, hogy törődöm a problémájával. De azért magam is ellenőrzöm, hogy tényleg nem lehet telefonálni, vagy csak szegény user szeretne valamit úgy csinálni, ahogy nem lehet.

Érdemes ettől a ponttól kezdve, most hogy a logikus g ondolkodás megvolt, egy betanult módszert követni: a más sokszor említett OSI modell rétegeit aqlulról felfelé vizsgálni, működés szempontjából:

1. A hardveres kapcsolat megfelelő -e. A vezeték nem törött (remek kábelteszterek vannak). A link LED-ek világítanak -e. Egyáltalán van -e tápellátás.
2. A switchek működnek -e. Ha klasszikus switchről beszélünk, akkor más eszközök mennek -e rajta, ha menedzselhetőről, akkor megfelelő -e a portkonfiguráció (a másikportot kipróbálni itt sem árt, sőt, egyszerűbb is lehet, de hibaelhárírás tekintetében mindenképp éredemes a konfigurációt is megvizsgálni).
3. A router működik -e. Kap -e az eszköz IP címet, ha statikus, akkor megfelelő hálózatból van -e, és nincs -e ütközés. Tesztelés céljára a ping parancs való.
4. Szállítási layer, itt is a routerek illetve tűzfalak és átjárók konfigurációjában lehet hiba. A VoIP rengeteg UDP portot igényel a felsőbb tartományból, az 5060 vagy 2000-es TCP-n, és esetleg 69-es TFTP-n kívül.
5. Ide általában én a SIP/SCCP regisztrációt/híváskezdeményezést szoktam sorolni. A hálózahoz ennek már sok köze nincsen, csak a két végponthoz, a központhoz, és a telefonhoz.
6. Adattitkosítás. Itt esetleg a VPN át dolgozó távoli munkatársak jöhetnek szóba.
7. Azonosítás. A SIP regisztrációhoz megfelelő a jelszó? A hívott számnak kéne egyáltalán működnie? Megjelenés. Mit ír ki a készülék kijelzője, és mit nem.

Jellemzően én azt vallom, hogyha az első, logikus felépítésű részben nem sikerül az embernek megoldani VoIP témában a gondot, de legalábbis azonosítania azt, de meggyőződött a hiba létezéséről, akkor érdemes szakembert, például minket értesítenie. Ekkor rendelkezik már elegendő információval a szakember számára a hiba részleteivel kapcsolatban.

Sokan kérdezik tőlem, mitől jobb a Cisco mint a többi? Meglepő módon rengetegen gondolják, hogy a márkaneven és megbízhatóságon kívül semmiben. Ezt mindjárt meg is cáfolom, és csak egy pár egyszerű hálózatos példát mutatok, hogy mivel tud többet egy Cisco eszköz, mint egy Linksys, D-Link  és egyéb SOHO  (Small Office, Home Office) eszköz.

Nem rabolom drága időtöket, íme egy példa:

Cisco 850 Router

A Cisco 800 Series routerek kissebbik modelljei méretben és külső megjelenésben a fém háztól eltekintve erősen hasonlítanak a tipikus ilyen SOHO eszközökre. De hol is van itt a nagy külömbség? A tudásban. És érdekes módon nem látszik. Első gondolata az emberenek a: “Mért szenvednék a parancssoros felülettel ennyi pénzért?”. A válasz a belső felépítésben rejlik. Ha hátulról nézzük, ugyanúgy

• 5 ethernet (sőt, valamelyiken csak 4) port található, de ha a hardware felől közelítünk, mindegyik külön hálózati interfész, ha úgy tetszik NIC (Network Interface Card). Hogy mit értek ez alatt?
• Mindegyik rendelkezhet saját hálózati beállítással, mindegyik kezelhet akár egy egész alhálózatot, külön külön, sőt kiválaszthatjuk, melyik NAToljon, melyik kérjen DHCP-n IP címet, és akár frissítsen egy DynDNS címet. A Cisco egyedi, szupertitkos
• VPN megoldásáról nem is beszélve (ez a termék például tökéletesen alkalmas távoli telephelyekre).

Routerek

Miért sokkal olcsóbb a SOHO az üzleti routerhez képest?

Ezzel szemben a SOHO eszközök úgy épülnek fel, hogy az operációs rendszer felé (ami mint már tudjuk, általában valami kis linux) kettő vagy három “hálózati kártya” látható, egy az internet (vagy uplink) oldal felé néz, tipikusan a NAT egyik oldalán, a másik a helyi hálózat felé, esetleg a WLAN külön szokott lenni. Hogy van akkor rajta mégis 4 RJ-45-ös csatlakozó a hátulján? Hát elé tesznek, egybe építik, a létező legolcsóbb kapcsolóval (switchel) jobb esetben, rosszabb esetben egy hubbal, amről már tudjuk, hogy osztott buszos ethernetet hoz létre. Ennek a hátrányait  bizonyára már mindenki tudja:

• egy nagy collision domain (ütközési tartomány),
• CSMA/CD algoritmus,
• lassú sebesség. De még ha switch van benne, akkor is meg van kötve a kezünk konfiguráció tekintetében.

Miért drágább egy üzleti router / switch?

A Cisco switchek azon kívül, hogy

• menedzselhetőek, megadható nekik interfészenként pár opció, mint például: biztonságtechnikailag fontos lehet az RJ-45-ös portokon csak bizonyos MAC címeket engedélyezni. Lehetséges,
• letiltani és engedélyezni portokat.
• Sávszélesség és duplex beállításokat megadni, QOSt programozni.

A titok a VLAN-ban rejlik

Sorolhatnám még a hasonló apróságokat, de én inkább egyet kiemelnék: Az úgynevezett VLAN kezelés. Erre persze nem mindegyik Cisco eszköz képes, viszont nincs más gyártónak olyan eszköze, ami ilyen okos lenne. A funkció lényege, és egyben végeredménye, hogy egyetlen ethernet kábelen több alhálózatot préselhetünk át, de nem akárhogy DHCP-vel, BOOTP-vel és egyebekkel, sőt, a switchen még úgyszintén portokon lehet állítani, hogy mihez férhet hozzá, és mihez nem.

Hirtelen ezeket a dolgokat gondoltam a legfontosabbnak, de még van sok más apróság, amiben funkcionalitás tekintetében is több egy Cisco a többinél. Remélem nagyjából megértettétek amit írtam, de ha nem az sem baj, erre vagyunk mi.

Aki kicsit is foglakozott már informatikával tudja, mért jó a moduláris felépítés. Könnyebben lehet hibát keresni, egyszerűbben lehet javítani, és könnyű további kiegészítőket készíteni. Ahogy azt említettem a korábbi bejegyzésemben, az IP kommunikáció meglehetősen élesen elválasztható részekre (rétegekre) bomlik. Ha telefonközpontot vásárolunk, elvárás lehet ugyanez.

Hogyan is néz ez ki nálunk?

Van a Gencom termékünk. Az egész egy CentOS Linuxon alapul, ami nem sokat jelent, mert a csomagkezelőt nem nagyon használjuk. Grafikus kezelőfelület (X) nincs. A központot webes felületen át érjük el. Van egy kiszemelt stabil kernelünk, ez  vezérli a hálózatot, akár a routolást. Ezt mondhatnánk alapszintnek, és ez az a szint, ami az OSI második és harmadik rétegét fedi le. Ennél eggyel magasabb szinten ketyeg egy Asterisk, szintén egy kiszemelt stabil változat, az 1.4.x-es sorozatból. Ez is teljesen moduláris felépítésű, megfeleltethető az OSI ötödik és hatodik rétegének. Továbbá van egy Apache webszerver php-vel, ami az Asterisk konfigurációs fájljait írja, illtve Berkley Socketen át kommunikál az Asterisk API-val, és jórészt a konfiguráció érvénybeléptetése érdekében újraolvastatja az Asteriskkel a frissített konfigurációs fájlokat. Ő szolgáltatja a megjelenítési rétegnek megfelelő funkciókat, illetve tartozik még ide egy MySQL adatbázis szerver, ami a híváslistát (CDR – Call Detail Records) tárolja, ezt az Asterisk írja (asterisk-addons csomag), de a php-s webes felületen lekérdezhető.

Ezzel szemben a Gencom mini csak kevés dologban különbözik: a 2.4-es szériából teljesen natív kernelje van, amit firmware formájában létezik. A hívásnaplót natív szöveges fájlban (csv – comma separated values – vesszővel tagolt értékek) tárolja a rendszer, hogy ne egye a memóriát az SQL. A webes felület a kliensoldali Javascript-en alapul, így a processzort se terheli túl. Az Asterisk is kicsit kevesebb modullal fut rajta.

Érdekes, a Cisco tananyagok tele vannak elméletekkel, modellekkel mint az OSI, TCP/IP, mégis a termékeik felépítéséről nem sokat beszélnek, sokkal inkább annak konfigurációjára összpontosítanak. Pedig az UC500-as sorozat bármennyire is integrált megoldás, mégis részekből áll. Aki a hálózati részben otthon van, az ismeri a különböző bővítőkártyákat amit a Cisco routerkbe leht tenni. Az UC is ilyenekből áll, csak egybeépítve. A hardver adott, az operációs rendszer elég egyedi. Az IOS (Internetwork Operating System) a Cisco saját terméke, ez a Unix adja a rendszer lelkét itt is. Ehhez jön hozzá a CallManager Express, illetve a Unity Express. Érdekes módon bár ezek egybe vannak építve, mégis programozáskor kiderül, hogy a Unity Express-t például egy másik IP címen érjük el.

Megközelíthetjük a Cisco esetében a témát kicsit hardveresebb szempontból is. A készülékben van rengeteg féle-fajta memória, és nem egyszerű átlátni a dolgot. Alapvetően az nvram az, ami az indítóregisztert tárolja, illetve az indításkor betöltendő konfigurációt. Az operációs rendszer, mint képfájl létezik a készülékbe cseréléhető nyíláson behelyezett CompactFlash memóriakártyán. Ez indításkor kibontódik a ramba (ha jól számolom, ez már a harmadik memória), sőt ide kerül egy másolat az indítókonfiguráció, amit tetszőlegesen szerkeszthetünk, a futási idő alatt, a változások azonnal érvénybe is lépnek. A CallManager Express szoftver, a maga kis minimális webes felületével úgyszintén a flash kártyán található. A Unity Express viszont a hardveren belül is szeparálva van, komplett másik Unix. A parancsok és a működés viszont nagyon hasonló.

Ezek után mondhatja nekem bárki, hogy egyszerű termék az UC500-as sorozat, nem az. Írtam már korábban is, hogy aki Cisco-ra adja a fejét az ne azért tegye, mert egyszerű és működik. Működik egy bonyolult konfiguráció után. Még a Cisco-n belül is a VoIP teljesen külön világ, nem csoda, hogy külön képzés a Cisco Voice Specialist.

A régi telefonközpontokon mindig előhívószámmal kellet kifelé irányba tárcsázni, ráadásul most változtak a mobilhívások módszere is. Mitől függ, és hogyan működik ez a dolog? Erre keressük a választ

Nem meglepő, hogy ez az opció kizárólagosan a konfiguráción műlik. A Cisco rendszereknél egy ’secondary-dial-tone’-nak nevezett megoldással van lehetőség a régi megoldás mellett maradni. Egy laikus mindjárt azt kérdezné: mért is jó ez? Egyáltalán van ennek előnye?

A válasz igen, van, de nem az amire először gondolnánk. Én arra gondoltam, amikor erről először halottam, hogy ezzel lehet jogosultságot adni/elvenni kifelé irányuló hívásokra. Nem így van. Ennek egyetlen oka van: a megszokás. Viccesen hangzik! Sőt, nem is annak a megszokása, hogy elő kell tárcsázni egy számot, hanem az idő.

Egy VoIP telefonon a rendszer a szám beírása után vár még egy másodpercet, hátha akar még a felhasználó számjegyeket beütni, és bár rövid ez az idő, mégis valakit úgy tűnik idegesít. Ezt lehet ezzel a funkcióval elhárítani. Különböző előhívó számokkal más fővonalakon át lehet kimenni. Mi lehet még ennek előnye? A fővonali oldalon a szolgáltató ilyenkor valóságosan, gombnyomás időben kapja meg a beütött számokat. Manapság ez már nem jelent előnyt, régebben, kompatibilitási problémák előfordulhattak, én nem tapasztaltam ilyet.

Gondolom már világossá vált, hogy ez nem éppen a legideálisabb megoldás, ennél egy VoIP rendszer lehet okosabb. Az előbb már írtam, hogy a telefon vár,  egy kicsit, és ha “meggyőződött” (eltelt az az idő), hogy a teljes szám be van írva, akkor küldje tovább a hívásirányító felé. Ha nekünk nagyon sürgős, akkor egy kettőskeresztre azonnal küldi (GrandStream telefonok van külön Send gomb a # alatt). Ebből a leszűrhető a lényeg: a központ egy teljes számot kap meg, és okosan gondolkozik. Először a belső mellékek között keres, ha nem talál, megy a fővonalra. Ez a megoldás hasonlít az alhálózat és az alapértelmezett árjáró kérdésére az adathálózatokban.

Sőt, ez még nem minden, a központhoz ugyanis adott esetben több fővonal lehet kapcsolva, például a VoIP szolgáltatón kívül egy ISDN és akár GSM adapter is. Erre a célra a központ konfigurálójának szabályokat kell létrehozni. A szabályokat a reguláris kifejezésekhez tudnám hasonlítani, bár annyira nem okosak. Hivatkozni lehet a hívott szám hosszára, adott számjegyére, akár számtartományra. Sőt, ezzel a megoldással akár a a 0690-es számokat le is lehet tiltani. De a legbeváltabb módszer az Asterisk esetében a 0620-as, 30-as, 70-es számok GSM adapterre irányítására kitalált _06[237]0X. mely annyit takar: minden számot ami 06-al kezdődik, és utána 2,3,7 áll majd egy nulla, és még legalább egy karakter, azt irányítsa eszerint a szabály szerint.

Nagyon Geekeknek: Amiről most beszélek dialplan-nek hívják a telefóniában. Az asterisk alapértelmezés szerint az /etc/asterisk/extensions.conf-ból olvassa ezt ki, de ide be lehet #include-olni más fájlokat is. Egy új hívást a rendszer a [default] kontextusból indít. Ide jellemzően más kontextusok listája kerül be. Lépéseket kell itt meghatározni, hogy mi történjen a hívással. (pl.: _s,1,Dial(SIP/ePhone,${ARG1})

Gencom mini – kimenő út hozzáadása

Cisco-ban ezt egy kicsit bonyolultabb összehozni, ott a ‘destination-pattern’ opcióval lehet játszani a ‘dial-peer voice’ módban. Illetve itt a számok módosíthatóak is ‘translation-rule’-okkal. Erről részletesebb leírást nem adnék, a Cisco oldalon van, másrészt meg ez egy elég bonyolult konfiguráció, parancssoros felületen bejárni egy ilyen nagy eseményhalmazt. Azt elfelejtettem, hogy az ilyen szintű beállításokat a Cisco-nál csak parancssoros felületről lehet elérni, amit teleneten, sshn vagy console porton át lehet megtenni.

Ökölszabály: mindig járjunk utána mi az aktuális álláspont a segélyhívószámok konfigurációjával kapcsolatban.

Cisco – dial-peer

Ezeket a fent említett konfigurációs beállításokat a Gencom rendszereken a kimenő utak / outbound routes menüpontok alatt kell keresni. Értelme csak akkor van, ha a fővonalak rendesen be vannak állítva a ‘Trunks’ menüpont alatt, a fővonalak beállításához kérje segítségünket.

Biztosan ismerős a helyzet, hogy feltelepít egy operációs rendszert, legyen az Windows, Mac vagy Linux, és a gép a mai világban addig gyakorlatilag használhatatlan, amíg nincsenek megfelelő kodekek telepíve (divx , perian, gstreamer és egyebek). Nekünk rendszergazdáknak ez egy rendszeres probléma. A VoIP technológia is alkalmaz különböző kodekeket a hang tömörítésére.

Itt azonban egyszerűbben működik a dolog. A telefonálásra használt protokollok, így a SIP is, megvalósít egy rendkívül érdekes szolgáltatást, amennyiben a készülékek közzétesznek egy listát az általuk használható kodekekről priorizálva, és az első azonos kodekekkel fog létrejönni a Session.

Ebből a lényeg ki is derül: egy adott kodeket vagy megvalósít egy készülék, vagy nem. A legtöbb készüléken ettől függetlenül változtathatunk a priorizálás sorrendjén, sőt, le is tilthatunk bizonyosakat. A fizikai készülékeket általában nem lehet új kodekekkel felruházni, elképzelhető esetleg firmware frissítéssel, de nem jellemző. Érdekesebb a helyzet a telefonközpontokkal. A Cisco ilyen tekintetben nem nagyon bővíthető, az Asterisk annál inkább. Ez egy moduláris rendszer, az kodekek is mint modulok léteznek (/usr/lib/modules/asterisk).

Fontos tudni, hogy egy beszélgetés során kitétel, hogy csak a két végpont végez kódolást vagy dekódolást, a hívásirányító rendszerek (telefonközpontok csak nagyon ritkán, ez garantálja a hangminőséget is). Ezért is elég nekik kisebb teljesítmény. Ezért képes a Gencom-mini ilyen minimális hardveren futni. Kevés erőforrást igénylenek a hangosmenük és a hívásrögzítés is, mert a már megfelelő formátumban lévő anyagot “olvassa fel” a rendszer, vagy az adott kódolás alapján írja azt lemezre. A belehallgatás funkció tulajdonkép nem igényel plusz erőforrást, mert az IP csomagok unicast helyett multicast módon továbbítódnak. Sokkal erőforrás igényesebb a konferenciahívás, ahol két vagy több hangsávot kell összekódolni, és azt multicastolni. A legdurvább pedig az IP fax szolgáltatás, mikor az analóg jeleket kell értelmezni digitális módon, illetve nagyon hasonló, mikor a DTMF kódokat az audiosávból kell kinyerni. Ezeket a rendszer alapvetően SIP-es szöveges információként küldi.

Nézzük át, milyen kodekek a népszerűek:

• G.711 ulaw/alaw – legáltalánosabb, a különbség az amerikai és európai szabvány (mint a TI/E1), Fax átvitel képes.
• G.729 nagyon erős tömörítés. Asteriskhez fizetős.
• GSM a mobiltelefonokhoz használt, tömörített szabvány.

Meg kell említeni az analóg-digitális átalakítás kérdését is. A telefonrendszereken szabványos a 8000Hz-es mintavételesés, 8bites tárolás, mono (egy hangsáv).

A hangkódolás is megjelenik mint késleltetés a kommunikációban, ezért sem érdemes a telefonokon spórolni. A fel nem dolgozott csomagok u.n. jitter-bufferbe kerülnek. Csomagszinten UDP protokoll használata miatt az elveszett csomagok nem kerülnek újraküldésre, nincs is értelme, mert valós időben kell gondolkodni.

Kodek táblázat

A kodekek tömörítési képességeinek ismeretében tudunk internet sávszélességet számolni. Ha alul számoljuk magunkat, rendkívül idegesítő tud lenni a rossz hangminőség, szakadozó szavak. Érdemes 10%-ot rászámolni, mert a SIP kapcsolat (Session) fenntartása is hálózati kommunikációnak számít.

Ha többet szeretne megtudni arról milyen internet kapcsolatra van szüksége, akkor hallgassa meg a Tárcsahang Rádió ide vonatkozó adását, vagy keressen fel minket.

Mint rendszergazda megszoktam, hogy a számítógép hálózat vagy működik, vagy nem. Esetleg elképzelhető, hogy lassú, ilyenkor általában gyorsabb szabvány után nézek. Az IP telefónia esetében a helyzet kicsit összetettebb. Lehet nekem akár gigabites hálózatom is, ez még nem garancia a megfelelő működésre.

Előfordult már velem, hogy ügyfelünk rossz hangminőségre panaszkodott, majd le is írta magukat a készülékeket, illetve a technológiát amit használtak. Pedig mint később  kiderült, a készülékek tökéletesek voltak. Általános rendszergazdaként én is úgy gondoltam, hogy az IP telefónia kizárólag az IP, vagyis az OSI modell harmadik rétegén működik. Van benne valami igazság, mert az ennél alacsonyabb rétegek elvben teljesen függetlenek az IP telefónia szempontjából. A magasabb számú rétegekre sokkal jellemzőbbek a VoIP-al használt protokollok. Az UDP, RTP, és végül a SIP vagy SCCP.

OSI modell

A téma azonban ennél sokkal összetettebb. Ha a hálózaton hangot szeretnénk átvinni, az hasonló módon utazik, mint az adat. Ezt úgy értem, hogy az aktuális adó oldalon a hang digitális adattá alakítása után ugyanúgy feldarabolódik és “leutazik” a rétegek között, akárcsak egy fájlt szeretnénk küldeni. A vevő oldalon meg ellenkező irányban történik mindez.

A különbség azonban ott van, hogy ez telekommunikáció. Nem csak arra gondolok, hogy kétirányú, hanem ennek következményeképp valós idejű. Hiába van az embernek király telefonközpontja és telefonjai, ha a hálózat többi része nem megfelelő. Vizsgáljuk meg ezt a kérdést egy kicsit közelebbről:

• Az első és talán legfontosabb, hogy a régebben (még az ezredforduló magasságában) használt u.n. osztott-buszos Ethernet semmiképp nem alkalmas IP telefóniára. Az osztott busz a co-ax kábelekkel kötött időkből származik, de mikor jött a modern UTP ezt nem törölte el. Hosszú ideig volt hatalmas különbség a hubok és a switchek árai között, szerencsére már csak az utóbbit lehet kapni. Azonban el tudom képzelni, hogy még mindig van ahol hubokat használnak. IP telefóniában elengedhetetlen, hogy az eszközök full-duplex módban működhessenek, tehát egy u.n. collison-domain-be pontosan két eszköz legyen. Ilyenkor a CSMA/CD algoritmusra nincs szükség, és a második rétegen nem alakulhat ki frame ütközés.
• Az előbbi probléma fent állhat az olcsóbb,” router”-eknek nevezett eszközök esetén is. Ezekben tipikusan négy RJ45-ös aljzat található együtt, és nem biztos, hogy mint switch van összekombinálva. (Én személy szerint azt is kifogásolhatónak tartom, hogy ezekbe az olcsó routerekben csak két IP interfész van csak, és rá merik írni, hogy “öt portos”.)
• Ha sikerült meggyőződni, hogy az előbbiek szerint topológiailag rendben van a hálózat, akkor még mindig  fent áll a veszélye, hogy ezek az eszközök még mindig nem az ideálisak. A switchek között is sok a különbség. Alapvető állapotában mindegyik egy MAC address táblát tart nyilván, a problémák nem is itt jelentkeznek. Amikor a switch megkap egy Ethernet frame-t valamilyen szintű ellenőrzést végez, mielőtt továbbküldi. A frame keretében van egy FCS (Frame Check Sequence)  mező, ami alapján meg kell vizsgálni, hogy hibamentes volt -e az átvitel. Ennek több módszere van, és ebből bizony adódhat késleltetés. Sőt, sajnos az alsó, de még a középső kategóriás switcheken sincs lehetőség ennek állítására. Mindenképp menedzselhető switchre kössük a telefonokat.
• A fentiek mellé jön még, hogy minél kisebb százalékban keletkezzen hibás frame. Ezt pedig minőség kábelezéssel lehet elérni, a maximális 100m-es vezetékhosszat betartva. Figyeljünk oda, a 100Mbps hálózattal szemben a gigabites kapcsolat mind a nyolc szálat használja, és követelmény a CAT6-os vezeték is.

Innentől kezdve a belső hívásoknak tökéletes hangminőséget kell produkálniuk, persze megfelelő eszközkonfiguráció mellett (itt értem azt, hogy nincs hurok a hálózatban, vagy a spanning-tree protokoll aktív). Gondolok itt a kodekekre és hasonlókra, melyet majd egy másik bejegyzésben tisztázok. Viszont mi a helyzet a külső hívásokkal? Itt már sokkal inkább számít a sebesség is. Nem tévedünk sokat, ha hívásonként 100KB/s-os sávszéllel számolunk, 50-el fel, 50-el le. Sajnos a szimmetrikus internetkapcsolatok még nem olcsóak, ezért a feltöltési sávszélesség jellemzően a kritikus pont.

Jellemző, hogy valószínűleg az intenetkapcsolatot másra is szeretnénk használni, és a szolgáltatóknál nem divat több publikus IP címet adni, így a forgalmat NAT-olni kell. A routerben ez is  plusz számítási teljesítmény a routeoláson kívül. Ügyeljünk, hogy a VoIP szolgáltatónknak mindig tartsuk fent az 5060-as TCP portot, hogy a hívások be tudjanak csörögni. Ez a SIP kommunikáció alapértelmezett portja.

A másik kérdés maga az internetkapcsolat. Ebbe sok beleszólása nincsen, de azért érdemes odafigyelni. Tiszta Ethernet alapú kapcsolat már csak a kábelhosszak miatt sem lehetséges. A szolgáltatók különböző 2. réteget bujtató (tunnelel) protokollokat használnak. ADSL-hez a PPP-t, a kábelnethez pedig egész keretrendszer létezik DOCSIS néven. Sajnos egyértelmű magyarázat nincs, melyik a jobb, mi viszont úgy tapasztaljuk, hogy a kábelneten egy minimálisan jobb minőség érhető el adott sávszélesség mellett.

Ebből is látszik, a sávszélesség nem minden. Hallgassa meg a Tárcsahang Rádió internetkapcsolattal kapcsolatos adását. Ha minőségi eszközökből szeretné hálózatát építeni, mert a jövőben elképzelhetőnek tartja a VoIP bevezetését, gondolkodjon előre! Kérjen tőlünk ajánlatot Cisco eszközökre, konfigurációt is vállalunk!