VoIP 1

Csomag alapú hálózatok alapjai................................................................................................................. 6

Áttekintés..................................................................................................................................................................... 6

Bevezetés....................................................................................................................................................................... 7

Kódolás........................................................................................................................................................................... 8

Kódolási szabványok.................................................................................................................................................... 9

Tömörítés minősége............................................................................................................................................. 10

Késleltetés................................................................................................................................................................ 11

Visszhang..................................................................................................................................................................... 12

Csomag alapú hangtovábbítás transzport lehetőségei........................................................ 13

Szinkron vonalkapcsolt hálózatok.......................................................................................................................... 13

Keret/cella hálózatok................................................................................................................................................. 14

IP hálózatok................................................................................................................................................................. 15

X.25 hálózatok............................................................................................................................................................. 15

Magán adat hálózatok............................................................................................................................................... 16

Jelzésrendszer: A hang összeköttetés létrehozása.................................................................. 17

Külső jelzésrendszer................................................................................................................................................... 18

Belső jelzésrendszer.................................................................................................................................................... 19

Csomag alapú hang hálózatok alkalmazása................................................................................. 20

A C&C Technológia................................................................................................................................................ 22

1.       Valós idejű együttműködési technológia /Real Time Collaboration Technology/............................. 22

CTI megoldástípusok........................................................................................................................................... 23

Összefoglalás.......................................................................................................................................................... 26

VoIP technológia...................................................................................................................................................... 27

Bevezető....................................................................................................................................................................... 27

Késleltetés.................................................................................................................................................................... 27

Kimeneti bufferkezelés............................................................................................................................................... 29

H.323 alapok................................................................................................................................................................ 31

A H.323 rendszer elemei..................................................................................................................................... 32

H.323 terminál............................................................................................................................................................. 32

Gateway........................................................................................................................................................................ 34

Proxy gateway............................................................................................................................................................. 35

Gatekeeper................................................................................................................................................................... 35

Multipoint controller................................................................................................................................................. 36

Multipoint Processor................................................................................................................................................. 36

Multipoint Control Unit............................................................................................................................................ 36

A H.323 szabvány ismertetése........................................................................................................................ 37

H.323 Audio................................................................................................................................................................. 39

H.323 Video................................................................................................................................................................. 39

H.323 adat.................................................................................................................................................................... 39

Jelzés............................................................................................................................................................................. 40

H.323 biztonsági kérdései......................................................................................................................................... 40

H.323 alkalmazások Cisco környezetben........................................................................................... 40

Cisco Multimedia Conference Manager................................................................................................................ 41

Átviteli minőséggel kapcsolatos kérdések.................................................................................... 52

Perem funkciók....................................................................................................................................................... 52

Compressed Real-Time Transport Protocol........................................................................................................... 52

RSVP.............................................................................................................................................................................. 54

Forgalomalakítás....................................................................................................................................................... 58

Custom Queuing.......................................................................................................................................................... 59

Priority Queuing......................................................................................................................................................... 59

Weighted Fair Queuing (WFQ)................................................................................................................................ 60

Többszörös kapcsolat széttördelés és közbeszövés (Multilink Fragmentation and Interleaving)............... 61

Szabályrendszer-alapú útvonalválasztás............................................................................................................... 61

Gerinc:............................................................................................................................................................................ 64

RED—torlódás megelőzés......................................................................................................................................... 64

Frame Relay QoS........................................................................................................................................................ 67

Voice over IP—Tervezés.................................................................................................................................... 69

VoIP tervezési szempontok FR és ATM hálózatok esetén......................................................... 70

Frame Relay................................................................................................................................................................. 70

ATM............................................................................................................................................................................... 71

Csomag alapú hang hálózatok tervezése.......................................................................................... 72

Hálózati Audit......................................................................................................................................................... 72

Hálózati követelmények................................................................................................................................ 73

Technológiák és szolgáltatások áttekintése.............................................................................. 73

VoIP............................................................................................................................................................................... 74

Műszaki irányelvek............................................................................................................................................ 77

Méretezés, erőforrás tervezés.................................................................................................................. 81

Pénzügyi analízis................................................................................................................................................... 82

Hang hálózat (alközponti hálózat).......................................................................................................................... 83

Adat hálózat................................................................................................................................................................. 83

Hálózat újra tervezése................................................................................................................................................ 84

Pénzügyi analízis........................................................................................................................................................ 88

Végső közvetkeztetés....................................................................................................................................... 90

Alkalmazások............................................................................................................................................................. 92

IP PBX................................................................................................................................................................................ 92

Meglévő PBX bővítése............................................................................................................................................... 92

Nincs hagyományos PBX........................................................................................................................................... 93

Távoli irodák elérése IP hálózaton......................................................................................................................... 93

Távhívási és helyi telefon szolgáltatások az Internet szolgáltatóktól............. 94

A Cisco Kommunikációs Rendszer architektúrája............................................................................................... 96

Toll Bypass................................................................................................................................................................. 97

Fax over IP................................................................................................................................................................... 97

A következő generációs telefon szolgáltatók............................................................................ 99

Call Centerek........................................................................................................................................................ 100

A Call Centerek előnyei:......................................................................................................................................... 100

Példa Call Center alkalmazásokra....................................................................................................................... 100

Más hasznos alkalmazások..................................................................................................................................... 101

Távhívó szolgáltatások............................................................................................................................... 102

Üzleti lehetőségek az ISP-k számára..................................................................................................................... 102

A lehetőségek köre.................................................................................................................................................... 102

Pre-paid Calling Card megoldás.............................................................................................................. 103

Egységes Kommunikáció (Unified Communication /UC/)........................................................... 104

Bevezetés.................................................................................................................................................................... 104

Az egységes üzenet kezeléstől az egységes kommunikációig............................................................................ 104

Egyesített kommunikációs megoldások................................................................................................................ 105

Unified Communications: A stratégia a szolgáltatók számára..................................... 109

Cisco és a Unified Communications........................................................................................................ 109

Az Open Packet Telephony architektúra: az egyesített kommunikáció sarokköve...................................... 109

Az Open Packet Telephony (OPT) és az egyesített kommunikáció.................................................................. 111

CTI megoldások, szoftverek....................................................................................................................... 112

WebLine...................................................................................................................................................................... 115

ICM.............................................................................................................................................................................. 124

Példák CTI technológia alkalmazására.......................................................................................... 131

Cisco VoIP termékek............................................................................................................................................. 135

Access router kategória.............................................................................................................................. 135

Cisco 1750................................................................................................................................................................. 135

A Cisco 2600/3600 család hang/fax modulja.................................................................................................... 135

Hang interfész kártyák (VIC).................................................................................................................................. 136

Nagy-sűrűségű hang/fax modul a Cisco 2600/3600 családhoz...................................................................... 137

AS5x00 Voice Gateway....................................................................................................................................... 138

AS5300....................................................................................................................................................................... 138

AccessPath VS-3....................................................................................................................................................... 139

Digitális Hang Port Adapter a Cisco 7x00-es család részére.......................................................................... 139

Menedzsment.......................................................................................................................................................... 141

Cisco Voice manager............................................................................................................................................... 141

Cisco CallManager............................................................................................................................................ 143

A CallManager szolgáltatásai............................................................................................................................... 144

Matáv rendszertechnika................................................................................................................................. 152

SOHO megoldások................................................................................................................................................ 152

SOHO 1-2 munkahely............................................................................................................................................... 153

SOHO 3-20 munkahely, alközpont........................................................................................................................ 154

SOHO 3-20 munkahely, IP telefonok.................................................................................................................... 155

Közepes és nagyvállalati megoldások.............................................................................................. 156

Közepes vállalat, 150 munkahely, ISDN alközpont, távoli behívás............................................................... 157

Nagyvállalat, 300 munkahely, távoli behívás, alközpont nélkül.................................................................... 159

Javasolt demoeszköz készlet................................................................................................................... 160

 

Csomag alapú hálózatok alapjai

Áttekintés

A telefon, több mint 100 éves fejlődése alatt a fejlett társadalmak egyik alappillérévé vált. Nélküle elképzelhetetlen lenne az üzleti élet. A nyilvános telefonhálózat tarifarendszerek szövevényéből épül fel. S bár az egyes hívások költsége nem túl magas, a vállalatok költségvetésében a rengeteg telefonálás jelentős összegként jelenik meg. A legtöbb vállalat esetében ezek a költségek drasztikusan csökkenthetők lehetnének. Sok vállalat bérelt vonalakkal próbálja meg lefaragni a telefon számláit, de ez a megoldás is komoly összegekbe kerül. Napjaink számítógépes hálózatai, jó néhány alternatív megoldást nyújtanak mind a hagyományos telefon, mind pedig a bérelt vonali szolgáltatások kiváltására. A legtöbb előnnyel kecsegtető megoldást azok a hálózati technológiák jelentik, melyeknél a különböző típusú hangátvitelt csomagok /packet voice/ szállításával oldják meg. Ez azért előnyös, mert így a számítógépes hálózatok a hangcsomagokat ugyanúgy továbbítják, mint a hagyományos adatcsomagokat. Ugyanazokat az átviteli utakat használják, melyeket eddig adattovábbításra használtak, és melyek költségei sokkal alacsonyabbak. A hangcsomagok sokkal kisebb sávszélességet igényelnek, mint a hagyományos hang, és ez megmutatkozik az átviteli költségekben is. Miközben a telefonok 64.000 bps-ot (bit/sec) igényelnek, a hangcsomagok alkalmazásánál kevesebb, mint 10.000 bps is elég. Sok vállalat tartalék kapacitásokkal rendelkezik az adatátviteli hálózatában, így az ezen továbbított hang számukra nem jelenne meg költségként, azaz „ingyenes” lenne.

A legtöbb esetben még akkor is megéri a hangot csomagokban szállítani, ha bővíteni kell ehhez az átviteli hálózat kapacitását. A nyilvános telefonhálózat többnyire távolság alapú tarifarendszerrel dolgozik, melyben a helyi hívás alapdíjához a hívás távolságának függvényében további költségek adódnak. A hang adathálózaton keresztül történő továbbításával ezek a költségek csökkenthetők. Még a nem távolságfüggő tarifa rendszer esetén is, a hang csomagokban történő szállítása 20 szoros, vagy még nagyobb sávszélesség kihasználást tesz lehetővé szemben a hagyományos digitális hang-átvitellel.

Az adat hálózatokon történő hangtovábbításnak is ára van. A jó minőségű hangátvitel csak olyan adat hálózatokon lehetséges melyek szigorú minőségi követelményeknek /QoS/ tesznek eleget. Amennyiben a hálózat nem képes eleget tenni ezeknek a követelményeknek, az átvitt hang minősége rossz lesz. Ez a jelenség figyelhető meg amikor a hang nyilvános hálózaton keresztül továbbítódik, pl.: Interneten keresztül, ahol a felhasználóknak csak igen korlátozott lehetőségek állnak rendelkezésre, a két végpont közötti szolgáltatás minőségének biztosítására.

A QoS gondok ellenére, a hangcsomagok alkalmazása robbanásszerűen terjed, a hatalmas költségmegtakarítások eredményeként. Még az Egyesült Államokban is, ahol a telekommunikációs költségek alacsonyak, a vállalatok csomagok alkalmazásával felére, harmadára tudják csökkenteni a költségeket.

Bevezetés

Minden csomag alapú hangátviteli rendszer azonos modellt követ, melynek egyszerűsített ábrája az 1. Ábrán látható. A csomag alapú hálózat, mely lehet IP, Frame Relay, illetve ATM /Asynchronous Transfer Mode/, az ábrán felhőként jelenik meg. A hálózat szélein lévő eszközöket, berendezéseket „voice agent”–eknek nevezzük. Ezen berendezések összekötő funkciót látnak el és az a dolguk, hogy a hagyományos telefonhálózatokban használt formára alakítsák a hangot tartalmazó csomagokat.

1. Ábra Csomag alapú hálózati modell

A hálózat átadja a csomagot a voice agent-nek, mely azt ha szükséges átalakítja, azután tovább küldi a hozzá csatlakoztatott berendezések /PBX, fax, számítógép/ felé.

A voice agent kapcsolati modell felvet két igen fontos kérdést:

Az első kérdés a hang kódolására vonatkozik: Hogyan kerül be a csomagokba a hang, és hogyan alakul vissza később ismét hanggá?

A második kérdés: Milyen jelzésrendszert használjunk ahhoz, hogy megállapítsuk ki volt a hívó, ki a hívott, és hogy hol helyezkednek el a hálózatban?

Kódolás

Az emberi hang, és persze minden más amit hallunk normális esetben analóg formában érkezik a fülünkbe. Az első telefon rendszerekben is analóg módon továbbították a beszédinformációt. Bár az emberi test jól fel van szerelkezve az analóg kommunikációhoz /száj, fül /, az analóg jeltovábbítás nem túl hatékony módszer. Ha az analóg jel megsérül, nehéz elkülöníteni a jel összetett struktúráját a véletlenszerű átviteli zajtól. Az analóg jel erősítésekor a zaj is erősödik, ezért az analóg kapcsolatoknál nagy az átviteli zaj. A digitális jelek diszkrét jelekből állnak: a két jel /„1” és „0”/ a zajtól és egymástól is egyaránt könnyen elkülöníthető, és a jel erősítése nem növeli a zaj szintjét. Mivel a digitális kódolás sokkal védettebb a zajok ellen már régóta ezt használják a nagytávolságú összeköttetéseknél, a világ kommunikációs rendszerei a digitális átvitelt kezdték alkalmazni és elsőként az impulzus kód modulációt /PCM/ honosították meg. A PCM kódolás során a hangból mintát vesznek /8000 mintavétel másodpercenként /, majd minden egyes mintát kódolnak. A 8000 minta/másodperc (125 ms a minták között) abból adódott, hogy az emberi beszéd felső frekvenciája kb.: 4000 Hz, és ha a jel frekvenciájának kétszeresével mintákat veszünk a jelből, akkor az eredeti jel pontosan visszaállítható a vett mintákból.

A mintavételezés után, tehát a minták digitális jelekké kódolódnak. A szabványos PCM kódolás 8 bites kódot használ, ami 64 kbps–ot jelent. Más kódolási szabványok, pl.: ADPCM /adaptív differenciális PCM/ 4 bitet használ és ez 32 kbps-ot jelent. Az ADPCM kódolást leginkább nagytávolságú kapcsolatoknál használják.

Többnyire a telefonos alkalmazások PCM ill. ADPCM kódolást használnak a szinkronizált digitális csatornákon, ez azt jelenti, hogy a csatornán áthaladó bitfolyam állandó, akkor is ha van társalgás, akkor is ha nincs. Egy átlagos társalgásban több ezer rövid szünet található, és minden egyes kis szünet kidobott pénz a felhasználó számára. A szabványos telefonhálózat nem nyújt semmilyen megoldást az ilyen pazarlások ellen.

Amennyiben csomagokat alkalmazunk ez a probléma nem merül fel. A csomagokban történő hangátvitel esetén a beszéd adatcsomagként utazik a hálózaton, és csak akkor jön létre egy-egy csomag, ha valóban folyik társalgás. Azzal, hogy csak akkor van csomagküldés, ha van információ, kevesebb mint egyharmadára csökken a kommunikációhoz szükséges sávszélesség.

Kódolási szabványok

Az átvitelhez szükséges sávszélességet más módszerekkel tovább lehet csökkenteni. Az ITU /International Tellecommunication Union/ számos szabvány hang kódolást definiált, ezek között található a fentebb említett 64 kbps PCM illetve a 32 kbps ADPCM kódolás is. Ahhoz, hogy a hangot csomagokban továbbítani tudjuk, nem árt tisztában lenni a hang kódolási szabványokban használt kódolási stratégiákkal. Az első a szabványok közül a „fix-mintavételezés”, mely a G.711 családba tartozik. Ez a szabvány a már fentebb leírt 8000 minta/másodperc stratégiát alkalmazza. Minden mintavételnél a kódoló eltárolja a hang pillanatnyi amplitúdó értékét. A mintákból azután a túloldalon visszanyerhető az eredeti jel.

2. Ábra PCM kódolás

A mintavételezési stratégia problémája az, hogy az átvitelhez szükséges sávszélesség csökkentése miatt, egyre kevesebb bittel kell kódolnunk a mintákat. Nyolc bit használatakor 256 különböző amplitúdó szintet tudunk megkülönböztetni. Ahhoz, hogy 32 kbps sávszélességet használhassunk, négy bitet használunk /64 db szint/, a 16 kbps-os ADPCM pedig már csak 2 bitet használ /4 érték/. Sajnos minél kevesebb szintet használunk, annál rosszabb lesz a hang minősége.

A szabványok másik csoportja jobb hang tömörítést végez, miközben jobb minőséget garantál. Ezekben a szabványokban olyan speciális algoritmusokat használnak a kódoláshoz /pl.: LPC (Linear Predictive Code)/, melyek az emberi beszédet modellezik.

A legtöbb LPC berendezés 64 kbps PCM kódot vár input jelként, a következő okok miatt:

Mivel ez a legáltalánosabban elterjedt hang formátum melyet a digitális PBX-ek és a telefon switch-ek használnak.

A PCM kódoló chip-ek olcsók, és igen elterjedtek a telefonhálózatokban.

Mind az LPC, mind pedig a PCM/ADPCM kódolás az ITU szabványok G-sorozatában került ajánlásra. Melyben a telefonos világ és a csomagokban történő hangátvitel legtöbbet használt hang kódolási szabványai találhatók meg. Ezek a szabványok a következők:

·         G.711        64 kbps PCM hangkódolás, átalakítás nélkül továbbítható a nyilvános telefonhálózat felé illetve PBX-ek felé.

·         G.726        40, 32, 24 és 16 kbps sebességű ADPCM kódolás. Az ADPCM kódolással kódolt hang is alkalmazható csomag alapú, nyilvános telefonhálózatokon, illetve alközponti hálózatokban.

·         G.728        a 16 kbps sebességű LD-CELP tömörítés, kódolást írja le. Ez a hangkódolás,  nyilvános telefonhálózatokban történő alkalmazás esetén, általában konverziót igényel.

·         G.729        8 kbps adaptív CELP tömörítés. Két formája van a szabványnak, de mindkettő ugyanolyan jó hang minőséget nyújt, mint a 32 kbps ADPCM.

·         G.723.1     beszéd és más audió jelek nagy arányú tömörítésére használják. A H.324 szabvány része, és két különböző sebességet tartalmaz:
-6.3 kbps sebességű, mely MP-MLQ kódolást használ
- 5.3 kbps sebességű, mely CELP kódolást használ

Tömörítés minősége

A tömörítések alkalmazásánál arra kell figyelni, hogy elkerüljük a tandem kódolást, kapcsolást. A tandem kódolás esetén a hang miközben a hálózaton keresztül utazik többszöri ki-be tömörítésen, vagy akár többszöri AD/DA (Analóg, Digitális) átalakításon megy keresztül, mire eléri a célberendezést.

A tömörítési stratégia hang minőségét mérni szokták, a leginkább elterjed mérési rendszer Mean Opinion Score (MOS). A beszéd és a hang szubjektív jellemzők, minden hallgató más-más módon ítéli meg az összeköttetés minőségét. A MOS skálán, a nulla jelenti a legrosszabb minőséget, az 5 pedig a jó értéket, a szabványos PCM kódolás 4.4 -et ért el ezen a skálán, a G.726 ADPCM kódolás 32 kbps-es verziója 4.2-őt kapott az értékeléskor.

G.728 CELP kódolás 4.2, és a G.729 ugyancsak 4.2-t kapott. Az 1. Táblázatban feltüntettünk néhány kódoláshoz tartozó MOS értéket.

1. Táblázat Különböző kódolások MOS és késleltetési értékei

Késleltetés

A késleltetésnek nagy jelentősége van a tömörített hang esetében. A hangok csomagokba történő tömörítése időbe telik. A fenti táblázat mutatja az átlagos késleltetés összefüggését azon elterjedt kódolási szabványok esetében melyekről korábban már szó volt. Nagy késleltetés esetén visszhangtörlésre van szükség, azért hogy ne alakulhasson ki zavaró mértékű visszhang. A legtöbb hangcsomagokat előállító berendezés használ valamiféle visszhangtörlést.

Két fő forrása van a késleltetésnek a hagyományos telefonhálózatokban és a csomag alapú hálózatokban egyaránt: a jelterjedési késleltetés és a jelfeldolgozási késleltetés.

Az első tényező a fény, illetve egyéb hullámok korlátos terjedési sebességével függ össze. A fény terjedési sebessége megközelítőleg 300000 km/s vákuumban az elektronok sebessége pedig 161000 km/s, ez azt jelenti, hogy például egy fél földet átívelő optikai kábelen (kb.: 20900 km) csak 70 msec késleltetést lehetne mérni. Ez a típusú késleltetés tehát elenyészően kicsi, és nem okoz komoly problémát.

A késleltetések kezelése hatással van a hagyományos hang hálózatokra. Minden E1/T1/J1 keret összeállítása és elküldése a megfelelő vonalon 125 ms –ot igényel, feltételezve azt, hogy minden keret a saját sebességével van elküldve (1.544, vagy 2.048 Mbps). Ezek az apró késleltetési idők /ún. sorba állítási késleltetés (serialization delay)/ összeadódnak, ahogy a keret utazik át a hálózaton. A teljes késleltetés megnőhet akár 20, vagy még több msec-ra, a kontinensek közötti vonalak esetében. A sorba állítási késleltetés hozzáadva a terjedési késleltetéshez már elérheti a 100 msec-ot, amit már a legtöbb ember észrevesz, bár még nem rontja a beszélgetés minőségét.

Összefoglalva, a hang csomag kódolás javítja a hálózat gazdaságosságát két okból kifolyólag; először azért, mert lecsökkenti a hang átviteléhez szükséges sávszélességet, másodszor azért, mert kiszűri a csend periódusokat. Ahhoz, hogy az ebből adódó előnyöket kihasználhassuk, az átvitelért felelős hálózat képes kell, hogy legyen kis sávszélességű forgalmakat is lebonyolítani és más forgalmakkal szemben előnyben részesíteni a gyors továbbítást igénylő hang csomagokat. Ezek a képességek leginkább a hálózat típusától függnek.

Visszhang

A hagyományos telefonhálózatokban a visszhangot többnyire a hálózatban használt 4 vezetékes rendszer és az előfizetői hurokban használatos 2 vezetékes rendszer impedanciájának a rossz illesztése okozza. Alapesetben kívánatos és a beszélgetők komfortérzetét növeli az, hogy ha a beszélő hallja a saját hangját telefonkagylóban. Azonban ha a saját hangunkat 25 ms-nál hosszabb idő elteltével halljuk vissza az zavaróan hat és élvezhetetlenné teszi a beszélgetést. A nyilvános telefonhálózatokban (PSTN) (amennyiben a késleltetés ezt szükségessé teszi) a visszhang kezelésére visszhangtörlő áramköröket alkalmaznak, valamint a csatlakozási pontokon megfelelő impedancia illesztéssel csökkentik a visszhang mértékét. A mai csomag alapú hanghálózatokban a visszhangtörlő áramkörök az alacsony sebességű kódolók DSP áramköreibe vannak beépítve. A visszhangtörlő áramkörök működéséhez szükséges a visszhang keletkezésének az ismerete.

Vegyük azt az esetet, amikor ’A’ beszél ’B’-vel, és ’A’-nak a ’B’ irányú beszéde ’G’. Ha ’G’ beleütközik valamilyen visszhangkeltő eszközbe (pl. rossz impedancia illesztés) visszajut az ’A’-hoz. ’A’ ezután meghallja a saját hangját a telefonkagylóban néhány milliszekundummal később, mint azt valójában mondta.

A visszhang, vonali eltávolításához az eszköznek, amelyen keresztül ’A’ beszél (’A’ router), meg kell őrizni ’A’ beszédének az inverzét, (’-G’), egy bizonyos ideig. Az ’A’ router visszhangtörlő áramköre a ’B’ felől jövő beszédből kivonja a ’-G’-t eltávolítva ezzel a visszhangot.

A visszhangtörlő áramkörök csak bizonyos ideig képesek raktározni a beszéd információt, és ezáltal eltüntetni a vonalról a visszhangot. Az ezen időn túl visszaverődő beszéd nem törlődik ki a visszhangtörlő áramkörön.

Csomag alapú hangtovábbítás transzport lehetőségei

Az előzőekből világosan kitűnik, hogy a tandem-kódolás /kettős kódolás/, a késleltetés és a időzítés, szinkronizáció elvesztése komoly gondot jelent a hangátvitel szempontjából. Miközben minden csomag alapú hálózatnak szembe kell néznie ezekkel a problémákkal, az egyes csomag alapú hálózatokban a megoldási lehetőségek különbözőek. A csomagokban történő hangátvitel tervezésénél figyelembe kell venni az átvitel technológiáját.

Hangcsomagok az alábbi WAN hálózat összeköttetési típusokon továbbíthatók:

·         Bérelt vonali hálózatok
Ezek a hálózatok többnyire a szolgáltató által bérbe adott T1/E1/J1 trönkökön alapulnak, fix sávszélességgel.

·         ATM állandó átviteli sebességű (CBR) virtuális áramköri szolgáltatás, illetve áramkör emulációs összeköttetések. Ezek az összeköttetések a vonalkapcsolt hálózati kapcsolt összeköttetéseket emulálják, néha szokták őket ATM Class A szolgálatnak is nevezni.

·         VBR /Variable Bit Rate/, ABR /Available Bit Rate/, UBR /Unspecified Bit Rate/ ATM szolgáltatási osztályú összeköttetések.

·         Frame Relay hálózatok, mind a nyilvános szolgáltatói, mind pedig a cégek által kiépített magán FR hálózatok

·         Nyilvános csomagkapcsolt (X.25) hálózatok, melyek nyilvános adatszolgáltatást nyújtanak sok nemzetközi alkalmazásban és gyakran használják nemzetközi adathálózatokként pl.: Európában. Ez inkább elméleti, mint gyakorlati lehetőség.

·         Nyilvános IP hálózat, beleértve az Internetet is

·         A magán hálózatok legtöbb típusa

Ezeket a hálózat típusokat jellemzőik alapján a következő nagyobb csoportokra bonthatjuk:

Szinkron vonalkapcsolt hálózatok

A szinkrón vonalkapcsolt technológiák, mint például a bérelt vonali hálózatok és az állandó átviteli sebességű ATM szolgáltatások, ugyanazokkal az átviteli tulajdonságokkal rendelkeznek, mint amilyet a hagyományos távbeszélő hálózatok jelenleg használnak, így a hang továbbítása nem jár semmilyen kockázattal. Ha a hálózati „felhő” az 1. Ábrán ilyen hálózatból van kialakítva, akkor a hangtovábbítás a normál telefonos hálózatoknál megszokott módon történik, és általában nincs szükség speciális voice agent-re a hálózatban. A legtöbb országos, illetve nemzetközi magán hálózat vonalkapcsolt technológián alapul, és a hang forgalom fix sávszélességgel, időrésekben bonyolítódik. Az átvitelnek ez a módszere, mivel megegyezik a hagyományos telefóniában használttal, pazarolja a sávszélességet. Ha hang csomagkódolást használunk a vonalkapcsolt hálózatokon, az egyedüli megtakarítás, a tömörítés miatt fellépő, alacsonyabb átviteli sebesség (például G.729-nél 8 kbps) lesz. A gazdaságosság mértéke ilyenkor nagyban függ attól, hogy a hálózat tudja kezelni a 64 kbps-nál kisebb időréseket /subrate multiplexing/, vagy sem.

Az ATM hálózatban, a CBR szolgáltatások tudják támogatni a 32, 16, vagy 8 kbps összeköttetéseket. Sok ATM hálózat csak 64 kbps-en áramkör emulációs összeköttetést biztosít /mivel az 1997-ben az ATM Forum által kiadott szabvány az ATM-en keresztül történő hangátvitelhez a G.711 kódolást ajánlották/, és ezáltal a hang tömörítéssel nyert alacsonyabb sávszélesség elveszik az átvitel során.

Keret/cella hálózatok

Keret/cella hálózatok, Frame Relay-t használnak, vagy változó átviteli sebességű ATM-et, kódolt, tömörített hang szállítására. Ezekhez a hálózatokhoz voice agent szükséges, mely a hangot cellákba, vagy keretekbe kódolja a szállításhoz, majd dekódolja a cellákat/kereteket a célállomásnál. A voice agent-nek minden telefon jelzést meg kell értenie, melyet a hang küldője és fogadója alkalmaz ahhoz, hogy azonosíthassa a hívott számát és kézbesítse a hívási folyamat jelzéseit. Tudnia kell a hálózat jelzési és címzési sajátosságait, ahhoz, hogy elérje a céloldalon lévő különféle voice agent-eket. Ez a képesség különösen a hagyományos hang hálózatok és a keret/cella hálózatok közötti kapcsolatoknál igen jelentős.

A Frame Relay, vagy ATM hálózatokban a hálózat késleltetését és a késleltetés idejének ingadozását sok esetben maguk a switch-ek vezérlik, amennyiben mindegyik switch és végpont ugyanahhoz a közös, forráshoz, vagy PRS-hez van szinkronizálódva a hálózatban. Rendszerint, a késleltetés idejének ingadozása a hálózatban olyan kicsi, hogy a kijövő hang csomagok időzítése jól megközelíti az input oldali beszédet, és a csomagok időzítéséhez nincs szükség speciális időbélyegek alkalmazására. Kivételt képeznek ez alól a szinkronizációhoz nem közös referencia forrást alkalmazó hálózatok. A gyakorlatban azt, ha egy ATM cellához időbélyeget adunk SRTS-nek /Synchronous Residual Time Stamp/ nevezzük, melynek segítségével időzítési információk továbbíthatók két végpont között.

Néhány ATM és Frame Relay switch és multiplexer támogatja a változó átviteli sebességű ATM hang kódolást, így ezek voice agent-ként is működhetnek. Mivel a Frame Relay és az ATM szabvány még fejlődik, vásárláskor körültekintőnek kell lennie a berendezés kiválasztásánál. Meg kell bizonyosodni arról, hogy a berendezés támogatja-e ezt az opciót és, hogy a tervezett alkalmazások által támasztott követelményeknek megfelel-e.

IP hálózatok

A csomag kapcsolt adat hálózatoknál /pl.:belső IP intranetek és az Internet/, ugyanazok a kódolási és címzési problémák merülnek fel mint a keret/cella hálózatoknál. Az ilyen típusú hálózatoknál, nincs garantált mértékű késleltetés illetve késleltetési idő váltakozás, és emiatt biztosítani kell a hálózat késleltetési idejének állandó, lehetőleg minél alacsonyabb szintjét. Például a magas szintű protokollok, úgyis mint TCP /Transmission Control Protocol/ folyamat vezérlést és hibajavítást nyújt, melyek kombinációja jelentős késleltetési idő ingadozást okozhat. Emiatt a TCP-t nem szokták hang átvitelnél használni.

Helyette a hang forgalmat UDP-vel /User Datagram Protocol/ oldják meg, sajnos ilyenkor nincs idő bélyeg alkalmazási lehetőség az időzítés kontrollálásához, és már a késleltetés idejének kismértékű változása is rontja a beszéd érthetőségét. A probléma megoldására a H.323 szabvány az IP-n keresztül történő hangtovábbításhoz az RTP-t alkalmazza, mely az UDP tetején helyezkedik el. Az RTP idő bélyeg szolgálatot nyújt, és lehetővé teszi (RTCP-n /Real Time Control Protocol/ keresztül pont-multipont hang összeköttetések létrehozását is. Napjaink hálózatai egyre növekvő számban kínálnak garantált szolgáltatási szinteket. Ezek a hálózatok jellemzően RSVP-t /Resource Reservation Protocol/ használnak. Az RSVP egy jelzés protokoll, melynek segítségével a switch-ek és router-ek utasíthatók arra, hogy tartsanak fent bizonyos forgalom számára erőforrásokat. Ezáltal lecsökkenthető a késleltetés, valamint a késleltetési idő ingadozása, mely az erőforrásokért folytatott verseny miatt alakulna ki.

X.25 hálózatok

Azok a nyilvános adat hálózatok amelyek X.25 csomagok szállításán alapulnak, a második rétegben beépített hiba javítással és a harmadik rétegben beépített forgalom vezérléssel rendelkeznek, melyet nem lehet kikapcsolni. Az ilyen hálózatok általában nagyon nagy kihasználtsági fokkal üzemelnek. Ezen okok miatt a hangcsomag szállítás ilyen típusú hálózatokon, sokszor csak rossz minőségben lehetséges. Ezek a hálózatok túlnyomórészt nem alkalmasak hang továbbításra.

Magán adat hálózatok

A magán adat hálózatokat aszerint kell osztályoznunk, hogy melyik nagyobb hálózati típusba tartozik:

·         a csomag alapú, összeköttetés mentes IP modellbe /Novell SPX/IPX, OSI, IEE 802.2 bridging, és így tovább/

·         a kapcsolat orientált X.25 modellbe /IBM SNA, DEC LAT, és így tovább/

Mivel az IP alapú hálózatok általában megengedik a felhasználónak, hogy kikerüljék a hibajavítást és a forgalom irányítást, ezért az ilyen típusú hálózatok alkalmasak hang továbbításra, amennyiben más késleltetést növelő tényezők ezt lehetővé teszik. Általánosságban elmondhatjuk, hogy az összes kapcsolat orientált magán adat hálózati protokoll megköveteli a hibajavítást és a forgalom irányítást, ami miatt többnyire nem használhatóak hang továbbításra.

Azok a hálózatok melyek alkalmasak hang továbbításra, felmerül a kérdés, vajon a hálózat milyen előnyöket nyújt ha hangot is továbbít. A válasz a hang csomag hálózat és a nyilvános telefon hálózat gazdaságossága közötti viszonytól függ, valamint a hang alkalmazásoktól, melyek behatárolják az átvitel minimális minőségét.

A legtöbb alkalmazás esetében a késleltetés jelenti a legnagyobb problémát. Az LPC hang kódolással, melyet a G.729 is alkalmaz, a hang csomag minősége kis késleltetésű hálózat esetén megegyezik a szabványos nyilvános telefonhálózatokban megtalálható hangminőséggel. A Frame Relay és az ATM hálózatok jellegükből adódóan olyanok, hogy a lehető legkisebb késleltetéssel továbbítják az adatot. Speciális késleltetés menedzsment mérésekre ritkán van szükség, akkor is legfeljebb csak ott, ahol a voice agent kapcsolódik a hálózathoz.

Az IP alapú hálózatok esetében, a késleltetés sok féle módon menedzselhető. Ahogy arról már korábban szó volt, az RSVP-n keresztül sok routert utasítani lehet arra, hogy tartson fent elkülönített erőforrás mennyiséget, és nagyobb prioritással kezeljen bizonyos típusú forgalmat, aminek köszönhetően a hangcsomagok késleltetése a hálózat forgalmától függetlenebbé válik.

Másik megoldás az lehet, hogy mindig nagyobb erőforrás mennyiséget biztosítunk a forgalom számára, mint amekkora az igényel, ezáltal elkerülhetjük a prioritás kezelést. A 70% feletti utilizációs szinten rohamosan nő a torlódások miatt fellépő késleltetési idő. A magas utilizációs szinttel rendelkező hálózatok nagy valószínűséggel beszéd minőség romlással számolhatnak.

A hálózat gazdaságossága nagy részt a magas utilizációs szinttől függ, ezért a router alapú menedzsment stratégiák sokkal inkább elterjedtek.

Jelzésrendszer: A hang összeköttetés létrehozása

A csomag alapú hang összeköttetéseknek és jelzésrendszereknek két fő modellje van.

·         A transzport modell – Ebben a modellben, két voice agent egy trönkön keresztül kapcsolódik a szállítást végző hálózati felhőhöz. Minden hívás ami az első voice agent-en kezdődik, a második voice agent-en kell hogy befejeződjön, így minden hang forgalom, amelyet az egyik létrehozott, a másik felé irányul. Ezt a modellt gyakran használják pont-pont hang kapcsolatoknál az Interneten. Hasonló a PBX bérelt vonali modelljéhez, ahol a kapcsolások és az összeköttetés teljes egészében a PBX dolga.

·         A transzlációs modell- ebben a modellben, akárhány voice agent kapcsolódhat a felhőhöz, abban az esetben, ha megérti az alkalmazott címzési és jelzés rendszert. A voice agent leképezi a natív telefon számokat az ATM, Frame Relay, vagy IP címekre, például egy telefonkönyvbe, vagy dial plan-ba, ahol az egyes címekhez /telefonszám, mellék/ be van jegyezve az is, hogy melyik voice agent-en keresztül lehet elérni. A dial plan-t mindig a kezdeményező voice agent használja arra, hogy megtudja, melyik másik voice agent felügyeli a hívandó számot, és melyik kapcsolaton keresztül lehet elérni azt a voice agent-et. Ez a modell tehát a hálózatot virtuális hang telefonközponttá, tandem kapcsolóvá alakítja.

3. Ábra Összeköttetés és jelzésrendszer modellek

A fenti 3. Ábra mutatja a két egymástól teljesen eltérő jelzésrendszer kapcsolatot a csomag alapú hálózatokban. Az első jelzésmódot külső jelzésrendszernek nevezzük /external signaling/, a voice agent és a hang berendezés között foglal helyet. Mivel ezek a hang berendezések arra készülnek, hogy hang hálózatokban üzemeljenek, ezért a külső jelzés a telefon szabványokon alapul. A másik típusa a jelzéseknek a voice agent és a hálózat között foglal helyet. Ez a belső jelzésrendszer /internal signaling/, mely a transzport hálózat, vagy a voice agent saját szabványán alapul.

Külső jelzésrendszer

Négy lehetséges alternatíva van a külső jelzésrendszerre melyeket általánosan támogatnak a csomag alapú hangátviteli rendszerek.

·         Szabványos DTMF, vagy analóg impulzus jelzés, melyeket a telefonokban is használnak. Ez a típusú jelzés alkalmas olyan csomag alapú alkalmazásoknál, ahol szabványos telefonkészülékeket kapcsolnak közvetlenül a voice agent-hez.

·         Analóg társközponti fővonal jelzésrendszer, más néven E&M jelzésrendszer, leginkább négy eres analóg trönköknél használatos.

·         Digitális közös csatornás jelzésrendszer, más néven CAS /Channel Associated Signaling/, digitális T1/E1 trönkökön szokták használni. A CAS szabványok földrészenként változnak, CAS esetén a jelzés információ ugyanazon az úton halad, mint maga a hang.

·         Digitális sávon kívüli jelzésrendszer, más néven CCS /Common Channel Signaling/, melynél minden egyes digitális trönk (T1/E1/J1) jelzése egyetlen, vagy több közös csatornában továbbítódik, külön választva a továbbított hangtól. Ez a módszer általánosan elterjedt a PBX-eknél . /például: DPNSS, illetve QSIG, ISDN D csatorna/

Más formát használnak a nyilvános telefonhálózattal való összeköttetéshez. Az SS7 /Signaling System 7/ jelzésrendszer egy belső protokol, sávon kívüli jelzést használ a hálózat egyes elemei között az összeköttetésekhez és a speciális szolgáltatások kérésénél /például ingyenes telefonszámok dekódolásánál/. A jövőbeni csomag alapú hangátviteli termékek valószínűleg támogatni fogják a SS7-et, mint külső jelzés protokollt.

Belső jelzésrendszer

A belső jelzésnek két sajátsággal kell rendelkeznie: összeköttetés vezérlés és hívás folyamat, illetve állapot információk.

Az összeköttetés vezérlés jelzésrendszere a kapcsolatok, vagy a voice agent-ek közötti utak létrehozásához a hangcsomagok áramlásának engedélyezésére szolgál. A hívási folyamat, illetve állapot információkat a voice agent-ek egymással kicserélik, ezzel jelezve a csengetést, a foglaltságot, és így tovább.

A hangcsomag hálózatok transzport modelljében, a belső jelzésrendszert elsődlegesen arra használják, hogy elkerüljék az állandó kapcsolatokat a transzport hálózaton keresztül, hogy támogassák a hívásokat a voice agent-ek között. A transzport modell belső összeköttetés jelzésrendszere összetartozik a kapcsolat orientált hálózatokkal, melyek fix sávszélesség erőforrásokat allokálnak. A csomagkapcsolt hálózatokon, nincs szükség összeköttetések létrehozására, hiszen a voice agent-ek egyszerűen csak megcímzik egymás felé a csomagokat, ha van átviendő információ.

A legtöbb hálózati típusnak /például ATM, Frame Relay, és IP / megvan a saját szabvány jelzésrendszere. Ezek az eltérő szabványok speciális voice agent-eket igényelnek.

A belső jelzésrendszer elfogadott modellje / összeköttetés, hívás lebonyolítás, / IP alapú hálózatok esetében a H.323 szabvány. A H.323 népszerű csomag alapú videó szabvány, és egy sor multimédiás kommunikáció szabványt definiál. A H.323 teljes multimédia hálózatot definiál, a berendezésektől kezdve egészen az alkalmazott protokollokig.

A H.323 kifejezéstárában, a voice agent-ek terminálok. A H.323 egy gatekeeper funkciót is definiál, mely cím fordítást és lookup-ot végez, a transzlációs modell számára.

Ha a hálózat különböző típusú transzport hálózatokból épül fel, a H.323 definiál egy gateway funkciót a hálózatok között, mely elvégzi a formátum fordítást és a jelzés fordítást melyek szükségesek a hálózati határokon keresztül történő szállításhoz.

A hangcsomag alkalmazások modellje mindig a felhasználó hálózatától függ. Ahol a csomag alapú összeköttetés társközponti fővonalként jelenik meg, a transzport modell és a szabványos hang kódolás és jelzésrendszer alkalmazása ajánlott.

 Ahol a több voice agent helyezkedik el a hálózati felhő körül, a transzlációs modell alkalmazása gazdaságosabb és nagyobb rugalmasságot biztosít. Ha a voice agent-ek különböző fajtájúak, rendkívül fontos, hogy a teljes rendszer a H.323 szabványon alapuljon, És ezzel biztosítva legyen a voice agent-ek és a katalógus funkciók /terminálok, gatekeeper-ek és gateway-ek/ kompatibilitása. Ilyenkor, a vásárlónak biztosnak kell lennie abban, hogy a H.323 részegységek támogatják a kiegészítő hang kódolási szabványokat, ha ezek szükségesek ahhoz, hogy biztosítsuk a hang minőségének szintjét és a hálózat gazdaságosságát.

A magán hálózatok esetében célszerű a H.323 alapú, homogén hálózatra törekedni a csomag alapú videó berendezések beszerzésénél, abban az esetben, ha a berendezések különböző gyártóktól származnak, ügyelni kell az egyes egységek közötti együttműködésre /tesztelés/. Mint ahogy más nemzetközi szabványok esetében is előfordul, a H.323 sok plusz funkciót enged meg, köztük sok igen hasznos hang tömörítési eljárást. Azonban az opcionális funkciók nem tartoznak bele szorosan a szabványba emiatt egyes berendezések nem feltétlenül rendelkeznek vele.

Gyakran előfordul, hogy a hálózat több szintű; IP szállítás Frame Relay-on, illetve ATM-en keresztül. Az ilyen típusú hálózatok esetében lehetőség van hangcsomagok küldésére bármelyik szinten, célszerű a szállításra legalkalmasabb szintet kiválasztani.

 

 

Csomag alapú hang hálózatok alkalmazása

A csomag alapú hang hálózatokat két nagy tényező alapján lehet jól felbontani: földrajzi fekvés alapján és a kiszolgált felhasználók típusai alapján. A hálózat gazdaságossága és az alkalmazott technológia nem befolyásolja ezeket a tényezőket, de lehetnek törvényes kényszerek sok térségben, ennek a két tényezőnek bizonyos kombinációinál.

A telekommunikáció országhatárokon belül és nemzetközi szinten egyaránt szigorúan szabályozott. Néhány országban, például az USA-ban többféle szintje van a szabályozásnak. Minden esetben szerződésekben rögzítettek a nemzetközi kapcsolatok szabályai, sebességei. Fontos minden hangátvitelre alkalmas hálózat tervezésénél, hogy ismerjük és betartsuk az ide vonatkozó előírásokat. A jelenlegi általános szabályozást a következőképpen foglalhatjuk össze:

·         A nemzeti szabályozás, illetve a távközlési törvények szinte minden esetben lehetővé teszik a vállalatok számára, hogy saját telephelyeiken hangátvitelre alkalmas csomag alapú hálózatokat építsenek ki.

·         Többnyire olyan hívások is szállíthatók ezeken a hálózatokon keresztül, melyek forrása hagyományos telefonhálózatban van.

·         Ha az ide vonatkozó előírások lehetővé teszik, más /akár másik országban lévő/ vállalatokkal létesített hangcsomag hálózati összeköttetések is megengedettek.

·         Olyan esetben ha egy külső, telefonhálózatból érkező hívás hang csomag hálózaton keresztül másik országba jut át, nemzeti monopóliumokat sérthet.

·         Amennyiben a hang csomag hálózat kapcsolja össze a vállalatot a nyilvános telefonhálózattal, a hangcsomag szolgáltató alapvetően helyi, illetve nemzetközi telefon szolgáltatást nyújt, melyre konkrét rendszabályok vonatkoznak.

·         Ha a hangcsomag hálózat nyilvános, országok közötti hívást tesz lehetővé, a hangcsomag szolgáltatóra nemcsak hazai, hanem a nemzetközi előírások is érvényesek.

 

A C&C Technológia

 

A C&C rövidítés, a Kommunikáció és Együttműködés /Communication and Collaboration/ szavakból származik. A C&C technológián belül öt fő területet különböztethetünk meg:

 

1.      Valós idejű együttműködési technológia /Real Time Collaboration Technology/

A valós idejű együttműködési technológia megoldásokat nyújt az egyidőben, együtt dolgozó emberek egymás közötti kommunikációjának javítására.

 

·         CTI technológia

Számítógép és telefon integráció /Computer Telephony Integration /, mely számítógépek segítségével irányítja a telefonokat. Hang és adat integráció.

 

·         Videó és dokumentum konferencia /Video és Document Conferencing/

Kiegészíti a CTI technológiát osztott vizuális munkahelyekkel. Ezeken a munkahelyeken több ember folytathat megbeszélést, hívásokat fogadhat, illetve kezdeményezhet és vizuális információkat szolgáltathat, valamint valós időben manipulálhatja a meg osztott anyagokat.

 

·         Tárol és továbbít együttműködési technológia /Store-and-Forward Collaboration Technology/

A nagy távolságok miatt valós idejű együttműködésre nincs lehetőség. A tárol és továbbít  technológia lehetőséget nyújt az emberek közötti együttműködésre, eltérő idő és hely esetén is.

 

·         Üzenetküldés /Messaging/

Magában foglalja az elektronikus leveleket, faxokat, hang üzeneteket és egyéb információkat, melyeket az egyik ember küld másik /lehet több/ embernek, és az információ érkezése és küldése időben egymástól kellően elkülönül.

 

·         Megjelenítés és tallózás /Publishing and browsing/

A megjelenítés és tallózás technológiák kiegészítik az üzenetküldési technológiákat. Az üzenetküldés direkt információ küldés, a megjelenítés és a tallózás technológiák esetén indirekt módon jutnak el az információk a személyekhez. Az információk azoknak áll rendelkezésére, akiknek jogosultságuk van a hozzáféréshez. Az Internet World Wide Web-je kiváló példa erre.

 

Az 5 fő terület közül az utóbbi időben leglátványosabb fejlődést, a CTI technológia produkált.

A CTI technológiának 3 aspektus van:

 

·         Hívás irányítás /Call control/
A hívás irányítás az a képesség, mellyel figyeljük és irányítjuk a telefonhívásokat, a kapcsolásokat és az állapotot, az ACD-ket és az ACD agent-eket, és olyan erőforrásokat használunk, mint pl: tone generátor, és tone detector.

 

·         Telefon vezérlés /Telephone Control/
A telefon vezérlés az a képesség, mellyel figyeljük és irányítjuk a ténylegesen létező telefon berendezéseket, illetve a számítógép perifériákat.

 

·         Eszköz hozzáférés /Media Access/
Az eszköz hozzáférés  magában foglalja a telefonhívások összekötését más médiákkal. /Pl: hang feldolgozás, fax feldolgozás, videókonferencia és telekommunikáció/.

 

 

CTI megoldástípusok

 

·         Hívás könyvelés
Hívás könyvelő alkalmazások, melyek  követik a hívásokat /hívott fél, hívó fél, hívás ideje, hívás időtartalma, stb./ figyelik a telefonok forgalmát, kihasználtságát, a szolgáltatások díját, stb.

 

·         Automata-hívás
Automata hívásokkal képessé válik a számítógép használója, hogy egyszerűen jelezze az igényét hogy beszélni akar valakivel. A CTI szoftver  magára vállalja a teljes folyamatot. Kikeresi a megfelelő személyt, kikeresi a hozzátartozó telefonszámot, meghatározza a hívás legoptimálisabb útvonalát /az időzóna, földrajzi hely, stb. függvényében/. Tárcsázza a számot és a számlázási információkat is lekezeli. Ezeknek az alkalmazásoknak elsősorban az időmegtakarítás szempontjából van jelentősége.

Az automatikus tárcsázás 1-10 másodpercet vesz igénybe, míg ez normális tárcsázás esetén /telefonszám kikeresése, tárcsázás, stb./ 15 másodperctől egészen 1 percig is terjedhet. A vállalatok napi sok száz telefonhívása esetén ez már havi lebontásban is  hatalmas idő (és természetesen pénz) megtakarítást jelent!

 

·         Képernyő alapú telefon  SBT  /Screen-based telephony/
A képernyő alapú /screen-based/ telefonok, olyan szoftverek, melyek telefonnal egyenértékű felületet  nyújtanak a felhasználónak. Az ilyen típusú telefonok ugyanúgy viselkednek, mint hagyományos társaik,  többnyire /implementálhatóságukból adódóan/ több plusz funkcióval rendelkeznek. Fontos tulajdonságuk, hogy a felhasználók egyéni igényeihez adaptálhatók (változtatható külső megjelenés, több/kevesebb funkció)
A megfigyelések azt bizonyítják, hogy a felhasználók sokkal több funkciót használnak telefonáláskor, mint a hagyományos asztali készülékek esetében (hívásvárakoztatás, parkoltatás, pick up/partner csoport, visszahíváskérés). Ez elsősorban az egyszerűbb használat miatt van, hiszen a hagyományos telefonok sok esetben  (*, illetve # beütése után) csak bonyolult számkombinációk után hajtották végre ezen funkciókat.

 

·         Ablakfeldobás /screen pop/
A bejövő hívások, automatikusan a  számítógép képernyőjére irányíthatók. Ilyenkor az ablakban megjelennek a hívó adatai, ami lehetővé teszi a számítógép mellett ülőnek, hogy felkészüljön a hívás fogadására, illetve tovább irányítsa más kollégákhoz, vagy a hangposta felé.

 

·         Programozható telefon
A számítógépben beállított jellemzők alapján a telefon vezérlése. Az alkalmazás lehet csak egy egyszerű bejövő hívás tiltás egy megadott telefonszámról, de lehet egy igen bonyolult interaktív válaszoló rendszer is, mely képes egy személyi titkárnő funkcióját ellátni.

 

·         Hangfeldolgozás
A programozható telefonok része, mely különböző médiák segítségével reagál a hívásra. Az egyszerűbb alkalmazások zenét játszanak le a várakozási idő alatt, hang üzenetet rögzítenek, a bonyolultabbak már hang infomációkat is képesek értelmezni.

 

·         Hívás irányítás /Call routing/
A programozható telefonok lehetőségei közé tartozik. Automatikus hívás továbbításra képes, adott telefonszámra. A hívás a telefon rendszer által szolgáltatott plusz információk alapján történik, vagy a hangfeldolgozás valamilyen művelete alapján.

 

·         Hívás megjelenítés /Call screening/
Lehetővé teszi a CTI technológia alkalmazásával a hívások szűrését és lekezelését. A hívások sorsa a hívó fél jellemzőitől /pl telefonszám/,  a hívó és a hívott szándékától egyaránt függnek. A felügyeleti hívás megjelenítés /Attended call screening/ ablakfeldobást használó megoldás. A képernyőn megjelenő információk alapján a felhasználó rögtön eldöntheti: szeretné-e fogadni a hívást. A döntést, a hívó telefonszáma alapján teszi meg.

 

·         Automatikus kezelő /Auto attendant/
Hang felismerés segítségével, hasonlóan a régi telefonos kezelőkhöz, kapcsolatba kerül a hívóval, és a kapott információk alapján a kívánt személyhez irányítja a hívást.

 

 

·         Információs visszakereső /Information retrieval/
Hang felismerő képességével megválaszolja /pl. visszajátsza/ a kért információkat, automatikusan, emberi beavatkozás nélkül. Alkalmazására intelligens üzenetrögzítőknél láthatunk példákat, ahol az üzeneteket parancsok kiadása után lehet lejátszatni, visszajátszani.

 

·         Fax visszaküldés /Fax-back/
Információ szolgáltatás faxon keresztül, melynek során a kérések faxhívások útján kerülnek megválaszolásra.

Összefoglalás

Napjaink nyilvános telefon hálózata sok szempontból ugyanolyan mint a 80’-as években elején volt. Ez idő alatt, robbanásszerű fejlődésen mentek keresztül az adathálózatok terén alkalmazott technológiák, melyek hatására az adat hálózatok gazdaságossága és az átvitel minősége egyre jobbá vált. Ez a fejlődés napjainkban is tart, az új irányt a hangátvitelt csomag alapú hálózatokon keresztül megoldó rendszerek jelentik. A hangcsomagok szállítása fejlett tömörítési algoritmusokat igényel, mint például az ACELP-alapú G.729, mely közel 16x kisebb sávszélességet igényel a hagyományos telefonhálózatokban alkalmazott PCM-hez képest. A felhasználók a már kiépített adat hálózatukon keresztül könnyen továbbíthatja a hang forgalmukat is, minimális költségekkel, illetve akár költségek nélkül. A vonalkapcsolt T1/E1/J1 hang hálózatok felhasználói a hangcsomag hálózat átvitellel plusz sávszélességet, tudnak felszabadítania a hang trönkökről, melyet akár adattovábbításra is felhasználhatnak.

Nem minden hálózat és nem minden felhasználó képes a csomag alapú hálózatok segítségével lecsökkenteni a telefonköltségeit. Néhány hálózat nem rendelkezik elégséges erőforrás tartalékkal a betömörített hang továbbítására. Az ilyen hálózatok fejlesztése a hangátvitel érdekében, előzetes pénzügyi analízist igényelnek. Leszögezhetjük, hogy a hangátvitelre alkalmas csomag alapú hálózatok sosem lesznek drágábbak mint a hagyományos vonalkapcsolt hálózatok, többnyire messze elmaradnak azok költségeitől és ezáltal rövid és hosszú távon egyaránt megéri őket megvalósítani.

VoIP technológia

Bevezető

Ebben a fejezetben azoknak a technológiáknak az ismertetése található, amelyek lehetővé teszik csomag alapú telefonhálózatok, speciálisan a Voice over IP rendszerek alkalmazását. A hangátvitel szempontjából olyan alapfokú ismereteket biztosít, amelyek a hang technológia csomag alapú hálózatokban történő alkalmazásának a megértéséhez szükségesek.

Késleltetés

A feldolgozási késleltetés a hagyományos telefonhálózatban is probléma azonban a csomag alapú hálózatokban nagyobb körültekintést igényel. A következő részben a különböző feldolgozási késleltetések és ezek hatásainak ismertetése található.

A G.729 kódoló algoritmusból adódó késleltetése körülbelül 20 ms. A Cisco IOS voice over IP termékek minden 10 ms-ban egy frame-et generálnak. Ezután két darab hang frame kerül egy hang packet-be, így kapjuk meg a 20 ms késleltetést. A különböző gyártók eldönthetik, hogy egy packet-ban hány hang frame kerüljön továbbításra. A Cisco termékekben a DSP processzor végzi a hang csomagok kezelésével kapcsolatos összes műveletet, annak érdekében, hogy a routernek minél kevesebb hangtovábbítással kapcsolatos többletfeladatot kelljen elvégezni, ezzel a javítva a routing feladatok gyorsaságát. Például a  Real-Time Transport Protocol (RTP) fejléc hozzáillesztése a csomagokhoz, a DSP áramkörben történik.

A csomag alapú hálózatokban több más késleltetés is adódik, a csomagok sorbarendezése és a sorban várakozás a továbbításra, további késleltetést okoz. A Cisco IOS szoftver kifinomult routing algoritmussal rendelkezik, más PC alapú eszközökhöz képest kisebb az ilyen típusú késleltetése. A kimeneti tárolóba kerüléstől a továbbításig eltelt idő a megfelelő sorbaállítási algoritmusok megválasztásával 10 ms alatt tartható. A 2. Táblázat a különböző típusú kódolók különböző késleltetés értékeit tartalmazza.

 

Compression Method

Bit Rate (kbps)

Compression Delay (ms)

G.711 PCM

64

0.75

G.726 ADPCM

32

1

G.728 LD-CELP

16

3–5

G.729 CS-ACELP

8

10

G.729a CS-ACELP

8

10

G.723.1 MP-MLQ

6.3

30

G.723.1 ACELP

5.3

30

2. Táblázat Kódolók késleltetései

További két tényező befolyásolja a késleltetést. Az abszolút késleltetés kihathat a telefonbeszélgetés szokványos ritmusára, és a késleltetés változás vagy jitter szintén befolyással van a beszédminőségre. Az abszolút késleltetés kieséseket okozhat a beszédben, megtörheti a ritmusát, vagy nagyon nagy késleltetés esetén CB-szerűvé válhat a kommunikáció, amikor is a beszélőnek külön szóval kell jelezni, azt, hogy befejezte a mondatot és a másik fél beszélhet.

A Jitter, a csomag várt érkezési ideje és a valós megérkezése idő között eltelt időtartam. A csomag alapú eszközöknek gondoskodniuk kell a jitter kompenzálásról. Az eszközök kimenetén egy megfelelő nagyságú buffer használatával biztosítani lehet a csomagok egyenletes feldolgozását, elkerülve ezzel a beszéd megszakadását.

A felhasználói oldalról a kimeneti buffer konfigurálás igen egyszerű. Az RTP enkapszulációt használva az ’adaptive playout-delay mode’ (alapbeállítás) kiválasztása lehetséges. A konfiguráció beállításánál definiálni kell egy kezdeti (nominális) értéket (alapértékben 60 ms) és egy maximum értéket (alapértékben 200 ms), feltételezve, azt hogy földi vonalakat figyelembe véve a G.729 esetében, a késleltetés nem lesz több mint 300 ms. Az adaptív kimeneti késleltetést megnöveljük ezzel a maximum értékkel. Ennek két oka van, az egyik, az hogy a maximális késleltetést, a DSP-ben a jitter buffer számára allokált memória határozza meg. Az aktuális DSP firmware verzióban a 64 kbps kódolók számára 200 ms, a 8 kbps kódolók számára pedig 1360 ms-nyi kimeneti késleltetés memória van allokálva. A másik ok pedig az, hogy ezáltal beállíthatunk egy maximális szintet ennek a kimeneti késleltetés komponensek. Abban az esetben, ha a késleltetés meghaladja a maximális értéket, tehát a kimeneti buffer kiürül az újabb csomagok megérkezése előtt, akkor lehetőség van a kapcsolat bontására, valamint a kimenti buffer statisztika jelzi a buffer kicsordulást. A minimális kimeneti késleltetés konfigurálása nem szükséges. Az ideális érték a 0, a Cisco eszközökben ez az érték 2 ms.

A vételi késleltetés tartalmazza a jitter kompenzálásához szükséges kimeneti késleltetést, valamint egy átlagos késleltetés értéket (a keretek megérkezése és a dekódolásra kerülés közötti idő), ami a PCM, és ADPCM esetében 5 ms, G.729 kódolóknál pedig 10 ms. Mindkét oldalon hozzáadva ezeket a késleltetéseket a kódolási, a csomagolási és a hálózati késleltetéshez, megkapjuk a kapcsolat két végpont közötti teljes késleltetését. A kódolási késleltetés tartalmazza az 5 ms-os VAD (voice activity detection) késleltetést, valamint a visszhangtörlés megvalósításához szükséges időt. A pont-pont késleltetés elemeinek a meghatározása egyszerű abban az esetben, ha ismert a teljes útvonal, a kódoló típusa valamint a csomagméret. Például egy egyetemi hálózatban, ahol a hálózati késleltetés fix értékei és a csatlakozási késleltetés közel nullával egyenlők, a kódoló típusa G.729 és a csomagméret 20 byte, a kódolási késleltetés 20 ms lesz, plusz ehhez hozzáadódik még 20 ms csomagolási késleltetés (a következő keret érkezéséig eltelt idő). Hozzáadva ezt a 40 ms-ot a vételi késleltetéshez egy elég jó becslést kapunk a teljes pont-pont késleltetéshez. A fenti példában, ha nincsen adattorlódás a teljes pont-pont késleltetés 50 ms körüli értéknek adódik. A vételi késleltetés esetében az aktuális, a minimális és a maximális érték statisztikát tartalmazzák az eszközök.

Amikor egy csomag nem érkezik meg az adott kimeneti késleltetés időtartamban vagy elveszik, kimeneti hibák keletkeznek. A hiányzó csomagok kiküszöbölése különbözik attól függően, hogy a hiba beszéd közben vagy olyan időszakra esik, amikor éppen nincsen beszéd. A beszédidőszakra eső csomagok a folyamatos hiányzó rész hosszúságától függően, pótolva lesznek az előző, meglévő mintákból. Ha 30-50 ms-ig nem érkezik érvényes csomag, akkor csend információ kerül a kimenetre.

Kimeneti bufferkezelés

A következő részben a kódoló kimeneti oldalán megvalósított késleltetés-vezérlés ismertetése olvasható.

A beérkező csomagok esetében a késleltetés értéke egy referencia késleltetéshez viszonyított érték, ez a referencia érték azonos a csomag megérkezése előtti időszakban mért minimum késleltetéssel. Az aktuális mintától időben távolodó minták exponenciálisan kisebb súllyal számítanak bele a referencia értékbe. Erre azért van szükség, nehogy egy 5000-10000 csomaggal régebbi abszolút minimum késleltetéssel érkező minta, végleg beállítsa a referencia késleltetést. Ha egy beérkező csomag késleltetése kisebb, mint a pillanatnyi referencia, és a csomag megfelelő sorrendben érkezett meg a referencia érték törlődik.

A megvalósítást követve a delay_Now változó a jitter buffer aktuális nagyságát jellemzi, a delay_update változó pedig a beérkező csomagok aktuális késleltetését követi. A jitter buffer  nagysága ezen változók segítségével követi az aktuális csomagok késleltetését. A legtöbb esetben a delay_Now változó a delay_update értékét veszi fel egy beszédfolyam elején. Ez a kiigazítás akkor is megtörténik, amikor a delay_update változó több mint 25 %-al eltér a delay_Now értékétől. Az utóbbi kiigazítás magyarázatul szolgál azokra az esetekre, amikor a VAD nem működik vagy a jitter gyorsan változik. Ezáltal elkerülhető az, hogy a delay_Now túl nagymértékben térjen el a delay_update értékétől.

Abban az esetben, amikor egy bejövő csomag késleltetése a delay_update 50-75%-a, nincs szükség frissítésre. Ha az előző szituáció elég hosszú ideig fennállna a referencia késleltetés úgy egyenlítődne ki, hogy az aktuális késleltetés kiesne ebből az 50-75%-os  sávból és a delay_update addig illeszkedne amíg be nem áll egy új értékre, kivéve abban az estben amikor a delay_update értéke azonos a minimum kimeneti késleltetéssel.

A delay_update növelése a delay_update 1/64-ed részével történik, ha a csomag késleltetése a delay_update 75-100%-a közé esik, ha a késleltetés meghaladja a 100%-ot a növelés üteme 25%-ra nő. A késleltetés felfelé irányuló növelése azért ilyen agresszív módon történik, mert ebben az esetben kevés csomag fog kiesni (elveszve ezáltal) az aktuális jitter buffer méretből.

A delay_update csökkentése akkor következik be, amikor a csomag késleltetése kisebb, mint a delay_update 50%-a. A csökkentés üteme sokkal kisebb, mint a növelésé. A delay_update 50%-os csökkenése 200-300 csomagnyi idő alatt megy végbe. Ez az idő 20 ms-os csomagidőtartamot figyelembe véve 4-6 másodperc, szintén 20 ms-os csomagok mellett kb. 15 másodpercet (kb. 750 csomag) igényel a delay_update lecsökkentése a maximum értékről a minimumra, ha a jitter a csomag időtartam alá esik. Körülbelül 6 csengetési idő alatt lecsökken a delay buffer nagysága a kezdeti (nominal_delay) 100 ms-os értékéről a minimum 2 ms-os értékre, abban az estben, ha nincs hangforgalom. A konvergencia exponenciális jellege miatt nem tartana sokkal tovább a minimumra csökkenés, egy magasabb kiindulási értékről sem.

H.323 alapok

Az ITU-T H.323 specifikáció multimédia (hang, adat, videó) információ továbbítását teszi lehetővé olyan lokális számítógép hálózatokon keresztül, amelyek nem rendelkeznek garantált minőségi paraméterekkel. A lokális hálózat használhat IP, IPX vagy tetszőleges hálózati protokollokat. A H.323 alkalmazásával biztosítható a különböző gyártók közötti együttműködés.

A H.323 a kommunikációban részt vevő elemeket specifikálja. Ezek az elemek a következők: H.323 MCU, H.323 gateway és a H.323 gatekeeper. A H.323 szabványnak nem része bármilyen QoS paraméter specifikálás. Egy H.323 terminál feladata hang és opcionálisan videó és adat továbbítás.

A H.323 protokoll magába foglalja az audió, videó, és hang-alkalmazásokat valamint ezek vezérlését. Az ajánlott audió kódolók a következők: G.711, G.722, G.723.1, G.728 és a G.729. A voice IP fórum a G.723.1 kódolási eljárást ajánlja VoIP alkalmazásokra. A videó kódolás területén a H.261 és a H.263 kódolók ajánlottak. A H.323 terminálok vezérléséhez a H.245, H.225.0 a Registration/Admission/Status (RAS), és a RTP/RTPControl Protocol (RTCP) protokollok használatosak.

A H.245 kontrol csatorna biztosítja a megbízható átvitelt a különböző jelzés információk számára (capabilities exchange, logical channel signaling, control, indication). A TCP biztosítja a VoIP számára a megbízható továbbítást. A H.245 segítségével tudják a H.323 terminálok közölni egymással a szolgáltatási paramétereiket, pl, azt hogy milyen kódolásra képesek.

H.225.0 protokoll a Q.931 egyszerűsített változatát használja, a H.323 terminálok közötti kapcsolat kiépítésére.

A RAS protokoll a H.323 gateway és gatekeeper kommunikációhoz használatos. A gatekeeper nem kötelező elem a H.323 hálózatban. A szabvány nem specifikálja, azt hogy a gatekeeper funkciókat mely eszköznek kell megvalósítania. A különböző gyártók maguk dönthetik el hogy melyik fizikai eszköz látja el ezen funkciókat.

Az RTP és az RTCP specifikációit a H.323 is tartalmazza. Miután a H.323 hívás-felépítési folyamat lezajlott, a hang és videó csomagok továbbítása UDP prtokollt (3. Táblázat) használva történik. Az audió és videó jelfolyam sorrendi kezelését az RTP fejlécben levő információk alapján végzik a H.323 eszközök. Az RTP fejléc tartalmaz egy idő megjelölést (time stamp) és egy sorozat számot (sequence number), aminek a segítségével az eszközök kezelni tudják a kimeneti buffer nagyságát, kiküszöbölve a hálózati jittert és késleltetést.

Az RTP és RTCP protokollok biztosítják a késleltetés és időérzékeny információk továbbítását a nem garantált paraméterű hálózatokon. Az RTCP protokol feladata a hálózat paramétereinek a figyelemmel követése és ezen információk közlése a résztvevő elemekkel. Az RTCP forgalom nem lépheti túl a hálózati forgalom 5%-át.

From

To

Application

Priority

0

16383

Not specified

Lowest

16384

32767

Audió

Highest

32768

49151

Whiteboard

Medium

49152

65535

Video

Low

3. Táblázat UDP portok

A H.323 rendszer elemei

Az ITU H.323 Ajánlás tartalmazza a H.323 kompatíbilis rendszer komponenseit. A komponensek lehetnek terminálok, gateway, gatekeeper, multipoint controller (MC), multipoint processor (MP) és multipoint control unit (MCU). A H.323 hálózat tartalmazhat még az IP kommunikációhoz, a biztonsági , QoS, proxi, firewall feladatok ellátásához szükséges elemeket.

H.323 terminál

A H.323 terminál a LAN hálózaton elhelyezkedő kommunikációs végpont, amelyik alkalmas valós idejű kétirányú kommunikációra másik H.323 terminállal, gateway-al, vagy MCU-val. A kommunikáció magában foglalja a kontrol, visszajelzés, audió, színes videó, és adat forgalmat a terminálok között. Bármely terminál kommunikálhat csak hang, hang és adat, hang és videó, és hang adat videó módban. Több H.323 terminál fejlesztés alatt áll pl. Internet telefon, audió, videó konferencia terminálok.

4. Ábra H.323 termiálok együttműködése

A H.323 terminál által kötelezően támogatott elemek:

·         H.245 csatorna használat és képesség egyeztetés protokoll

·         Q.931 hívásfelépítés/vezérlés

·         RAS protokoll a gatekeeperrel való kummunikációhoz

·         RTP/RTCP audió és videó csomagok időzítése, sorrendi kezelése

A H.323 terminál által opcionálisan támogatott elemek

·         Videó kodek

·         T.120 adatkonferencia protokoll

·         MCU képességek

·         Gateway

Az 4. Ábra a különböző H.323 terminálok közötti együttműködést mutatja.

Gateway

A gateway a H.323 opcionális eleme. A gateway a LAN hálózaton elhelyezkedő eszköz, feladata a való idejű, kétirányú kommunikáció biztosítása a LAN-on elhelyezkedő H.323 terminálok és gateway-ek valamint a WAN hálózaton elhelyezkedő más, H.425 és Q.931 protokollt használó ITU terminálok között.

A gateway alkalmazására akkor kerül sor, amikor a következő kommunikációk valamelyikére szükség van:

·         Analóg PSTN kapcsolat

·         H.320 terminál ISDN kommunikáció

·         H.324 terminál PSTN kommunikáció

A gateway letükrözi a LAN H.323 terminál karakterisztikáját a WAN terminál számára és vissza. A gateway képes a H.323 konferencia elemek és terminálok közötti konverzióra. Ez a funkció kiterjed a különböző formátumok (pl., H.225-ről H.221-re), és a különböző kommunikációs eljárások (pl., H.245-ről H.242-re) közötti konvertálásra. A gateway képes az audió és videó kodekek közötti konvertálásra, valamint a LAN és a WAN oldalon hívásfelépítésre és bontásra. A H.323 gateway képes továbbá H.310, H. 321, H.322, és V.70 szabványú terminálok támogatására. A 5. Ábra egy H.323/H.320 gateway-t illusztrál.

5. Ábra H.323/H.320 gateway

Proxy gateway

A proxi gateway egy speciális gateway, biztonságos kapcsolatot biztosít a H.323 terminálok számára. A Cisco Multimedia Conference Manager tartalmaz proxy szolgáltatást, amivel traffic shaping, security, és policy menedzsment szolgáltatásokat tud nyújtani biztonságos csatornán keresztül.

Gatekeeper

A gatekeeper a H.323 opcionális eleme, hívásvezérlő szolgáltatásokat nyújt a H.323 végpontok számára. Egy vagy akár több gatekeeper is lehet egy hálózatban, logikailag elkülönül a hálózati végponttól. Ameddig a gatekeeper-gatekeeper kommunikációs szabványok nincsenek megalkotva a fizikai implementáció közös lehet a terminállal, MCU-val, gateway-el vagy más nem-H.323 LAN eszközzel.

A gatekeeper szolgáltatásai a következők:

·         Address translation—Alias címek használata címfordításnál. A gatekeeper egy translation táblát használ, amit regisztrációs üzenetek felhasználásával frissít.

·         Admission control—LAN hozzáférés authorizálás ARQ/ACF/ARJ/H.225.0 üzeneteket használva. Használhatjuk oly módon, hogy minden kérelmet elfogadjon szűrés nélkül (null function).

·         Bandwith control— BRQ/BRJ/BCF üzenetek támogatása, Használhatjuk oly módon, hogy minden sávszélesség igény kérelmet elfogadjon szűrés nélkül (null function).

·         Zone management—A fenti funkciók biztosítása regisztrált terminálok, MCU-k, és gateway-ek számára.

Opcionális gatekeeper funkciók lehetnek a következők:

·         Call control signaling—a gatekeeper vezérli a jelzéscsatornák (Q.931 protokoll) kiépülését a végpontok között, egy végpont között kiépülhet közvetlen vagy a gatekeeper-en keresztüli jelzéscsatorna.

·         Call authorization—A H.225 jelzések alapján a gatekeeper elutasíthat hívásokat jogosultsági hibák esetén. A jogosultsági vizsgálatok alapulhatnak fizikai (pl. bizonyos eszközök csak bizonyos gateway, terminálhoz férhetnek hozzá) vagy időkorlát jogokon.

·         Bandwith management—H.323 terminálok egy időbeni többszörös LAN hozzáférésének a vezérlése. Sávszélesség szegény esetekben a gatekeeper a H.225.0 jelzések használatával elutasíthatja a terminál felől érkező hívásokat. Ez a funkció akkor is működik, amikor egy aktív terminál több sávszélességet igényel.

·         Call management— Az aktív H.323 kapcsolat nyilvántartása. Ezek az információk jelzik, pl. azt hogy a hívott terminál foglalt, vagy információval szolgálnak más erőforrás menedzsment funkcióknak.

·         Directory services

Az ITU a következő két funkciót a H.323 szabvány következő verziójáig nem specifikálta:

·         Gatekeeper menedzsment információ adatstruktúra

·         Sávszélesség allokálás azon terminálok számára, amelyek nem támogatják ezt a funkciót.

A Cisco MCM tartalmaz gatekeeper funkciókat, amelyek autentikációs, sávszélesség menedzsment, jogosultság hozzáférés szolgáltatásokat nyújtanak. A Cisco Proxy-val együttműködve további erőforrás allokálási/menedzselési, hívásvezérlési, H.323 traffic shaping és alkalmazás specifikus routing szolgáltatásokat képes nyújtani.

Multipoint controller

A multipoint controller (MC) a LAN hálózaton elhelyezkedő H.323 eszköz, amely három vagy több terminál konferencia kommunikációját irányítja. Vezérelhet olyan pont-pont kapcsolatokat, amelyekbe később újabb felek vonhatók be. A terminálok az MC segítségével képesek egymás képességeinek a megismerésére. Vezérelhet egyéb konferencia erőforrásokat, mint például a multicast videó.

Az MC funkció fizikailag megvalósítható a gatekeeper, a gateway, a terminál, vagy az MCU eszközben. A H.323 szerint egy multipont konferenciában egyszerre egy MC lehet.

Multipoint Processor

A multipoint processor (MP) a LAN hálózaton elhelyezkedő H.323 eszköz, amelyik központosított módon dolgozza fel a konferenciában résztvevő elemek adat, videó, és audió folyamait. Az MP végzi a különböző adatfolyamok keverését, kapcsolását, feldolgozását az MC utasításai alapján.

Multipoint Control Unit

A multipoint control unit (MCU) teszi lehetővé a három vagy több fél közötti konferenciát. A H.323 szerint az MCU egy a központosított konferencia vezérléshez szükséges MC-t, és az információfolyamok feldolgozásához szükséges opcionális egy MP-t tartalmaz.

A H.323 szabvány szerint csak a centralizált multipont konferencia esetén kötelező az MCU jelenléte, az elosztott konferencia esetén különböző multicast technikák alkalmazásával történik az adminisztráció.

A H.323 multipont konferenciában résztvevő terminálok a kommunikáció alatt az MCU-val állnak pont-pont kapcsolatban, mind az információtovábbítás mind pedig a vezérlés szempontjából. Az MC funkció végzi a H.245 jelzések alapján a kommunikáció kiépítéséhez szükséges képességek egyeztetését a különböző résztvevők között. Továbbá az MC vezérli konferencia erőforrásokat, nyilvántartva azt, hogy melyik audió, videó folyam multicast. Az MP kezeli közvetlenül az audió és videó folyamokat, valamint elvégzi a konvertálást a különböző kódolások és sebességek között.

Elosztott multipont konferencia esetés a terminálok multicast módon továbbítják az audió, videó folyamokat, a H.245 jelzésinformáció feldolgozását ebben az esetben is végezheti MCU.

Hibrid multipont konferencia esetén a centralizált és az elosztott vezérlés kombinációját használják. Ebben az esetben az MCU a centralizált és elosztott vezérlésű konferencia terminálok közötti bridge-elést végez, a terminálok számára ebben az esetben az MCU átlátszó.

A H.323 szabvány ismertetése

A H.323 szabvány a H.320 szabvány kiterjesztése, ami által az intranet és más csomagkapcsolt hálózatok számára is lehetővé válik a multimédia és konferencia információk továbbítása. A H.323 szabvány részei azok az eszközök, amelyek részt vesznek vagy vezérlik a H.323 kommunikációt. A szabvány nem foglalkozik a LAN hálózattal, valamint a LAN hálózatokat összekötő protokollokkal.

A többi ITU multimédia szabványhoz hasonlóan a H.323 pont-pont és pont-multipont kapcsolatok kiépítését teszi lehetővé. A konferencia kommunikáció lehet centralizált vagy szétosztott vezérlésű.

Az ITU által specifikált komponensek:

·         H.225: Hívásvezérléshez szükséges üzenetek, mint jelzések, azonosítás, csomagkezelés, szinkronizálás,

·         H.245: Különböző média folyamok felépítéséhez szükséges üzenetek

·         H.261: Videó kodek, Nx64 Kbps sebességekre

·         H.263: Analóg telefonvonalakon használatos új videó kodek

·         G.711: Audió kodek, 3.1 KHz mintavételi sávval 48, 56, és 64 Kbps sebességekre

·         G.722: Audió kodek, 7 KHz mintavételi sávval 48, 56, and 64 Kbps

·         G.728: Audió kodek, 3.1 KHz , 16 Kbps

·         G.723: Audió kodek, 5.3 és 6.3 Kbps

·         G.729: Audió kodek

A H.323 előnyei:

·         Rugalmas és átfogó konfiguráció VoIP, asztali videó konferencia, whiteboard alkalmazásokhoz

·         Multimédia szabvány a már meglévő szabványos IP alapú infrastruktúrára, az új szabvány szükségtelenné teszi a számítógépes és hálózati infrastruktúra kicserélését

·         A hálózat erőforrásainak a menedzselése, ezáltal elkerülhető a hálózati torlódás vagy blokkolódás multimédia konferencia esetén. Az MCM lehetővé teszi a konferencia számára rendelkezésre álló sávszélesség korlátozását.

·         Az iparág, vezető vállalati által támogatott: Cisco, Intel, Microsoft…

·         Platform független. A H.323 elemek nincsenek semmilyen hardware-hez vagy operációs rendszerhez kötve, a megvalósítás széles eszköz határok között változhat, pl. PC, célhardware..

·         A konferencia kapcsolat nem csak azonos típusú és képességű eszközök között jöhet létre. Például egy audió terminál részt vehet egy konferenciában olyan terminálokkal, amelyek audió és videó átvitelt is támogatnak.

·         A H.323 képes konferenciahívásra, speciális multipont vezérlő egység nélkül

·         A H.323 segítségével lehetőség van két egymástól távol lévő LAN felhasználók konferencia kommunikációjára. Az RTP/RTCP protokollok lehetővé teszik a videótovábbítást az interneten.

H.323 Audió

Az audió jelek digitalizált, tömörített, többnyire beszéd információt tartalmaznak. A H.323 támogatja az ITU G.711 56 és 64 kbps kódolási algoritmusát, valamint opcionálisan az ITU G.722,G.723, G.728, G.729 kódolókat.

H.323 Video

A videó képességek opcionálisak. A videó átvitelre alkalmas H.323 terminálnak támogatnia kell a H.261 kódolást, és opcionálisan a H.263 támogatást. Mind a H.261 mind pedig a H.263 rendelkezik QCIF, támogatással. A különböző típusú terminálok közötti kommunikáció lehetséges.

Format

ImageSize

H.261

H.263

Sub-QCIF

128x96

optional

Required

QCIF

176x144

required

Required

CIF

352x288

optional

Optional

4CIF

702x576

N/A

Optional

16CIF

1408x1152

N/A

Optional

4. Táblázat Video formátumok

Az H.261 nX64 Kbps csatornákat használ a videó információ továbbítására. A H.261 kódolásban nem a képminták teljes továbbítása történik, meg hanem csak az egymást, időben követő minták közötti különbség. Állókép esetén így minimális sávszélesség szükséges.

A H.263 szabvány a H.261 újabb változata, és felülről kompatibilis. Jelentősen jobb képminőséggel rendelkezik, újabb, az alacsony sebességű továbbításhoz optimalizált prediktív elven működő kódolást, és Huffman kódtáblát használ.

H.323 adat

A H.323 ajánlás opcionális jelleggel tartalmaz konferenciahívás melletti adattovábbítás támogatást. Ez magában foglal hálózati adattovábbítást, közös applikáció használatot, file mozgatást, vagy whiteboard felhasználást. A H.323 rendszer támogatja a T.120 alatti adatforgalmat. A T.120 ajánlás a pont-pont és pont-multipont adatkonferencia applikációs, hálózati és szállítási rétegét írja le.

Jelzés

A H.323 egy bizonyos TCP portot használ a Q.931 jelzés kommunikációra. A H.245 jelzések különböző portokon mennek, a különböző adat, hang, videó csatornák esetében a portok egyeztetése automatikusan történik a végpontok között. Ez a dinamikus portkijelölés megnehezíti a különböző biztonsági, policy, traffic shaping funkciók alkalmazását.

A H.323 adatkonferencia használ garantált és nem garantált kapcsolatot. A garantált összeköttetésen a vezérlési információk valamint az adatforgalom folyik. A nem garantált kapcsolatot pedig az audió és videó folyamok használják. A nagy késleltetést szenvedő audió és videó csomagok eldobásra kerülnek. Tehát a H.245 vezérlő csatorna, a T.120 adatcsatorna és a hívásvezérlő csatorna TCP kapcsolatokon kommunikál, míg az audió a videó és a RAS csatornák az UDP protokollt használják.

A Cisco H.323 eszközök támogatják a H.323 alkalmazásokban a legtöbb IETF IP protokollt és eljárást: (IP multicasting, RTP/RTCP header compression, IP precedence, RSVP).

H.323 biztonsági kérdései

Mivel a H.323 kompatíbilis alkalmazások dinamikusan allokált portokat használnak az audió, videó, és adatcsatornák továbbításához, egy tűzfal intelligensen tudja kezelni a H.323 forgalmat. A tűzfalnak rendelkeznie kell egy H.323 proxival, vagy tudnia kell a H.323 kontrol csatorna üzeneteiről ahhoz, hogy megállapítsa az éppen aktív H.323 portot és engedélyezze azt, amíg a kontrol csatorna aktív. A Cisco PIX Firewall és a Cisco IOS Firewall Features Set képes engedélyezni a dinamikusan felépülő H.323 portok forgalmát, a kontrol csatorna üzeneteinek a feldolgozása alapján.

H.323 alkalmazások Cisco környezetben

A videokonferencia megoldások az 1980-as évek óta teszik lehetővé a távoli helyszínek közötti hatékonyabb kommunikációt. Az első generációs megoldások az ITU H.230 szabványát használták az ISDN alapú videó konferencia megvalósításához. A második generáció eszközök már a személy számítógépet is felhasználták, de még mindig kötve voltak az ISDN vonalakhoz és a drága kodekekhez. A 90-es évek közepétől kezdve a harmadik generációs berendezések egyre általánosabbá váltak, azonban ezek az eszközök még mindig nem alapultak semmilyen szabványon, a különböző gyártók eszközei sokszor nem működtek együtt.

Az új H.323 és H.324 szabványok lehetővé teszik az újabb és jobb alkalmazások mellett a különböző rendszerek széles körű együttműködését. A H.323 szabvány LAN-on míg a H.324 hagyományos telefonvonalon keresztüli videokonferencia beszélgetést definiál. Ezen alkalmazásoknak a legtöbb eleme könnyen elérhető, a szoftverek az internetről letölthetők, a digitális videó készülékek általánossá váltak, ezzel az asztali videokonferencia széles körű elterjedésének megvannak a feltételei.

A H.323 szabvány alkalmazásának a mai fejlett számítástechnikai környezetben megvan minden feltétele:

·         A mai PC-k támogatják a multimédia alkalmazásokat,

·         A számítógép hálózatokban egyre elterjedtebb a nagyobb sávszélességet adó kapcsolt 10 Mbps sebességű portok használata, valamint megjelentek a 100 Mbps és gigabit sebességű eszközök is

·         A felhasználók igénylik az eszköz és szoftverfüggetlen konferencia lehetőségét

A Cisco a kezdetektől fogva elkötelezte magát a multimédia rendszerek támogatása mellett, mára a Cisco IOS és más Cisco eszközök támogatják a multimédia alkalmazások megvalósításához szükséges H.323 szabványt. Ezek az eszközök biztosítják a megfelelő infrastruktúrát és intelligenciát a multimédia alkalmazások IP hálózaton való továbbításához. Jelenleg a Cisco PIX Firewall és Cisco IOS támogatja az intelligens H.323 konferencia alkalmazásokat.

Cisco Multimedia Conference Manager

Cisco Multimedia Conference Manager egy speciális IOS szoftver. A Cisco MCM alkalmazásával a hálózatok képesek lesznek a H.323 alkalmazások futtatására a többi kritikus alkalmazás mellett. A Cisco MCM két H.323 komponenst valósít meg a gatekeeper és a proxy funkciókat. Ezeknek a részletesebb ismertetése a későbbiekben ismertetésre kerül. A Cisco MCM alkalmazásával a hálózatok képesek lesznek a H.323 forgalom kezelésére. A Cisco MCM további előnye, hogy a jól ismert és elterjedt IOS szoftver része, kihasználja a szoftver többi biztonsági és QoS funkcióját.

Cisco Multimedia Conference Manager funkciók:

·         Felhasználó jogosultság vizsgálat.

·         Biztonságoz cím feloldás

·         Nyilvántartás (Accounting)

·         Sávszélesség allokáció a LAN hálózaton a H.323 alkalmazások számára

·         Sávszélesség allokáció a WAN hálózaton a H.323 alkalmazások számára

·         QoS biztosítása H.323 konferencia számára

·         Biztonságos intranet alapú H.323 kommunikáció

H.323 alkalmazások a Cisco Multimedia Conference Manager használatával

A következő fejezetben a Cisco MCM, gatekeeper és proxy felhasználásával megvalósított H.323 szabványos pont-pont multimédia alkalmazások ismertetése következik.

A gatekeeper alrendszer szolgáltatásai:

·         Felhasználó engedélyezés, ahol a jogokat AAA (authentication, authorization, accunting) rekordok tartalmazzák

·         Zóna menedzsment az aktív kapcsolatok limitálására

·         H.323 hívás routing

·         Cím meghatározás

A proxy alrendszer szolgáltatásai:

·         H.323 forgalom engedélyezés

·         Hatékony sávszélesség szabályozás

·         QoS eljárások alkalmazásának a lehetősége: IP Precedence, RSVP

·         Biztonságos kommunikáció külső hálózatokkal

Terminálok, a Gatekeeper és Proxy együttműködése

A H.323 terminálok zónákba vannak szervezve, ez adminisztráció szempontjából hasonló Domain Name Server (DNS) doménhoz. Mindegyik zónában található egy gatekeeper ami a zónán belüli forgalmat vezérli. Mivel a gatekeeper jelenleg opcionális elem a H.323 szabványban, ha egy hálózatban Cisco proxy-t használunk egy Cisco gatekeeper-nek is feltétlenül jelen kell lennie. A Cisco Multimedia Conference Manager mindkét funkció ellátására képes.

A terminálok és proxy-k bekapcsoláskor megpróbálják megtalálni a gatekeeper-t. A sikeres keresés után az eszközök regisztrálják magukat a gatekeeper-nél. A gatekeeper tartja számon az aktív és inaktív terminálokat.

A 6. Ábra szerint háromféle hívás-felépítési mód lehetséges.

6. Ábra Hívásfelépítés különböző zónák között

1. típus: Zónán belüli hívások

A 6. Ábra alapján, ha a ta1 terminál a saját zónájában elhelyezkedő tb2 terminált akarja felhívni, a gatekeeper kezeli a hívást és megadja tb1 címét ta1-nek. Ezután ta1 felépíti a hívást.

2. típus: Zónák közötti hívások proxy nélkül

A 6. Ábra alapján, ha ta1 egy hívást akar felépíteni a másik zónában elhelyezkedő ta2 terminálhoz, először egy RAS üzenetet küld az gk1 gatekeeper-hez. A gk1 gatekeeper lokalizálja a távoli zónában levő gk2 gatekeeper-t, ezután gk1 egy RAS üzenetet küld gk2-nek, amelyben a ta2 terminál IP címét kérdezi. ta1 miután megkapta ta2 IP címét, felépíti a hívást. A gatekeeper-ek csak azokban a zónákban levő terminálok IP címeit szolgáltatják, amely zónák a gatekeeper számára engedélyezve vannak.

3. típus: Zónák közötti hívások proxy használatával

A proxy-k használatának elsődleges célja az, hogy a zóna valós IP címeit elrejtsük egy másik zóna eszközei elől. Az elszigetelt zónák a gatekeeper-ben nem elérhetőként vannak konfigurálva. A 6. Ábra alapján, ha ta1 terminál kommunikálni akar ta3 terminállal, elküld egy RAS üzenetet a gk1 gatekeeper-nek. gk1 lokalizálja gk3 gatekeeper-t. Ezután gk3 nem gk1-nek küldi vissza ta3 címét, hanem a p3 proxinak. A gk1 gatekeeper ezután utasítja ta1 terminált, hogy a hívásfelépítést ne közvetlenül, hanem a p1 proxy-n keresztül végezze el. Miután p1 proxy megkapta a hívás-felépítési kérelmet, megkérdezi gk1-től hogy valójában merre vezet a hívás. Végül felveszi a kapcsolatot p3 proxy-val aki befejezi a hívásfelépítést ta3 felé.

A Cisco Proxy használata

A Cisco Proxy használatának előnyei:

·         Biztonsági problémák megoldása

·         QoS signaling a H.323 végpontok számára

·         Alkalmazás specifikus routing a H.323 átvitel javítására

A biztonság növelése Proxy-k használatával

Abban az esetben, ha a terminálok közvetlenül kommunikálnak egymással mindenkinek joga van a másik IP címének az ismeretéhez. Ez az információ rosszakaratú kezekbe kerülve jelentősen megkönnyíti a hálózat feltörését, pláne akkor, ha a hálózati tűzfal nem támogatja a H.323 jelzéseket.

A H.323 protokoll tűzfalon keresztüli alkalmazásának a sikeressége azon múlik, hogy a tűzfal milyen mértékben ismeri az igen komplex H.323 protokollt. A proxy-k esetében csak az általunk engedélyezett minimálisan szükséges cím információk kerülnek nyilvánosságra.

Két fő esetet kell megvizsgálnunk abban az esetben, ha tűzfalakkal akarjuk kezelni a H.323 forgalmat:

·         H.323 protokoll engedélyezés tűzfalon keresztül. A H.323 egy igen komplex és dinamikus protokoll, igen sok alrendszerrel. Az aktuális portok/socket-ek állapotáról és kapcsolatáról a tűzfal csak a H.323 hívás-felépítési és jelzésüzenetek feldolgozása alapján szerezhet információt.

7. Ábra Gatekeeper és proxy elhelyezése

Ha a tűzfal nem támogatja a dinamikus hozzáférés vezérlést az aktuális kapcsolatok állapota alapján, akkor egy proxy alkalmazása szükséges a tűzfalon belül, a H.323 kontrolüzenetek értelmezéséhez. Mivel csak a gatekeeper (RAS-on keresztül) és a proxy (hívásfelépítő protokoll-on keresztül) kommunikál a tűfal külső portján elhelyezkedő elemekkel, igen egyszerű felállítani egy access kontroll listát a gatekeeper és a proxy felé irányuló forgalom átengedésére.

·         Network Address Translation (NAT) alkalmazása a H.323 protokollra. Ha H.323 terminálok rendelkeznek belső lokális és a külvilág felé látszó valós IP címmel, akkor a tűzfalnak képesnek kell lennie a H.323 protokoll által használt címek dekódolására. Ha a tűzfal nem képes erre a címfordításra, akkor külön proxy-t kell használni ennek a feladatnak az elvégzésére. A proxy-nak ebben az esetben mind a hálózat belső részével mind pedig a tűzfallal kapcsolatban kell állnia. (8. Ábra). A tűzfal ezután a proxy felé irányuló forgalmon nem végez NAT-ot, és a proxy is csak a H.323 protokoll forgalmat fogja engedélyezni a hálózat belseje felé.

8. Ábra Proxy és tűzfal együttes használata NAT esetén

Abban az esetben, amikor a tűzfal támogatja a H.323 protokollt és a hálózaton nem történik NAT, a proxy és a gatekeeper elhelyezkedhet a tűzfal külső részén. (9. Ábra)

9. Ábra Proxy a demilitarizált zónában

Proxy-server és NAT használatának veszélyei:

·         Ha a NAT aktív, mindegyik H.323 végpontnak regisztrálni kell magát a gatekeeper-ben arra az időre, amíg a végpont aktív. Ennek a nagyszámú NAT információnak a kezelése adott esetben nagyon leterhelheti a tűzfalat.

·         Ha a tűzfal nem támogatja a H.323 dinamikus protokollt, alkalmazhatunk statikus access listákat a proxy és gatekeeper node-ok felé, ezzel azonban nagyon sebezhetővé válik a hálózat.

A következő táblázatok (5.-6 Táblázat) a lehetséges tűzfal konfigurációkat tartalmazzák.

 

Tűzfal és H.323 NAT

Tűzfal H.323 NAT nélkül

Tűzfal Dynamic Access Control képességekkel

Gatekeeper és proxy a tűzfal belső oldalán

Co-edge gatekeeper és proxy

Tűzfal Dynamic Access Control nélkül

Gatekeeper és proxy a tűzfal belső oldalán, plussz statikus access lista a tűzfalon

Co-edge gatekeeper és proxy

5. Táblázat Tűzfal NAT esetén

 

Tűzfal és H.323

Tűzfal H.323 nélkül

Tűzfal Dynamic Access Control képességekkel

Gatekeeper és proxy a tűzfal belső oldalán

Gatekeeper és proxy a tűzfal külső oldalán

Gatekeeper és proxy a tűzfal belső oldalán

Gatekeeper és proxy a tűzfal külső oldalán

Tűzfal Dynamic Access Control nélkül

Gatekeeper és proxy a tűzfal belső oldalán, plussz statikus access lista a tűzfalon

Gatekeeper és proxy a tűzfal belső oldalán, plussz statikus access lista a tűzfalon

 

6. Táblázat Tűzfal NAT nélküli hálózatban

Quality of Service paraméterek javítása proxy használatával

Abban az esetben, amikor két H.323 terminál egymással kommunikál a hívás minőségi paraméterei nem definiáltak. Nagy sávszélességű intranet kommunikáció esetén a kapcsolat minősége elfogadható lehet, de egy relatív lassú WAN összeköttetésen keresztül a késleltetés és a jitter miatt gyakran rossz vagy elfogadhatatlan az összeköttetés minősége.

Ennek megfelelően H.323 alkalmazások telepítése olyan magán hálózatot feltételez, amelyben nagy a rendelkezésreálló sávszélesség, kicsi a késleltetés, kevés a csomagvesztés, vagy pedig olyan hálózatot, amelyben a H.323 számára biztosítottak a megfelelő QoS paraméterek.

Ezen QoS paraméterek biztosításához megfelelő protokollok használata szükséges:

·         Sávszélesség foglalás adott QoS paraméterek biztosítására, RSVP protokollal.

·         IP precedence bit használata H.323 forgalom prioritásának növeléséhez

Sajnos a mai rendszerek H.323 termináljai egyik megoldást sem támogatják. Ezekben az esetekben proxy párok használata lehetséges azon hálózatok között, ahol a szolgáltatási paraméterek javítása szükséges.

A Multimedia Conference manager segítségével a felhasználók konfigurálni tudják protokoll és felhasználói szinten a QoS paramétereket. A legjobb megvalósításban a terminálok olyan proxy-t használnak, amelynek a kommunikációja rendelkezik a megfelelő QoS paraméterekkel. A 10. Ábrán látható hogyan használható a Cisco Multimedia Conference Manager a QoS biztosítására, az RSVP vagy az IP precedence protokollok segítségével.

10. Ábra Cisco MCM használata QoS biztosítására

H.323 alkalmazás-specifikus routing, proxy használatával

A megfelelő QoS paraméterek biztosításához egy létrehozhatunk egy az adathálózattól szeparált hálózatot. Ebben az esetben a proxy az application specific routing (ASR) használatával biztosítja a QoS-t.

Az ASR működése egyszerű: amikor a proxy a külső hálózat felé irányuló csomagot kap, azt nem a reguláris routing útvonalon továbbítja, hanem azon a hálózaton keresztül, ahol biztosítottak a megfelelő minőségi paraméterek. Ha a hálózat minden proxy-ja használja az ASR protokollt, akkor minden beérkező forgalom a QoS garantált hálózaton fog haladni. A hálózat adminisztrátoroknak gondoskodniuk kell arról, hogy a közönséges adatforgalom ne a szeparált QoS garantált hálózatot használja. (11. Ábra)

 Az ARS alkalmazása lehetővé teszi hogy:

·         minden egyes proxy-k közötti kapcsolat-felépítés esetén az ASR alapján automatikusan létrejön az interfészre mutató route

·         a proxy konfigurálható arra, hogy loopback interfészeket használjon. A proxy cím látható mind az ASR port mind pedig a reguláris routing információt használó portok számára, azonban semmilyen route nem mutat az ASR interfész felé. Ez garantálja azt, hogy a nem H.323 specifikus forgalom nem az ASR interfészt használja.

11. Ábra ASR használata a Cisco Multimedia Conference Manager segítségével
Gatekeeper konfiguráció
Zónák definiálása

Zónánként csak egy gatekeeper lehet, a gatekeeper-t konfigurálni kell, hogy mely végpontok forgalmát engedélyezi. A végpontok RAS üzeneteket használnak a gatekeeper megtalálásához. A gatekeeper csak az előre specifikált subnetekből érkező hívásokat fogad el. A hívások csak akkor lesznek elfogadva, ha kérelem egy specifikált subnet-ből érkezik és a hívó meghatározta a nevét (van joga a gatekeeper hozzáféréshez), vagy a hívás a ’default’ subnetből érkezik.

Terminálok címzése

A gatekeeper kétféle címzést fogad el:

·         H.323 ID: tetszőleges sztring

·         E.164 címek.

Ha a zónák közötti kommunikáció a cél akkor a terminálok saját teljes mail címe lehet a H.323 címük. Az e-mail cím domain része célszerűen lehet a H.323 zóna név a gatekeeperben. Célszerű egy E.164 címet is hozzárendelni a terminálhoz.

Zónák közötti kommunikáció

Ahhoz hogy a terminálok zónák között is kommunkálni tudjanak a gatekeeper-nek meg kell tudnia határozni a zóna tagságot és megtalálni a másik zóna gatekeeper-ét. A gatekeeper ezeket kétféle módon tudja megtenni.

·         Mindegyik gatekeeper-nek lehet saját DNS domain neve. Amikor a gatekeeper egy olyan e-mail címre érkező hívást kap, amelyik nincsen regisztrálva, RAS üzeneteket használva megpróbálja azonosítani a végpontot.

·         Ha a DNS nem elérhető, mindegyik gatekeeper-ben konfigurálni kell a többi gatekeeper és domain címeket.

Azonosítás RADIUS és TACACS+ segítségével

A H.323 specifikáció 1. Verziója nem nyújt semmilyen végpont regisztrációs és azonosítási módot. Csak egy kezdetleges azonosítási módot tesz lehetővé, abban az esetben, ha a gatekeeper-ben az AAA rekordok engedélyezve vannak és RADIUS vagy TACACS+ szerverek is vannak a hálózatban.

Ha ez a funkció engedélyezve van, akkor gatekeeper azonosításkor az RADIUS vagy TACACS+ szerverekhez fordul. A regisztráció sikeres, ha a RADIUS vagy TACACS+ azonosította a nevet.

Multipoint Conference Unit-ok használata az MCM segítségével

Az MCU egységek olyan elemek amelyek képesek az MCM által nyújtott szolgáltatások igénybevételére. Az MCU képes többirányú kapcsolatkiépítésre és az adat/jelzéscsatornák kezelésére egy időben.

Azon kívül, hogy az MCU képes több kapcsolat fogadására ugyanazon eszköztől, lényegében nem különbözik egy szabvány termináltól. Egy konferencia kezdetén az MCU regisztráció MCM-nél történik. Amikor egy felhasználó, konferencia kapcsolatot akar létesíteni egy MCU egységgel, elküldi az alias nevet az MCM-nek. Az MCM úgy kezeli, mint egy normál terminált és megnézi hogy van-e ilyen alias regisztrálva az adatbázisában. Ha megtalálta a nevet, akkor bekapcsolja a felhasználót az MCU konferenciába.

Gateway és MCM használata

A gateway egy speciális eszköz, amelyik képes az MCM szolgáltatásainak a használatára. A gateway szolgáltatásai is a gatekeeper-ben vannak regisztrálva. Amikor a gatekeeper egy olyan kérelmet kap, amiben a hívás a VoIP hálózaton kívülre irányul a hívást a megfelelő gateway felé irányítja. Ha gateway szükséges egy bejövő hívás lekezeléséhez, az MCM úgy kezeli a gatewayt-t mint egy közönséges terminált és felépíti a kapcsolatot.

Átviteli minőséggel kapcsolatos kérdések

Hangcsomag átvitele esetén az ideális végpont-végpont közötti késleltetés 150 és 200 milliszekundum között van. Láthattuk, hogy a CODEC-ek és csomagképzés két útvonalválasztás közötti átvitelbe 50 és 60 milliszekundum közötti késleltetést iktat be. A következőkben bemutatjuk, hogyan kell úgy egy hálózatot beállítani, hogy megfelelő késleltetés és késleltetés-ingadozás értékekkel rendelkezzen, csak 100-140 milliszekundumot igényeljen a végpontok közötti csomagátvitel.

A Quality of Service (QoS), Class of Service (CoS), és a Type of Service (ToS) olyan széleskörűen használt kifejezések, amelyeket gyakran helytelenül és túlzóan használnak. Az alapvető cél a szükséges sávszélesség biztosítása és megfelelő értékű késleltetés elérése valamely speciális alkalmazás számára. Az ilyen paraméterekkel rendelkező szolgáltatásnál az eredmény sokkal fontosabb, mint a felhasznált eszközök, technológiák. Más szavakkal a QoS problémák megoldásánál nem csak egy QoS eszközökre kell fókuszálni, hanem a hálózatot, mint egészet kell kezelni, és azt kell vizsgálni, hogy az egyes QoS eszközökkel milyen részfeladatokat lehet megoldani. Az sem szabad elfelejteni, hogy minél finomabb a sorba állítás és a vezérlés annál alacsonyabb a csomagok továbbítási sebessége.

Egy jól megtervezett hálózatban elkülönülnek a perem és a gerinc funkciók. A legjobb QoS elérése érdekében is fontos ez. A Cisco cég számos eszközt biztosít a QoS megvalósításához. Néhány esetben a hálózat QoS-e QoS eszközök használata nélkül is megvalósítható. Minden egyes hálózatnak más-más problémái vannak és ezeket egy vagy több, a következőkben ismertetendő QoS eszközzel lehet megoldani.

Perem funkciók

Compressed Real-Time Transport Protocol

Az RTP egy szabványos Internet protokoll valós-idejű adat átvitelére, beleértve a hang és a videó jelek csomagban történő átvitelét is. Az RTP szabványban definiált tömörítési eljárás alapvetően a TCP/IP fejléc tömörítés során használt eljáráson alapul (RFC 1144).  Az RTP-t interaktív szolgáltatásoknál (pl. Internet telefon) és médián elérés (Real-Time Audio) használják. Az RTP-nek adat és vezérlési része van, az utóbbit RTCP-nek nevezik.

Az RTP adat része egy egyszerű protokoll, amely a valós idejű alkalmazások számára (pl. folyamatos hang és/vagy videó átvitel) biztosít támogatást beleértve az időzítés helyreállítását, a csomagvesztés érzékelést és tartalomazonosítást.

Az RTCP Internet alapú, tetszőleges résztvevőszámú, valós-idejű csoportkonferenciát tesz lehetővé. Biztosítja a forrásazonosítást, támogatja az átjárók használatát (pl. hang és videó hidak, multicast-unicast transzláció). Az RTCP QoS információ visszacsatolást biztosít a vevőktől a multicast csoport felé és támogatja a különböző média folyamok szinkronizálását is.

A Compressed Real-Time Transport Protocol, röviden csak CRTP a kapcsolati szinten használatos az IP/UDP/RTP fejlécek 40 bájtról átlag 2-4 bájtra tömörítésére. Csomag alapú hangátvitel a 20 milliszekundumonkénti beszéd mintavétel és keretezés 20 bájtos csomagokat állít elő. A teljes IP csomagméret egyrészt ebből a 20 bájtból, az RTP fejlécből (12 byte), az UDP fejlécből (8 byte) és az IP fejlécből (20 byte) áll össze. Látható, hogy a fejlécek méreteinek az összege kétszerese a hasznos tartalom méretének. 20 milliszekundum-ként előállított csomagoknál egy lassú adatátviteli vonal sávszélességének nagy részét elfoglalják a fejlécek.

A rendelkezésre álló sávszélesség szükségtelen elfoglalása ellen a CRTP-t használják az adatkapcsolati szinten (2. szint).  Ez a tömörítés 2 bájtra szorítja le az IP/UDP/RTP fejlécek méretét abban az esetben, ha nincs UDP checksum elküldés és 4 bájtra, ha az UDP checksum használatos.

A TCP fejléctömörítésnél a 2: 1 arányú összenyomás abból a tényből következik, hogy az IP és a TCP fejlécekben lévő byte-ok fele állandó a TCP kapcsolat során.

Az RTP fejléctömörítésnél az előzőhöz hasonlatos technika alkalmazható. Azonban a nagy lehetőséget az rejti, hogy ugyan jó néhány mező változik minden egyes csomagnál, de a változás (az első rendű különbség, az 1. derivált) csomag és csomag között gyakran állandó és a változás változása (másodrendű különbség, a 2. derivált) pedig nulla. Amennyiben mind a tömörítő és a kibontó ismeri a tömörítetlen fejlécet és annak első rendű különbségét a kapcsolat során, akkor csak azt az információt kell átvinni, hogy a másodrendű különbség nulla-e. Amennyiben nulla, akkor a kibontó képes visszaállítani az eredeti fejlécet információvesztés nélkül, az első rendű különbségnek az elmentett, tömörítetlen fejléchez történő hozzáadásával minden egyes csomagnál beérkezésénél.

Hasonlóan a TCP fejléctömörítéshez, ahol több párhuzamos TCP kapcsolat állapotát figyelik, az IP/UDP/RTP tömörítésnél is több kapcsolat helyzet állapotát vizsgálják. A kapcsolat helyzetet az IP forrás- és célcím, az UDP forrás és cél kapuszám és az RTP szinkronizációs forrás mező (SSRC) definiálja. A tömörítő megvalósításánál ezekkel a mezőkkel kódolást végezhetnek a tárolt kapcsolati helyzetek táblájának sorszámozására, megcímzésére. A tömörített csomag egy kis egész leíróval van megjelölve amelyet kapcsolati helyzet azonosítónak (CID) neveznek; ez jelzi, hogy a csomag mely kapcsolat helyzethez tartozik az adott csomag. A kibontó a CID felhasználásával címzi meg a helyzeti kapcsolatok tábláját.

A CRTP legtöbbször 40 bájtról 2-4 bájtra szorítja le a fejléc méretét. Néha azonban az IP/UDP/RTP fejlécet nem lehet tömöríteni, mert változás történt egy olyan mezőben, amelynek az értéke állandó szokott lenni. Például ha a tartalom típus mező megváltozik, akkor a tömörítetlen fejlécet kell elküldeni.

A CRTP-t csak WAN interfészeken kell alkalmazni, ahol a sávszélesség kritikus lehet és a forgalom nagy része RTP-t használ.

A használt kapuszámok Cisco eszközöknél 16384 + 4 * a rendelkezésre álló csatornák száma az adott eszközön.

(Például egy Cisco útvonalválasztás 12 hangcsatornával a 16384–16432 kapuszámokat használja.)

Megjegyzések a CRTP-hez

A CRTP-t nem kell nagy sebességű interfészeken használni, mert csak hátrányokat jelenthet. A nagy sebesség definíciója persze meglehetősen relatív, a gyakorlatban E1 sebesség felett nincs szükség a CRTP használatára, habár néhány hálózatban már 512 kbps nagy sebességnek számít.

RSVP

Az RSVP az első jelentősebb szabványként elfogadott protokoll, amellyel dinamikusan lehet végponttól végpontig terjedő QoS-t megvalósítani heterogén hálózat esetén. Az RSVP mind az IPv4-gyel (a jelenlegi IP szabvány) mind az IPv6-tal együttműködik. Az RSVP transzparens működést biztosít azon hálózati csomópontokon (útvonalválasztókon) keresztül is, amelyek nem támogatják magát az RSVP-t. Leegyszerűsítve az RSVP a hálózati végpont azon képessége, amely lehetővé teszi számára, hogy bizonyos szintű QoS-t kérjen a hálózattól. Az RSVP megfelelő útvonalon csomópontról csomópontra végigviszi a hálózaton a kérést, minden egyes csomópontnál megkísérli a szükséges erőforrásokat lefoglalni az adatátviteli folyam számára.

Az RSVP-t úgy tervezték meg, hogy kihasználja a jelenlegi IP útvonalválasztó algoritmusok erősségeit. Ez a protokoll nem végez saját útvonalválasztást; ehelyett az útvonalválasztó protokollokra hagyatkozva határozza meg, hogy hol erőforrás lefoglalást végrehajtania. Ahogy az átviteli útvonalak változása követi a topológia változásokat, úgy az RSVP is módosítja a lefoglalásokat. Ez a felépítés nem zárja ki azt, hogy RSVP más útvonalválasztó szolgáltatást is igénybe vegyen. A jelenlegi fejlesztések az RSVP-nél arra irányulnak, hogy az RSVP képes legyen olyan útvonalválasztó szolgáltatások használatára, amelyek alternatív és fix útvonalakat nyújtanak.

Az RSVP együttműködik a jelenlegi sorba állítási mechanizmusokkal, és nem helyettük dolgozik. Ugyan az RSVP kéri az adott QoS-t, de az interfész sorba állítási mechanizmusnak (Weighted Fair Queuing [WFQ], Weighted Random Early Detection [WRED]) kell azt megvalósítania.

Az erőforrás lefoglalás úgy történik a hálózati csomóponton (útvonalválasztón), hogy az RSVP daemon két helyi döntést végző modullal kommunikál, a kibocsátás vezérléssel és a szabályrendszer vezérléssel. A kibocsátás vezérlés meghatározza, hogy a csomópontnak van-e rendelkezésre álló erőforrása a kért QoS kielégítésére; a szabályrendszer vezérlés pedig abban dönt, hogy a felhasználónak van-e adminisztratív jogosultsága a lefoglaláshoz. Ha bármelyik ellenőrzés elutasító választ ad, akkor az RSVP hibajelzést küld vissza a kérést kibocsátó alkalmazásnak. Ha mindkét ellenőrzés sikeres eredménnyel tér vissza, akkor az RSVP daemon beállítja a paramétereket a csomagosztályozónál és csomagidőzítőnél a kért QoS eléréséhez. A csomag osztályozó minden egyes csomagnál meghatározza a QoS osztályt, és az időzítő rendezi a csomagok kibocsátását

a visszaigazolt QoS kéréseknek megfelelően.

Két típusú dinamikus lefoglalást lehet végezni az RSVP-vel: ellenőrzött terhelést és garantált szolgáltatást. Az RSVP RFC-je az ellenőrzött terhelést a következő módon definiálja:

A hálózati elemek által egy alkalmazásnak nyújtott végponttól-végpontig terjedő viselkedés, amely ellenőrzött terhelés szolgáltatást nyújt, szorosan közelíti azt a viselkedést, amelyet az alkalmazás számára látható és legjobb erőfeszítés szolgáltatást nyújt terheletlen feltételek vagy kevéssé terhelt/torlódott feltételeknél. Ez nem jelenti az összes többi, ugyanazoktól a hálózati elemektől származó forgalom hiányát. Ha a hálózat megfelelően működik, akkor ezek az alkalmazások feltételezhetik azt, hogy:

·         a küldött csomagok nagyon magas százalékát sikeresen juttatja el a hálózat a célpontokhoz (a sikertelen csomagok aránya szorosan közelíti az átviteli média hibaarányát)

·         az átvitt csomagok igen magas százalékánál az észlelt átviteli késleltetés nem nagyon éri el a más csomagoknál észlelt minimális átviteli késleltetést (ez a minimális átviteli késleltetés magában foglalja a fényterjedési sebesség és az útvonalválasztó, illetve más kommunikációs eszközök által okozott késleltetést az átvitel út során).

Annak érdekében, hogy ezeknek a feltételeknek a meglétéről megbizonyosodjanak, az ellenőrzött terhelés szolgáltatást igényelő kliensek  a közbülső hálózati elemeknek információt adnak arról, hogy mennyi tervezett forgalmat fognak generálni – ez TSpec. Válaszként a szolgáltatás megbizonyosodik arról, hogy a hálózati elemek elegendő erőforrással rendelkeznek a kliensek által megfogalmazott szolgáltatás megvalósításához. Ha a kliensek által generált forgalom tulajdonságai mégis kívül esnének a Tspec paraméterek által meghatározott területen, akkor a kliens részére nyújtott QoS egy túlterhelt átvitel képét mutathatja nagyszámú késve érkezett vagy elveszett csomagokkal. A szolgáltatás definiálása nem igényli azt, hogy a túlterhelt viselkedés precíz karakterisztikája megegyezzen azzal, amit egy legjobb erőfeszítéssel átvitt adatfolyamnál kapnánk ugyanazon az útvonalon, túlterhelt feltételekkel.

A garantált szolgáltatás definíciója a következő:

A hálózati elemek által egy alkalmazásnak nyújtott végponttól-végpontig terjedő viselkedés, amely összhangban van ezzel a dokumentummal egy biztosított sávszélesség, amelyet ha egy szabályozott átvitel használ, akkor kötött késleltetésű szolgáltatást nyújt sorba állítási veszteség nélkül a megfelelő adatcsomagok részére (hálózati részek hibamentességét és az átvitel ideje alatt útvonal váltás kizárását feltételezve).

A végponttól végpontig terjedő viselkedés összhangban van a folyadék modellel úgy, hogy a behozott sorbaállási késleltetés nem éri el a folyadék késleltetést többször, mint a specifikált hibakorlát.

A garantált szolgáltatás nem ellenőrzi a minimális vagy az átlagos késleltetését az adatcsomagoknak, inkább a maximális sorba állítási késleltetést. Továbbá az adatcsomag által észlelt maximális késés kiszámításához az útvonal késleltetését kell meghatározni és hozzáadni a garantált sorba állítási késleltetéséhez. (Azonban a késleltetés körülbelüli mértéke kiszámítható egy csomag átvitele során észlelt késleltetés megfigyelésével).

Ez a kibocsátás vezérlés feladatai közé tartozik.

Másként megfogalmazva bizonyos bit arány lefoglalását végzi a szolgáltatás. A korlátozott késleltetést WFQ vagy WRED kedvezményezett súlyozással történő használata biztosítja. A késleltetési korlát nem specifikált, azonban az ellenőrzött terhelés szolgáltatás csupán „jó kiszolgálást” ígér; és a garantált szolgáltatás ad olyan információt, amelyből kiszámíthatóak az aktuális késleltetési korlátok.

Ennek az oka nyilvánvaló. A késleltetési korlát nem olyan egyszerű, mint „19 kbps 500 milliszekundumos késleltetéssel”.

Ha ez a 19 kbps egy E1 része, akkor az 500 milliszekundum nevetségesen hosszú, a késleltetési határ nem lesz több, mint kb. 20 milliszekundum. Amennyiben a 19 kbps egy 64 kbps vonalhoz tartozik, akkor valószínűleg két átmeneti tároló kimeneti várakozási sorával és adott sorba állítással dolgozunk; a késleltetési korlát kb. 400 milliszekundum. Egy 19.2 kbps sebességű vonalon 19 kbps-os átvitel esetén 1 másodperc körül van a késleltetési korlát.

Megjegyzések az RSVP-hez

Habár az RSVP egy fontos eszköz a QoS eszköztárában, ez a protokoll nem oldja meg az összes QoS-sel összefüggő problémát. Az RSVP-nek számtalan hátrányos tulajdonsága is van: nem eléggé skálázható, a kibocsátási vezérlés nem teljesen megfelelő és a végponttól-végpontig terjedő lefoglalás felépítéshez szükséges idő túl nagy.

Az RSVP-t már kipróbálták nagy kiterjedésű hálózatban is. Az  RSVP számára a legrosszabb helyzetet az jelentené, ha egy gerinchálózati útvonalválasztó használnánk, ahol több ezer lefoglalást kellene kezelni és minden egyes átvitelt sorba kellene állítani a beállított lefoglalásoknak megfelelően.

Az RSVP skálázhatóságát körülvevő információhiány miatt ez a protokoll leginkább csak a hálózat szélén alkalmazott, emiatt a gerinchálózaton általában más QoS eszközöket célszerű használni.

Egy másik fontos szempont a felhasználók authentikálása és authorizálása, azaz annak az eldöntése, hogy a lefoglalást kérő felhasználónak joga van-e az adott  lefoglalás kérésére. Jelenleg az RSVP nem rendelkezik ezzel a képességgel.

Az RSVP az IP csomagok teljes hosszával számol, nem veszi számításba a lehetséges tömörítési sémákat, a CRC-ket vagy a vonali csomagolásokat (Frame Relay, Point-to Point Protocol [PPP], High-Level Data Link Control [HDLC]). Például amikor RSVP-t és G.729-es kódolást alkalmazunk VoIP esetén, akkor a Cisco IOS 24 kbps-t foglal, összehasonlítva az RTP használata esetén elérhető 11 kbps körüli értékkel. Másként megfogalmazva egy 56k-s kapcsolaton csak 2 db 24 kbps-es lefoglalás enged meg annak ellenére, hogy akár több 11 kbps-os VoIP átvitel is elférne.

Egy jól megtervezett és ellenőrzött hálózatban azért lehet erre a problémára megoldást adni. Lehetőség van arra, hogy a vonal sávszélességét az RSVP lefoglalások engedélyezése miatt „túllépjük” – azaz több sávszélességet foglalunk le mint amennyi normálisan rendelkezésre állna. Ezt az interfészeknél beállított sávszélesség érték manipulálásával lehet megtenni. Például egy 56 kbps sebességű vonalon 100 kbps-es sávszélesség értéket használunk. Ezek után az RSVP a rendelkezésre álló „virtuális” sávszélesség 75%-át, azaz 75 kbps-et lesz képes lefoglalni a különböző kérések számára. Így 3 G.729-es kódolású VoIP beszélgetés részére lesz képes az RSVP sávszélességet lefoglalni. A jelentkező veszély nyilvánvaló, mert ha nem használunk CRTP-t, akkor valóban túllépjük a vonali sávszélességet.

Forgalomalakítás

A token (zseton) vödör a hivatalos definíciója az átviteli sebességnek, amelynek 3 komponense van: a burst méret, az átlagos sebesség és az idő intervallum. Habár az átlagos bit sebességet általában bit per másodpercben fejezik ki, a következő képlet segítségével bármely kettő ismeretében a harmadik kiszámítható:

Átlagos bit sebesség = burst méret / idő intervallum

Definíció szerint az intervallum bármely egész számú többszörös esetén sem éri el a bit sebesség az átlagos bit sebességet. Az intervallumon belül a bit sebesség tetszőleges értékű lehet.

A forgalmat gyakran alakítani kell. Ez nem csak azért történhet, hogy ne legyen a helyi interfészen torlódás, hanem azért is, hogy megfelelő legyen a távoli interfészeknek, illetve a szabályrendszernek. Ez a változtatás általában a megfelelő token vödör szűrő megtalálását jelenti (átlag sebesség plusz az elfogadható forgalmi burst sebesség ellenőrzés nélkül egy időperiódus alatt). A token vödör értéket a felhasználó állíthatja be, vagy az interfész típusából lehet meghatározni.

A legegyszerűbb eset az, amikor a szabályrendszer kényszeríti azt, hogy egy adott interfész sebessége átlagban ne érjen el egy bizonyos sebességet, még akkor sem, ha időlegesen túl is lépi azt. Az ilyen korlátozásnak általában az az oka, hogy a kérdéses átviteli szolgáltatást egy bizonyos sebességgel biztosít a szolgáltató.

Egy sokkal bonyolultabb kérdés egy olyan adatátviteli hálózat, amely torlódás esetén jelzést ad, különböző hozzáférési sebességeket nyújt különböző DTE eszközök számára, és képes lehet egy időben több átviteli kapacitást nyújtani az egyik DTE-nek mint a másiknak. Ebben az esetben szükséges a token vödör vezérlése.

Bármelyik esetet is alapul véve nagyon kritikus fontosságú az, hogy a valós idejű forgalom (hang) érzékeny a késleltetésre és ezért a forgalom teljes mennyisége és csomagvesztés a hálózati kapcsolatokon erősen behatárolt, fontos a forgalom útvonalválasztók által történő alakítása. Az útvonalválasztó képes a forgalmat az általa meghatározott garanciáknak megfelelően priorizálni.

Interfész szintű forgalomalakítás

Az interfész szintű forgalom alakítás egy olyan szolgáltatás, amely a token vödröt és a fair queue-t használja a szoftver interfész leíró blokknál (IDB) (amely vagy interfészhez vagy szubinterfészhez kapcsolódik).  A parancs beállítja az átlagos sebességét a szoftver IDB-ben lévő token vödörbe tett forgalom számára, hogy összhangban legyen a kívánalmakkal és elindítja a megfelelő processzt.

Custom Queuing

A Custom queuing lehető teszi a felhasználók számára, hogy meghatározzák egy bizonyos protokoll/forgalmi típus számára a rendelkezésre álló sávszélesség hány százalékát használhatják. 16 kimenő várakozási sort lehet definiálni, de létezik egy addicionális sor is a rendszer üzenetek (keepalive, stb.) számára. Minden egyes sor ciklikus sorrendben kap kiszolgálást és a forgalom meghatározott százalékát továbbítja.

A útvonalválasztókon meghatározzuk azt, hogy az egyes várakozási sorokból hány bájtot kell továbbítani egy ciklus alatt, ez a számítás az interfész sebességén és szükséges sávszélesség hányadon alapul.

Priority Queuing

A priority queuing lehető teszi a hálózat adminisztrátora számára, hogy 4 forgalmi prioritást használjon (magas, normál, közepes és alacsony). A bejövő forgalom szűrőlistás osztályozás révén a 4 kimenő várakozási sor valamelyikébe kerül. A magas prioritású sor mindaddig kiszolgálásra kerül, amíg üres nem lesz; ezután kerülnek csak a következő szintű várakozási sorból továbbításra a csomagok.

Ez a sorba állítási elrendezés lehetővé teszi azt, hogy a kritikus fontosságú forgalom mindig megkapja azt a sávszélességet, amit igényel, és jócskán visszafogja a többi alkalmazás forgalmát.

Ennél a sorba állítási mechanizmusnál különösen fontos tudni a forgalmi viszonyokat annak érdekében, hogy az alkalmazások ne szenvedjenek sávszélesség hiányban.

Weighted Fair Queuing (WFQ)

A WFQ lehető teszi azt, hogy a várakozási sorok ne szenvedjenek sávszélesség hiányban, és a forgalom megjósolható kiszolgálást kapjon. Az alacsony forgalmi igényű adatátvitelek kiemelt szolgáltatást kapnak, az összes átvinni kívánt forgalom időben továbbítódik. A magas forgalmat okozó adatátvitelek a fennmaradó sávszélességen egyenlő mértékben vagy arányosan osztoznak.

A fair queuing dinamikusan azonosítja az egyes adatátviteli folyamokat és dinamikusan priorizálja azokat az előzőleg elfogyasztott sávszélesség alapján. Ez a felállás lehető teszi azt, hogy a sávszélesség tisztességes módon kerüljön megosztásra szűrőlisták használata vagy más időrabló adminisztratív feladatok nélkül. A fair queuing az egyes adatátviteleket forrás- és célcím, protokoll típus, kapuszám és QoS/ToS értékek alapján különbözteti meg.

A fair queuing az alacsony sávszélesség igényű alkalmazások számára – amelyek a forgalom nagyobbik részét teszik ki – lehető teszi, hogy annyi sávszélességet igényeljenek, amennyire csak szükségük van; háttérbe szorítva a maradékon osztozó nagy sávszélesség igényű forgalmakat. A fair queuing csökkenti a késleltetés ingadozását, tisztességes módon megosztja a rendelkezésre álló sávszélességet az alkalmazások között.

A súly érték a súlyozott fair queuing-nál több tényezőből áll össze:

·         IP elsőbbség

·         RSVP

·         Frame Relay DE, FECN és BECN bitek

·         az adatfolyam által összesen forgalmazott adatmennyiség.

Az IP elsőbbség mező értéke 0 (ez az alapértelmezett) és 7 között változhat. Ahogy nő ennek a mezőnek az érték úgy ad több sávszélességet az adatfolyam számára az algoritmus.

Frame Relay hálózatoknál a torlódást az FECN és a BECN bitek jelzik. Amikor torlódásjelzés érkezik, akkor az algoritmus által használt súlyok úgy változnak, hogy a torlódással szembetalálkozó alkalmazás kevesebbszer továbbíthasson.

 Az adatfolyam súlya fordítottan arányos az elfogyasztott sávszélesség összegével.

Többszörös kapcsolat széttördelés és közbeszövés (Multilink Fragmentation and Interleaving)

A többszörös kapcsolat széttördelés és közbeszövés vagy a Multichassis Multilink PPP (MMP) az az eljárás, amelyre több alacsony sávszélességű vonal esetén van szükség. A nagyobb méretű csomagok széttördelésre kerülnek, a sorba állítási rendszer a kisebb méretű csomagokat a nagyobb méretű csomagok darabjai közé helyezi be.

Az alapvető megoldandó probléma az, hogy a legnagyobb (1500 byte) – a maximálisan elküldhető egység (MTU) méretével megegyező méretű – csomagoknak 215 milliszekundumra van szüksége egy 56 kbps sebességű vonalon való áthaladáshoz. A valós idejű forgalmat vivő csomagoknak (főként hangátvitel esetén) a teljes végponttól végpontig terjedő késleltetése a 150-200 milliszekundumos tartományba kell hogy essen, de ezt ugye a 215 milliszekundumos vonali késleltetés esetén túllépjük.

Az MMP az MP csomag széttördelő képességére épít. Az MMP 4 vagy 16 félbeszakítási/felfüggesztési szintet („sorba állítást”) nyújt, amíg az MP csak egyet. Az MMP esetén nincs szükség arra, hogy a vonal minkét vége támogassa az MMP-t.

Megjegyzések az MMP-hez

Az MMP-t csak Point-to-Point Protocol-t használó (PPP) interfészeken lehet alkalmazni, kizárva a többi WAN átviteli módszert (Frame Relay, stb.).

Az MMP csak a széttördelési eljárást és a félbeszakítási szinteket specifikálja, és nem specifikálja az egyes csomagdarabok priorizálásához szükséges sorba állítási technikát.

Szabályrendszer-alapú útvonalválasztás

A szabályrendszer-alapú útvonalválasztás esetén a rendszer adminisztrátorának lehetősége van az általa beállított szabályrendszerrel irányítani a forgalmat, és nem csak az útvonalválasztó protokollok által meghatározott útvonalválasztást használni. A szabályrendszer-alapú útvonalválasztás lehetővé teszi az IP elsőbbség mező megváltoztatását, és ezzel lehetőséget teremt a különböző szolgáltatási osztályok engedélyezésére a hálózaton.

A szabályrendszer alapulhat az IP címeken, kapu számokon, protokollokon vagy a csomagok méretén. Egyszerű esetben csak az egyik ilyen szempontot vehetjük figyelembe a szabályrendszer kialakításakor, de akár mindegyiket is használhatjuk egy bonyolultabb esetben.

Minden csomag, amely egy szabályrendszer-alapú útvonalválasztásra engedélyezett interfészen érkezik be egy route map-nak nevezett kifinomult szűrőn halad át. A route map dönti el, hogy a csomag hová kerüljön továbbításra.

A route map bejegyzéseket engedélyező vagy tiltó jelzéssel látjuk el. Ha a bejegyzés tiltó, akkor az összehasonlítás feltétellel egyező csomagok a normális továbbító csatornán keresztül kerülnek továbbításra (más szavakkal a célcím alapú útvonalválasztás hajtódik végre). Ha a bejegyzés megengedő, de a csomag nem egyezik meg az összehasonlítási feltétellel, akkor a csomagok szintén a normál útvonal-választási csatornán át továbbítódnak. Csak akkor kerülnek a szabályrendszer-alapú útvonalválasztás által specifikált beállítások végrehajtásra, ha a bejegyzés megengedő és a csomag összehasonlítása a feltétellel egyező eredményt ad.

Megjegyzés: a szabályrendszer-alapú útvonal-választást a csomagot fogadó és a nem a csomagot elküldő interfészen kell megadni.

Standard vagy kiterjesztett IP elérési vezérlő listát lehet használni az összehasonlítási feltételek megfogalmazására. Standard IP elérési listával forráscím feltételeket lehet specifikálni; kiterjesztettel pedig forrás- és célcím, alkalmazás, protokoll típus, ToS és elsőbbség mező érték alapján lehet dönteni.

Az egyezési vizsgálatot továbbfejlesztették, hogy a csomagokat méret specifikált minimum és maximum méret alapján is lehessen vizsgálni. A hálózati adminisztrátor ezek után a csomagméretet, mint feltételt használhatja az interaktív és tömeges forgalom megkülönböztetésére (a tömeges forgalom általában nagyobb csomagméretet használ).

A szabályrendszeres útvonal-választási processz addig vizsgálja a route map-et, amíg egyezést nem talál. Ha nem talál egyezést, vagy tiltó bejegyzést talál, akkor a normál célcím alapú útvonal-választás következik.

Megjegyzés: mint mindig, most is ott van egy implicit tiltás az egyezést kifejezések listájának a végén.

Nagysebességű kapcsolatok

Alacsony terhelésű kapcsolatokon jobb lehet a sorba állítási technikákat nem használni. Nagy sebességű vagy nagymértékben terhelt kapcsolt esetén ajánlott először tesztelést végezni, hogy melyik QoS eszköz nyújtja a legkövetkezetesebb megoldást.

IP Elsőbbség—Szolgáltatási osztály

Az IP elsőbbség egy perem funkció, amely lehetővé teszi a gerinchálózati QoS eszközöknek (Random Early Detection [RED], WRED), hogy a forgalmat a szolgáltatási osztálynak megfelelően továbbítsák. A rendszergazda 6 szolgáltatási osztályt definiálhat. Ezek után kiterjesztett elérési vezérlő listák és szabályrendszer térképek használatával torlódáskezelésre és forgalmi osztályok számára történő sávszélesség foglalásra használhatja ezeket. Az IP elsőbbség szolgáltatás az egyes csomagokhoz történő CoS hozzárendelésére az IP fejléc ToS mezejében lévő három elsőbbség bitet használja fel. Az IP elsőbbség szolgáltatás jelentős flexibilitást nyújt az elsőbbség hozzárendeléséhez; lehetőség van alkalmazás, IP cím, MAC cím vagy fizikai por alapján történő hozzárendelésre.

A rendelkezésre álló IP elsőbbség beállítások a következők lehetnek a ToS mezőben:

routine                 Set routine elsőbbség (0)

priority                Set priority elsőbbség (1)

Immediate         Set immediate elsőbbség (2)

Flash                  Set Flash elsőbbség (3)

flash-override    Set Flash override elsőbbség (4)

critical                 Set critical elsőbbség (5)

internet               Set internetwork control elsőbbség (6)

network              Set network control elsőbbség (7)

A 6-os és a 7-es értéket a hálózati vezérlő és ellenőrző információk részére (útvonal-választási információfrissítés, stb.) van fenntartva. Alapesetben minden csomag a 0-s osztályba tartozik.

Az IP elsőbbség szolgáltatás lehetővé teszi, hogy a hálózat vagy passzív módon (a felhasználó által beállított elsőbbséget hagyva) vagy aktív módon (a megadott szabályrendszert használva beállítsa vagy felülírja az elsőbbségi hozzárendelést) viselkedjen. Az IP elsőbbséget le lehet képezni más hasonló technológiáknál alkalmazott QoS eljárásokra (például Tag Switching, Frame Relay, vagy ATM), lehető téve végponttól végpontig terjedő QoS szabályrendszer nyújtását heterogén hálózati környezetben. Ezért az IP elsőbbség szolgáltatási osztályokat tesz lehetővé a meglévő alkalmazások módosítása és bonyolult hálózati jelzésrendszer nélkül.

Az IP elsőbbség nem egy sorba állítási módszer, de lehető teszi más sorba állítási eljárások számára (WFQ, WRED), hogy az IP elsőbbség alapján priorizálják a csomagokat.

Megjegyzések az IP elsőbbséghez

A Cisco IOS szoftvernél a passzív mód az alapértelmezett. Ebben a módban nincs bebocsátás ellenőrzés, és bármely IP elsőbbség opcióval rendelkező alkalmazás magasabb QoS-t kaphat. Az IP elsőbbség bitek értékét az útvonalválasztás során lehet felülírni route map-ek és szűrőlisták segítségével.

Gerinc:

RED—torlódás megelőzés

A véletlenszerű korai detektálás - Random Early Detection (RED) – egy torlódás megelőzési algoritmus, amely azon az elven alapul, hogy bizonyos forgalom típusok érzékenyek a csomagvesztésre, és lelassítják a forgalmat, amikor csomagvesztést érzékelnek. A 1980-as évek elején kifejlesztett RED a csomageldobás módszerét használja a csomagokat küldő host-ok forgalom-kibocsátásának csökkentésére.

A RED jól működik olyan környezetekben, ahol a forgalom magas százaléka a csomagvesztést jól tűri (TCP). Ha a forgalom jelentős százaléka nem ilyen (például Novell NetWare vagy AppleTalk), akkor az algoritmus által a forgalom csökkentése érdekében eldobott csomagok nagy valószínűséggel súlyos mellékhatásokat okoznak. Hasonlóan, a csak egyszer elküldhető (valós idejű) forgalom, mint például a hangátvitel nehezen tűri a csomagvesztést. Az RED által okozott adminisztratív többletterhelés meglehetősen alacsony, ezért egészen az OC-3 sebességű interfészekig alkalmazható.

A RED működésének megértéséhez a legáltalánosabb használt megbízható protokoll, a TCP működését kell megértenünk csomagvesztési szituációban.

Amikor a TCP vevő egy adat szegmenset vesz, akkor ez vagy az a szegmens, amit várt (az oktet szekvencia szám az, amire számított), vagy nem az. Ha ez a következő várt szekvencia szám, akkor az összes elküldhető adatot továbbítja az alkalmazás felé, frissíti a várt szekvencia számot, és vagy azonnal, vagy kis késleltetéssel elküldi a nyugtázást (ACK) jelezve, hogy mindent megkapott kivéve azt az egy (hiányzó) szekvencia számot. Vagyis minden más elküldött szegmensre nyugtázást próbál küldeni. Az ok egyszerű: a legtöbb alkalmazásban van valamilyen visszaküldött válasz, amelyre a nyugtázást rá lehet ültetni, és ez a kis késleltetés lehetővé teszi a „hordár” elkapását. De ha valamit nem sorrendben kap, akkor általában azonnal nyugtáz mindent, amit csak tud. A cél az, hogy ha valami elveszik, akkor az első ismételt küldés befoltozza a hiányzó részt.

Amikor a TCP küldő megkapja a nyugtázást, akkor először is ellenőrzi, hogy van-e valami kinnlevő, nyugtázandó adat. Ha nincs, akkor ez egy keepalive üzenet. Ha van, akkor ez vagy a küldött adat egy részét, vagy semelyik részét sem nyugtázza. Ha egy részét nyugtázza, akkor a küldő ellenőrzi, hogy megnövekedett-e a hitelkeret, amely a küldő számára több adat küldését teszi lehetővé. Ha semelyik részét sem nyugtázza és van kinnlevő adat, akkor csak egy lehetséges magyarázat van – ez egy megismételt nyugtázás. Nos, miért is ismétel meg egy küldő egy nyugtázást? Legvalószínűbben azért, mert néhány adatot nem megfelelő sorrendben kapott meg (ez okozza az első nyugtázást), majd megkapta a második szegmenset szintén nem megfelelő sorrendben (a második nyugtázást okozva). Nos, miért kaphatott meg két szegmenset nem megfelelő sorrendben? Bizonyára azért, mert egy szegmens eldobódott.

Amikor egy TCP küldő kiesett szegmenset érzékel, vagy az imént leírt módon vagy időtúllépés miatt, akkor a nyugtázási várólistáján lévő első szegmenset ismét elküldi (az adatátvitel újraindítása érdekében) és a lassú indítás állapotba lép be. Ez teszteli a hálózatot, hogy mekkora az a sebesség, amellyel adatvesztés nélkül adhat.

Egy RED-et nem használó hálózatban a megtelő átmeneti tárolók és eldobódó csomagok több TCP kapcsolatnál lassú (újra) indítást okoznak. Ez a helyzet végső fokon azt eredményezheti, hogy a hálózati forgalom a TCP ablakok méreteinek növekedésével szinte hullámokban jön.

A router a RED használatával képes menedzselni a TCP lassú indítás mechanizmust, először csak egy TCP átvitelt visszafogva, megmérve az okozott hatást, majd ha szükséges, a többi TCP átviteleknél is csomagokat eldobva.

A RED a várakozási sort két részre osztja, egy normális működésre szánt részre, ahonnan szándékosan sohasem kerül adat eldobásra, és egy másikra, amely az additív terhelést okozó, túlburjánzó TCP kapcsolatok által okozott túlcsordulások kezelésére hivatott. Ezek a túlcsordulások közvetlenül összefüggnek az adási és a várokozási sorok mélységével. A RED méri is az átlagos sor mélységét - amikor az átlagos sor mélység az alacsony tartományban van, akkor a felső tartomány átmeneti tárolóként szolgál, de amikor az átlagos sor mélység a felső tartományba esik, akkor el kell kezdeni az adatok eldobását. Nem minden kerül eldobásra, csak bizonyos arányú eldobás kezdődik el.

Az eldobási mértéknek a legutóbbi eldobás óta eltelt idő (minél több idő telt el azóta, annál nagyobb a valószínűsége, hogy ez az üzenet eldobásra kerül) és az átlagos sor mélység sztohasztikus függvényének kell lennie. Ha a forgalom szintje hullámzik, akkor először egy csomag eldobásra kerül, és valamennyi idő eltelhet abban az esetben, ha a hullám csak időleges volt. Ha a forgalom szintje növekszik, akkor további csomagok kerülnek eldobásra a növekvő forgalmi terhelés arányában.

Továbbá, az eldobások közötti intervallumnak elég hosszúnak kell lennie, hogy a TCP küldőnek lehetősége legyen a csomagvesztés érzékelésére és a lassú indítás állapotba lépésre. Természetesen, ha a forgalom véletlenül kerül kiválasztásra és az első TCP küldőnek relatíve alacsony a forgalma, akkor néhány más kapcsolat fajlagoson többször kerül „eltalálásra”.

A RED nagy sebességű TCP/IP hálózatoknál hasznos, a vezérelt csomageldobással megelőzi a torlódás kialakulását.

A Cisco ajánlása szerint az exponenciális súlyozási tényezőt alapértéken célszerű hagyni; azonban a működési környezettől függően szükséges lehet az érték megváltoztatására. Például a 10-es érték (az alapértelmezett), amely 10-4 elvesztési arányt valósít meg nagy sebességű kapcsolatok esetén javasolt (DS3 és OC-3); míg a 7-es érték, amely 10-3 elvesztési arányt valósít meg, T1 sebességű kapcsolatoknál ajánlott.

A RED egy típusa a FIFO sorba állításnak, és ezért nem lehet olyan interfészen bekonfigurálni, amely custom, priority vagy fair sorba állításra van már konfigurálva.

Frame Relay QoS

Ez a rész néhány alapvető eljárást mutat be a hang forgalom priorizálására és a szükséges minőség biztosítására Frame Relay csatornán, valamint megjegyzéseket fűz minden egyes megoldáshoz. A megoldások skáláján megtalálható az MTU változtatása, az RTP fejléctömörítés, külön DLCI a hang és az adatforgalom részére, a rendelkezésre álló sávszélességnek a CIR-hez állítása és az általános forgalom alakítás használata. Az adott hálózaton legsikeresebben használható eszköz megtalálásának érdekében ki kell tesztelni az adott Frame Relay hálózat karakterisztikáját.

Alacsony sávszélességű Frame Relay kapcsolatoknál szükséges a nagyobb méretű csomagok széttördelése a nagy csomagméret miatt jelentkező késleltetés elkerülése érdekében. Az MMP-hez hasonló adatkapcsolati szintű széttördelést végző eszköz nélkül az interfész MTU értékét szükséges megváltoztatni a késleltetési tűrés és a sávszélesség függvényében. Ez a beállítás megoldja a nagy csomagok kérdését, mert az interfészen minden, az „új” MTU méreténél nagyobb csomag széttördelésre kerül.

Az MTU átméretezés különböző problémákat okozhat. Egy csomag 300 bájtokra tördelése a csomag processz kapcsolását okozza. A széttördelt csomagok egész hálózaton történő utazásuk során „új” MTU méretűek lesznek. Természetesen a kisebb csomag méretek az egész hálózat teljesítményét is befolyásolják. És ha valamelyik csomagnál a ne-tördelj-szét bit be van állítva, akkor az eldobásra kerül.

Az általános szabály MTU változtatásra az, hogy 64 kbps-os interfészen 100, 128 kbps-on 200, 256 kbps-on 400 és 512 kbps-on 800 a javasolt. Amikor a sávszélesség eléri az 1 Mbps-t, akkor már nincs szükség az MTU változtatásra. Általánosságban elmondható, hogy ahol csak lehetséges a teljes késleltetés tűrési keretet kell figyelembe venni az egy interfésznél eltölthető idő (késleltet) kiszámításánál.

Mint a PPP-t alkalmazó bérelt vonalnál, a CRTP-t csak alacsony sávszélességű kapcsolatnál kell használni.

A tesztelések azt mutatják, hogy a legjobb hangminőség Frame Relay esetén 2 DLCI használatával érhető el. Ebben az esetben az első DLCI az adat DLCI, a második a hang DLCI; minden hang forgalomnak a hang DLCI-t kell használnia, a többi forgalom az adat DLCI-t használhatja.

Ennél a példánál két szubinterfészt használunk, minden adatforgalom a serial 0.1 interfészen át továbbítódik (adat DLCI). Az adat DLCI nincs a CIR értékre korlátozva, szükség esetén bármikor használhatja a Frame Relay burst sebességét. MTU méretezést kell használni az adat DLCI-n, mert csak egy fizikai kapcsolat van a Frame Relay hálózathoz. Csak egy fizikai interfész esetén a nagy csomagok a hang DLCI-n átmenő forgalom akaratlan késleltetését okozhatják.

A serial 0.2 szubinterfész limitált sávszélességre van beállítva a rendelkezésre álló CIR alapján. Mivel nagy csomagok nem kerülnek a hang DLCI-hez küldésre, ezért az MTU méretezés nem szükséges.

Az általános forgalom alakítás használata mind a hang, mind az adat DLCI-n lehetővé teszi a forgalom lelassítását a Frame Relay hálózaton érkező torlódásjelzés (BECN) esetén. Emellett szintén megengedi  a hálózati rendszergazdának az időperiódus és az alatt elküldhető teljes adatmennyiség mértékének beállítását.

Megjegyzés: a Frame Relay forgalomalakítás és az RSVP jelenleg nem kompatibilisek.

Megjegyzések a kettős DLCI-khez

Mint minden más hálózati elrendezésnél, ennél is vannak hátrányos tulajdonságok. A legbonyolultabb a Frame Relay hálózatban szükséges DLCI duplázás megvalósításához szükséges adminisztratív munka. További adminisztratív munkát jelent az IP útvonalak megkétszerezése és a komplex beállítások használata. Nem elhanyagolható a két DLCI használat okozta többletköltség sem.

Megjegyzés: a felhasználónak szabályrendszer-alapú vagy állandó útvonalválasztást kell ahhoz beállítania, hogy az x forgalom az x interfészen át továbbítódjon.

Az előzőek áttekintést és rövid magyarázatot adtak a Cisco IOS legtöbb QoS eszközéről. Ezek után itt az idő megérteni, hogy ezek az eszközök hol és milyen típusú hálózatoknál használhatóak. Általánosságban elmondható, hogy a perem szekcióban leírt eszközöket az alacsony sávszélességű kapcsolatoknál kellene használni, ahol a sorba állítás és a tömörítés a legnagyobb hatást fejti ki. A gerinchálózati részben ismertetett eszközöket pedig megközelítőleg a hálózat központjában kell bevetni. A gerinchálózaton a fő cél nem a csomagok osztályozása vagy biztonsági listák előírása, hanem a csomagoknak a cél felé történő lehető leggyorsabb kapcsolása, továbbítása. Azonban néhány gerinchálózatnál szükséges a torlódás menedzsment eszközök használata, például a WRED alkalmazása a forgalom ellenőrzésére és a terhelési túllövések levágására.

Voice over IP—Tervezés

Amikor VoIP hálózatot tervezünk, akkor a késleltetést és az átviteli időt szigorúan ellenőrzés alatt kell tartani. Elfogadható hangminőséges eléréséhez a végponttól-végpontig terjedő késleltetést 200 milliszekundum alatt kell tartani. Ez a késleltetési határ nem az átlagos késleltetésen, hanem az egyes csomagoknál megengedett késleltetésen alapul.

Két VoIP-t végző Cisco útvonalválasztó és torlódásmentes kapcsolat esetén a késleltetés az 50-60 milliszekundumos tartományba esik. Az elérendő 150-200 milliszekundumos  késleltetést célul kitűzve és a két VoIP útvonalválasz okozta késleltetést adottnak véve, 90-150 milliszekundumig tarthat a csomagforrástól végpontig való átvitele.

Amikor tervezésre vállalkozunk, akkor az egyik legelső és fontos dolog a használandó CODEC kiválasztása. Azok, akik VoIP hálózat telepítését választják, legnagyobb valószínűséggel kihasználják a csöndelnyomás (VAD) és a tömörítés (G.729) adta előnyöket. Más cégek emelt minőségű szolgáltatást akarnak nyújtani, ekkor a G.711 a vonzóbb.

A CODEC választásnál figyelembe veendő szempontok között szerepelhet a MOS érték, a tandem kódolás, a rendelkezésre álló sávszélesség, a megtakarítható költség és a felhasználók száma. Ezeket a szempontokat gondosan mérlegelni kell a CODEC kiválasztás előtt.

Nagyon fontos megérteni, hol tart ma a felhasználó hálózata és milyennek akarja a felhasználó az adat-hang integráció után. A következő kérdésekre kell választ kapni mielőtt a javasolt megoldásról szó eshetne:

1.      Mennyi a hang hálózat éves költsége és mekkora a szükséges tőkebefektetés?

2.      Mi a VoIP alkalmazásának elsődleges célja?

3.      Hány távoli kirendeltség van?

4.      Hány fő van a távoli kirendeltségeken?

5.      Hány perc az átlagos telefonhasználati idő / fő / távoli helyszín?

6.      A hívások hány százaléka irányul a cégen belülre?

7.      Mekkora az átlagos költség percenként és helyszínenként?

8.      Milyen a felhasználók által elvárt hangminőség (rádiótelefon, fizető minőség)?

9.      Hány perc a helyszínek között lebonyolított távolsági hívások idejének összege?

10.  A forgalom hány százaléka lesz hang és hány százaléka fax?

11.  Támogatja-e a meglévő IP infrastruktúra a hangátvitelhez szükséges QoS-t?

 

VoIP tervezési szempontok FR és ATM hálózatok esetén

Frame Relay

 

Késleltetés

Frame Relay hálózatok késleltetését alapvetően az állandó sorbaállítási és a változó bufferelési késleltetés határozza meg. Az előbb említett két tényező mellett a terjedési idő is jelentős szerepet tölthet be (például VSAT-os FR szolgáltatás esetén), de normál körülmények között ezt elhanyagolhatjuk. A sorbaállási késleltetés a frame relay keret méretétől és vonal sebességétől függ. A keret méret növelése hatékonyabb sávszélesség kihasználást, ugyanakkor nagyobb késleltetést is eredményez. Pl. 64 kbi/s és 1500 bájt hosszúságú csomagméret esetén a sorbaállítási késleltetés egyetlen linken 187 ms (1500*8/64 000). Természetesen amennyiben a FR keret több FR linken, kapcsolón megy keresztül, minden egyes kapcsoló újabb sorbaállítási késleltetést eredményez. A nagy méretű adat csomagok okozta késleltetés megelőzése érdekében a Frame Relay Forum FRF 12 szerinti FR keret darabolás/összeállítási eljárást is alkalmazhatjuk.

A bufferelési késleltetést a forgalmi, torlódási viszonyok és a berendezés belső felépítése (buffer méret) határozza meg. A hang csomagok megfelelő prioritással történő kezelése “Átviteli minőségi követelmények” fejezetben ismertetett mechanizmusok (RSVP, IP precedence , FRF 12 ...) segítségével történik.

Általában a FR hálózat okozta késleltetés nem jelent megoldhatatlan problémát az IP alapú hangtovábbítás számára. A FR tervezési irányelvekkel részletesen foglalkozik még a “Frame Relay Qos” fejezet.

 

Sávszélesség

A hangcsatornák számának meghatározása után rendelkezésünkre áll a minimálisan szükséges sávszélesség. A FR virtuális áramkör garantált átviteli sebességének (CIR- Committed Information Rate) egyenlőnek vagy nagyobbnak kell lenni, mint a hangcsatornák és jelzésrendszerek átviteléhez szükséges sávszélesség. Természetesen a CIR igénylésekor más adat alkalmazás sávszélesség igényét is figyelembe kell venni.

A hang és adat forgalom megfelelő prioritással történő kezelése a routerekben, access koncentrátorokban az “Átviteli minőségi követelmények” fejezetben ismertetett mechanizmusok (RSVP, IP precedence ,..) segítségével történik. A felhasználók a hang és adat forgalmat FR szinten is elkülöníthetik, ha két PVC-t bérelnek a szolgáltatótól, de erre a legtöbb esetben nincs szükség.

ATM

 

ATM Szolgáltatások

Az ATM különböző szolgáltatási osztállyal igényelhető, amely közül az IP alapú hangátvitelre leginkább a CBR és a VBR  szolgáltatási osztály a legalkalmasabb. Az UBR a szabvány szerint nem garantál késleltetés sem átvitt adat mennységet. Az ABR alkalmas hangtovábbításra elterjedése azonban még meglehetősen limitált.

 

Késleltetés

Mivel az ATM szolgáltatást úgy tervezték, hogy alkalmas legyen valós idejű információ továbbítására, a késleltetés és a jitter nem okoz problémát. CBR esetén a késleltetés és a késleltetés ingadozása (CDVT) kicsi, VBR (nrt, rt) szolgáltatás esetén nagyobb, de még így is nagyságrendekkel alacsonyabb, mint amit a FR kapcsán láttunk.

 

Sávszélesség.

CBR szolgáltatás esetén a PCR-nek (Peak Cell Rate –Maximális Cella Sebesség) nagyobbnak vagy egyenlőnek kell lenni, mint a hangátvitelhez meghatározott sávszélesség.

VBR szolgáltatás esetén a SCR-nek (Sustained Cell Rate – Átlagos Cella Sebesség) kell nagyobbnak vagy egyenlőnek lenni, mint a hangátvitelhez kiszámított sávszélesség. A VBR szolgáltatási osztály jobban alkalmas időben változó forgalom

Csomag alapú hang hálózatok tervezése

Az integrált hang, adat hálózatok tervezése előtt fel kell hívnunk a figyelmet a hang illetve adat hálózatok közötti hasonlóságra. Mindkét hálózat végpontól-végpontig szeretne kapcsolatot kialakítani a felhasználók részére, ami a jelzésrendszer, a címértelmezés és a routing koncepciók hasonlóságát eredményezi.

Az igazi feladat az integrált hang adat hálózatok tervezésénél éppen annak a megértése, hogy lehet ezeket az elemeket konfrontáció nélkül egyetlen hálózatba elhelyezni. A késleltetést és késleltetés ingadozását valamint azt, hogy hogyan csökkentjük ezek hatását részletesen kell tárgyalnunk a következő fejezetekben, hiszen a késleltetés érzékeny hang és a késleltetés érzékeny adat (pl. SNA) ugyanazon a hálózati elemen keresztül halad.

Nem minden forgalom, amit egy hang áramkörön továbbítunk késleltetés érzékeny. Például fax és hang posta nem feltétlenül támaszt olyan valós idejű követelményeket, mint amilyen egy természetes telefonbeszélgetéshez szükséges. Fax és hangposta továbbítás önmagában is olyan jelentős tényező, ami igazolásul szolgálhat egy integrált hang adat hálózat kialakításánál.

A tervezést alábbi hat lépésben célszerű végrehajtani:

1.      Hálózati Audit

2.      Hálózati Követelmények

3.      Technológiai és Szolgáltatás Áttekintés

4.      Műszaki Irányelvek

5.      Kapacitás Méretezés

6.      Pénzügyi Analízis

 A folyamat a jelenlegi hálózat kiértékelésével kezdődik, ami segít a következő lépés a hálózati célok és követelmények meghatározásában is. Ezt követi a rendelkezésre álló technológiák kiértékelése és a speciális hang átvitelhez szükséges mérnöki tervezések és tervezési irányelvek elkészítése. Utolsó lépésként a pénzügyi analízist kell elvégzése.

Hálózati Audit

Az első lépés a hálózat tervezésénél a jelenleg állapot meghatározása. Számba kell venni a meglévő eszközöket és azok képességeit, valamint üzemeltetési költségeiket. Meg kell határozni a jelenlegi megoldás költségeit és hogy a hálózat hogyan igazodik a tervezett  hang és adat igényekhez.

Fel kell térképezni azokat a jövőbeni projekteket amelyek hálózati erőforrásokat igényelnek és amennyire lehetséges meg kell határozni ezen projektek hatását a hálózatra.

Milyen a jelenlegi hang és adat hálózat szolgáltatás minősége? Szükséges a színvonal növelés? Végezetül szükség lehet forgalom analízisre a jelenlegi forgalmi viszonyok pontos meghatározásához. Lehetséges, hogy néhány helyen csökkenthetjük a linkek számát, amíg más helyeken újakat kell kialakítani.

Hálózati követelmények

Amint az alapok megvannak a következő feladat az integrált hang adat hálózat követelményeinek meghatározása. Először is meg kell határozni azt a domináns forgalmi típust, amit a hálózatnak támogatni kell. Azt is meg kell határozni, hogy a mennyire legyen szoros a hang adat integráció szintje. Ez utóbbi a megfelelő technológia kiválasztásában segít (VoATM, VoFR, VoIP).  A szükséges hang minőség meghatározása behatárolja a késleltetési és tömörítési lehetőségeket.

Meg kell határozni a telefon terhelésnek, forgalomnak azt a szintjét, amit még a hálózat le tud bonyolítani anélkül, hogy az adat forgalmat zavarná. A pénzügyi követelmények meghatározzák a megfelelő ROI és megtérülési időszakot.

Technológiák és szolgáltatások áttekintése

A következő lépés, hogy a rendelkezésreálló technológiák és szolgáltatásokat kiértékelése után ki kell választani azt a modellt, technológiát ami legjobban teljesíti az előző fejezetben

meghatározott követelményeket.

Minden csomag alapú hangátvitel azonos alapokon nyugszik, amit a 1. Ábra mutat. A csomag alapú transzport hálózat lehet IP, FR, ATM. A hálózat peremén találhatók a voice agentek. A voice agentet tartalmazó eszköz feladata, hogy a hagyományos telefóniában használt hang információt, a csomag alapú hálózaton történő továbbításra alkalmas formára alakítsa. A hálózat ezt követően továbbítja a csomag szintű információt ahhoz a voice agenthez amelyik a hívót felet szolgálja ki.

Integrált hang adat hálózat tervezése magában foglalja az alábbi három technológia kiértékelését.

·         Voice over ATM (VoATM)

·         Voice over Frame Relay (VoFR)

·         Voice over IP (VoIP)

A következő fejezetben csak a VoIP-t fogjuk áttekinteni. Először a hang adat integráció transzport és transzlációs módját mutatjuk be.

Mint az előbb említettük a hang adat integrációnak két alapvető módja van a transzparens és a transzlációs. Transzparens módban az adat hálózat átlátszóan, transzparens módon továbbítja a hang, beszéd illetve jelzés információkat. Ennek egyik példája az ATM, ahol az áramkör emuláció szimulálja a trönköket és transzparensen továbbít minden információt.

Transzlációs mód esetén az adathálózat a hagyományos távbeszélő funkciókat látja el. A jelzés értelmezése, majd egy kapcsolt virtuális áramkör létrehozása ATM hálózaton keresztül, egy példa erre. A transzlációs mód sokkal összetettebb, mint a transzparens és a megvalósítása jelenleg számos szabványosítási szervezet témája.

A megfelelő modell kiválasztása műszaki, technológia és elérhetőség kérdése.

VoIP

Ebben a fejezetben röviden a VoIP jelzésrendszert, routingot és címzést ismertetjük.

VoIP jelzés három különálló részre bontható: jelzés a PBX-től a routerig, jelzés a két router között és jelzés a routertől a PBX-ig. A magánhálózat az intranet az alközpont számára úgy látszik, mint egy trönk interfész, aminek az alközpont utasítást adhat a trönk lefoglalására. Alközponti jelzésrendszer lehet az analóg FXS vagy E&M illetve digitális közös csatornás jelzésrendszer, mint pl. QSIG. Az alközpont hasonló módon továbbítja a routernek a tárcsázott számokat, mintha egy telefon főközponthoz továbbítaná.

A routerben a Dial Plan Mapper a tárcsázott számot egy IP címre képezi le és Q.931 Call Establisment Request üzenetet küld az IP cím által jelzett távoli peernek.

Ez alatt a vezérlő csatorna, felépíti a Real Time Protocol (RTP) audió összeköttetést és az RSVP protokollt lehet arra használni, hogy garantált szolgáltatás minőséget biztosítson.

Amikor a router veszi a Q.931 szerinti hívás kezdeményezés üzenetet, lefoglalja az alközpont vonalát. Amint az alközpont küld egy visszaigazolást, a router a PBX-nek továbbítja a tárcsázott számokat és egy visszaigazolást küld a hívást kezdeményező routernek.

Összeköttetés mentes hálózatokban, mint amilyen az IP hálózat, a kapcsolat felépítés a végberendezések feladata, aminek a szükséges jelzésrendszert is tartalmaznia kell.

Ahhoz, hogy sikeresen lehessen emulálni a telefon szolgáltatást az IP hálózaton keresztül, a jelzésrendszer protokoll készletének bővítésére volt szükség.

Például egy H.323 agent tarozik a routerhez, hogy a szabványos módon támogathassa az audio és jelzésrendszer folyamot. A Q.931 protokoll használják a végberendezések a H.323 agentek közötti hívás felépítéshez és bontáshoz. Az RTCP saját maga építi fel az audió csatornát. Megbízható session orientált TCP protokollt alkalmazzák a jelzés információ biztonságos továbbítására. Az RTP ami az UDP felett található szállítja a valósidejű audio jelfolyamot. RTP azért használja az UDP-t mint transzport protokoll mert az általa okozott késleltetés kisebb mint a TCP-é. A hang összeköttetés a jelzésrendszertől és az adat forgalomtól eltérően toleráns a kis adat vesztesre de az adat újra küldés hatékonyan nem használható.

A 7. Táblázat az ISO protokoll referencia model alapján a voice agent  IP protokoll készletét mutatja.

7. Táblázat IP protokoll készlet

VoIP címzés

A már meglévő magánhálózatban, intranetben az IP számozási rendszer változatlan maradhat. Az IP számozási rendszeren belül a hang interfészek úgy látszanak, mint egy plusz IP hoszt.

A tárcsázott telefonszám IP címre fordítását a Dial Plan Mapper végzi. A hívott telefon száma vagy annak egy része lesz megfeleltetve egy IP címnek. Amikor a router megkapja a telefonszámot, összehasonlítja a routing táblájában lévő számokkal. Ha talál ugyanolyat, a hívást az ahhoz tartozó IP címhez irányítja. Az összeköttetés felépülése után, az intranet összeköttetése a felhasználók számára transzparens. 

VoIP routing

Az egyik erőssége az IP-nek a routing protokolljának fejlettsége. Modern routing protokoll, mint amilyen például az EIGRP képes arra, hogy a késleltetést figyelembe vegye a legjobb útvonal meghatározása során. Ezek a protokollok gyorsan konvergáló protokollok, amelyek a hangösszeköttetések számára biztosítják az öngyógyító képességükből származó előnyöket. Fejlett funkciók, mint amilyen a policy routing, hozzáférési lista lehetővé teszik, hogy összetett és biztonságos routing módszert alakítsunk ki a hang forgalom részére.

A VoIP gateway az RSVP-t automatikusan igénybe veheti annak érdekében, hogy a hang a legmegfelelőbb útvonalon haladhasson. Ez akár több hálózati szegmensen keresztül is történhet, mint pl. kapcsolt LAN vagy ATM hálózat. Napjaink legérdekesebb fejlesztés az IP routing területén az MPLS (Tag Switching). MPLS lehetővé teszi az IP routinng, poliszi és RSVP funkcionalitást, ATM hálózati transzport vagy más nagy sebességű traszporthálózat ötvözésével. További előnye az MPLS-nek a forgalom tervezési lehetőség, ami lehetővé teszi a hálózati erőforrások hatékony kihasználását. A forgalom szabályozást lehet végezni különböző feltételeknek alapján, például a napszaknak megfelelően.

VoIP és a késleltetés

Routereknek és az IP hálózatokkal szemben nagy kihívás, hogyan alkalmassá kell válniuk arra, hogy a késleltetést és késleltetés ingadozását korlátok között tartsa. Tradiconális IP hálózat “best effort”-ként működik, ami azt jelenti, hogy a bejövő IP csomagokat először jött, először megy alapon továbbítják.

A csomagok természetüknél fogva változók, ami lehetővé teszi, hogy a nagy fájl transzfer kihasználja a nagy csomag méretből fakadó előnyöket. Ezeknek a jellemzőknek köszönhetően a csomag továbbítás során nagy késleltetés és késleltetés ingadozás lép fel a hálózatban. Jelenleg számos erőfeszítés irányul arra, hogy szabványos vagy a Cisco saját fejlesztéseken keresztül a késleltetés érzékeny forgalmat lehessen továbbítani. RSVP lehetővé teszi számunkra, hogy a hálózat erőforrásait a végberendezések lefoglalják. Az RSVP lehetővé teszi hogy különböző típusú forgalmak számára megfelelő buffert (queut) foglaljunk, ezzel segítve elő a késleltetés és késleltetés ingadozásának csökkentését az IP hálózatban.

RFC 1717 a nagy csomagokat kisebbekre darabolja az adatkapcsolat réteg szintjén. Ez a megoldás csökkenti a hang csomagok késleltetés és késletetés ingadozását olyan módon, hogy hang csomagoknak kevesebbet kell várni trönk interfészre jutásához.

Weighted Fair Queuing vagy priority queuing lehetővé teszi, hogy a hálózat a különböző típusú forgalmakat, egymástól független szolgáltatás minőségű (QoS) sorba helyezze. Az eljárás úgy lett tervezve, hogy a hang prioritást kapjon az adat forgalommal szemben, ami csökkenti a potenciális sorbanállási késleltetést.

A következő pontokban néhány fejlesztést mutatnánk be, amit az IP társadalomban végeznek. Egyik megoldandó feladat az IP alatti különböző második rétegbeli protokollok alkalmazása és a cím meghatározás szükségessége. Cím meghatározás történhet statikusan, táblázatban fixen definiált információ alapján, alkalmazhatunk valamilyen broadcast megoldást vagy használhatunk egy központi cím meghatározó szervert.

A korábban már ismertetett DHCP lehetővé teszi, hogy ne foglalkozzunk a saját gépünk IP címével, a DNS pedig abban segít, hogy ne kelljen tudnunk annak végpont fizikai a címét ha kommunikálni szeretnénk vele. Talán hasonló mechanizmus fogja segíteni, a telefon mint fizikai berendezés logikai megfeleltetését.

Műszaki irányelvek

Ebben a fejezetben azt mutatjuk be, mi lehet hatással a hang minőségére és ez mellet, útmutatót szeretnénk adni a megfelelő hangminőség eléréséhez. Bemutatjuk, hogy mekkora az a késleltetés  ami még elviselhető.

Kódolás és hang tömörítés az első tényező, ami alapvető hatással van a hang minőségére. Kódoláson azt az eljárást értjük ami az analóg jelet digitális jelfolyammá alakítja. PCM az  a szabványos megoldás, ami az analóg jelet 64 kbit/s sebességű digitális jelfolyammá alakítja.

Tömörítés lehetővé teszi, hogy a szabványos és hagyományos 64 kbit/s helyett ennél kevesebbet kelljen használni. Többszöri konvertálás analógról digitálisra vagy tömörítési eljárások változtatása súlyos hatással lehet az eredeti hang jelfolyam minőségére.

A késleltetés két negatív hatással van a beszélgetésre. A hosszú késleltetés a beszélgetés során azt eredményezheti, hogy a hallgató előbb kezd el beszélni, mint mielőtt a beszélő befejezné a mondanivalóját. A másik, hogy a hosszú késleltetés a visszhang megjelenését vonhatja maga után, amit az eredeti jelnek a távoli végponttól történő visszaverődése hoz létre.

Visszhang kis késleltetés esetén nem zavaró és szinte észrevehetetlen, észrevehető csak a nagy késleltetéseknél lesz. A vonal minősége szintén hatással van a hang minőségére, de ez nem tarozik ennek a tanulmánynak a hatáskörébe.

Amikor a hangtömörítésről beszélünk elsősorban a hang minőség és sávszélesség csökkenés okozta előnyöket/hátrányokat kell mérlegelni. PCM azt a minőséget adja, amit a nyilvános távbeszélő szolgáltatástól elvárunk. A PCM 64 kbit/s sebességű és tömörítés nélkül működik, így nem ad lehetőséget a sávszélesség csökkentésre.

Adaptive Differential Pulse Code Modulation (ADPCM)  három fajta tömörítést tesz lehetővé. A minőség változás alig észrevehető a PCM-hez képest. A forgalomi összetételtől függően 32 K ADCMP-el 25%, 24 K ADPCM 30 %, 16 K ADPCM 35% költség megtakarítást eredményez. 

A következő tömörítés amiről szólni kell a Low-Delay Code-Excited Linear-Prediction vagy másképpen LD_CELP. CELP algoritmus az emberi hangot modellezi. A 16kbit/s LD_CELP a forgalmi viszonyoktól függően 35% megtakarítást tesz lehetővé.

Conjugate-Structure Algebraic-Code-Excited Linear-Prediction vagy röviden CS_ACELP, a PCM-hez viszonyítva nyolcszoros sávszélesség megtakarítást tesz lehetővé. CS_ACELP a legutoljára kifejlesztett algoritmusok egyike, ami minőségben összehasonlítható az LD_CELP-el és a 24 kbit/s ADPCM-el. Ismét csak a forgalmi viszonyoktól függően, átlagosan 40% költség csökkenés érhető el.

A különböző tömörítési eljárások minősítését a MOS szubjektív eljárás alapján a 8. Táblázat tartalmazza.

8. Táblázat Kódolási eljárások összehasonlító táblázata

A MOS értékek folyamatos javulását a digitális jelfeldolgozó processzorok (DSP) teljesítményének növekedése teszi lehetővé. A 8. Táblázat egyértelművé teszi, hogy a hang adat integrációt a hang jó minőségének megtartása mellet lehet végrehajtani.  Felhívjuk a figyelmet a MOS érték és késleltetés közötti kapcsolatra. Hálózat tervezéskor a késletetést úgy kell kiegyenlíteni, hogy a hang minőségére ne legyen hatással.

A 9. táblázat az ITU hang késleltetésre vonatkozó útmutatóját, ajánlását tartalmazza. 150 ms késleltetés a legtöbb alkalmazás számára elfogadható. 150 ms és 400 ms közötti késleltetés a jelenlegi hang minőséghez viszonyítva lehet elfogadható. Például Chicago és New York között 200 ms késleltetés elfogadhatatlan, a jelenlegi nyilvános távbeszélő szolgáltatás minősége miatt. A másik oldalon Chicago és Singapore között a 200 ms késleltetés megfelelő lehet a jelenlegi viszonyok miatt. Nagyobb késleltetés engedhető meg ha a fő szempont a költségek csökkentése.

9. Táblázat ITU késleltetés ajánlás

A fentiek alapján a tömörítésre és késleltetésre vonatkozó minőségi irányelvek létrehozható

A következőben a késleltetés összetevőit vizsgáljuk, először az állandó azt követően a változó összetevőket.

Az állandó, időben nem változó késletetés összetevőit az 12. Ábra mutatja.

12. Ábra Állandó késleltetés összetevői

Az első tényező a terjedési idő (Propagation delay) a két végpont közötti távolság függvénye. Tervezési  során 6 micromásodperc/km értékkel számolhatunk.

Sorbaállítás (Serialisation) az a folyamat, ami a bit folyamot a fizikai interfészre juttatja. Minél nagyobb sebességű az interfész sebessége annál kevesebb idő szükséges a biteknek az interfészre helyezéséhez. Például 125 mikor másodperc szükséges egy bájtnak, egy 64 kbit/s sebességű interfészre juttatásához. Ugyanennyi bájtnak STM-1-es interfészre továbbításához 0,05 mikro másodpercre van szükség.

Feldolgozási idő (Processing delay) a következőkből összetevőkből állhat: kódolás, tömörítés, kicsomagolás és dekodolás késleltetési ideje, aminek idejét az alkalmazott algoritmus határozza meg. Ezeket a funkciókat szoftverből és hardverből is meg lehet valósítani. A speciális hardver a jelfeldolgozó processzorok alkalmazása jelentőse javítja a minőséget és csökkenti a hang és video kódolási, tömörítési eljárások okozta késletetést.

Csomagolási késletetés alatt azt az időtartamot értjük ameddig a berendezés a hangmintákat nyűjti, és belehelyezi a csomagba. Vannak technológiák, amelyek megengedik, hogy részlegesen megtöltött csomagokat továbbítsunk, (pl. ATM CES) a hosszú csomagolási idő elkerülése érdekében.

Az 13. ábrán látható késletetés komponensek, időben változó késleltetést okoznak, álltalában ezeknek a késleltetéseknek a befolyásolására nagyobb lehetőségünk van.

13. Ábra Változó késleltetés összetevői

Sorbaállási (queuing delay) késleltetés az a késleltetés, amit az okoz, hogy egy csomagnak várakoznia kell a trönk interfészre jutásra addig, amíg az előtte lévő csomagok a trönk interfészre kerülnek. Ez az érték a forgalomtól és a csomagok méretétől is függ.

Dejitter buffert a távoli végponton használnak és a késleltetés ingadozásának kiegyenlítésére szolgál. A buffer segít a dekódolásnál, a kicsomagolásnál és egyenletes kiolvasást tesz lehetővé. A buffert túl kicsi beállítása csomagvesztést, túl nagy értéke pedig nagy késleltetést eredményez. Valójában a dejitter buffer csökkenti vagy teljesen megszünteti a késleltetés ingadozást és állandó késleltetést eredményez.

Miután tisztában vagyunk az állandó és változó késleltetést okozó komponensekkel, a hálózat késletetés határait képesek vagyunk meghatározni. A késleltetési korlát az az érték, ami még lehetővé teszi, hogy a kitűzött hang minőségi követelmény teljesüljön.

A hálózatban a tandem alközpontok eliminálása tovább csökkentheti az összesített késleltetést.

Ez a fejezet útmutatót adott arra, hogyan határozzuk meg a követelményeket, hogyan számolhatjuk ki a késleltetés limitet, amit az integrált adat hálózat tervezésénél használhatunk. Természetesen a tervezésnél általában a minőség és a költségcsökkentés között kell megtalálni az egyensúlyt. Az új magas MOS értekkel rendelkező kódolási eljárásoknak köszönhetően ez egyre könnyebben megy.

A műszaki útmutatót a következőképpen összegezhetjük:

·         Találd meg az egyensúlyt a hang minőség, késleltetés, felhasznált sávszélesség között

·         Határozd meg az elfogadható késleltetést és késleltetés ingadozás küszöbértékeit

·         Számítsd ki a választott modellhez tartozó késleltetést

·         Kerüld el a tandem kapcsolást, többszörös konverziót

Méretezés, erőforrás tervezés

A szükséges kapacitás tervezéséhez, az első feladat az alközpontól az integrált hang adathálózatig menő trönk interfészek számának meghatározása. A trönk interfészek meghatározása után a következő feladat annak meghatározása, hogy ez a trönkök a hálózattól mekkora sávszélességet igényelnek.

A szükséges alközponti trönkök számát a forgalom mennyisége és eloszlása, az igényelt szolgáltatás minőség a blokkolások mennyiségének elviselhető mértéke, és más hálózat specifikus tényezők határozzák meg. Néhány cég egyszerűen a jelenlegi trönköket az integrált hang adat hálózatra helyezi. Más cégek a hang adat integrációt arra használják fel, hogy újra felmérjék a forgalmi viszonyaikat.

Mindkét megoldás alkalmazható és gyakran alkalmazzák is mindkettőt.

A transzparens és transzlációs módszer alkalmazása hatással van a hálózati trönkök számára. Traszparens mód esetén, hangátvitel szempontjából minden változatlan marad.  A jelenlegi trönk kapcsolatokat egy az egyben leképezik virtuális áramköri kapcsolatokra. Transzlációs mód esetén azonban a hálózat egy tandem alközpontot szimulál, így van arra lehetőség, hogy kevesebb trönk interfészt alkalmazzunk.

A hálózati topológia, a trönkök száma alapján a szükséges sávszélesség meghatározható. A sávszélesség számításakor a tömörítés, az overhead, és a kihasználtságot célszerű figyelembe venni. Ezek e jellemzők a különböző csomag alapú hangtovábbítási technológiáknál eltérnek.

A helyszínek közötti késleltetés mátrix elkészítése után, megállapíthatjuk hogy a rendszer teljesíti-e a késletetési elvárásainkat. Amennyiben nem teljesíti, növelni kell a sávszélességet vagy más technológiát kell alkalmazni.

Pénzügyi analízis

A követelmények, a technológia kiválasztása a forgalmi méretezés elvégzése, a szükséges trönkök számának és kapacitásának meghatározása után fel kell tenni a kérdést: kifizetődő a hálózat pénzügyileg?

A következőben egy eset tanulmányt ismertetünk, amely bemutatja a pénzügy előnyeit egy VoIP integrált hang adat hálózatnak. Az eset tanulmányban egy kis nemzetközi cég szerepel, amely routeres magánhálózattal rendelkezik.

Az esettanulmányhoz az ismertetett tervezési módszereket használtuk és a nemzetközi telefon és bérelt vonali tarifákat alkalmaztuk.

A cég Párizsi központtal és hét regionális központtal rendelkezik. A regionális fiókokban 15 ember dolgozik ez alól kivétel London és New York ahol 45. A hálózati topológiát és a bérelt vonalak sebességét az 14. ábra mutatja.

14. Ábra Hálózati elrendezés

A legtöbb hívás a fiók alkalmazottjai és a helyi ügyfelek között történik. A hívások száma a fiókok alkalmazottjai és a központ alkalmazottjai között az összes hívásnak csak a 20%-át teszi ki. Annak ellenére, hogy az összes forgalomnak ez csak a kisebb részét teszi ki, költség oldalról nagyon jelentős, hiszen nemzetközi hívásokról van szó. A cég a nemzetközi távhívásokért havonta 38 000 $-t fizet, ami éves szinten 456 000 $-t jelent.

Hang hálózat (alközponti hálózat)

A kis key systemek és alközpontok a nyilvános kapcsolt távbeszélő hálózathoz csatlakoznak. Az analízis elvégzésénél azt feltételeztük, hogy a cég által keltett forgalom elég nagy ahhoz, hogy a normál tarifákhoz viszonyítva 15% kedvezményt kapjon. A központ a kapcsolt telefon hálózathoz E1 interfészen keresztül csatlakozik.

A fiókokban az egyes alkalmazottak kb. kettő és fél órán hosszat kommunikál telefonon vagy faxon keresztül. A forgalom 20 % irányul a központ irányába (10 Táblázat).

10. Táblázat Telefon és fax forgalom

Adat hálózat

A Párizsból kiinduló 8 telephelyet tartalmazó hálózat routereket tartalmaz. Két fiók a másik fiókokon keresztül képes csak elérni a Párizsi központot. Ezt a megoldást a bérelt vonali költségek minimalizálása érdekében választották. A központban egy 320 kbit/s sebességű FE1-es interfész tartja a kapcsolatot a fiókokkal.

Hálózat újra tervezése

Alapvető elvárás az újra tervezett hálózattól, amely már támogatja a hang továbbítását is, hogy ne legyen negatív hatással adathálózat teljesítmény viszonyaira. A terv az, hogy a PSTN számla csökkenés fedezze az újratervezett hálózat költségeit. A megvalósításhoz természetesen bármely más csomag alapú technológiát használhatnánk, mi most a tanulmány témája miatt a VoIP-et használtuk példának.

Először a hang és fax forgalom lebonyolításához szükséges plusz sávszélesség meghatározása a feladat. A  legjobb, ha a key systemekből az alközpontokból, a routerekből a forgalmi statisztikákat kinyerjük és az adat és hang forgalmat összeadjuk, grafikusan megjelenítjük. Ez utóbbi lehetővé teszi, hogy megfigyeljük az összegzett forgalom milyen gyakran lépi túl a rendelkezésreálló sávszélességet. Sajnos ezek a forgalmi statisztikák néha nem állnak rendelkezésre. Amennyiben ezek az információk nem állnak rendelkezésre meg kell becsülni, hogy a hang információ továbbítása mennyi plusz sávszélességet igényel, és ennek megfelelően kell megnövelni a bérelt vonal sebességét. Ezt követően a hang forgalmat az adat hálózatra lehet továbbítani és két fajta teljesítmény mérést érdemes elvégezni: az egyik a felhasználók által érzékelt hang minőség a másik az adatátvitel sebességének, késleltetésének vizsgálata. Amennyiben valamelyikkel probléma van, az azt jelenti, hogy több sávszélességre van szükség.

A hang és adat forgalom csúcs időszaka gyakran más időpontban van. Az adat forgalom ezért gyakran élvezi a megnövekedett sávszélesség előnyeit.

A hálózat újratervezésénél a következő feltételezéseket tettük:

·         Kis fiókokban 15 ember a nagy fiókokban 45 ember dolgozik.

·         A kétirányú telefon és fax forgalom 2,5 óra/személy/nap/fiók

·         A hívások 20% zajlik a fiókok és a központ között

·         A Cisco hang tömörítés modulja 8 kbit/s tömörítést alkalmaz, és plusz 1 kbit/s forgalmat feltételezünk hívásonként. Azt feltételeztük, hogy egy 64 kbit/s sebességű trönk, csak 5 db (nem 7 db) hívást támogat, ami meglehetősen konzervatív megközelítés.

·         A kis fiókok key systemeibe 1 db trönk modulra, a nagy fiókok alközpontjaiba 2 db kártyára van szükség.

·         A fenti feltételezések és az alábbi számítások végrehajtásával megkapjuk az a forgalmat, amit a kapcsolta telefon hálózatról a több funkciós hálózatba továbbítunk.

·         2.5 óra hívás mennyiség/fő/nap X 15 alkalmazott=37,5 óra telefon forgalom naponta a fiókokban

·         37,5 óra=2250 perc

·         2250 perc X 17% (forgalmas óra)=382,5 perc/forgalmas óra

·         382,5 perc forgalmas óraX 1 Erlang/60 perc forgalmas óra=6,375 Erlang

·         6,375 Erlang X 20% központ irányába menő forgalom=1,275 Erlang

A trönk interfészek számát Erlang 11. Táblázat segítségével határozhatjuk meg, amelynek használatához ismerni kell a szolgáltatás minőségi követelményeit (P grade of service). A cég P.05-öt választott.

11. Táblázat Erlang táblázat

Az Erlang táblázatból azt kapjuk, hogy kis fiókokban 4 trönkre, a nagy fiókokban 8 trönkre van szükség.

London és Frankfurt közötti bérelt vonal sebességét a fentieknek megfelelően 64 kbit/s-ról 128 kbit/s-ra kellett növelni ahhoz, hogy a hálózat a telefon forgalommal megnövekedett forgalmat képes legyen lebonyolítani. Mivel a New York és Párizs közötti bérelt vonalnak a Chicagoból jövő 4 hangcsatorna mellet a salyát 8 tömörített hangcsatornáját is hordoznia kell, a bérelt vonal sebességét 192 kbit/s-ra kellett növelni. A maximális forgalom ebben az esetben 12 tömörített hangcsatorna X 9 kbit/s=108 kbit/s, ami 84 kbit/s szabad kapacitást biztosít az adat forgalom számára akkor is, ha az összes hang csatorna foglalt. Mivel az idő nagy részében a hang trönkök közül találunk szabadokat, az adat forgalom számára több sávszélesség fog rendelkezére állni, ami az adatátvitel érzékelhető minőség javulását eredményezi.

A Chicago és New York közötti 64kbit/s sebességű bérelt vonal sebességét nem kellett növelni. Maximális telefon trönk kihasználtság mellet is a telefon forgalom csak 36 kbit/s sávszélességet igényel, ami azt jelenti hogy az adatátvitelre minimum 28 kbit/s fog rendelkezésre állni. A Chicagoi fiókhoz hasonlóan más fiókok is azt tapasztalják, hogy a relatív sávszélesség csökkenés okozta kismértékű késleltetés növekedést az adat alkalmazások képesek tolerálni. Mind már az előbb említettük ezt az is segíti, hogy az adat és a hang forgalom csúcs időszaka általában különböző időpontban van a két forgalmi típus ritkán interferál.

A Hong Kong-Tokyo link a Chicago-New York linkhez hasonlóan nincs szüksége sávszélesség növelésre.

A Tokyo összesített forgalma Párizs irányába maximum 72 kbit/s (4 csatorna Hong Kongból, 4 csatorna Tokyoból) így ennek sebességét 128 kbit/s-ra kellett emelni. A linken az adat forgalom számára minimum 56 Kbit/s fog rendelkezésre állni, ami azt jelenti, hogy hang szempontjából a nem forgalmas órákban, az adat átvitelre a jelenleginél jóval több sávszélesség áll majd rendelkezésre, ami a teljesítmények javulásában lesz érzékelhető.

A sávszélesség növelés természetesen nincs ingyen. A 15. Ábra az új hálózati topológiát, a 12. Táblázat az új költségeket mutatja. A teljes pénzügyi analízis a következő fejezetben található.

 

 

 

15. Ábra Integrálás utáni hálózati elrendezés

 

12. Táblázat Hálózati költségek

 

Előfizetői berendezések

Cisco 3620 routerek lettek telepítve a kis fiókokban és Cisco 3640 routerek a két nagy fiókban. Minden egyes kis fiókban a key systemek 4 db FXO trönkjét a 3620 routerhez csatlakoztatták. A key system a központ irányú forgalom 95%-át továbbította a Cisco routerhez csatlakoztatott négy trönk valamelyikére. A torlódás következtében a maradék 5% forgalmat a kapcsolt hálózaton keresztül továbbította.

A bérelt vonalak Párizsban végződnek, ahol hang csatornákat kibontják (kitömörítik) és az alközponthoz irányítja a router. A Párizsi központ az egyik E1-es PSTN kapcsolatát megszüntetheti, hiszen a telefon forgalom áthelyezésével 23 csatornát lehetett megszüntetni.

A Cisco 3600 routerek 8 kbit/s-os G.729 CS-ACELP tömörítést alkalmaznak. Minden egyes hang csatorna egy dedikált DSP processzort használ a kódoláshoz, tömörítéshez.

A 3600 architektúrája, a dedikált DSP processzorok alkalmazása nagy teljesítményt és kiváló hang minőséget eredményez.

A megbízható valós idejű hang továbbítás érdekében az Cisco Internetworking Operating System (IOS) számos technikát alkalmaz.

Az Resource Reservation Protocol (RSVP) sávszélességet foglal le, amikor egy távoli telefonszámot tárcsáznak. Compressed Real Time Protocol (CRTP) tömöríti a teljes fejrészt, ami kis overheadet és nagy átviteli sebességet (throughput) eredményez.

Átlagosan a beszélgetések idejének 50%-ban csend van. Ha nem továbbítjuk a csendet, több sávszélesség marad az adat alkalmazásoknak. Cisco IOS összetett, csönd elnyomás eljárást alkalmaz. Annak érdekében, hogy a vevő fél biztos legyen abban, hogy a hívás nem szakadt meg a helyi berendezés az elnyomás ideje alatt komfort zajt ad.

Jövőben, a példában szereplő cég a WAN hálózatba Frame Relay meghonosítását és távmunka bevezetését tervezi. A Cisco 3600-as router képes access szervereként működni, segítve azokat a dolgozóknak, akik otthonukból szeretnék elérni a cég informatikai rendszerét. Ha a cég úgy dönt, hogy Frame Relay szolgáltatást szeretne igénybe venni, a 3600-as routerek ezt a protokollt is támogatják.

Megjegyezzük, hogy nem mindegyik key system támogat preferenciák szerinti automatikus útvonal kiválasztást, kapcsolást. Ezek részleteit az alközpont key system gyártóival kell tisztázni.

A következő fejezetben a hálózat áttervezéséből származó költéség megtakarítást összegezzük.

Pénzügyi analízis

A 13 Táblázat a fiókok és központ összköltségeit tartalmazza. A sávszélesség növelésből származó költéség növelés az előző fejezet alapján 22,050 $ havonta. A kiadások és a megtakarítások összehasonlítását, a havi megtakarítást a 14. Táblázat tartalmazza.

13. Táblázat Havi összesített költségek

14. Táblázat Megtakarítások, megtérülési időszak

A cég 250 000 $ éves megtakarítást ér el azzal, hogy a belső telefonos forgalmát a routeres gerinchálózatra továbbítja. A megtérülési időszak, mindössze 5 hónap. A legfontosabb számokat az 16. Ábrán foglaltuk össze.

16. Ábra Pénzügyi összesítés

Perc költség

A szervezet telefon költségének egy percre vetített költsége a kiadások jó mérőszáma. A telefon beszélgetések percenkénti költségének kiszámítását a X. Táblázat mutatja. Az összes fiók telefon forgalma havonta 107 270 perc, ami összesen 38 908 $-ba kerül, így az egy percre jutó telefon költség a központ és fiókok között 0,36 $. Ahhoz, hogy az összes forgalom 95 %-át a integrált hang adat hálózaton lehessen továbbítani, a hálózatot bővíteni kellett, ami most havi szinten 22 050 $ kiadással jár havonta. A 107 270 perc kilencvenöt százaléka 101 906 perc. A bővítésből származó havi költségeket elosztva a beszélgetések idejével, 0,22 $ percenkénti költséget kapunk. Ez utóbbi azt jelenti, hogy a vállalatnak a telefonálásból származó percenkénti kiadásait 40%-al (0,36 $-ról, 0,22 $-ra) sikerült csökkenteni.

Végső közvetkeztetés

Az előző öt lépésben bemutattuk, hogy hogyan kell a minőségi követelményeket kielégítő integrált hang adat hálózatot tervezni. Az utolsó lépés azt mutatta, hogy ez a hálózat gazdaságos is.

Alkalmazások

IP PBX

A Cisco termék család lehetővé teszi az IP telefónia üzleti használatát a vállalatok lokális vagy nagy távolságú adat hálózatán. A Cisco lehetőséget ad az ISP-k számára, hogy a Cisco Ip telefonokat használva új szolgáltatásokkal lépjenek a piacra.

Meglévő PBX bővítése

Ez a megoldás az IP hálózatot használva  bővíti a meglévő PBX-et (17. Ábra). A Cisco kommunikációs rendszer analóg vagy digitális (a trönk típusa a felhasználók számától és a forgalom nagyságától függ) trönk gateway segítségével kapcsolódik a PBX-hez.

Ez az alkalmazás lehetővé teszi, hogy a hagyományos telefon szolgáltatásokat és a mellékek számát bővítsük, felhasználva a meglévő IP hálózatot, anélkül, hogy új PBX-et vásárolnánk. Azon hívásokat, melyeket a Cisco IP telefon tulajdonosa nem tud megválaszolni (foglalt, nincs a helyén), átirányíthatjuk egy másik telefonra, vagy éppen egy hangpostára. A készülék felhasználójának nem kell új tárcsázási adatokat megtanulnia, mivel azok azonosak a hagyományos telefonokéval.

És végül, az alközpont “kihosszabbítható” akár otthonig is felhasználva a standard remote access termékeket.


17. Ábra         Meglévő PBX bővítése IP PBX-el

Nincs hagyományos PBX

Az alábbi konfiguráció a Cisco Kommunikációs rendszert tartalmaz hagyományos PBX helyett (18. Ábra). A Cisco IP telefonok felhasználói a megszokott számok tárcsázásával tudnak irodán belül, vagy azon kívül telefonálni.

A Call Manager biztosítja a szolgáltatásokat az IP telefonok számára, mint például hívás továbbkapcsolás, hívás átirányítás, konferencia, hívás parkoltatás. A gateway interface teszi lehetővé a felhasználók számára, hogy csatlakozzanak a PBX-hez, és elérjék azon keresztül annak szolgáltatásait, illetve a fővonalakat (természetesen figyelembe véve a rendszer adminisztrátor által beállított jogosultságokat)

A CallManager software egy NT szerveren fut más IS adat szerverek mellet, mint például DNS, e-mail, és DHCP.


Mint egy hálózati kártya, a, Cisco IP telefonok is közvetlenül az IP hálózathoz csatlakoznak. A telefonokat és a vonalakat a Cisco CallManager segítségével lehet konfigurálni.

18. Ábra Homogén IP PBX hálózat

Távoli irodák elérése IP hálózaton

Ez az alkalmazás elérhetővé teszi a Cisco Kommunikációs Rendszert a WAN IP hálózaton keresztül a távoli irodák számára (19. Ábra). A CallManager ilyenkor a központi oldalon maradhat, vagy egy második CallManager telepíthető a távoli oldalon.


19. Ábra IP PBX a nagytávolságú hálózatban

 

Ez a Cisco Kommunikációs Rendszernek egy általános konfigurációja. A több telephelyes cégek is nagyon gyorsan és könnyen létrehozhatják teljes telefonhálózatukat IP adathálózatuk segítségével. Ez a távolsági hívások számának csökkenése miatt költség megtakarítást eredményez, valamint el lehet tekinteni egy második (telefon) hálózat költséges kiépítésétől minden távoli irodában. Ez a lehetőség maximális rugalmasságot tesz lehetővé az egyes irodák növekedése, vagy csökkenése esetén.

Cisco Access Gateway-eket használva a távoli irodákban, az ottani alkalmazottak is hívhatják egymást lokálisan. A távolsági hívások átirányíthatók a WAN IP hálózatra, ezáltal csökkenthetők a távhívási költségek. A Cisco kommunikációs rendszer lehetővé teszi, hogy a hívás útvonalától függően konfiguráljuk a hang tömörítés paramétereit. Például lehetőség van arra, hogy a lokális hívásokat ne tömörítsük, de a WAN hálózaton átmenőket igen. A CallManager automatikusan kiválasztja a szükséges tömörítési metódust, így a felhasználónak nem kell semmiféle speciális kódot tárcsáznia.

Távhívási és helyi telefon szolgáltatások az Internet szolgáltatóktól

Az Internet szolgáltatók a Cisco rendszer révén szélesíteni tudják szolgáltatásaik körét. A CallManager-t az Internet Szolgáltató oldalán installálva, a szolgáltató a telefonvonali szolgáltatókhoz hasonló helyzetbe kerül. Képes lesz telefon szolgáltatást és annak kiegészítő funkcióit, valamint távhívási lehetőséget biztosítani ügyfeleik számára.


Az Internet Szolgáltatók a Cisco rendszert használva, mélyen leszállított árakkal tudnak szolgáltatni ügyfeleik számára.

20. Ábra ISP alközpont jellegű IP telefon szolgáltatás


Tehát az Internet Szolgáltatók számlázási és menedzsment rendszerük segítségével képesek komplett telekommunikációs, távhívási és internet elérési szolgáltatásokat biztosítani ügyfeleik számára.

21. Ábra Távolsági IP telefon szolgáltatás

A Cisco Kommunikációs Rendszer architektúrája

A Cisco Kommunikációs Rendszer integrálja a telefon és IP hálózatot.


22. Ábra Hagyományos helyi hálózat, elkülönült adat (IP) és alközponti hálózat

A rendszer felépítésének vezérlő elvei

·         Hang szolgáltatások működtetése anélkül, hogy csökkenne az IP hálózat teljesítménye

·         Teljes együttműködés biztosítása a meglévő PBX és PSTN hálózattal

·         Biztosítsa az együttműködést a H.323 kompatibilis szoftverekkel és eszközökkel

·         Biztosítson digitális hangminőséget

·         Biztosítson szolgáltatásokat egy vállalati rendszer számára, melyek jelenleg csak PBX-el érhetők el.


23. Ábra Cisco Integrált hang adat helyi hálózata

Toll Bypass


A Toll bypass a legáltalánosabb alkalmazás, melyet a vállalatok figyelembe vesznek Voice over IP hálózatuk fejlesztése során. A Toll bypass lehetővé teszi, hogy a vállalatok jelenlegi bérelt vonali kapcsolataikat, melyek csak alközpontjaikat kötik össze, kiváltság, és telefonhívásaikat a meglévő adathálózati infrastruktúrán bonyolítsák le (mint a 24. Ábra mutatja). A vállalatok Voice over IP rendszerekkel lecserélik a kisebb alközpontjaikat a távoli irodákban és eközben felkészítik nagyobb kapacitásra a központi VoIP eszközeiket. Egy másik felhasználási mód a VoIP területén a valós idejű fax átvitel, mely az irodák közötti forgalomra használatos. A tanulmányok azt mutatják, hogy a nagytávolságú hívások nagy része fax forgalom. Tény, hogy a Japánba irányuló távolsági hívások 60%-a fax forgalom.

24. Ábra Toll Bypass nagy magánhálózatban

Fax over IP

A Fax over IP vagy más csomag alapú átviteli technológia egyszerű módszer a szabad sávszélesség rugalmas kihasználására. Ez az alkalmazás megvalósítható valós idejű (real-time) vagy tárol és továbbít (store-and-forward) elven.

A jelenlegi G3-as faxok átvitelének szinkronizációja közvetlen összeköttetésben történik (T.30 engine) oldalankénti egyeztetéssel. Real-time fax átvitelt használva csomagkapcsolt hálózaton a T.30 engine adatait a Cisco router kicsomagolja és értelmezi. A Cisco router becsapja a faxot így nem okoz gondot a csomagkapcsolt hálózatból adódó késleltetés.

A másik ismert faxolási eljárás a store-and-forward fax. Ha implementálni szeretnénk ezt a megoldást, a felhasználónak tudomásul kell vennie, hogy a faxok késleltetése a másodperctől az óráig terjedhet, a módszer logikájából adódóan. A felhasználók nem teszik szóvá, ha faxuk néhány perces késleltetéssel ér célba. A Store-and-forward fax eljárás lehetővé teszi, hogy a fax tárolásra kerüljön, majd továbbítódjon a csomagkapcsolt hálózaton. Ez a beállítás lehetővé teszi, hogy a PSTN költségeket csökkentve, a rendszer a fax számára legkisebb költségű utat válassza. A fax készülékek kisebb problémát okoznak ebben a konfigurációban, mivel a Cisco routereknek nem kell becsapniuk, imitálva, hogy a fax átvitel végpontól végpontig rendben megtörtént.

A 25. Ábra bemutatja, hogy az Austin Texas-i irodájából hogyan jut el a fax London közelében lévő irodába. Austinban az alközpont a faxokat a csomagkapcsolt gateway-en keresztül a fax gateway-be irányítja. A fax gateway válaszol a fax hívásra, és eltárolja a faxot. A Least-Cost Routing algoritmus a fax gateway-ben SMTP üzenetként elküldi a London-i fax gateway-nek két órán belül, amikor a hálózati forgalom kicsi. Amikor a London-i fax gateway vette az SMTP üzenetet, megnézi saját Least-Cost Routing algoritmusát, mikor a legoptimálisabb továbbítani a faxot. A fax továbbításához a fax gateway a Cisco gatewayt használja a PSTN felé. Amikor a fax gateway Londonban vette a visszaigazolást, hogy a fax kézbesítés sikeres, továbbítja azt  a fax gateway-nek Austinba.


25. Ábra Store and Forward Fax továbbítás

A következő generációs telefon szolgáltatók

Jelenleg a legtöbb internet szolgáltató (ISP) szembenéz azzal a kihívással, csak akkor van profitjuk, ha előfizetőnkénti költségük csak havi 20$. Csak korlátozott számú üzleti ügyfélnél lehet magasabb hasznot elérni. Az ISP-knek találniuk kell új szolgáltatásokat, hogy növelhessék előfizetőik számát, valamint új fizető szolgáltatásokat kell találniuk. Több szolgáltató tervezi, hogy IP alapú telefon szolgáltatást nyújt előfizetőinek, felhasználva meglévő infrastruktúrájukat. (Többen már csinálják is.) Ez egy jó ötlet, hiszen a telefonhívások piaca trillió dolláros piac, és a belföldi távhívások piaca is 700 billió perc (USA).

Több ISP is nagy tőkét fektet nagysebességű IP infrastruktúra kiépítésébe. Ha az új hálózat rendelkezik a QoS tulajdonságokkal, valamint több szintű szolgáltatásra is van lehetőség, akkor a hálózat felruházható új applikációkkal, melyek eladhatóak. Hosszú távon ezen szolgáltatások közül talán a legérdekesebb a hang vagy telefon.

Például, ha feltételezzük, hogy Ön otthon ül Californiában és fel szeretné hívni a nagymamáját Bostonban. Ha az Ön nagymamája egy PC guru, használhatják pl. a Microsoft Netmeeting-et és próbálkozhatnak az interneten keresztül. Azonban Ő nagymama így Ő csak a meglévő telefonokat tudja használni. Azonban ha egy ISP VoIP-et szolgáltat két módon is el tudja érni a hálózatát.

Először a felépített kapcsolatát felhasználva használhat egy H.323 kompatibilis applikációt (pl Microsoft Netmeeting) abban közli az alkalmazással, hogy használni kívánja az ISP-je gateway-ét. Mikor is az ISP azonosítja Önt, majd engedélyezi a gateway használatát, melynek segítségével felhívhatja nagymamáját. A nagymama észre sem veszi, hogy Ön VoIP alapon telefonál, mivel Ő a hívást saját telefonján fogadja.

A második lehetőség, ha az ISP VoIP szolgáltatást nyújt a 800-as számon (USA), a felhasználó beüt egy kódot, mely szükséges a VoIP hálózat eléréséhez, másrészt ezen azonosítás alapján történik a számlázás.

Call Centerek

 

A call centerek képezik a vállalatok és az ügyfelek közötti összekötő kapcsot. Fontosságuk kétségtelen, hiszen a tanácsadás, rendelkezésre állás, a gyors és udvarias ügyintézés alapján döntenek sokszor az ügyfelek.

A Call Centerek előnyei:

·         A call centerek kapcsolatot nyújtanak az ügyfelek felé.

·         Gyorsabb és hatékonyabb válaszadás érhető el velük.

·         Nincsenek kihasználatlan sales hívások

·         Növekvő bevétel: több hívás rövidebb idő alatt és növekvő szolgáltatási színvonal.

·         Költséghatékonyság: a képességek és erőforrások jobb kihasználása.

·         Az ügyfelek miközben a kapcsolásra várnak újabb információkhoz juthatnak a termékekkel kapcsolatban.

·         Az ügyfelek nincsenek hosszabb időre magukra hagyva a vonal túlsó végén.

·         Könnyű elérni a megfelelő üzletágat, részleget.

·         Az információk könnyen, gyorsan hozzáférhetőek a termékekről és a szolgáltatásokról.

·         Könnyebben létesíthető kapcsolat az ügyfelek és a velük foglalkozó munkatársak között.

·         Ügyfél adatbázis menedzselés.

·         Nagyobb termelékenység a jobb erőforrás kihasználtság miatt.

·         Az agent számára az ügyfelek egységes képet nyújtanak annak ellenére, hogy azok több csatornát használhatnak párhuzamosan, illetve sorosan.

·         Az ügyfelek számára sima és gondmentes megoldást nyújt a kapcsolatfelvételre.

 

Példa Call Center alkalmazásokra

·         Hotel

Különböző országokban lévő hotelek számára szobafoglalások menedzselése egyetlen call center központ segítségével. A külföldről jövő hívások  mindig az adott  hotel nevében kerülnek fogadásra. A hívó helyének beazonosítása lehetőséget nyújt arra, hogy mindig a hívó ország nyelvét beszélő munkatársak fogadják a hívást. Ez több szempontból hasznos, hiszen ezáltal sem az ügyfél, sem a munkatársak nem kerülhetnek kínos helyzetbe.  Többnyire a munkatársak 2-3 idegen nyelvet ismernek társalgási szinten, ritka és drága az a munkaerő, aki ennél több nyelven beszél. Fontos ilyen esetekben a hívások zökkenőmentes irányítása, hogy mindig a  megfelelő nyelvtudással rendelkező munkatárshoz fusson be a hívás.

 

·         Szerviz Centrum

A szerviz kiterjedt ügyfélhálózattal rendelkezik. A szerviz profilja széles, az egyes szakemberek csak a saját szakterületükön jártasak. Az egyes termékcsoportoknak külön termékfelelőse van. A call centerbe bejövő hívások a hívó fél azonosítása után, az ügyfélhez tartozó kontaktszemélyek csoportjához továbbítódnak. Ha a választott személy valamilyen okból nem kapcsolható, a csoport másik tagjához továbbítódik a hívás.

Az ügyfél így rögtön ahhoz a személyhez kerül, akit ismer.

 

·         Városi Tanács

A call center alkalmazására ilyen körülmények között, elsősorban a nagyfokú hívásfogadási képessége, a hatékony menedzselési lehetőségek, és a valós idejű információ megjelenítés miatt kerül sor. Lényeges, hogy az ügyfelek hívásai a lehető legzökkenőmentesebben legyenek lekezelve. Call center alkalmazása mellett, nagyságrendekkel, közel a felére, csökken az ügyfél várakozási ideje, hiszen nem kell végig várnia a szervezeti hierarchia lépcsői, osztályai közötti átirányításokat. A valós idejű adatok segítik az ügyfelek igényeihez való gyorsabb alkalmazkodást, az erőforrások esetleges átcsoportosítását, az agent-ek hatékonyságának figyelését.

 

Más hasznos alkalmazások

Feltételezzük, hogy Ön a Web-en keresgél. Meglát valami érdekeset, amit meg szeretne venni, de vannak kérdései a termékkel kapcsolatban a vásárlás előtt, de a Web lapon nem talált rá választ. Az eladó egy kis cég, akinek nincs zöld száma, és Ön nem szeretné bontani a meglévő kapcsolatát. Mi lenne, ha Ön kattintani tudna egy gombra a cég Web lapján és felépülne, pl. Netmeeting segítségével egy kapcsolat a cég ügyfélszolgálatával? Az ügyfélszolgálat megválaszolja a kérdését és rögzíti a megrendelését, nincs megválaszolatlan kérdés, az ügyfél és a cég is boldog. A cég megtakarította a zöld szám plusz költségeit, Ön pedig időt takarított meg, valamint pénzt is, mivel nem kellet új kapcsolatot felépítenie telefonálás miatt, főleg ha az távolsági hívás lett volna

Természetesen minden ilyen applikáció igényli a szolgáltatás és a minőség szintek állíthatóságát. Azt is el kell fogadni, hogy csomagkapcsolt hálózatok esetén, jelentős költség megtakarítás csak egy elfogadható hangminőség mellett lehetséges. Például, az emberek elfogadják, hogy többet fizetnek a rosszabb hangminőségért, ha mobil telefont használnak, mivel bárhonnan telefonálhatnak. A csomagkapcsolt telefónia ipar azzal a problémával szembesül, hogy az IP alapú telefonálás minősége gyenge. A valódi probléma az, hogy napjaink internet rendszereiből, valamint IP alapú telefonos applikációiból hiányoznak a QoS paraméterek.

Az ügyfeleknek meg kell mutatni, hogy a QoS alapú hálózat és egy jól megtervezett voice router együttesen jó hangminőséget eredményez.

Távhívó szolgáltatások

Üzleti lehetőségek az ISP-k számára

Az ISP-k a következő előnyöket érhetik el ha a toll-quality távhívás szolgáltatást ajánlják:

·         Új szolgáltatást tudnak nyújtani a meglévő ügyfeleiknek

·         Növelhető a bevétel a meglévő területeken

·         Az ügyfelek számának növelése a meglévő internetes előfizetőkön túl

·         Szolgáltatás csomagok kialakítása a hang és adatszolgáltatások területén

·         Lehetőség értéknövelt applikációk és szolgáltatások használatára, indítására

·         Az IP infrastruktúra költségének relatív csökkenése a tömörített hangátvitel és csend elnyomás megjelenése miatt.

A lehetőségek köre

Az alacsonyabb költségű IP infrastruktúra révén jelentkező megtakarítások kisebb tarifákat tesznek lehetővé az ügyfelek számára. A nemzetközi viszonylatban, ahol a távhívások aránya nagy, az ISP-k versenyképes árakat tudnak kialakítani magas profit mellett. Az  ISP-k nagyot léphetnek előre hatalmas adat és hang szolgáltatási lehetőségeik révén, és elnyerve az ügyfelek bizalmát az ajánlott emelt szintű szolgáltatások révén.


26. Ábra VoIP távhívó hálózat

 Pre-paid Calling Card megoldás

A Cisco IOS™ új lehetősége a pre-paid calling card megoldás. Miként működik a pre-paid calling card szolgáltatás?

A felhasználó hív egy hozzáférési kódot a VoIP szolgáltatójánál, ez általában fel van tüntetve a hívó kártyán.

A Cisco VoIP gateway (pl. AS5300) felismeri a hívó által tárcsázott hozzáférési kód alapján (DNIS), hogy a hívó prepaid szolgáltatást akar igénybe venni. A gateway lejátssza az üdvözlő üzenetet és kéri a felhasználót, hogy üsse be kártyája azonosító számát.

A gateway a fent említett információkat elküldi a RADIUS szervernek egy hozzáférést kérő üzenetben, és megvárja a választ, mielőtt felépíti a hívást.

A RADIUS szervernek azonosítania kell a hívókártyát, visszakeresi a kártyához tartozó hitelkeretet, átváltja a kártyát (meghatározza a perc költséget) és kiszámolja, hogy a kártya hány percig érvényes.

A RADIUS szerver válaszol a Cisco VoIP gateway-nek a hozzáférést kérő üzenetre és megadja a kártya egyenlegét, a telefonállásra rendelkezésre álló percek számát.

A gateway közli a hívóval a kártya egyenlegét, és a telefonálásra felhasználható percek számát, majd felépíti a hívást.

Ha a hívó eléri a telefonálásra felhasználható percek maximumát, egy figyelmeztető üzenet után megszakad a hívás.

Számos paraméter állítható, beleértve a kártya azonosító kódjának hosszát, szükséges-e külön PIN kód beadása és a figyelmeztető üzenettől a bontásig terjedő időszak hossza. A felhasználó egymás után lebonyolíthat több hívást is a hozzáférési kód, kártya azonosító kód és a PIN kód újbóli megadása nélkül Ez egy kényelmi szolgáltatás az ügyfél számára, és megtakarítja a szolgáltató többszöri felhívásából adódó többlet költséget.

Egységes Kommunikáció (Unified Communication /UC/)

Bevezetés

A telefon szolgáltatók és az Internet szolgáltatók között növekszik a verseny és csökken a távolság. A Cisco nyitott felépítésű rendszert biztosít az új jövedelmező, költséghatékony szolgáltatáshoz, az egységes kommunikációhoz.

Az UC új szolgáltatási bevételeket biztosít, megerősítve, hogy beszéd, e-mail, fax kommunikáció független a helytől, időtől és az eszköztől. Eltérően a hagyományos megoldásoktól az UC lehetővé teszi mind a címzett, mind a feladó számára a kommunikáció felügyeletét. Ez a legjelentősebb érték a felhasználó számára — és új bevételi forrás a szolgáltatók számára, biztosítva a költségtakarékos és szabványos infrastruktúrát.

Az egységes üzenet kezeléstől az egységes kommunikációig

A kommunikációs technológia fejlődését a kapcsolódás bárhova, bármikor igénye vezérli. Napjainkban több mint egy billió személyes üzenet – tárolt hangüzenet, szöveg, grafikus kommunikáció személyek, vagy csoportok között - érkezik hangpostán, üzenetrögzítőn, vagy PC-n keresztül az otthonokba. Ez a természetesen jelentkező igény az egységes üzenetkezelésre – a különböző típusú üzenetek konvergenciájára.

De még az egységes üzenetkezeléssel sem változik az a tény, hogy a címzett passzív résztvevő, nehezen tudja azonosítani a beérkező információt és prioritását meghatározni. A kommunikációt valójában az a személy kontrollálja, aki küldi az üzenetet, és a címzettnek kevés lehetősége van a reagálásra. Ez néha csak azt jelenti, hogy szortírozzuk a tárolt és átirányított üzeneteket. Vagy arra kényszeríti a címzettet, hogy válasszon, vagy megválaszol egy mobil hívást egy tárgyalás alatt, vagy megkockáztatja, hogy egy fontos hívást nem fogad. És a fontos üzenet – például egy fontos üzleti hívás – a többi hangüzenet, e-mail vagy fax közé keveredik. Az egyszerű üzenetkezelés nem oldja meg ezt a problémát

Az egységes kommunikáció (Unified communications) a fenti problémát alapjaiban változtatja meg, mivel tartalmazza az egységes üzenetkezelés store-and-forward kézbesítési képességét. Az UC lehetőséget biztosít a címzett számára is (feltéve, hogy képes a kommunikációra aktuálisan), az üzenet kontrollálására. Az UC több kontroll lehetőséget ad a címzett kezébe, biztosítva a valódi kommunikáció lehetőségét, megvalósítva a szinkron valós idejű információ cserét. Felhasználva a normál eszközöket, mobil telefont, faxot és az Internet szolgáltatást, a levél címzettje számos módon magához tudja ragadni a kezdeményezést.

Például ha egy címzett igénybe tud venni egy szolgáltatást, mely egyes meghatározott hívókat azonosítani tud és átirányítja hívásukat a mobil telefonra, míg mások számára tájékoztató üzenetet ad. Vagy a felhasználó beállíthatja UC rendszerét, hogy adjon azonosítást minden hívóról. És ha a felhasználó nem kívánja fogadni a hívást, a hívót automatikusan a hangpostaládához irányítja. A felhasználónak lehetősége van az üzenetet telefonon, e-mail-ben, vagy faxon fogadni arra alkalmas időben.

A Cisco a Unified Communications erejét megfelelő felépítéssel és szabványos protokollokkal biztosítja, megkönnyítve az applikációk integrálását. Megerősítve a partneri együttműködést a vezető fejlesztő cégekkel, a Cisco velük együtt ad UC megoldásokat, melyek napjaink legjobb applikációi.

Egyesített kommunikációs megoldások

Az egyesített kommunikáció első megoldásai:

IP alapú hangposta és Egyesített Üzenetkezelés

Fax store and forward

Rendszer Integrálás

Az alábbiakban áttekintjük ezen szolgáltatások előnyeit, melyek a szolgáltatók számára fontosak lehetnek.

Hívás megválaszoló szolgáltatás

Amteva Technologies fejlesztése, a mobil felhasználók és a kis illetve otthoni irodák dolgozói számára biztosít hangposta megoldást.

Szolgáltatásai:

·         Hívások átirányítása foglaltság illetve nem válaszol esetén

·         A hívók számára lehetővé teszi az üdvözlő üzenet átugrását

·         Üzenetek rögzítése

·         Rögzített üzenetek lejátszása

·         Üzenet újbóli felvétele

·         Másik üzenet hagyása ugyanazon, vagy másik felhasználó számára

Ezek az alkalmazások elszigetelten kerültek megvalósításra az Aamteva által, egy közép kategóriájú Service Platform (SP) alapján. Az Amteva SP-je független hálózati objektumokat tartalmaz, melyek skálázhatóvá teszik a funkcionalitást. Így a megoldás is skálázható az egyszerű egyszerveres változattól a bonyolultabb elosztott hálózaton működő rendszerekig, anélkül, hogy az alkalmazási rétegen változtatni kellene.

A Cisco moduláris OPT architektúrája kulcsfontosságú ehhez az alkalmazáshoz. A Cisco AS5x00 eszközök biztosítják a H.323 gateway-t a PSTN és IP hálózat között, mely IP hálózatra szüksége van az Amteva szervernek. A gateway biztosítja a hívás felismerést és irányítást, a média transzlációt és a távközlésben használatos jelzésrendszert. A Cisco gatekeeper végzi a terhelés elosztást.

Az AS5x00 eszközök irányítják a hangokat s az átirányításhoz szükséges összes hívás információt az üzenetkezelő szerverhez. Az Amteva szervere tárolja a postaláda információkat, az üzeneteket felhasználva a Netscape vagy a Software.com telefonkönyv illetve üzenet tárolási technológiáját.

Hangposta IP alapon

Ez a megoldás a standard Internet protokollt használja a hangposta üzenetek tárolására egy e-mail rendszerben.

Szolgáltatásai:

·         Üdvözlő üzenet és belépési folyamat

·         Üzenet lista

·         Üzenet lekérés

·         Üzenetrögzítés és küldés

·         Üzenetrögzítés és küldés csoport számára

·         Személyes üdvözlőüzenet adminisztráció

·         Személyes postaláda adminisztrálása

·         Új üzenet jelzés beállíthatósága szaggatott tárcsahangra, fényjelzésre

·         Felhasználó értesítése személyhívó rendszeren keresztül

Web mail és e-mail IP alapon

Ezzel a lehetőséggel, az IP alapú hangposta PC-s felhasználói számára lehetővé válik, hogy hangpostájukat közvetlenül PC-jükről érhessék el. A felhasználó hangposta üzenetét e-mail-hez csatolt WAV fájlként kapja meg és ezt játszhatja le. A felhasználó akár azonnal megteheti ezt, vagy akár archiválhatja, mint bármelyik e-mailhez csatolt dokumentumot. A szolgáltatóknak megvan az a lehetősége is, hogy WEB alapú elérést biztosítsanak az e-mailekhez

Ez lehetővé teszi:

·         A teljes körű e-mail szolgáltatást a Software.com vagy a Netscape üzenet szervereire alapozva.

·         Egységes postaláda kezelést hangpostára és e-mailre

·         Kiszolgálja a POP és IMAP klienseket

·         PC és Web alapú kliensek

Fax store and forward

A store and forward fax mint UC megoldás a következő problémákkal foglakozik a Cisco és partnerei technológiáját kombinálva:

·         A faxok integrálása elektronikus dokumentumokkal A faxokat Multipurpose Internet Mail Extension (MIME) formátumú üzenetté konvertálják, Tagged Image File Format (TIFF) formátumú dokumentumként csatolva, mely dokumentumok visszakonvertálhatóak.

·         Javított kézbesítés kontroll címtár szolgáltatások révén, melyek Simple Mail Transfer Protocol (SMTP) alapú mail szerverek és egyéb címtár szolgáltatások révén lehetővé teszik a fax számok és a felhasználók összerendelést

·         Üzenet tárolás és visszaállítás tartalmazza azt a szoftvert, mely a PC-s dokumentumokat TIFF dokumentumokká konvertálják.

·         Lgkisebb költségű út megkeresése (Least-cost routing), számlázás, management és felhasználói belépés web-en keresztül.

Az UC store and forward fax megoldás esetén az  AS5X00 gateway a fogadott fax üzeneteket MIME formátumú üzenethez csatolt TIFF állománnyá konvertálja. A beérkező üzenetek hitelesítésre kerülnek. A gateway készít egy hívástörténet rekordot és az állományt az ESMTP mail szerverhez irányítja, a meghatározott célállomás paraméterrel.

Az üzenetkezelő szerver biztosítja az üzenet átvitelt, a least-cost routingot, az üzenet tárolást és visszaállítást, az e-mail gatewayt és a címjegyzék szolgáltatásokat.

27. Ábra Fax továbbítás Cisco AS5x00 berendezéseken keresztül

 

Az IP hálózat kimeneti oldalán újabb Cisco AS5X00 eszköz biztosítja a gateway átmenetet a PSTN hálózatba. Ezen a ponton a fax applikáció az AS5X00-on fut, biztosítva a küldő fél azonosítását. Az access szerver fax oldallá konvertálja az e-mai szöveges részeit és/vagy a TIFF filet. A gateway elküldi a faxot a célállomás faxkészülékének a PSTN hálózaton keresztül, elkészíti a hívás történet rekordot és ebből generálja a kézbesítési értesítést a feladónak.

A Cisco UC megoldása: a következő lépés

Az UC megoldás képességei bővítésre kerülnek az Amteva új szoftververziói révén.

Az ígért új képességek:

·         Egy számos elérés

·         Hangüzenetek kézbesítése a hagyományos hangposta rendszerekbe.

·         Kimenő hívás szolgáltatások

·         Szöveg beszéddé konvertálása, lehetővé téve az e-mail üzenetek meghallgatását telefonon keresztül.

Az egy számos elérés csak egy példa az UC fejlesztéséből. Amikor valaki kezdeményez egy hívást, egy hangbejátszás értesíti a hívottat, hogy ki a hívó. Ha a hívott nem kívánja fogadni a hívást, visszautasítja azt. Eközben a hívó nem szerez tudomást erről a kis közjátékról és csak azt tapasztalja, hogy hívása egyből a hangposta rendszerbe fut. Az üzenet tárolódik a mail szerveren amíg a címzett azt el nem olvassa. Ha a címzett felhívja a hangpostáját, egyben lehetősége nyílik arra is, hogy meghallgassa e-mail üzeneteit is. Végül a címzett kezdeményezhet kimenő hívást is a rendszerből, hogy azonnal reagáljon pl. egy e-mailre.

Unified Communications: A stratégia a szolgáltatók számára

Az egységes kommunikáció legnagyobb jelentősége abban rejlik, hogy a hagyományos vonalkapcsolt hálózaton működő hang applikációk fokozatosan a háttérbe szorulnak, és átveszik helyüket a csomagkapcsolt hálózaton működő applikációk és telefonos megoldások. Kezdetben prognosztizálható a bevételek növekedése az új hangposta és e-mail szolgáltatások révén. De ez csak a kezdet. Új piacok és csatornák nyithatók meg, ajánlva például a személyhívón keresztüli értesítést, a web-alapú e-mailt.

Az UC megoldás igazából még csak érlelődik de várhatólag attraktív megoldásokat fog nyújtani a nagyvállalati kommunikáció területén is. Azok az IP szolgáltatók, akik képesek UC-t szolgáltatni versenyképes előnyre fognak szert tenni.

Cisco és a Unified Communications

A lehetőségek feltérképezése után tovább lépve az Open Packet Telephony területére a Cisco összegyűjti a megfelelő számú partnert. Ők együtt képesek segíteni a szolgáltatóknak létrehozni a moduláris architekturát, a nyitott interfészekkel és szabványokkal.

Az egyesített kommunikációs rendszerrel a hálózati applikációk egy új kategóriája hozható létre.

Az Open Packet Telephony architektúra: az egyesített kommunikáció sarokköve

Az egyesített kommunikáció IP infrastruktúrát használ, hogy egyesíthesse a kommunikációs eljárásokat, melyek korábban egymástól függetlenül működtek – e-mail, fax készülékek, hangposta rendszerek, mobil telefonok és az Internet. Ez lehetővé teszi a felhasználónak azt az eljárást, mellyel elérheti üzeneteit, és valósidejű kommunikációt kezdeményezhet bármilyen hétköznapi eszközről.

A nehézség ezen szolgáltatás kialakításában abból a távolságból adódik, mely a régi vonalkapcsolt nyilvános telefonhálózatok és az új csomagkapcsolt hálózatok - frame relay, ATM és IP között van. Az tény, hogy a 64Kbps-es csatornák telefonálási célzattal nem eredményezik a sávszélesség hatékony kihasználását. A különbség az, hogy a csomagkapcsolt hálózatok csak a szükséges sávszélességet használják a hívás során. A gyors növekedés és technológiai fejlődés a csomagkapcsolt hálózatok terén nem csak az adatátvitel szempontjából fontos, hanem a beszéd forgalom szempontjából is. A csomagkapcsolt telefonia legerősebb hajtóereje a hagyományos TDM hálózatok cseréjé csomag kapcsolt hálózatra, mely egyaránt kiszolgálja a beszéd, adat és videó kommunikációs igényeket.

A fő akadály az említett applikációk kialakításánál a jelenlegi telefonközpontok struktúrájából adódik. A kapcsolt vonali központok esetén a hívásvezérlés és szolgáltatás logikák gyártónként egyediek – lezárva az utat és elérhetetlenné téve az IP szolgáltatók számára. A frissítések és az új szolgáltatások megjelenése csak akkor lehetséges, ha a központ gyártója úgy dönt, hogy azt ajánlja. Ezáltal a vevő kiszolgáltatott helyzetbe kerül.


A CiscoUC rendszere elkerüli ezt a szűk keresztmetszetet a csomagkapcsolt telefon rendszer segítségével, mely felbontja a régi zárt TDM világot külön álló rétegekre, saját nyitott protokollokkal.

28. Ábra Open Packet Telephony

A Cisco Open Packet Telephony (OPT) felépítése réteges, mely elválasztja a hívásvezérlést a kapcsolástól, lehetővé téve az IP szolgáltatóknak hogy fejlesszék hálózatukat függetlenül a kapcsolóközpont forgalmazójától.

A rendszer a következő rétegekből áll:

Szállítási réteg (Transport layer)—ez ATM vagy IP-alapon működik mely felépíti és vezérli a szállítási kapcsolatokat a hívás vezérlő szinttől kapott vezérlő üzenetek alapján, megfelelő hangminőséget biztosítva.

Nyitott hívás vezérlő réteg (Open Call Control Layer)—feldolgozza a hívás kezdeményezéseket és tájékoztatja a szállítási réteget, hogy építse fel a megfelelő szállítási kapcsolatot a TDM és a csomagkapcsolt hálózat közötti együttműködés céljából. Ez valamelyest hasonlít a hagyományos Szolgáltatáskapcsolási Pontra (Service Switching Point /SSP/) de több rugalmas protokoll hozzáadható, beleértve a H323 és a Media Gateway Control Protocol (MGCP).

Nyitott Szolgáltatás Alkalmazási réteg (Open Service Application Layer)—ellátja a szolgáltatás logikát. Szintén szabványos protokollokat, és applikációs program interfészt használ, hogy kialakítsa az Intelligens Hálózati Szolgáltatás (Intelligent Network /IN/ Service) logikát, jelszó ellenőrzést (Authentication), jogosultság ellenőrzést (Authorization) számlázást (Accounting) (AAA) és a cím felbontást (Address Resolution). Ez lehetővé teszi a fejlesztőknek, hogy új applikációkat fejlesszenek, függetlenül a kapcsolóközpont forgalmazójától, és lehetőséget ad az együttműködésre másokkal. Ez a lehetőség kinevel olyan partnereket, akik integrált, együttműködő megoldásokat fejlesztenek.

Az Open Packet Telephony (OPT) és az egyesített kommunikáció

A Cisco egyesített kommunikációs rendszere vezető módon implementálja az OPT architektúrát. Az UC üzenetkezelő applikációinak szolgáltatásai a Service rétegben találhatók, az UC hívás felépítési logikáját a Hívás Vezérlés (Call Control) réteg tartalmazza, a kapcsolási logika pedig a Kapcsolati (Connection) rétegben található. Az eredmény egy olyan platform, mely nyitottságával biztos alap a jelenlegi és jövőbeni fejlesztésekhez.


29. Ábra Egyesített kommunikációs hálózat elemei

 

Az 29. Ábra bemutatja, hogy az IP szolgáltatók mi módon alakíthatják ki gateway-eiket a tradicionális PSTN vagy Mobil szolgáltatók hálózata és saját csomagkapcsolt OPT hálózatuk között. A hangposta applikációk esetén a PSTN irányítja az ügyfél foglaltsága, vagy nem elérhetősége esetén a hívásokat a gatewayre. Ott a gateway H.323-as protokollt használva kommunikál a gatekeeper-rel és a Transport rétegen felépíti a kapcsolatot a távoli egyesített üzenetkezelő szerverrel. Az üzenetkezelő rendszer Lightweight Directory Access Protocol (LDAP) protokollal lekérdezi az ügyfél adatait és Internet Message Access Protocol (IMAP) segítségével irányítja az üzenetet a tároló helyre. Az ügyfél az üzenetet telefonon, e-mail-en vagy Web alkalmazáson keresztül kaphatja meg.

 

CTI megoldások, szoftverek

 

Napjaink  ügyfelei sok esetben a call centerek helyett a web-alapú kapcsolatfelvételt választják, és az interneten próbálnak válaszokat találni a kérdéseikre. Ez a tendencia egyre jobban megfigyelhető, a vállalatok nagy megelégedésére, hiszen a web olcsóbb és sok esetben hatékonyabb kereskedelem  és tanácsadás szempontjából egyaránt.


Azonban sok esetben a Web-es tanácsadás nehézségekbe ütközik, mivel:

 

·         Az ügyfélnek esetleg csak egyetlen vonala van, és emiatt ki kell jelentkeznie a Web-ről ahhoz, hogy hívást kezdeményezhessen.

·         Az ügyfélnek nem áll rendelkezésére a megfelelő telefonszám.

·         Az ügyfél rossz telefonszámmal rendelkezik, melynek következtében a hívását tovább kell irányítani /általában nem is egyszer/, ami miatt az ügyfél frusztrált lesz.

·         Az ügyfél rendelkezik a megfelelő telefonszámmal, de hívása várakozási sorba kerül, mely miatt mellőzve érzi magát, és gyorsan feladja a várakozást.

·         Az ügyfél a megfelelő emberhez kerül, de mégis el kell mondania, mit csinált, miket tanulmányozott a Web-en, mert a hívás fogadója nem ismeri azokat a Web oldalakat, /nincs minden információ birtokában/.

·         Az ügyfél kérdése megválaszolásra kerül /pl.: kap egy URL címet/, de azt azonnal nem tudja leellenőrizni /mert a telefon foglalja a vonalat/, sok esetben a  cím tévesen kerül lejegyzésre. Ami tovább növeli a frustrációt és az információ gyűjtéssel eltöltött időt.

 

Ezek a problémákat Web alapú kapcsolattal, CTI alkalmazásokkal könnyen elkerülhetők.

 

 

A gondok:

 

Ha egy már meglévő call centerbe újabb hozzáférési csatornákat akarunk nyitni, akkor arra  fel kell készíteni a call centert. Az Internet-hozzáférést támogató szoftvernek  olyan funkciókat kell tartalmaznia, mint pl.: visszahívás gomb, chat, VoIP.

Természetesen a különféle Web böngészőkkel is együtt kell tudnia működni.

A hibamentes működés alapfeltétele, hogy az ügyfél oldaláról csak minimális hátttérinformációkat, erőforrásokat feltételezünk (pl.: telefonszámok/URL címeket nem ismer, a kliens szoftver ill. hardver beállításokat nem tudja megváltoztatni, nincs második telefonvonala).

Az agent oldaláról viszont elvárjuk a berendezések, szoftverek kezelésének megfelelő ismeretét.


WebLine

 

 

Internet/Call Center Integráció

 

A WebLine Communication cég 3 Java alapú programot fejlesztett ki a  Call Center–ek Internetes alkalmazására.

Ezek a következők:

 

·         WebLine Collaboration Server

Támogatja a visszahívást, és együttműködik a Web böngészővel és a szöveg alapú chat-el. Támogatja a pont-pont , pont-több-pont és a több-pont-több pont kapcsolatokat.

 

·         WebLine Media Blender

Bár a Collaboration szerver különálló termék, a Media Blender  teszi lehetővé, hogy a  PBX-ekkel és az ACD-kkel integrálódjon. Szintén a  Media Blender kerül alkalmazásra a VoIP gateway-el való csatlakozásnál. A Media Blenderrel, valamint a CyberSeminar szoftverrel pont-több-pont  1000 résztvevős online konferenciák valósíthatók meg. Végül a Media Blender lehetővé teszi a az interaktív e-commerce alkalmazások készítését, a WebLine Development Kit segítségével.

 

·         WebLine eMail Manager

Az eMail Manager automatikusan a megfelelő agent-hez, vagy support csoporthoz  továbbít, csoportosít és eldönti az üzenetek prioritását, hatékony válaszsablonokat ajánl, és  kívánság esetén automatikusan válaszol is. Fax üzenetek is tud kezelni, melyeket e-mail–ekké alakít.

 

Kapcsolat az ügyfél szolgálattal

 

Tipikus Collaboration Server és Media Blender alkalmazás az az eset, amikor az ügyfél a Web oldalon megnyomja a Help gombot, mely más oldalakra mutat olyan  opciókkal, mint pl.: visszahívást kérek, szövegalapú chat /társalgás/. Ilyen eset figyelhető meg az alábbi ábrán.

 

 

29/a.Ábra: Kapcsolat az ügyfélszolgálattal, a WebLine-on keresztül

Ábra magyarázat: Az ügyfél rákattint a WebLine-os „Click for Help” gombra(1). A kérést fogadja a WebLine Collaboration  szerver majd onnan tovább kerül a WebLine Media Blender (2) felé. A Media Blender  meghívja az ACD funkciót mely a CTI stratégián alapul(3). Például, az ACD azonnali visszahívást kezdeményez (4). Az ACD az agent várakozási sorába tesz egy bejegyzést (5). Miután az agent felveszi a kapcsolatot, az agent és az ügyfél adat alapú kommunikációja (pl. osztott WEB lap, vagy szöveg alapú chat) a WebLine Collaboration szerveren keresztül folyik(6).

 

Ha az ügyfél valamilyen opcióra kattint, (ebben az esetben: visszahívás az együttműködő Web  böngészővel), a HTML kód hozzá van rendelve ahhoz a kódhoz, mely kívánságot generál a WebLine Collaboration szerver felé. Ezen a ponton a  Collaboration szerver igény menedzsment  modulja letölti a 80Kbyte-os Java klienst az ügyfél munkaállomására. Kezdésnek egy kicsi (3Kbyte-os ) JavaScript és a HTML kód aktiválódik.

A WebLine Lite Caller néhány alapvető diagnosztikai információt visszaküld a Collaboration szervernek: operációs rendszer, böngésző típusa, verziószámok, és a kapcsolat sebessége. Ezután a Lite Caller két irányú Web lap megosztást, file átvitelt, szöveg alapú chat-et, és kulcsszó-alapú hirdetést tesz lehetővé. A 3.0 verzió támogatja a csak adatot fogadó Windows alkalmazás demókat is.

Eközben a Collaboration Server továbbítja a kérést (lásd 2. lépés) a Media Blender Web integrációs modulja felé.

A 3. lépésben  a Media Blender üzeneti busz-án keresztül a kérés befut a Media Blender ACD integrációs moduljába, mely tartalmazza a különféle  CTI megoldásokat. /Például, meg kell csörgetni az ügyfél telefonját bizonyos típusú kérések esetén/. Más esetben az ügyfelet várakozási sorba kell tenni, amíg a megfelelő agent-hez nem irányítható. A Media Blender képes ACD által generált információk továbbítására is /várakozási sorok, illetve az ügyfél böngészője felé/, ahogy az a 4.  lépésnél látható.

Amikor az agent várakozási sorában a bejegyzés sorra kerül, (5. lépés), az agent felveszi a kapcsolatot az ügyféllel. Az agent ezután Web lapokat tud küldeni az ügyfél képernyőjére (6. lépés).

Bizonyos megszorításokkal, az ügyfélnek is lehetősége van az agent képernyőjére Web lapot küldeni. Ez a megoldás sokkal hatékonyabb, mintha csak  az URL címeket diktálnánk le az ügyfélnek telefonon keresztül.

 

Amennyiben az ügyfél a VoIP kapcsolat mellett dönt, a kapcsolat a Media Blender-től  a VoIP gateway-en keresztül megy a switch-ig.

 

Egyedülálló Collaboration Server esetén (Media Blender, PBX és ACD nélkül), a szerver a kéréseket TCP/IP hálózaton keresztül a megfelelő agent-hez közvetlenül küldi.

Lucent és Aspect PBX-ek esetén, a parancsok a Media Blender-ből az ACD-be közvetlenül mennek. A Nortel és Rockwell PBX-ek esetén a parancsok valamilyen szoftvergyártó CTI termékén keresztül mennek át /mint pl. a Dialogic cég CT-Connect nevű szoftvere/.

A 29/b. ábra megmutatja, hogy a közvetlenül kapcsolódó, illetve a driver-alapú felületek hogyan működnek együtt az ACD-vel és a többi komponenssel.

A Collaboration server és a Media Blender lekezeli a Web-es, szöveg alapú chat, VoIP  beszélgetés, illetve visszahívás kéréseket. Hozzáillesztik ezeket a kéréseket, a már meglévő call center rendszerhez.

WebLine architektúra

 

 

29/b Ábra. WebLine architektúra

A Media Blender és az ACD közötti csatlakozó felület, hagyományos a Lucent és az Aspect ACD-knél. A Nortel és Rockwell ACD-k esetében azonban külön CTI driver (például CT-Connect /Dialogic/) szükséges az összeillesztéshez.

E-mail-ek továbbítása külön történik a többi kommunikációs formához képest.

 

Szolgáltatások és funkciók

 

Útvonalválasztás és várakoztatás / Routing and Queuing/

Komoly kihívás, hogy a már meglévő call center útválasztás és várakoztatási funkcióihoz kapcsolódási felületet alakítsunk ki. Azzal, hogy Web-ről kezdeményezett kapcsolatok úgy látszanak, mint  Call Centerbe bejövő hívások, a Media Blender lehetővé teszi, hogy felhasználhassuk a  rendszer útválasztó képességeit ezekhez a kapcsolatokhoz is.

A visszahívás kérések, szöveg alapú chat, és VoIP kapcsolatok  bekerülnek az egyes agent-ek saját várakozási sorába. A call center rendszer ezáltal képes ugyanazokat a szabályokat, elveket, és útválasztási stratégiákat használni, mint hagyományos esetben, és az agent is hagyományos, megszokott  módon tudja kezelni őket, függetlenül attól, hogy  hagyományos telefonhívásról, vagy pedig Web-en keresztül kapott kérésről van szó. Persze, néhány esetben ez nem előnyös /pl. ha a Web-ről származó kérés, hirtelen megjelenik az agent képernyőjén, mialatt ő éppen telefonál/, mert az agent hatékonysága csökkenhet.

Ezért ahelyett, hogy a bejövő kérések, azonnal megjelennének a képernyőn,  várakozási sorba kerülnek, és csak akkor aktivizálódnak, amikor sorra kerülnek.

A telefonhívásokhoz hasonlóan, a VoIP kapcsolatok és a szöveg alapú chat-ek is ugyanúgy tartásba tehetők, illetve konferencia képezhető belőlük.

 

Web lap feldobás /Web Pop/

Ha az ügyfél Web lapon keresztül kapcsolatot kezdeményez, egy Web lap bukkan fel az agent képernyőjén, amikor a várakozási sorban a kérés sorra kerül. Az agent ezért már azelőtt tudja, hogy mi iránt érdeklődik az ügyfél, mielőtt fogadná a hívást. Az agent ezenkívül  információkat kap arról is, hogy az ügyfél milyen operációs rendszert, milyen típusú és verzió számú böngészőt használ, és milyen gyors az internet hozzáférése. A kapcsolat sebességmérés a WebLine Collaboration Server és az ügyfél közötti adatcsere alapján történik. A kapcsolat tűréshatár /Connection threshold/ funkció, figyelmezteti az agent-et, ha az ügyfél túl lassú kapcsolattal rendelkezik.

 

Elosztott művelet /Distributed operation/

A WebLine Media Blender-t kiegészítették automatikus útvonalválasztó szoftverrel /GeoTel  termék/, így az agentek transzparensen tudnak átküldeni kéréseket földrajzilag elosztott call centerek között.

 

Jelentés /Reporting/

Alapvetően 3 féle jelentés típus áll rendelkezésre a WebLine környezetben: Call center jelentések, WebLine jelentések, és integrált jelentések.

 

·         Call Center jelentések

Ezek tartalmazzák, a Webline alapú kapcsolatokat is, a call center rendszer úgy látja ezeket a kapcsolatokat mint hagyományos telefonhívásokat. Például, a call center manager  felhasználhatja ezeket a jelentéseket, hogy megállapítsa, vajon az együttműködő Web böngészés csökkentette, vagy növelte a support hívás időtartalmát.

A call center jelentések  átfogó képet adnak a call center működéséről.

Az agentek is összehasonlíthatók, lehetőség van arra, hogy az agentek az egyes kapcsolati módok szerint rangsorolva legyenek, és ezek alapján leghatékonyabb agenteket fogadják a legtöbb adott típusú kapcsolatot.

A jelenlegi call centerek általában csak a telefonhívásokra vonatkozó jelentéseket tudják elkészíteni. Pedig az együttműködő Web-es kapcsolatoknál az is fontos adat lenne, hogy az ügyfelek melyik Web lapokat nézik a legtöbbet, mennyi ideig nézik a lapokat, honnan jutottak el az adott Web lapra.

 

1.      WebLine jelentések

Ezek a jelentések azokat az információkat tartalmazzák, melyek a WebLine saját működésére vonatkoznak, így kimaradtak a call center jelentésekből.

 

2.      Integrált jelentések

A rendszer külön, egyedi programozásával  (Quintus, Clarify, Vantive termékei), vagy SQL adatbázisok (mint pl. Oracle, Sybase, vagy MS SQL Server) olyan jelentések készíthetők melyek ötvözik a call center és a WebLine által szolgáltatott jelentéseket. Az ilyen jelentések készítése programozást igényel.

 

 

Java

A WebLine Java alapú. A WebLine saját termékei a Java Telephony API (JTAPI)-n alapulnak és gyakran a JTAPI használatával integrálódnak össze más termékekkel. A kliens funkciók egy 3 Kbyte-os JavaScripten és egy 80 Kbyte-os Java applet-en keresztül valósulnak meg, melyeket a Collaboration Server  letölt az ügyfél böngészőjébe.

A letöltés elméletileg transzparens az ügyfél számára. Azonban, ha az ügyfél böngészője úgy van beállítva, esetleg riasztást küld, a letöltési kísérlet miatt.

 

Az ügyfél zavartalanul tovább szörfözhet az internetet, miközben az agent visszahívására várakozik, hiszen a Java applet jelez az ügyfélnek ha esedékes a kapcsolatfelvétel.

Az ügyfelet igény esetén az applet automatikusan vissza tudja vinni a kiinduló oldalra, ha az agent fel akarja venni vele a kapcsolatot. Az applet jelez akkor is, ha a szöveg alapú chat válasz megérkezett. Az agent oldalt is fel tud dobni, az ügyfél képernyőjére, miközben az ügyfél tovább szörfözik a hálózaton, bár ez a megoldás kicsit erőszakosnak tűnhet.

 

A Collaboration Server  kulcsszó alapú hirdetéseket tud küldeni a tartásba tett ügyfelek számára. Ezenkívül, szöveges üzeneteket tud küldeni a kérés kiszolgálásának állapotáról (pl:  „Ön éppen csatlakozott”, „Ön jelenleg harmadik a várakozási sorban”, illetve kijelezheti mennyi időt kell várni előreláthatóan.

Ezeket az információkat az ACD készíti, ezért ezen információk erősen függnek a csatlakozási felülettől, és az ACD-től. A Collaboration Server  a várakozási idő alatt Web lapokat, videót, audiót (pl. hirdetéseket) tud küldeni az ügyfélnek. Ezeknek a küldeményeknek tartalma különböző forrásokból származhat, mint például Web/videó szerverektől  (pl. hirdetések ), ACD-ktől  (várakozási idő kjelzés).

 

 

Előnyös tulajdonságok

 

·         Osztott képernyős Web együttműködés. Az agent egyszerre két különböző Web lapot tud egymás mellé feltenni az ügyfél képernyőjére.

·         Űrlap megosztás. Az agent segíteni tud az ügyfélnek az űrlap kitöltésében.

·         Az elterjedt böngészők támogatása. Ez vonatkozik a különböző verziók támogatására (Netscape, MS Internet Explorer), illetve a nemzeti verziókra is.

·         Java A Java előnyeinek kihasználása: platfom függetlenség. Server oldalon támogatott operációs rendszerek: Windows NT, Solaris és a Linux operációs rendszereket.

·         E-mail automatizálás eMailManager segítségével

·         Nincs szükség kliens oldali szoftver installációra. Nincs szükség plug-in-ekre, kiegészítésekre, varázslókra. Ez igen fontos szempont pre-sales, illetve e-commerse alkalmazások esetében, mivel az átlagos ügyfél nem szeret/nem tud szoftvert installálni, beállításokat végezni.

·         Zökkenőmentes együttműködés a vezető call center gyártók termékeivel (pl. Lucent, Aspect,Nortel, Rockwell). /Ez a négy legnagyobb gyártó a piac 80%-át uralja/.

·         Nincs szükség speciális biztonsági követelményekre. WebLine együttműködik a mindenkori Web biztonsági követelményekkel. Nincs szükség sem új portok nyitására a tűzfalon, sem proxi újra konfigurálásra, nincs szükség a szűrő feltételek megváltoztatására.

·         A kapcsolatfelvétel széles választékát támogatja.

Kapcsolati módok:

·         Visszahívás

·         VoIP

·         Szöveg alapú chat

·         Együttműködő Web böngészés

·         E-mail

·         A WebLine kapcsolatok automatikusan megjelennek a call center jelentéseken, mellyel lehetőséget adnak a call center menedzsereknek arra, hogy újabb aspektusból mérhessék a promóciók hatékonyságát, az agent-ek munkáját, a Web lapok nézettségét.

 

ICM

 

A Cisco ICM szoftver olyan CTI  környezetet biztosít, mely integrálja a hang/adat hálózatokat, az ACD-ket (Automatic Call Distributor), az IVR-eket (Interactive Voice Response System), Web szervereket, adatbázisokat, agent munkaállomásokat, és egyéb egységeket. A szoftver képes a különböző hang és adat rendszerek menedzseléséhez  egységes felületet biztosítani.

 

Cisco ICM Software

 

1.       Periféria Gateway (PG) folyamatosan adatokat küld /agentekről, hívásokról/ az ICM szoftver felé.

2.      Ügyfél hívás, ingyenes számmal

3.      Hálózat routolási lekérdezést és hívás információkat a gépéről (SCM) az ICM szoftver felé.

4.      Az ICM lekérdezi az ügyfél nyilvántartást és folyamatosan felülvizsgálja a teljesítmény és erőforrás értékeket.

5.      Az ICM szoftver megmondja, a hálózatnak a legmegfelelőbb erőforrás elhelyezkedését.

6.      A hálózat a hívást ahhoz az ICM által mondott ACD-hez kapcsolja, amelyiknél a választott agent csoport elhelyezkedik.

Intelligens kapcsolat menedzsment megoldás

 

Az ICM szoftver csomag a kritikus működésű CTI alkalmazások összeintegrált halmaza, mely képes kielégíteni mind a jelenlegi, mind pedig a jövőbeni igényeket a kisebb illetve nagyobb egy-központos call centerek területén.

Ez a Cisco megoldás core platformot nyújt az integrált ACD-k, IVR-ek, vállalati adatbázisok, multimédia  kapcsolatú csatornák és desktop alkalmazásoknak, felhasználja a már meglévő központi rendszereket, miközben kiterjeszti azok értékét és a képességeit.

 

 

A termék javítja az ügyfelek iránti nyitottságot, és a központ hatékonyságát azzal, hogy optimalizálja az ügyfelek és az erőforrások közötti interakciót.

 

Az ICM képességei és előnyei

 

 

·         Adatszolgáltató CTI

A vállalati CTI termékek csatlakozási felületetet képeznek az ICM szoftver és a desktop/szerver alkalmazások között. Az agent képernyőjére a hívással egy időben, plusz információkat (a hívóhoz kapcsolódó információk, események/beruházások, az ügyfélnyilvántartás adatait) helyeznek fel. Az adatok akár több hálózatból, különböző ACD-kből, IVR-ekből és munkaállomásoktól is összegyűjthetők.

·         CTI Szerver

Menedzseli a valós idejű, illetve korábban eltárolt, különböző hálózatokból származó  információkat. A rendszer nyílt architektúrájába könnyen beleépíthetőek újabb szerverek,  megoldások,  melyek az adott igényeket jobban kielégítik. A rendszer teljesen hibatűrő és korlátlan mennyiségű kliens kapcsolódását támogatja, ebből következően flexibilis, és kiválóan skálázható.

 

·         CTI Desktop

A CTI Desktop felruházza az agent munkaállomását egy telefon összes képességével. A termék ActiveX vezérlők gyűjteményéből épül fel, mely desktop alkalmazást nyújt teljes CTI szerver hozzáféréssel, miközben a létező telefon rendszer leírásával, a fejlesztők és a kapcsoló központok menedzserei könnyen integrálhatják az alkalmazásokat az ICM környezetbe bonyolult programozás, illetve rendszerintegráció nélkül. A CTI desktop  teljes funkcionalitást foglal magában: egyéni kialakítású szoftver telefonok /softphone/, számos softphone kontroll-ok, melyek  már létező alkalmazásokba is beépíthetőek, fejlesztői  készlet, TAPI 2.1 interfész, valós idejű agent statisztikák a desktophoz, és teljes mértékű hibatűrés.

 

·         Java Kliens

A Java kliens beágyazható bármely Java alkalmazásba. A termék olyan desktop alkalmazásokat nyújt, melyekkel a telefon rendszer részletein alapuló CTI funkcionalitások korlátlanul  hozzáférhető. Végül, a CTI működések könnyen létrehozhatók és integrálhatók a vállalati alkalmazásokkal, azok programozása nélkül.

 

·         Pre-Routingä

A Pre-Routing a hívás-elosztás intelligencia egyik alkalmazása, amikor az ügyfél a hálózatban van már, mielőtt valamelyik erőforráshoz továbbítanák a hívását. Az ICM ezen képessége lehetővé teszi, hogy hatékonyan szegmentálja a hívókat, súlyozza a hívásokat a központ felé és minden hívást a lehető legjobb kezelőhöz továbbítson. Minden beérkező hívásnál, az ICM szoftver útválasztási kérést kap a hálózattól. A hívásról a rendelkezésre álló információk alapján megállapításra kerül, hogy honnan jött és milyen okból.

A rendszer folyamatosan nyilvántartja, hogy milyen erőforrások állnak rendelkezésre (agent hatékonysága/rendelkezésre állása, IVR státusz, várakozási sor hossz, stb.) és ezek az erőforrások hogyan érhetőek el.

Ahogy a rendszer jellemzői változnak, az adaptáció a felhasználó által meghatározott routolási sablonok alapján történik. Ez garantálja az adott tevékenységhez legjobban illeszkedő útvonalválasztást.

·         Post-Routingä

Olyan intelligens kapcsolat elosztás, mely a vállalat hálózatának valamelyik perifériájához már hozzákapcsolódott hívásokat érinti. Ha a hívást át kell irányítani, a periféria post-route  kérést küld az ICM szoftvernek. Az ICM szoftver ekkor, lefuttatja ugyanazt az útvonalválasztó scriptet, mint a pre-routing esetében.

 

·         Több szolgáltatós hálózat támogatása /Multi-carrier, Multi vendor Capabilities/

A több szolgáltatós megoldás lehetővé teszi a vállalatoknak, hogy függetlenedjenek a kizárólagos szolgáltatótól. Az ICM szoftver nyílt architektúrája támogatja a heterogén szolgáltatói hálózatokhoz való kapcsolódást.

Az ICM szoftver lehetővé teszi a vállalatnak, hogy routoljon ingyenes  számokat egyszerre több hálózaton keresztül és ezáltal kihasználhassa a 800-as számok hordozhatóságának  előnyeit.

Az ICM megoldás platform függetlenséget is nyújt, mivel a kevert típusú ACD-s környezetet (Alcatel, Aspect, Lucent, NEC, Nortel Networks, Rockwell és Siemens ) is támogat.

Hasonlóképpen az IVR gyártók esetében is széles palettát támogat.

Végül, az ICM integráció, a legkiválóbb hívás-nagyság előrejelző, munkafolyamat kezelő, agent ütemező programokkal, valamint a prediktív tárcsázás és más funkciók , lehetővé teszik, hogy a vállalat az egyéni sajátságaihoz legjobban adaptálódó, hatékony  rendszerrel dolgozhasson.

 

·         IVR Integráció

Az  IVR-ek /Interactive Voice Response / rendszerek, igen fontos részegységei a vállalati rendszereknek. Az ICM szoftver sokféle gyártó IVR-jével együtt tud működni, mint a pre, mint pedig a post routing részében a hívásoknál. A vállalati IVR-ek támogatják a hívófél azonosítást, és szegmentálást, a hatékonyság alapú útvonalválasztást, és az IVR terheltség elosztás. Közvetlen, két irányú kommunikációt is lehetővé tesz az ICM szoftver az IVR port utilizációjának menedzselésére és ahhoz, hogy az IVR által küldött adatok belekerülhessenek a központ teljesítmény jelentéseibe.

 

·         Távoli és nem ACD agentek támogatása /Remote and Non-ACD Agent  Support/

Hívás elosztás, és jelentés készítésre van lehetőség  nem csak a kisebb vállalatok esetében, hanem SOHO (Small Office/Home Office) és más nem ACD-alapú agent-eknél is.

A készenállás alapú útvonalválasztás mellett, softphone-okat, oldal feldobást, és egyéb hívás irányító funkciókat tesz lehetővé a távoli agent-ek számára. Az otthoni munkavégzés lehetősége bővíti és javítja a munkaerőpiacot, az agentek elvándorlása lecsökken, az üzemeltetési költségek a helyfüggetlenség miatt radikálisan csökkenthetőek /egyetlen központ használata, otthoni munkavégzés/.

 

·         Web integráció

Az interaktív Web-es alkalmazások segítségével a kapcsolatfelvételi lehetőségek kiszélesedett. A szabványos, nyitott felület ugyanúgy osztja el az Internetes hívásokat, mint a hagyományos hanghálózatról érkező hívásokat. Amennyiben az ügyfél kapcsolatfelvételt igényel, adatgyűjtés, hatalmas adatmennyiségű lapok képernyőre dobása és egyéb alkalmazások segíthetik a munkát.

 

·         Ügyfél-alapú útvonalválasztás

Az ICM szoftver tartalmazhat SQL-gateway-t /SQL adatbázis szerverek felé/ és egyéb gateway-eket /nem SQL alapú szerver alkalmazások felé/ melyek adatokat szolgáltathatnak a hívások útvonalának megválasztásához. Az ilyen adatbázisokban az ügyféllel foglalkozó vállalati kontakt személyek is nyilvántarthatók. A hívófélazonosítás után az ügyfél ezen adatok alapján, azonnal a megfelelő emberhez kerül. Olyan személy fogadja a hívását, akit ismer, és aki megfelelő háttér-információkkal rendelkezik.

 

·         Munkaerő menedzsment integráció /Workforce Management Integration/

Kapcsolati terv /Schedule Link/ befolyásolja a hívás-mennyiség-előrejelzés adatot és agent ütemezést, melyet a munkaerő menedzsment  rendszer készít. A vállalat hatékonyságát ez elsősorban az erőforrások állandó, optimális kihasználása miatt növeli.

 

·         Rendszer partícionálása

A partícionálás lehetővé teszi a vállalatnak, hogy egyetlen ICM szoftver segítségével üzemeltessen különböző vállalati egységeket. A különálló egységek autonómiával rendelkezhetnek működési politika, eljárások  és központi műveletek területén, például saját scriptek, saját csoportok, és ütemezés. A rendszer természetesen komplex egységként működik, hiszen csak így valósítható meg a vállalat egészének, (az ACD-k, a hálózati elemek, és az erőforrások) optimalizálása.

 

·         Nyílt architektúra

Mivel az ICM szoftver olyan rendszereket támogat mint pl: Microsoftä Windows NT, Microsoft SQL Server és Powersoft InfoMaker, a vállalatok élvonalbeli vezető szoftvereket alkalmazhatnak, akár szerény hardverköltségek mellett is. Az ICM szoftver nyitott architektúrája / mely magában foglal ODBC-kompatibilis adatbázis, nyitott CSTA switch interfész, TAPI és ActiveX interfészek a CTI megoldásokhoz/ lehetővé teszi a szoros kapcsolódást a már létező központi megoldásokhoz. Ezáltal lecsökkennek a fejlesztési/beruházási költségek, miközben a felület teljeskörű támogatást nyújt a jövőbeni alkalmazások számára is.

 

·         Elosztott hibatűrés /Distributed Fault Tolerant/

Minden ICM szoftver komponens és külső alkalmazás hibatűrő, mind hardver, mind pedig szoftver szempontból. Öndiagnosztika és automatikus hibajavítás. A rendszer rugalmasan kezeli a hardver eszközök kiesését, a kommunikációs hálózat hibáit, és/vagy az aszinkron szoftver hibákat. Az ICM szoftver, SNMP üzenet küldő képessége miatt, nagykiterjedésű hálózatok menedzsment rendszereibe is könnyen beintegrálható.

 

·         Véglegesített, átfogó vállalati jelentések

Az ICM szoftver átfogó vállalati, normalizált, valós idejű és régebbi adatok gyűjteményét tudja szolgáltatni a működésileg nagy fontosságú központokról. Az ICM nyílt architektúrája folyamatos információ gyűjtést, szolgáltatást tesz lehetővé a hagyományos hang hálózatról, az Internetről, az ACD-kről, az IVR-ekről, Web szerverekről, adatbázisokról, vállalati alkalmazásokról, az agent-ekről  és más erőforrásokról. A hívások, az ügyfelek és a perifériák adatai Microsoft SQL Szerverben vannak összegyűjtve, tárolva. Az agent-ekről személyre szólóan információk gyűjthetők, és ezáltal hatékonyan lehet mérni az agent-ek hatékonyságát.

Az ICM szoftver jelentés készítő csomagja, lehetővé teszi a vállalatnak, hogy már előre kialakított jelentési sablonokat használhasson, monitorozzon meghatározott tűréshatárok alapján, megszabhassa a jelentések részletességének/felbontásának mértékét, és időinterallumhoz kötött jelentéseket készíthessen.

 

·         Web-alapú Monitorozás

Web View csak figyelő (monitorozó) hozzáférést tesz lehetővé az ICM szoftver jelentéseihez, a routolási scriptekhez Microsoft Internet Explorer 4.0, illetve Netscape Navigator  3.0/4.0 Web böngészők segítségével. A jelentések igény esetén, illetve  folyamatosan figyelhetők. A Web View ideális alkalmazást jelent a rendszer supervisor-jainak, menedzsereinek.

 

 

 

Példák CTI technológia alkalmazására

 

Otthoni felhasználás

 

CTI technológia nélkül

Tévénézés közben eszébe ötlik, hogy fel kell hívnia egyik külföldi kollégáját, aki éppen külföldön van és hamarosan tovább utazik. Ezért meg kell keresni a telefonkönyvben a külföldi hotel telefonszámát, és az ország  hívószámát. Majd fel kell hívni a számot /többnyire csak másodikra sikerül a hossz miatt/. Mire vége a hívásnak,  a filmnek  lassan vége….

 

CTI technológiával

A film alatti egyik reklámblokkban a TV távirányítóval megjeleníti a személyes könyvtárát a TV képernyőjén kép-a- képben funkcióval, majd kiválasztja a kolléga telefonszámát.

A TV képernyőjén ekkor megjelennek azok a telefonszámok, melyeken keresztül a kollégát el lehet érni /többek között a hotel száma is/. Kiválasztja a hotel számát az adatok közül és hívást kér. A hívás automatikusan felépül. A TV ekkor átalakul telefonná, és a hangszórókon keresztül lefolytatható a társalgás, anélkül, hogy telefont a kézbe vennénk, illetve felkelnénk a fotelből. A hívás költsége, és a hívott szám, automatikusan rögzítésre kerül az otthoni adatbázisban.

 

 

 

Távmunka, bedolgozás

 

CTI technológia nélkül:

A távmunka sok kompromisszumot jelent. A rengeteg telefon gyorsan megtölti a munkahelyi hangposta fiókot. Nem jó ötlet az otthoni telefonszámra irányítani az összes hívást…

 

CTI technológiával:

Nincs szükség kompromisszumokra. Az otthoni számítógép közvetlen kapcsolatban áll a munkahelyi LAN-al, miáltal nyomon követhetőek a munkahelyi telefonra beérkező hívások. Ha fontos hívás fut be, a számítógép jelzi a hívó számát, ezután csak azt kell eldönteni, hogy a hívás az othoni készülékre legyen átirányítva, vagy pedig a munkahelyi hangposta fiók  vegye át a hívást. Ha az otthoni telefon éppen foglalt, akkor Internet telefon segítségével fogadható a hívás. Ilyen megoldással a Call Center-ben dolgozó agent-ek akár otthonról is tudják végezni a munkájukat.

 

Munkahelyen

 

CTI technológia nélkül:

A hangposta fiókba sokszor érkeznek olyan hívások, melyeket más munkatársak le tudtak volna kezelni. A hívások nagy része hangpostába ütközik, és ez elvesztegetett időt, újrahívásokat, sok bosszúságot eredményez.

 

CTI technológiával:

A munkahelyi személyi számítógép átalakul személyi titkárnővé. A hívás összes lényeges információja megjelenik a képernyőn /a hívó telefonszáma, a telefonszámhoz tartozó egyéb információk az adatbázisból/. A hívások fogadása letiltható, illetve automatikusan továbbíthatóak a tárgyalásra alkalmas személyek felé. Ha a  hívott fél foglalt, illetve nem elérhető, a  számítógép képes a  folyamatos újrahívásra a háttérben. Amikor felépült a kapcsolat a hívottal, ezt tudatja a képernyőn keresztül.

 

Iskolai alkalmazás

 

CTI technológia nélkül:

Az egész iskolában összesen 3-4 telefonvonal található, melyeket kizárólag a tanári szobából, illetve a gazdasági és az igazgatói irodából lehet elérni. A telefonálás az iskolában szigorú ellenőrzés alatt áll, a tanulók csak komoly indokkal használhatják a telefonokat. A telefonokat elsősorban azért nem teszik nyilvánossá, mert nem tudnák ellenőrizni a telefonhasználatot és nem bíznak eléggé a diákokban.

Az iskolákon belüli kutatások, fejlesztések, egyéb projektek azonban sok esetben igényelnék a telefon használatot…

CTI technológiával:

Az iskola Internet telefon gateway-el rendelkezik, és a könyvtárban, termekben  lévő számítógépek  rendelkeznek hangkártyával, fülhallgatós mikrofonnal, valamint ezeket  vezérlő szoftverekkel. A tanulók képesek ezekkel az eszközökkel nem csak egymást, hanem más iskolák tanulóit is elérni. A hívásokat természetesen adatbázis alapján szoftveresen engedélyezni, illetve korlátozni lehet.

 

Értekezlet, konferencia

 

CTI technológia nélkül:

Komoly problémát jelent, hogyan várjunk egy igen fontos hívást, miközben egy ugyanolyan fontos megbeszélés közepén vagyunk.

Ha nincs személyi titkárnőnk, és nem lehet felvenni minden hívást a megbeszélés alatt, akkor  legjobb ötletnek az tűnik, hogy hangpostába küldünk minden hívást. A hangposta  meghallgatásához pedig, gyakran kell kimennünk a teremből, a szokásos bocsánatkérő szövegeket mondogatva…

 

CTI technológiával:

A személyi titkárnő funkciókat átveszi az irodai számítógép.  Minden egyes befutó hívást megvizsgál, és eldönti róla, hogy milyen fontosságú. Ahelyett, hogy automatikusan hangpostába rakná a hívót, azt mondja, hogy megpróbál megkeresni és kapcsolni. Ezután rövid szöveges üzenetet küld a személyhívóra/mobil telefonra mely tartalmazza a hívó számát, és azt, hogy a hívó jelenleg tartásban  van. A visszaküldött válaszüzenet alapján a hívót kapcsolja, átirányítja egy általunk megadott másik számra, illetve közli vele, hogy nem tud kapcsolni, majd hangpostába rakja a hívót. A megbeszélés többi résztvevője nem is sejti, hogy közben a számítógéppel folytattunk társalgást.

 

 

 

 

 

Cisco VoIP termékek

Access router kategória

Cisco 1750

A Cisco 1750-es a legkisebb adat/hang integrációt megvalósító access router. Felépítésében a sikeres Cisco 1720-as modularitását és nagy teljesítményét követi, a VoIP és adatkommunikációs moduljai (WIC, VIC, VWIC) közösek a Cisco 1700/2600/3600 családéval. Mivel a Cisco 1750 hivatalos megjelenése az év harmadik negyedében várható, ezért részletesebb információval ezen anyag készítésekor még nem rendelkezünk.

A Cisco 2600/3600 család hang/fax modulja

A Cisco 2600/3600 család hang/fax modulja a hang és fax forgalom IP vagy Frame Relay hálózaton való továbbítását biztosítja. Ezek a modulok a 2600/3600 modulhelyeire kerülhetnek és egy vagy két hang-interfész kártyahelyet (VIC) tartalmaznak. A modulra kerülő hang-interfész kártya biztosítja a kapcsolatot a telefónia berendezéseivel. Hasonlóan az adatforgalomhoz használt WAN interfész kártyákhoz, a hang-interfész kártyák tetszőlegesen cserélhetőek egymás között.

30. Ábra 2600/3600 család hang/fax modulja

Az analóg hang-interfész kártyák választéka két-portos FXS, FXO és E&M, valamint szintén két-portos digitális ISDN BRI. A Cisco 2600 és a 3620 egy hang/fax modult támogat, ami akár két VIC-et is tartalmazhat, míg a Cisco 3640 három modullal hat VIC-et is használhat. Így ezzel a modullal a Cisco 2600 és 3620 maximuma négy, a 3640-é pedig12 interfész. A Cisco 3660 router már az alaplapon tartalmaz LAN interfészt, így ebben akár 24 hang interfészt is kaphatunk.

A hang/fax modul a Voice over IP-t és a Voice over Frame Relay-t is támogatja, alkalmazása csökkenti a menedzsment költségeket, minimumra szorítja késleltetést, kiemelkedően alacsony a hibaaránya és előnyösebb a legtöbb VoIP gyártó PC-alapú megoldásainál, akik nem tudnak versenyezni a Cisco alacsonyabb hívás késleltetésének. A Cisco hang/fax modulok H.323 kompatibilisek, együttműködnek a Microsoft NetMeeting-gel és a LAN alapú IP telefon megoldásokkal. Támogatják az ITU G.729 és G.711 szabványt, előbbi közel tökéletes minőséget nyújt 8 kbps tömörítéssel.

Használatához egy hang modulra (NM), a hang interfész kártyára (VIC) és 11.3T vagy későbbi Plus IOS™ szoftvercsomagra van szükség (a BRI hang interfész kártya minimum 12.0(3)T vagy későbbi IOS™ verziót igényel). Az egy kártyahelyes modulra egy VIC (két interfész), a két kártyahelyesre kettő installálható (négy interfész). Az ISDN BRI hang interfész négy hangcsatornát nyújt, ezért mind a négy használatához az NM-2V-re van szükség, az NM-1V-ben csak 2 hangcsatorna fog működni. Az NM-2V modulon analóg kártyával is kombinálhatjuk, de ekkor is csak 2 hangcsatorna fog működni (összesen 4).

Hang interfész kártyák (VIC)

A hang/fax modulok konvertálják a telefon hangjelzéseket az IP vagy Frame Relay feletti átvitelhez, saját interfészük nincs. A rajtuk használatos hang interfész kártyák biztosítják a direkt kapcsolatot a telefon berendezésekkel vagy a szolgáltatói hálózattal.

Az FXS (foreign exchange station) interfész (RJ-11) kapcsolódik közvetlenül telefonkészülékre, fax készülékre vagy hasonló berendezésre. Az interfész biztosítja a csöngető feszültséget, a tárcsahangot, stb. a készüléknek (31. Ábra).

31. Ábra FXS hang interfész kártya

Az FXO (foreign exchange office) interfész kapcsolja az érkező hívásokat telefonközponthoz. Ez az interfész ekvivalens azzal, amit egy szokásos telefonkészülék biztosít. Az FXO interfésznek külön európai változata van.

A két portos E&M hang/fax interfész támogatja az 2- és 4-eres interfészeket és tipikusan a telefonközpontok trönk interfészére kapcsolódik.

Az ISDN BRI hang interfész közvetlenül a telefonhálózatra vagy PBX-ekre kapcsolódhat, két portos ISDN, S/T, felhasználói oldali felülete van. Két fizikai interfészén (RJ-45) négy hangcsatornát támogat. Támogatja a Cisco IOS™-ben levő összes ISDN jelzésrendszert, a DID és Caller ID átadását.

Nagy-sűrűségű hang/fax modul a Cisco 2600/3600 családhoz

A nagy-sűrűségű hang/fax modul a Cisco 2600/3600 család legutóbbi újdonsága (32. Ábra). Ezek a digitális T1/E1 hang trönk modulok átjárást biztosítanak a telefonközpontok vagy a publikus telefonhálózat felé. Jellemzői a következők:

32. Ábra Nagy-sűrűségű hang/fax modul a Cisco 2600/3600 családhoz

q       együttműködik a Cisco multi-service hang és adattermékekkel (például Cisco 2600, 3600, 7200, 5300, Cisco IP telefonok)

q       A T1/E1 trönk hangmodul közös a Cisco moduláris access router-ei számára (2600, 3620, 3640, 3660), így skálázható megoldást biztosít a kis irodák, regionális központok és adatcentrumok számára. Moduláris felépítésének köszönhetően minimum 6, de akár 288[1] hangcsatornát biztosít egy berendezésben

q       támogatja a H.323 gateway és gatekeeper funkcionalitást illetve együttműködést, így megkönnyíti a nagy rendszerek adminisztrálást

q       a programoztató DSP-k támogatják az ITU szabványos tömörítési algoritmusait (G.711, G.723, G.726, G.728, G.729 and G.729a/b), ily módon testre-szabott megoldásokat ad a hangminőség és sávszélesség igényeink számára

q       Packet Voice Digital Signal Processor modulok telepítésével (PVDM-12=) az adott modul hangfeldolgozó kapacitása növelhető

q       egy vagy két-portos T1 interfésszel rendelkezik, amik telefonközpontra és/vagy a publikus telefonhálózatra kapcsolódhatnak. Az E1 interfész támogatása 1999 utolsó negyedére várható.

q       az egy vagy két-portos T1/E1 interfész a MultiFlex Voice/WAN interfész kártya (VWIC), amit közös más adat és hang modulokkal

q       az összes hangfeldolgozási feladatot elvégzi ez a hang trönk modul, így a Cisco 2600/3600 router teljesítménye változatlanul ki tudja szolgálni a routing, betárcsázás, tűzfal és VPN igényeket

q       Használatához 12.0(5)XK, 12.0(6)T vagy későbbi verziójú Plus IOS™ szoftvercsomagra van szükség

q       a jövőbeni szoftverfejlesztések során nemcsak a VoIP-et, hanem a VoFR-t és a VoATM-et is támogatni fogja, a jelzésrendszerek terén QSIG, E1 ISDN PRI, CCS és R2 támogatása is várható

AS5x00 Voice Gateway

AS5300

A Cisco AS5300 Voice Gateway (33. Ábra) három kártyahellyel rendelkezik. Az egyik kártyahelyet a négy-portos E1/PRI foglalja el és a másik kettő szabadon használható VoIP vagy modem kártyáknak. Mivel az új VoIP kártya már 60 beszélgetést támogat, a Cisco AS5300/Voice Gateway rendszer összesen 120 beszélgetésig skálázható.

33. Ábra Cisco AS5300 Voice Gateway

 

A VoIP kártya több DSP modult tartalmaz, a maximális kiépítés 5 DSP modul, ami 60 B csatorna feldolgozását teszi lehetővé. A VoIP kártya jellemzői:

q       MIPS 4700 100 MHz CPU

q       GT-64010 system controller támogató chip-készlet

q       szabványos 72 pin SIMM DRAM (4, 8, 16 MB)

q       egyedi Cisco Flash 80 pin SIMM memória

q       öt DSP modulhely

A VoIP kártyán levő DSP modulok végzik a hang tömörítését és csomagokra alakítását, számuk bővíthető. A VoIP kártyának saját szoftver komponense van, amit VCWare-nek hívunk, a DSP-k jellemzői:

q       6 DSP per kártya, 4 DSP a T1 konfigurációkhoz, 5 az E1 konfigurációkhoz

q       TI TMS320C542 DSP chip a 30 kapacitású kártyán, TMS320VC549 chip a 60 kapacitású kártyán

q       támogatott kódolások G.711, G.729, G.729a és G.723.1

q       128 Kwords (16 bit) DSP SRAM

A Voice Feature Card használatához minimum 11.3NA IOS™ verzióra van szükség, a 60-as kapacitásúhoz 12.0.2XH vagy későbbire.

AccessPath VS-3

A Cisco AS5300 Voice Gateway ideális a stack-elt konfigurációkhoz, amikor egy virtuális elérési pontot hozunk létre nagyméretű szolgáltatói alkalmazásokhoz. Ennek az egyik alkalmazása a díjnyertes AccessPath VS-3 (34. Ábra), ami egy előre konfigurált, és előre tesztelt VoIP stack, ami különálló router-t és switch-et is tartalmaz, valamint opcionális Cisco 3640 H.323 GateKeeper-t.

34.       Ábra AccessPath VS-3

Nagyobb kapacitású telepítések alternatívája a Cisco AS5800, ami szintén elérhető VoIP gateway konfigurációban. Az AS5800 teljes kiépítésben 1344 hang csatornát támogat, ami legnagyobb VoIP DSP koncentráció ami egy önálló VoIP gateway-ben rendelkezésre áll.

Digitális Hang Port Adapter a Cisco 7x00-es család részére

A Cisco nemrég jelentette be a digitális hang port adapter család első tagját a Cisco 7x00-es család részére, ami vállalati központok számára jól skálázható, nagy kapacitású hangátvitelt biztosít telefonközpontok vagy a publikus telefonhálózat felé. A kártya egy nagy kapacitású, szimpla szélességű port adapter, ami két univerzális T1/E1 interfészt tartalmaz és 30 nagy teljesítményű DSP-t, amik akár 120 hangcsatornát biztosítanak.

35. Ábra Digitális Hang Port Adapter a Cisco 7x00-es család részére

Az első fázisban csak a Cisco 7200-as támogatott és októbertől a Cisco 7100-ason és a 7500-ason. Az egy router-be telepíthető PA-VXC-2TE1 kártyák számát tekintve nincs korlátozás, a kártyán levő két interfész együtt konfigurálható T1-re vagy E1-re.

Hasonlóan a Cisco 2600/3600 NM-HDV moduljához a hang tömörítési kapacitás a kódolási típustól függ. A PA-VXC-2TE1 60 hangcsatorna kapacitással rendelkezik, ha alacsony bit sűrűségű kódolást használunk, mint például a G.723.1, kapacitása megduplázódik vagy négyszereződik ha kevésbé bonyolult kódolást használunk, mint például a G.711 vagy a G.726. Egyúttal a PA-VXC-2TE1 és a NM-HDV ugyanazokat a hang T1/E1 gateway képességeket nyújtják, de a PA-VXC-2TE1 port adapternek kétszer annyi DSP erőforrása van mint a Cisco 3600 moduljának. A PA-VXC-2TE1 kártya kapacitása a Cisco 7x00-es család robusztus WAN aggregációs képességeivel párosítva az ideális megoldás a központi telephelyek hang feldolgozására.

 

Minden DSP két hangcsatornát kezel a legbonyolultabb kódolásokkal (G.723 és G.729), négyet a közepes kódolásokkal (G.729a, G.728, G.726) és nyolcat az alacsony bonyolultságú kódolással (G.711).

Az év során a későbbiekben egy szoftver upgrade formájában realizálódik a második fázis, aminek a fő újdonságai az első fázishoz képest:

q       CCS és Q.SIG támogatása

q       modem jelek átvitele

q       Cisco 7500 platform támogatása

q       a Cisco 7200VXR MIX (multiservice interchange) buszának támogatása

Vegyük észre, hogy a PA-VXC-2TE1 a nem VXR 7200-asban is használható, azonban a kártyák közötti TDM kapcsolási lehetőség igénybevételéhez szükség lesz a VXR sasszé MIX képességeire. A MIX busz lehetővé teszi, hogy a DSP erőforrásokat felosszuk a PA-VXC-2TE1 kártyák között, ez az oka annak is, hogy a kártyán két T1/E1 port-hoz 120 csatorna van, mert a második fázis megvalósításától lehetővé válik a hangcsatornák más interfészekről való átvétele a VXR hátlapon.

A PA-VXC-2TE1 a Cisco IOS™ 12.0XE vagy 12.0T verziójával működik.

Menedzsment

Cisco Voice manager

A Cisco Voice Manager egy web-alapú menedzsment alkalmazása, ami könnyen alkalmazható de hatékony megoldás a VoIP hálózatok konfigurálásra, figyelemmel tartására és diagnosztikájára.

A CVM segítségével a rendszergazdák telepíthetnek, üzemeltethetnek VoIP hálózatokat az összes költségek csökkentésével, a hívásminőség felügyeletével és hívásadatok kimutatásaival. A skálázhatóság érdekében beépített web szervere és SQL adatbázisa van, teljesen Java alapú. A CVM automatikusan felismeri a hangot is támogató termékeket és számos segédeszközt nyújt a hálózati problémák megoldására, és értékes híváskimutatásokat nyújt.

A CVM a VoIP berendezésekkel az IP hálózaton keresztül kommunikál, a CVM szerver és a kliens között a http protokollt használja, a CVM szerver és a berendezések SNMP protokollal és telnet-tel kommunikálnak.

Hang konfigurációs menedzsment

A CVM egy erőteljes és könnyen alkalmazható valóidejű hang konfigurációs eszköz. A web felületen keresztül az adminisztrátor automatikusan felderítheti a VoIP berendezéseket, lekérdezheti az aktuális konfigurációt, és módosíthatja a beállításokat. A CVM a konfiguráció során útmutatóval szolgál a hang interfészek, paramétereik és a dial plan beállításaihoz. A CVM felhasználó által definiált konfigurációs mintákat és a megismétlendő konfigurációkhoz batch üzemmódot is tartalmaz.

A CVM a következő tevékenységeket biztosítja a VoIP interfészek konfigurációjához:

q       digitális és analóg interfészek egyenkénti vagy batch konfigurációja

q       helyi (POTS) és globális (VoIP) dial plan egyenkénti vagy batch konfigurációja

q       number expansion konfigurációja

q       híváskövetés konfigurációja a hívások lekérdezéséhez

Felügyeleti és diagnosztikai szolgáltatások

A CVM valósidejű adatokat és statisztikákat ad a VoIP hálózat felügyeletéhez és hibakereséséhez.

q       ISDN csatornák kihasználtsága

q       Dial plan ellenőrzése teszteléssel az integritás és az end-to-end elérhetőség ellenőrzésére

q       SNMP Trap Monitor megjeleníti azokat az SNMP trap-eket, amik a hangminőségi problémákat jeleznek

q       információkat ad a DSP-k állapotáról, riasztásaikról, statisztikáikról

q       router segédprogramok segítségével lementhetők és módosíthatók a konfigurációk

Kimutatások

A hanghálózatok alapvető felügyeleti igénye, hogy tudjuk, ki hívott kit, mennyi ideig beszéltek, megszakadt-e a beszélgetés, és ha igen, miért? Szintén kritikus, hogy ismerjük milyenek a minőségi jellemzők és sérültek-e a QoS paraméterek.

36. Ábra CVM kimutatások

A CVM kiterjedt kimutatás-készítő alrendszert tartalmaz, ami segíti teljesítmény és statisztikai diagnosztikát. Ezek végponttól-végpontig terjedő hívásrekordok, amik időponttal ellátva részletes adatokkal szolgálnak a forrásról, a célról, az időtartamról és hasonló paraméterekről. A kimutatások táblázatos és grafikus formában is megjeleníthetők, és könnyen exportálhatóak (36. Ábra).

q       a Call History részletes hívásrekordot tartalmaz a megadott intervallumban végponttól-végpontig terjedő hívásokról

q       a Quality of Voice Exception megadja azokat a hívásokat, ahol alacsony volt a minőség

q       az Active Calls kimutatás, az éppen folyamatban levő hívásokat mutatja meg

q       a Call Volume kimutatás a teljes hívás-időtartamokat és sikeres, sikertelen, elutasított hívások számát adja meg

Biztonság

A web-alapú alkalmazásoknál kulcsfontosságú a biztonság, a CVM ezt kétszintű felhasználói hozzáféréssel biztosítja.

q       szabályozható kik léphetnek be Cisco Voice Manager szerverre

q       eszköz alapú szabályozással állítható, ki fér hozzá olvasási, vagy olvasási/módosítási jogokkal megadott eszközökhöz

A Cisco Voice Manager kétszintű beállításai a hang biztonsága érdekében:

q       Adminisztrátorok állíthatják mely router-eket felügyeljük, azokra mely felhasználók léphetnek be

q       Felhasználók felügyelik a VoIP hálózatot és használják a kimutatásokat

A Cisco Voice Manager Windows NT-n és Sun Solaris-on fut, egy ingyenes evaluation változat is elérhető, ami csak az eszközök számára vonatkozóan tartalmaz korlátozásokat.

Cisco CallManager

A Cisco CallManager szoftver a Cisco Kommunikációs Rendszer szervere. Ez egy kliens/szerver applikáció mely kontrollálja a hívás feldolgozást, a routing-ot, több telefon szolgáltatást, az eszközök konfigurációját, és a rendszer beállításokat. Minden eszköz, mely része a Cisco rendszernek a CallManager szoftverből konfigurálható és kontrollálható.

A CallManager szoftver egy dedikált Windows NT szerver PC-re installálandó (A Cisco ajánlja a dedikált PC-t, de nem követelmény). A rendszer konfigurációs adatbázis ugyan azon, vagy egy elkülönített szerveren tárolódik. Az adatbázis egy Web-alapú interfészen keresztül módosítható (37. Ábra). Az interfész, melynek neve CallManager Administration, Web-alapú, így az adatbázis módosítása, rendszer működési problémák diagnosztizálása bármilyen Web browser segítségével lehetséges bárhonnan a világon. A szerver bárhol lehet az IP hálózatban, lokálisan vagy távol.


37. Ábra Cisco CallManager

 

A CallManager biztosítja a telefon szolgáltatásait, mint például hívás tartás, hívás továbbkapcsolás, hívás átirányítás, hívás várakoztatás, hívófél azonosítás, stb. A CallManager egy SMDI interfésze biztosítja a kapcsolatot a különböző voice mail és IVR rendszerekkel, és a CallManager szolgáltatja a hívás adat rekordokat a könyvelési és számlázási rendszer részére. A CallManager menedzseli a hívás régiókat, hogy biztosítsa az adott hálózati sávszélesség és teljesítmény függvényében a maximális hang minőséget. Ha a hívás egy szűk hálózati keresztmetszeten megy át a CallManager értesíti a Cisco IP telefont, hogy használjon nagyobb kompressziót, mint a G.723. Azon hívások esetén, melyek a PSTN irányába mennek, a CallManager értesíti a telefonokat, hogy használjanak G.711-es tömörítést, mely a PSTN hívásokhoz szükséges. A rendszer használhat több CallManager-t is, például redundancia céljából.

A CallManager szolgáltatásai

Automatikus sávszélesség választás (régiók)

Az automatikus sávszélesség választás szolgáltatás lehetővé teszi, hogy korlátozzuk a sávszélesség felhasználást egyes eszközök között, a régiók alapján. Például beállítható két régió: Kék és Piros régió. Bármely hívás a két régió között tömörített (kb. 6 Kbps-re). De azon hívások, amelyek régión belül maradnak, azaz egy Cisco IP telefon a kék régióból hív egy másik Cisco IP telefont a kék régióban, nem kompresszált hívásként épülnek fel (sávszélesség igény 64 Kbps).

Automatikus telefon installálás

A rendszer ezen képessége lehetővé teszi, hogy  egy új telefon installálása és alap konfigurálása, csak addig tart, amíg a telefont egy RJ45-ös csatlakozóval csatlakoztatjuk az IP hálózathoz és adapterét csatlakoztatjuk a 220 V-os hálózathoz. Minden szükséges információt a CallManager feljegyez és a regisztrációt automatikusan elvégzi.

Automatikus költözés

Ez a szolgáltatás lehetővé teszi, hogy a telefont egyik helyről a másikra (hálózaton belül) áthelyezzük programozás nélkül. Minden beállítás és szolgáltatás a telefonnal együtt vándorol. A szolgáltatás abból adódik, hogy minden telfon gyakorlatilag egy IP terminál és az IP cím információk a telefon nem felejtő memóriájában tárolódnak.

Azaz ha a telefon egy másik subnetre kerül a DHCP és router révén eléri a CallManager-t. Azokon a helyeken, ahol nincs DHCP szerver a CallManager IP címét manuálisan kell beírni a telefonba.

Hívás adat record (CDR)

A hívás adat recordok a Cisco hálózat kimenő és bejövő forgalmának részletes történetét mutatják. Például minden hívás kezdeti időpontját, időtartamát hívó és hivott oldali telefonszámát. A CDR információk vesszővel elválasztott formátumuak, így minden olyan alkalmazásba importálhatók, amelyek ismerik a CSV file formátumot. Például, Microsoft Access és Microsoft Excel.

DHCP service a Cisco IP telefonok esetén

A Cisco IP telefonok támogatják a Dynamic Host Configuration Protocol (DHCP) szolgáltatást. Amikor a telefon inicializálódik kap egy IP címet a DHCP szervertől. A DHCP nagymértékben egyszerüsítheti a Cisco hálózatot, mivel automatikusan meghatározza a telefon IP címét, és automatikusan felismeri, ha a telefon egyik helyről a másikra költözött.

Tárcsázási terv

A Cisco CallManager rugalmas tárcsázási tervvel rendelkezik a külső, belső, kimenő és bejövő hívások irányítására. Például az “123”-al kezdődő számokat az egyik Gateway irányába irányitja, a ”987”-el kezdődőeket pedig a másik irányába. Azaz lehetőség van arra, hogy a hívásokat a tárcsázott számok típusa (mellék-, helyi-, táv-, nemzetközihívás) alapján irányítsa.

Hívás blokkolás

Meghatározott számok, vagy azok csoportjának hívása tiltható. Ha tiltott számot hív egy mellék a Cisco hálózaton, a hívás nem épül fel.

Szolgáltatói hozzáférési kódok

A számozási terv oly módon is konfígurálható, hogy a hívások irányítása, távhívások esetén, a távhívó szolgáltató hozzáférési kódja (10XXX) alapján történik. Például hívva a 10222 számot a nyilvános hálózatban a hívás egy adott távhívó szolgáltatóhoz irányítodik, míg a 10333-at hívva egy másik távhívó szolgáltatóhoz irányítódik hívásunk. Ezen hozzáférési kódok segítségével, hívásaink közvetlenül a megfelelő trönkre irányítódnak minden szolgáltatónál.

Trönk hozzáférési kódok

A Cisco rendszer számozási terve képes trönk hozzáférési kódokat is kezelni. A hívások a hívott számot megelőző trönk hozzáférési kód alapján a megfelelő irányba irányíthatóak. Például a külső híváshoz 9-est kell tárcsázni. A trönk hozzáférési kódok használata opcionális, a CallManager beszúrhatja, vagy levághatja a kódot a hivott szám elé illetve elöl, mielőtt kapcsolodik a nyilvános telefonhálózatra, vagy alközpontra.

Egyedi számozási terv

A Cisco számozási terve konfigurálható mint egyedi számozási terv, vagy idomulhat a meglévő vállalati számozási tervhez (például idomulhat egy egységes vállalati alközponti számozási tervhez). Egyedileg meghatározható, hogyan épül fel a számozási terv. A hívások bármilyen szám alapján irányíthatóak, amelyek 1-23 digit hosszúságúak. A leginkább elfogadott és megszokott a 4 számjegyes számozás.

Közvetlen beválasztás (Direct Inward Dialing /DID/)

Direct Inward Dialing lehetővé teszi a felhasználóknak, hogy közvetlenül fogadjanak hívásokat a nyilvános hálózatból kezelő közbeavatkozása nélkül. A CallManager képes módosítani a beérkező számokat hozzáadva vagy levágva egyes digiteket, ezáltal biztosítva az idomulást a saját számozási tervhez. DID használatához szükség van DID-alkalmas gateway-re, mint például a Cisco Access digital ISDN gateway-ek.

Esemény naplózás

A CallManager eseményei a Windows NT event log-ban kerül rögzítésre. A rögzített események a Windows NT Event Viewer-ével tekinthetők meg. Az üzenetek tartalmazzák az esemény időpontját, forrását, kódját és leírását.

Esemény Megtekintő

A Windows NT Event Viewer-el megtekinthetők a biztonsági és az aplikációkkal kapcsolatos események a Windows NT Szerveren. Az Event Viewer segítségével megtekinthetők a Cisco rendszer eseményei, mint pl. phone service on/off, major task on/off, trunk interface on/off.

Külső voice messaging (VM)/automated attendant (AA)/interactive voice response (IVR) rendszerek támogatása SMDI interfészen

Lehetőség van külső rendszerek csatlakoztatására, melyek a következő lehetőségeket adhatják a rendszerhez:

· Voice messaging (a message waiting jelzés látható a Cisco IP telefonokon)

· Automated attendant szolgáltatás a beérkező hivások megfelelő mellékhez történő irányítására.

· IVR (interactive voice response) lehetőségek, melyek révén például biztosítható unified messaging interface a Microsoft Exchange Server számára.

IP precedence bit támogatás a telefonok és gateway-ek számára

Minden hang csomag, mely a Cisco Analog Gateway-ektől vagytelefonoktól származik egy type of service bit beállítással, mely biztosítja a Cisco Routerekben a priority queuing-ot. Ez a szolgáltatás növeli a hangminőséget a kiterjedt hálózatokban.

IP irányítás

A telefonok a nem felejtő memóriában tárolják az IP address információkat (IP address, subnet mask, router gateway IP address, DNS server address, és a TFTP server address). A jelzés és hang csomagok is az IP hálózaton kerülnek továbbításra. Az IP address információk tápáram kimaradás esetén is megmaradnak. A routolható protokollok lehetővé teszik, hogy a telefonokat és CallManager(ek) szétszórtan helyetkedjenek el egy kiterjedt hálózatban.

Licenc menedzsment

A Licenc menedzsment mindenkor kijelzi a regisztrált eszközök számát, valamint a felhasználó licecének kihasználtságát. A licenc számításánál figyelembe vett eszközök: Cisco Access Digital és Analog Gateway Trunk portok, Cisco Access Analog Station Gateway portok, conference bridg-ek, Cisco IP telefonok, és a Cisco VirtualPhones™-ok.

Szám hordozhatóság

Ez a szolgáltatás lehetővé teszi, hogy telefonját bárhol csatlakoztatva a Cisco rendszerhez, megtartsa telefonszámát.

Például, ha telefonját kihuzza New York-ban, elküldi Bangladesh-be és csatlakoztatja az IP hálózatra, melyről elérhető a CallManager, akkor  a telefon letölti a configurációját és ugyan az a mellék lesz mintha New York-ban ülne.

Teljesítmény Monitor

A Teljesítmény Monitor (Performance Monitor) a Windows NT Server applikációja, mely lehetővé teszi a rendszer számos változójának valósidejű monitorozását. Például megtekinthető az adott pillanatban folyamatban levő hívások összes száma, vagy csak egy adott gateway-en átmenő hívások száma. A Performance Monitor láthatóvá teszi az általános és a Cisco specifikus real time státusz információkat.

PRI protocol support

A Cisco számos ISDN protokolt támogat, ezek felsorolása alább látható. A PRI paraméterek és időzítések konfigurálhatók, amennyiben szükséges a szolgáltató vagy a telafon alközpont interfészéhez való csatlakozás során.

·         NI2

·         4ESS

·         5E8, 5E8 Teleos, 5E8 Custom

·         5E9

·         DMS-100

·         DMS-250

Redundancia

Második CallManager is installálható a hálózatba azzal a céllal, hogy biztosítsa a hívás feldolgozó szerver redundanciáját. Abban az esetben ha a CallManager szerver meghibásodik, minden hozzá tartozó telefon és Gateway automatikusan átáll a redundáns CallManager-re administrátor közbeavatkozása nélkül.

Távfelügyelet

Megfelelő jogosultsággal rendelkező adminisztrátorok Web browser segítségével tudják monitorozni a Cisco CallManager állapotát.

Web (HTML) adminisztrálás

Web-alapú adminisztrálása révén a CallManager és telefonjai bárhonnét a világon adminisztrálhatóak. Ez szükségtelenné teszi egy dedikált adminisztrátor konzol kialakítását.

Web-alapú gyorstárcsázó telefonkönyv

Ez a szolgáltatás lehetővé teszi a keresést egy Web-alapú listában, mely tulajdon képpen az adott vállalat telefonkönyve. A felhasználó a kiválasztott telefonkönyvre klikkelve egyből kezdeményezheti is a hívást. A CallManager a felhasználó telefonjának csengetésével válaszol, majd hívja a kiválasztott számot. Ez a telefonkönyv automatikusan generálódik a CallManager adataiból (38. Ábra).

 


38. Ábra Cisco CallManager telefonkönyv

 

Web dokumentálás


A Cisco Communications System dokumentációja Web-alapú, a CallManager szerveren található.

 

39. Ábra Selsius dokumentációs rendszer

Matáv rendszertechnika

Ebben a fejezetben mintakonfigurációkat mutatunk be a SOHO illetve a közepes és nagyméretű irodák számára.

Ezek célja a leggyakoribb igények és megoldások bemutatása. Minden példa esetén ismertetjük a működését illetve a szükséges eszközök konfigurációját. A mintamegoldások ismertetésén keresztül megismerhetők az ajánlott eszközök, kialakítható egy eszközpark amely alkalmas tetszőleges demonstrációs rendszer összeállítására.

A megoldások többsége a telefonköltségek csökkentését célozza a vállalaton belüli hívások hálózaton belül tartásával. Természetesen az adott eszközkészlet lehetőséget nyújt egyedi megoldások kialakítására, rugalmas, a helyi igényekre alapozott szolgáltatások kifejlesztésére.

Az utolsó példa egy vállalati-szolgáltatói közös hálózat megoldást mutat be, ahol a szolgáltató az IP hálózati szolgáltatásba építi be telefon elérést.

SOHO megoldások

A következőkben a legkisebb – tipikusan otthoni környezetben kialakított – irodák számára alkalmas megoldásokat mutatunk be. Ezen irodák jellemzője, hogy csak néhány felhasználó dolgozik a hálózaton.

Feltételezzük egy – a SOHO szempontjából - központi telephely meglétét. Itt helyezkednek el a VoIP rendszer azon elemei melyekre kis felhasználószám esetén nincs szükség illetve nem gazdaságos a telepítése.

A valós idejű fax átvitel nagyon érzékeny a késleltetésre ezért megoldások telephelyek közötti összeköttetésként QoS lehetőségekkel bíró IP hálózatot tételeznek fel. Ez megvalósítható bérelt vonal, frame-relay illetve  ISDN felett, vagy akár IP VPN szolgáltatás segítségével.

A SOHO megoldásoknál közös hogy a konfiguráció külső kapcsolatai a következők:

-          összeköttetés a központi telephely felé

-          ISDN vagy analóg telefonvonal a szolgáltató felé

A felhasználói igények becslésekor feltételeztünk munkahelyenként egy telefont és irodánként 1-2 fax készüléket.

A példákban a helyi router szerepét egy Cisco 2600 látja el a megfelelő kiépítésben.

SOHO 1-2 munkahely

Ez a példa egy olyan irodát mutat ahol nincsen szükség több kettőnél több helyi telefonra.

A konfiguráció központi eleme egy router. Alapesetben 1 LAN (Ethernet) egy szinkron soros vagy ISDN BRI és 4 hang csatolóval rendelkezik (2xFXS és 2xFXO vagy BRI).

A router fogadja a központ fele induló vonalat, és az iroda telefonvonalát is. Ez utóbbi lehet ISDN vagy analóg is. Az alapkonfiguráció 1 db ISDN BRI vagy 2 db hagyományos telefonvonal fogadására alkalmas.

A helyi telefonok a router FXS csatolóira csatlakoznak. Tipikusan egy telefon és egy kombinált telefon/fax üzemel. A két készülék illetve a külvilág közötti a telefonfogamat a router irányítja. Az analóg telefonok DTMF jelei alapján lehetséges a hívás továbbítása a központ felé IP felett vagy a publikus telefonhálózatra.

A LAN-ra csatlakoztatott számítógépeknek nem kell részt venni a telefon kommunikációban. Amennyiben valamely H.323 kompatibilis alkalmazást használunk (pl. NetMeeting) lehetőség van további “mellékállomások” bekapcsolására a hálózatba. A H.323 Gateway funkciót a router látja el. Amennyiben a rendszerben H.323 Gatekeeper funkcióra is szükség van, akkor azt a központban elhelyezett Call Manager illetve egy dedikált biztosítja.


40. Ábra SOHO 1 rendszertechnika

 

A konfiguráció elemei:

 

1 db CISCO2610

1 db WIC-1T vagy WIC-1B-S/T

1 db NM-2V

1 db VIC-2BRI-S/T-TE vagy VIC-2FXO-EU

1 db VIC-2FXS

1 db SF26CP-11.3.9T Cisco 2600 Series IOS  IP PLUS

SOHO 3-20 munkahely, alközpont

A második példa egy olyan kis irodát mutat (41. Ábra) ahol a szükséges telefonok száma már nagyobb mint amennyi egy routerre ésszerűen közvetlenül csatlakoztatható.

A telefon fővonal vagy fővonalak illetve a helyi telefonkészülékek egy kis alközpontra csatlakoznak. Az alközpont lehet analóg vagy ISDN rendszerű is, ennek megfelelő csatolóval csatlakozik a routerre.

A hívások irányítása az alközpont feladata, a routerbe csak a központ fele irányuló IP felett továbbítandó hívások jutnak el.

H.323 alkalmazások esetén a Gateway illetve Gatekeeper funkciók az első példával megegyezően alakulnak.

 


41. Ábra SOHO 2. rendszertechnika

 

A konfiguráció elemei:

 

1 db CISCO2610

1 db WIC-1T vagy WIC-1B-S/T

1 db NM 1V vagy NM-2V

1 vagy 2 db VIC-2BRI-S/T-TE vagy VIC-2FXO-EU vagy VIC-2FXS

1 db SF26CP-11.3.9T Cisco 2600 Series IOS  IP PLUS

SOHO 3-20 munkahely, IP telefonok

A harmadik példában a felhasználók telefonjai nem hagyományos készülékek, hanem IP telefonok melyek a helyi hálózatra csatlakoznak. Ennek megfelelően nincsen szükség alközpontra. A publikus hálózat fele a router biztosít csatlakozást. Az irodai telefaxok szintén a router FXS portjaira csatlakoznak.

Az IP telefonok vezérlésére alkalmas lehet a központban elhelyezett Call Manager, de ez

esetben az összeköttetés megszakadása esetén a külvilággal megszakad a telefonkapcsolat. Ezért javasolt egy helyi Call Manager telepítése is.


42. Ábra SOHO 3. Rendszertechnika

 

A konfiguráció elemei:

 

1 db CISCO2610

1 db WIC-1T vagy WIC-1B-S/T

1 db NM-2V

1 db VIC-2BRI-S/T-TE vagy VIC-2FXO-EU

1 db VIC-2FXS

1 db SF26CP-11.3.9T Cisco 2600 Series IOS  IP PLUS

1 vagy 2 db Cisco Call Manager

3-20 db Cisco 12SP+ IP Phone

Közepes és nagyvállalati megoldások

Ebben az alfejezetben olyan megoldásokat részletezünk, melyek a több telephellyel rendelkező vállalatok számára nyújtanak lehetőséget a VoIP technológia felhasználására. A mintakonfigurációk feltételezik több, hasonló felépítésű hálózat meglétét. Az összeköttetés ez esetben is QoS támogatott IP hálózat. Egy ilyen telephely funkcionálhat központként a korábban említett SOHO hálózatok számára.

A bemutatott megoldások csupán példák. Ilyen méretű rendszerben már annyi változat lehetséges, hogy azokat konkrét konfigurációkkal nehéz lefedni. A minták mutatják a különböző igényekre alkalmas eszközök típusait, így lehetőség van egy univerzális eszközkészlet összeállítására.

A hasonló méretű vállalatoknál szokásos igény a távoli felhasználók kapcsolt vonali behívási lehetőségének biztosítása. A választott routerek lehetőséget adnak ennek megvalósítására is közös készülékben.

A javasolt router a szükséges csatolók számától és típusától függően Cisco 3640 vagy AS5300 típusú lehet.

A két példa két szélső esetet mutat be, a gyakorlati megoldások valahol a kettő között elképzelhetők.

Közepes vállalat, 150 munkahely, ISDN alközpont, távoli behívás

A példa kiinduló alapja egy szokásos vállalati hálózat. A rendszerben található egy router amely a többi telephellyel való kapcsolatot biztosítja. A telefonok és faxok egy alközpontra csatlakoznak és ez fogadja a külső telefonvonalakat is.

A VoIP alkalmazás első lépése a router kicserélése megfelelő típusúra (esetleg a meglevő megtartásával) és annak összekötése az alközponttal. A csatoló típusa jellemzően ISDN PRI.

A hívásirányítást az alközpont végzi, a router a VoIP gateway szerepét tölti be.

Amennyiben H.323 Gatekeeper funkció is szükséges az alkalmazások miatt, ez vagy egy dedikált router (pl. Cisco 3620) vagy egy Call Manager alkalmazásával oldható meg.

A router összeköttetését a helyi hálózattal egy fast-ethernet csatoló biztosítja. A távoli telephelyek bérelt vonalait egy E1 interface fogadja. Az alközpont felé egy E1 csatoló kapcsolódik. A modemes távoli felhasználók a routerben elhelyezkedő digitális modemek segítségével jelentkezhetnek be a hálózatba.

 


43. Ábra Közepes méretű vállalat rendszertechnikája

 

A router konfiguráció:

 

1 db CISCO3640

1 db NM-1FE1CE1B

1 db NM-12DM

1 db NM-HDV(=)

2 db PVDM-12=

1 db VWIC-1MFT-E1

1 db S364CP-12.0.4T Cisco 3620 Series IOS IP PLUS

 

Az opcionális H.323 Gatekeeper:

1 db CISCO3620

1 db NM-1E

1 db S362CU-12.0.4T            Cisco 3620 Series IOS IP/H323

Nagyvállalat, 300 munkahely, távoli behívás, alközpont nélkül

E példa egy nagyvállalati környezetet mutat be (44. Ábra). A telefonos kommunikáció kizárólag IP telefonokon keresztül zajlik. A fax forgalom jelentős része is papírmentes módon történik az AS5300 store-and-forward fax szolgáltatásának felhasználásával. Az AS5300 fogadja az ISDN PRI bejövő vonalakat. Lekezeli a VoIP konverziót valamint a modemes és ISDN távoli bejelentkezéseket. Egy második router, egy 3640 E1 csatolókon keresztül kapcsolódik a távoli  telephelyeket bekötő bérelt vonalakhoz. Ezen az eszközön elhelyezhetők analóg csatlakozók a hagyományos faxkészülékek bekötéséhez.

A H.323 Gatekeeper funkciókat és az IP telefonok vezérlését egy Call Manager látja el.


44. Ábra Nagyvállalati rendszertechnika

 

A konfiguráció:

 

1 db CISCO3640

1 db NM-1FE2CE1B

2 db NM-2V

4 db VIC-2FXS

1 db S364CP-12.0.4T Cisco 3620 Series IOS IP PLUS

 

1 db AS5300

1 db AS53-E1-60VOXD60DM

1 db S53CP-12.0.4T   Cisco AS5300 Series IOS  IP PLUS

 

1 db Cisco Call Manager

250 db Cisco 12SP+ IP Phone

50 db Cisco 30VIP IP Phone

Javasolt demoeszköz készlet

Mennyiség

Kód

Megnevezés

3

CISCO3640

Cisco 3600 4-slot Modular Router-AC with IP Software

3

MEM3600-8U32FS

8-to-32MB Flash Factory Upgrade for the Cisco 3600

3

MEM3640-32U48D

32-to-48 MB DRAM Factory Upgrade for the Cisco 3640

3

S364CP-12.0.4T

Cisco 3620 Series IOS IP PLUS

 

 

 

3

NM-1FE2CE1U

1 Port F.Ether. 2Port Channelized E1/ISDN-PRI Unbalanced NM

2

NM-12DM

12 Port Digital Modem Network Module

 

 

 

2

NM-HDV(=)

High Density Voice Network Module.

Acts as the base carrier card fo r the PVDMs and the VWIC card

5

PVDM-12=

12-Channel Packet Voice/Fax DSP Module

1

VWIC-1MFT-E1

1-port RJ-48 Multiflex Trunk - E1

1

VWIC-2MFT-E1

2-port RJ-48 Multiflex Trunk - E1

 

 

 

8

NM-2V

Two voice/fax interface card slot network module

2

VIC-2E/M

Two-port Voice Interface Card - E&M

4

VIC-2FXO-EU

FXO Voice Interface Card

4

VIC-2FXS

Two-port Voice Interface Card - FXS

4

VIC-2BRI-S/T-TE

Voice Interface Card with two ISDN BRI S/T interfaces (Terminal Equipment)

 

 

 

4

CISCO2610

Cisco 2600 Ethernet modular router with Cisco IOS™ IP software

4

MEM2600-24U32D

24 to 32MB DRAM Factory Upgrade for the Cisco 2600 Series

4

MEM2600-8U16FS

8 to 16 MB Flash Factory Upgrade for the Cisco 2600 Series

4

S26CP-12.0.4T

Cisco 2600 Series IOS IP PLUS

 

 

 

4

WIC-1T

1-Port Serial WAN Interface Card

4

WIC-1B-S/T

1-Port ISDN-BRI WAN Interface Card

 

 

 

2

AS5300

AS5300 Dial Shelf

2

AS53-AC-PWR

AC Power Chassis for the AS5300

1

AS53-E1-60VOXD60DM

60 Voice sessions, and 60 MICA modems, and Quad E1 card

1

AS5300-120VOIP-A

AS5300 VoIP Gateway-120 voice channels, 4E1, all coders

2

S53CP-12.0.4T

Cisco AS5300 Series IOS  IP PLUS

 

 

 

1

CISCO3620

Cisco 3600 2-slot Modular Router-AC with IP Software

1

NM-1E

1-Port Ethernet Network Module

1

MEM3620-32U48D

32-to-48 MB DRAM Factory Upgrade for the Cisco 3620

1

S362CU-12.0.4T

Cisco 3620 Series IOS IP/H323

 

 

 

4

990-0801-020

Cisco Demo Pkg, 5-12SP+, 5-30VIP, AT-4

 

 


[1] T1 interfész, Cisco 3660