Informatika | Hálózatok » Szabó Károly - Integrált hang-adat szolgáltatás megvalósítása IP-VPN hálózaton

Gábor Dénes Főiskola Integrált hang-adat szolgáltatás megvalósítása IP-VPN hálózaton 676/2003 SZABÓ KÁROLY PÉTER BUDAPEST 2003 Tartalomjegyzék 1. Előszó 3 2. Bevezetés 3 2.1 A hálózatokról általában 3 2.11 A hálózatok kiterjedése szerint lehetnek: 3 2.12 A hálózatok hozzáférhetőségük szerint lehetnek: 4 2.2 A nagykiterjedésű magánhálózatokról 5 2.21 Klasszikus magánhálózatok: 5 2.22 Virtuális magánhálózatok: 5 2.3 A protokollokról 7 2.31 A hét rétegű hálózati modell: 7 2.32 A TCP/IP protokollcsalád: 9 2.33 Rangsorolt adatforgalom megvalósítása Quality of Service (QoS) segítségével 14 2.34 A H323 szabvány 21 3. A jelenlegi hálózat és az ügyfél igényének bemutatása 35 2.2 Az ügyfél jelenlegi hálózata 36 4. Az ügyfél hálózatának megtervezése 37 5. Fejlesztési javaslatok 39 6. Összefoglalás 39 7. Irodalomjegyzék 39 8. Mellékletek 39 2 1. Előszó A gazdaság szereplőinek

kritikus hatékonysági tényezője kommunikációs hálózatuk rugalmas, biztonságos, egyszerű és átlátható működtetése, illetve a költségek kordában tartása. Egyre fontosabb tényező ez a több telephelyes vállalkozások esetében, különösen akkor, ha ezek a telephelyek adott esetben, eltérő informatikai struktúrával rendelkeznek. Két lehetőség kínálkozik a különböző telephelyek közötti kommunikációs csatornák használatára. Az egyik – az esetek többségében a drágább – megoldás, a telephelyek közvetlen összekötése menedzselt bérelt vonali (MLLN) kapcsolatok kiépítésén keresztül A másik, ma már általánosan elterjedt és a költségek szempontjából is kedvezőbb megoldás valamely távközlési, vagy Internet szolgáltatótól virtuális magánhálózati szolgáltatás (Virtual Private Network, VPN) igénybe vétele. Dolgozatom célja minél sokrétűbben ismertetni az IP alapú VPN hálózatokat, az Integrált Hang-adat

(IVD) szolgáltatás alapjait, a protokollokat, a hangátvitel műszaki megoldásait mind elméleti, mind a gyakorlati síkon. A gyakorlati megvalósítást egy kereskedelmi cég jelenlegi MLLN hálózatának áttervezésével fogom bemutatni A folyamat végére az ügyfél egy tökéletesen működő, megbízható és költséghatékony IP-VPN IVD hálózattal fog rendelkezni A kereskedelmi cég és a hálózat felépítése egyaránt valós, ezért néhány konkrétumot (ami csak erre a hálózatra jellemző) nem, vagy módosítva fogom bemutatni – az üzleti titoktartásra való tekintettel. 2. Bevezetés 2.1 A hálózatokról általában A hálózatokat többféleképpen lehet besorolni, például kiterjedésük vagy hozzáférhetőségük szerint. 2.11 A hálózatok kiterjedés szerinti csoportosítása  LAN – Local Area Network (helyi hálózat): Az átívelt távolság tipikusan 10-1000 m, az adatátvitel sebessége 10-1000 Mbit/sec. Egy LAN többnyire teljes

terjedelmé- 3 ben egyetlen tulajdonos fennhatósága alá tartozik, tipikusan homogén adatátviteli technológiát alkalmaz. Teljes értékű hálózati operációs rendszerrel, és általában széles körű védelmi rendszerrel rendelkezik A PC-hálózatok legjellemzőbb típusa  MAN – Metropolitan Area Network (városi hálózat): Tipikus kiterjedése az 1-100 km tartományba esik, sokszor egyetlen városra korlátozódik, azon belül néhány intézményt kapcsol össze. A kapcsolatkiépítés a LAN-ok között többnyire a városi távközlési hálózatra épül, hagyományos telefonvonalon, optikai kábelen, mikrohullámú adókon át. Az összekapcsolt számítógépek gyakran eltérő adatátviteli technológiát alkalmaznak Tipikus adatátviteli sebességnek a 1-155 Mbit/sec tekinthető Egyre inkább eltűnő kategória, határai összemosódnak a manapság nagyobb távolságokat áthidalni képes LAN-nal. WAN – Wide Area Network (nagy kiterjedésű hálózat):

Országokon belül, illetve  országokat (kontinenseket) összekötő hálózat. Tipikusan több tulajdonos (szolgáltató) felügyelete alá tartozik, gyakran nagymértékben különböző, teljesen eltérő adatátviteli technológiák együttműködését igényli Jellemző adatátviteli sebessége, elsősorban a kontinensek közötti nagykapacitású gerincvezetékek esetében a 2,6 Gigabit/sec 2.12 A hálózatok hozzáférhetőség szerinti csoportosítása  Nyilvános hálózatok (például az Internet): Helyi, regionális és országos számítógépes hálózatok laza hálózata, amely az IP protokollt használja a kommunikációra. Az ARPANet-ből kifejlődött Internet ma már a világ legnagyobb WAN rendszere, mely több tízezer kisebb hálózatot köt össze, sok millió felhasználóval. A kapcsolódást az Internetre ISP-k (Internet Service Provider – Internet Szolgáltató) teszik lehetővé. A legnépszerűbb alkalmazás a WWW, sokan csak és kizárólag ezt

is értik alatta Bár ezen a világhálón más, ugyancsak sokat használt alkalmazások is elérhetők Például a FTP (File Transfer Protocol) az adatállományok cseréjére, Email az elektronikus levelezésre, IRC (Internet Relay Chat) az online „beszélgetésre”, stb 4  Magánhálózatok (vállalati LAN – WAN hálózat): A nyilvános hálózattól védetten megvalósított, általában a cégek telephelyein üzemelő számítógépek összeköttetését megvalósító hálózat. Ez lehet egy kis kiterjedésű LAN hálózat, illetve egy ehhez illesztett, távoli telephelyeken üzemelő LAN hálózat is. A magánhálózatok szegmenseinek kialakításakor többféle hozzáférési közeget alkalmaznak (Tokenring, Ethernet illetve Fast-Ethernet). A közegek közötti hálózati átjárhatóságot bridge segítségével tudjuk megoldani. Az alkalmazott hálózati réteg protokoll is lehet IP vagy IPX. Ebben az esetben a kettő közötti átjárhatóságot gateway segíti

2.2 A nagykiterjedésű magánhálózatok ismertetése 2.21 Klasszikus magánhálózatok Kezdetekben a cégek távoli telephelyeiken üzemelő hálózatrészek elérésre dial-up, majd menedzselt bérelt vonal összeköttetést alkalmaztak. A magánhálózaton szinte csak a kezelő személyzettől függ, hogy milyen típusú adatkommunikáció zajlik rajta. Ez akár IPX-el megfejelt hangforgalom is lehet. A hálózat elkülönülése és sajátkezű karbantartása biztosítja az adatok védelmét, azonban a bérelt vonali kapcsolat kiépítése és fenntartása költséges, skálázhatósága nehézkes. Ezenkívül a cégeknek rendelkezniük kell képzett szakemberekkel is, akik a hálózaton folyó adatkommunikációt menedzselik. Az MLLN alapú magánhálózat topológiája csillag vagy gyűrű, forgalom és jogosultságok elosztás alapján az előbbi, megbízhatóság szempontjából az utóbbi a jobb megoldás. Képek 2.22 Virtuális magánhálózatok Az Internet

térhódításával jobban skálázható és a különböző igényeket is jobban kiszolgáló, úgynevezett virtuális magánhálózatokat megvalósító technológiák terjedtek el. Ezek elterjedését relatív olcsóságuk segíti. 5 A virtualitás lényege, hogy egy megbízhatatlan közegen (Internet) alakítunk ki egy teljesen elkülönített és biztonságos hálózatot. Az elkülönítés különböző kódolási eljárással valósul meg. Software közeli megoldások A legtöbb sofware alapú VPN programcsomag lehetőséget ad a csomagok címzés, vagy protokoll szerinti tunneling-jére. Különbség, hogy Layer2 vagy Layer3 tunnel-ként valósul meg. Layer2 esetén a kliens PPP (Point to Point Protocol) kapcsolaton keresztül éri el azt a hálózatrészt (tipikusan egy cég Intranet-jét) melyhez kapcsolódni kíván. A szolgáltató nem végződteti a PPP kapcsolatot, hanem enkapszuláció révén (L2TP, L2F, PPTP, stb.) juttatja el a végfelhasználó forgalmát az

adott hálózatrészhez (pl: VPDN szolgáltatás, ahol egy a szolgáltatótól erre a célra igényelt telefonszámot kell hívni). Előnye, hogy jól skálázható, hátránya viszont, hogy mélyebb szintű háttértudás szükséges a beállításához a kiszolgáló operációs rendszer általános ismereténél. Az operációs rendszerek túlnyomó része ma már önmagában is ad valamilyen szintű támogatást A leggyakrabban alkalmazott operációs rendszerek a következők (a teljeség igénye nélkül): Microsoft Windows 2000, Apple Mac OS X, Sun Solaris 8, HP Unix, Linux + FreeSwan Az IPSec alkalmazásához szükséges egy Internet kapcsolat (ez ISP független) és egy speciális software, amely a tunnel-t az igénybe vett Internet kapcsolaton keresztül, Layer3 szinten hozza létre. Ez az alkalmazás, valamilyen titkosító eljárással (például 3DES) kódolja a csomagokat, újracsomagolja, és ami a legfontosabb, az Internet kapcsolatot tiltja a VPN tunnel ideje alatt. A

működéshez szükséges még IPSec végződtető berendezés (IPSec Tunnel Terminátor), amit a szolgáltató tart fenn, és a MPLS (Multiprotocol Label Switching) alapú VPN, ahova a tunnel felépül. A software alapú megoldások abban az esetben ideálisak, ha minél olcsóbban kell megvalósítani a VPN-t. Ezekkel a megoldásokkal helyettesíteni lehet a RAS-t (Remote Access Service), távmunkahelyeket lehet kialakítani, amit az országhatárok sem gátolnak (ISP és telefonhálózat független az IPSec). Hardware közeli megoldások A szoftveres VPN megoldással szemben a hardveres számos előnyt nyújt. A VPN hardver több Internet csatornát (tunnel-t), nagyobb sebességet tud kezelni, és a teljes rendszer paraméterei jobbak bármely szoftveres rendszernél. A legmagasabb fokú hálózati áteresztőképességet (throughput) nyújtják az összes többi megoldással szemben, hiszen nem 6 emésztenek fel fölösleges erőforrásokat plusz operációs rendszer és

segédalkalmazások kiszolgálására. Az ügyfélnek nincs feladata a VPN kialakításában, mert az a szolgáltató hálózatában valósul meg. A CE routerek egyszerű konfigurációt igényelnek Az MPLS alapú VPN-ek fix megbízható bérelt vonali (MLLN, ATM, stb.) összeköttetéssel rendelkeznek, ami kiszámítható adatmennyiség mozgatását teszi lehetővé A software közeli megoldással ellentétben itt alkalmazható a QoS (Quality of Service), mely az integrált hang-adat szolgáltatáshoz elengedhetetlen. Kialakítható több sub interfész, így elkülöníthetők a tunnel-ek (adat és hang csatornák) A CE router megfelelő kiépítésben képes fogadni és feldolgozni, azaz digitalizálni és tömöríteni, analóg hang csatornákat, nem route-olható protokollokat átcsomagolni IP-be (majd a másik oldalon újra visszacsomagolni), továbbá képes adatokat fogadni POS termináloktól is, stb. Létrehozható olyan topológia, ami megfeleltethető a hagyományos

hálózatok felépítésének (Csillagpont – Hub and Spoke, Gyűrű – Full Mashed). 2.3 A protokollok A virtuális magánhálózatok létrejöttét is, mint minden mást a műszaki világban, szabványok teszik lehetővé. Ezek a szabványok teszik összeköthetővé a különböző gyártok berendezéseit annak ellenére, hogy esetenként a funkciójuk sem azonos (router és telefonalközpont összekötése). 2.31 A hét rétegű hálózati modell A számos létrejött hálózatkialakítási mód megkívánta, hogy szabványosítsák az eszközöket és a kapcsolódási pontokat. Erre szolgál a hét rétegű modell, amely az International Standards Organization (ISO: Nemzetközi Szabványügyi Szervezet) ajánlása A kidolgozott modell az OSI (Open System Interconnection), azaz a nyílt rendszerek összekapcsolása A létrejött modell minden egyes rétege egy absztrakciós szint, minden réteg jól definiált feladatokat lát el. A legfelső réteg OSI környezetben

együttműködő alkalmazási entitásokból áll A lejjebb fekvő rétegek nyújtják azokat a szolgáltatásokat, amelyeken keresztül az alkalmazási entitások együttműködnek Ezek biztosítják a hírközlő szolgáltatás lé- 7 pésenkénti átadását, azaz az n-edik réteg oly módon nyújtja szolgáltatásait az (n+1)-edik rétegnek, hogy az (n-1)-edik rétegtől vett szolgáltatásokat kiegészíti saját funkcióival. A hét réteg feladatai és szolgáltatásai röviden: 1. Fizikai réteg A fizikai réteg biztosítja a bitátvitelhez szükséges fizikai összeköttetések bekapcsolásához, fenntartásához és kikapcsolásához szükséges mechanikai, villamos, funkcionális és eljárási eszközöket. A fizikai réteg entitásai a fizikai közeggel vannak összekötve. 2. Adatkapcsolati réteg Az adatkapcsolati réteg hibamentes virtuális adatkapcsolati összeköttetést biztosít a hálózati entitások számára. Az adatkapcsolati összeköttetés egy vagy

több fizikai összeköttetésre épül. Az adatkapcsolati réteg jelzi, és lehetőleg javítja a fizikai rétegen belül keletkező hibákat A hálózati réteg számára lehetővé teszi a fizikai rétegben az adatáramkörök összekapcsolásának vezérlését 3. Hálózati réteg A hálózati réteg az alkalmazási entitásokat magukba foglaló nyílt rendszerek között létesít, tart fenn és bont hálózati összeköttetéseket, valamint eszközöket biztosít a szállítási entitások közötti adatcseréhez. A hálózati réteg a szállítási entitásokat mentesíti az adott hálózati összeköttetés létesítésével és üzemeltetésével kapcsolatos forgalomirányítási és ismétlési feladatoktól 4. Szállítási réteg A szállítási szolgáltatás átlátszó, megbízható és költséghatékony adatátvitelt végez a viszonyentitások között. 8 A szállítási réteg optimalizálja a rendelkezésre álló hálózati szolgáltatás használatát, hogy a

viszonyentitások által igényelt minőséget a legkisebb költséggel nyújtsa. A szállítási rétegen belüli protokolloknak vég-vég értelme van, amelynek végeit az egymással levelezésben álló szállítási entitások jelentik Szállítási protokollok csak végrendszerek között működnek. 5. Viszony réteg A viszonyréteg eszközöket nyújt a megjelenítési entitások párbeszédének szervezéséhez, adatcseréjük menedzseléséhez. 6. Megjelenítési réteg A megjelenítési réteg az információ ábrázolásával foglalkozik. Azt az adatábrázolást nyújtja, amelyet az alkalmazási entitások a kommunikációhoz vagy hivatkozásaikban felhasználnak A megjelenítési réteg csak a szintaxissal, vagyis csak az adatok megjelenítésével és ábrázolásával. foglalkozik Az alkalmazási entitásoknak szintaxisfüggetlenséget biztosít. Ehhez elvégzi a szintaxis megválasztását és a szintaxisok közötti transzformációt Továbbá végrehajthat speciális

funkciókat is, például titkosítás, tömörítés, stb A megjelenítési réteg protokollja bizonyos menedzselési tevékenységet is végez. 7. Alkalmazási (felhasználói) réteg Az alkalmazási réteg biztosítja az alkalmazási folyamatok számára az OSI környezethez való hozzáférést, az eltérő rendszerek közötti állománytovábbítást, a különböző terminálprotokollok támogatását, a levelezést és a távoli futtatást. A számtalan inkompatibilitásból származó funkciókat egy virtuális hálózati terminál segítségével oldja meg. 2.32 A TCP/IP protokollcsalád Az Internet kialakulásához nagymértékben hozzájárult az Amerikai Védelmi Minisztérium egyik kutatási projectje, melynek célja egy nehezen megsemmisíthető, katonai célú számítógépes hálózat létrehozása volt. E kutatás során kifejlesztettek egy csomagkapcsolt hálózati protokollt, mely felépítésével és redundáns útvonalaival biztosítani tudta a megfogalmazott

követelmények maradéktalan teljesítését. A protokoll – amely TCP/IP néven vált ismertté – civil alkalmazására először a 70-es évek közepén került sor, egy elsősorban az amerikai egyetemekhez kötődő számítógépes hálózatban, hogy később ebből a háló9 zatból fejlődjön ki a mai Internet. Napjainkra a hálózat az egész világot átszövi, megváltoztatja az emberek üzletről, szórakozásról, információáramlásról alkotott képét Jelentőssége napról napra nő, ezért is rendkívül fontos az alapját képező technológia megismerése és megértése. TCP/IP protokoll ismertetése Ezt a protokollt csomagkapcsolt hálózatok adatátviteli protokolljára hozták létre. Ez egy négy réteget tartalmazó hálózati protokoll rendszer, szemben az ISO OSI hét rétegű modelljével. A TCP/IP protokoll felépítése • Host to Network Layer: Ez a szint az OSI modell fizikai és adatkapcsolati rétegéhez áll közel, feladata a kapott

bájtok átvitele. A fölötte levő rétegek csak azt várják el tőle, hogy bájt folyamokat tudjon fogadni, illetve átadni • Internetwork Layer: Ez a réteg felelős az adatok átviteléért a hálózaton, a gépek közötti kapcsolat összeköttetés mentes és nem tudja biztosítani a réteg az adatok korrekt átvitelét sem. Ezen a szinten több protokoll is megtalálható, de ezek közül a legfontosabbak: a) IP (Internet Protocol) b) ARP (Adress Resolution Protocol) c) ICMP (Internet Control Message Protocol). a) Internet Protocol: Az összes kommunikáció a host-ok között IP csomagok formájában történik. Ez a protokoll gondoskodik a csomagok átviteléről a hálózaton A kommunikációhoz nem szükséges állandó kapcsolat kiépítése, mivel ez egy összeköttetés mentes protokoll. Adatátvitel szempontjából nem megbízható, a csomagokkal bármi megtörténhet: elveszhetnek, megsérülhetnek, sorrendjük összekeveredhet. Egy IP csomag két részből áll:

⇒ IP header: ez tartalmazza a csomagot azonosító információkat; ⇒ Adat: ebben a részben van az az adat, amit ténylegesen át kell vinni. 10 Az IPv4-es header felépítése Az egyes mezők jelentése az IPv4-es header-ben:  Version: Ez egy négybites információ arról, hogy a header hányas IP verziót használ.  Header Length: A header hossza bájtos egységekben.  TOS (Type Of Service): Ebben a mezőben lehet megadni kéréseket a routerek felé, arra vonatkozóan, hogy a csomagot hogyan továbbítsák. A csomaghoz prioritást lehet rendelni, például kérni lehet, hogy a kisebb késleltetésű úton, vagy a nagyobb sávszélesség felé, vagy akár a nagyobb megbízhatóságú úton menjen a csomag. Ez csak egy kérés a routerek felé, nem kötelesek ezeket figyelembe venni  Identifier: A fragmentáció támogatására szolgál. Amennyiben egy IP csomagot fel kell bontaniuk a routereknek kisebb csomagokra, akkor ebben a mezőben lesz egy

azonosító az eredeti csomagra vonatkozóan. Ha az egyes alhálózatok eltérő keretmérettel dolgoznak, szükségessé válhat a csomagok hosszának a csökkentése. A fragmentáció során keletkezett csomagokat, természetesen a routerek nem építik össze egy egységes csomaggá, amikor már a csomagméret megengedhetné, mivel az egyes IP csomagok két host között nem feltétlenül egy útvonalon közlekednek. Az eredeti csomag előállításáról mindig a host-oknak kell gondoskodniuk.  Flags: Ez a mező is a fragmentáció támogatására szolgál. Amennyiben egy csomag fragmentált, akkor azt ebben a mezőben jelzik  Fragment offset: Fragmentált csomag esetén azt mutatja, hogy az adott csomag az eredetinek hányadik darabja.  TTL (Time To Live): Ez a mező minden egyes routoláskor eggyel csökken, amennyiben ez a mező 0-ra csökken akkor a routerek eldobják a csomagot. Ez arra szolgál, hogy a hibás címmel bekerült csomag ne keringjen

végtelenségig. 11  Protocol: Ebben a mezőben adják meg, hogy az IP csomag adat része milyen header-t tartalmaz. Azaz, milyen protokoll várja fent ezt a csomagot(például TCP, UDP, ICMP stb).  Header checksum: Ellenőrző összeg a header-re.  Source Adress: A küldő IP címe.  Destination Adress: A címzett IP címe. b) Adress Resolution Protocol: Ez a protokoll az IP cím alapján történő fizikai cím megtalálására szolgál. Először egy cache-ben keresik a fizikai címet Amennyiben ott nem található, akkor egy IP csomagot állít elő, amelybe beteszi a keresett IP címét, a fizikai címnek hagy egy üres mezőt, majd beteszi a saját IP címét és fizikai címét. Ezt az IP csomagot broadcast módon elküldi. Aki az IP cím alapján magára ismer, az kitölti a fizikai címre szolgáló helyet, és visszaküldi a csomagot A csomagból ki tudja venni a feladó IP címét, és fizikai címét, és azt be tudja építeni a saját cache-be. Ez

célszerű, hiszen egy ilyen kereső csomag rendszerint éppen valamilyen más kapcsolatfelvételt jelez és előz meg. c) Internet Control Message Protocol: A két kommunikáló fél ennek segítségével küld egymásnak beállítandó paramétereket, valamint hibajelzésre is szolgál. Természetesen ez is IP csomag formájában közlekedik a hálózaton, az adat mezőbe van beírva az üzenet Az adatmezőben van két darab bájt, amely az üzenet azonosítására szolgál. Ezt követi az ellenőrző összeg, majd opcionálisan az egyéb paraméterek Tipikus üzenetek lehetnek:  Hibás IP header checksum  A címzett nem elérhető  Az írási sebességet lassítsa a küldő  Echo req/replay  TTL mező 0-ra csökkent. • Transport Layer: Ezen a szinten két különböző protokoll található, teljesen eltérő tulajdonságúak: a) TCP (Transmission Control Protocol) b) UDP (User Datagram Protocol) a) Transmission Control Protocol: Felfelé megbízható

adatátvitelt biztosít úgy, hogy alatta egy megbízhatatlan protokoll található. Felülről bájt folyammal le- 12 het táplálni (stream orientált), full duplex átvitelt biztosít, kapcsolat orientált. Kliens-szerver kapcsolatok kialakítására képes, bárki lehet egyszerre kliens és szerver is. A kapcsolat felvétele mindkét oldalon nyugtázva történik A kezdeményező küld egy kérés csomagot, a címzett válaszol a kérésre, majd a kezdeményező küld egy nyugtát arról, hogy vette a címzett válaszát. A kapcsolatok azonosítására szolgálnak a portok A szerver egy adott porton érkező kérésekre figyel, és az ott érkező kéréseket kiszolgálja. A TCP portok közül az első 1024 foglalt a standardalkalmazások számára. A megbízhatóság érdekében a protokoll a teljes TCP csomagra számol ellenőrző összeget A megbízható kapcsolat kialakítására pozitív nyugtázást használ A küldő oldal nyugtát vár minden egyes elküldött TCP

csomagról. Amennyiben egy később küldött csomagról előbb kap nyugtát, mint egy korábban küldött csomagról, akkor a korábban küldött csomagtól kezdve megismétli az adást. Egy TCP csomag szintén két részből áll, egy headerből és az átvinni kívánt adatokból. b) User Datagram Protocol: Ez sokkal gyorsabb protokoll, mint a TCP protokoll, viszont nem megbízható adatátvitel szempontjából. Nem kapcsolat orientált, nincs hibajavítás, nincs nyugtázás Tulajdonképpen az IP szint által biztosított szolgáltatásokat nyújtja felfelé Akkor szokták használni, ha az adatátvitel sebessége a legfontosabb, minden többi feladatot a felette elhelyezkedő réteg lát el. Tipikusan a DNS-ek (Domain Name Server), real-time alkalmazások, játékok szokták használni (egy játékban vagy real-time hang átvitel esetén ha egy csomag rossz, akkor ott legfeljebb „döccen” egyet, de ez még min- 13 dig kisebb baj, mintha az adott pontnál megállna és

onnantól elkezdené újra adni a csomagokat). A szegényesebb szolgáltatásból adódóan sokkal egyszerűbb az UDP header • Application Layer: Ezen a szinten helyezkednek el az alkalmazások. Az adatok átvitelét TCP, vagy UDP porton keresztül történő hívásokkal valósítják meg A portok tulajdonképpen a kommunikációs csatorna egy végpontjának az azonosítására szolgálnak A szabvány 65535 TCP és 65535 UDP portot engedélyez, ezek közül az első 1024 foglalt szabványosított protokollok számára (pl.: Telnet, SMTP, POP3, FTP, SNMP, HTTP, stb.) Az összeköttetés kliens szerver alapon valósul meg Az egyes szerver alkalmazások az adott host gép operációs rendszerénél bejegyeztetik magukat, hogy egy adott TCP, vagy UDP portra érkező kérések kiszolgálásáért az adott alkalmazás legyen a felelős. Az egyes kliens alkalmazások, amikor megszólítják a szerver gép adott portját akkor az ott futó operációs rendszer értesíti a szerver

alkalmazást arról, hogy kérés érkezett az adott portra. Azaz amikor egy szolgálat azonosítására van szükség a hálózaton akkor nem elég a szerver gép IP címét megadni, hanem szükséges az adott szolgáltatáshoz kapcsolódóan megadni a szerver adott TCP, vagy UDP portját. 2.33 Priorizált adatforgalom megvalósítása Quality of Service (QoS) segítségével A jelenlegi, Internet alapú hálózatok BE (Best Effort – Legjobb Szándék) elven működnek, ami azt jelenti, hogy minden felajánlott forgalmat megpróbálnak célba juttatni, de annak módjára vonatkozóan nem adnak, és nem ígérnek semmilyen garanciát. Ez a működési mód nem is jelent gondot a hagyományos TCP/IP adatforgalom esetén, mert torlódás miatt elveszett adatcsomagokat ismétléssel lehet pótolni. A Real Time adatforgalom esetében ez nem járható út. Itt biztosítani kell, hogy a maximális késleltetés ne legyen nagyobb a teljes hálózatban, mint az erre a típusra megengedett

150 ms és az elveszett csomagok száma sem haladhatja meg a 0.2%-ot Az IP karakterisztikájából adódóan adott minőségű paraméterek biztosításához priorizálásra van szükség. A QoS alkalmazása ezen prorizálás megfelelő konfigurálását jelenti a hálózatban, mely révén a hálózat az átvitel során elsőbbséget biztosít a ki- 14 emelt üzleti alkalmazások (mission critical applications) által generált forgalom számára. Fontos, hogy az IP esetében sem valamilyen paraméterre vállal garanciát, hanem arra, hogy az átvinni kívánt csomagok egy csoportja az átvitel során előnyben részesül a csomagok egy másik csoportjával szemben Így valósul meg a „jobb minőség”, azaz a relatíve kedvezőbb átviteli paraméterek A QoS képességek megfelelő biztosításával a platform képes az IP alapú hangtovábbításra. Ennek során a hangforgalom magas prioritású, rövid csomagokban halad át a hálózaton Forgalmi osztályok: Real Time –

hangátvitel Prémium (business) – priorizált Normál (Beste Effort) QoS-t támogató szabványok Mint minden műszaki megoldásnál, a QoS esetében is ajánlatos a szabvány által specifikált megoldásokat előnyben részesíteni az egyedi gyártói megoldásokkal szemben. Szerencsére, az elmúlt néhány évben számos alapvető szabvány jött létre az IP hálózatokban történő QoS biztosítása tekintetében. Az IETF (Internet Engineering Task Force) két QoS rendszertechnikát szabványosított: az IntServ [R1633] és a DiffServ [R2475] architektúrát. Az előbbi az adatfolyamok (traffic flow), míg az utóbbi a forgalmi osztályok (traffic class) szintjén történő priorizálásra ad megoldást A szolgáltatói hálózatokban az adatfolyamok nagy száma miatt értelemszerűen a DiffServ architektúrával lehet QoS funkciókat biztosítani. A DiffServ megoldás lényege, hogy a hálózatba belépő csomagokat ún. forgalmi osztályokba sorolják. és a forgalmi

osztálynak megfelelő “színnel” látják el Az IP Precedencia mező kiterjesztésének köszönhetően az immáron 6 bites DSCP (DiffServ Code Point) mező révén 64 forgalmi osztály megkülönböztetésére van lehetőség [R1122][R1349][R2474]. A DiffServ implementációk megjelenésével tehát, igen nagy számú prioritási osztály lesz definiálható egy IP hálózatban, ami a hálózati erőforrások minden eddiginél hatékonyabb kiaknázását eredményezheti. 15 A hálózat szélén elhelyezkedő eszközök természetesen kontrolálják a hálózatba belépő forgalom volumenét is. A hálózat szélén elvégzett színezést követően a hálózaton belül a csomagok továbbítása a forgalmi osztályukra vonatkozó szabályok szerint történik, melyeket a szabvány ún. PHB-ként (Per-Hop Behavior) definiál A szabványok két PHB-t rögzítenek: Expedited Forwarding (EF) és Assured Forwarding (AF) [R2598][R2597]. Az EF-ként karakterizált forgalom

minimális késleltetés/késleltetés ingadozás és garantált erőforrás allokáció mellett kerül továbbításra, ami a VoIP jellegű alkalmazások transzportjára alkalmas. Az AF teszi lehetővé a hálózati sávszélesség több osztály közötti felosztását. Egyes gyártói implementációk további, egyedi igényeknek megfelelő továbbítási módok konfigurációját is megengedik QoS osztályok bevezetése A szabvány által biztosított 64 QoS osztály teljes kihasználása egyelőre még elég futurisztikus. A sokféle lehetőség közötti eligazodás még a kellő szakmai háttérrel rendelkező ügyfelek számára is komoly kihívást jelenthet. Ugyanakkor az ügyfelek elvárásai ma még kielégíthetőek néhány QoS osztály révén. A közeljövőben ezért a következő forgalmi/prioritási osztályok használata célszerű:  hang,  videó,  magas prioritású adat,  best-effort adat,  üzemeltetői forgalom. Sokak számára meglepő

a hang és a videó osztály megkülönböztetése, hiszen közismert, hogy hasonló követelményeket támasztanak az átvitellel szemben (alacsony késleltetés, alacsony késleltetés ingadozás és alacsony csomagvesztés). A megkülönböztetés hátterében az igencsak eltérő forgalmi karakterisztikák állnak A hangcsoma16 gok ugyanis jellemzően igen rövidek (20-30 ms-nyi hangmintát tartalmaznak), míg a videó átviteli adatcsomagok jellemzően nagy méretűek, mivel a videókép átviteléhez jóval több információ transzportjára van szükség. Ugyanakkor az átviteli követelmények teljesítése szempontjából a sorban állási pufferek méretezése és kezelése a meghatározó A sorban állással kapcsolatos komplex kérdések megoldása pedig külön pufferek – azaz külön QoS osztályok – alkalmazásával lehetséges QoS támogató funkciók A QoS osztályokhoz tartozó átviteli paraméterek biztosításához, azaz a DiffServ architektúra

megvalósításához az alábbi funkciókat kell biztosítani az IP hálózat eszközrendszerében:  Klasszifikáció,  Rendfenntartás (Policing),  Torlódás megelőzése,  Torlódás kezelése. Lévén, hogy ma már szinte minden szolgáltató MPLS alapú IP hálózattal rendelkezik a továbbiakban MPLS alapú hálózati jelölések (CE router, PE router, LSR) kerülnek alkalmazásra. QoS biztosítása az MPLS hálózat eszközeiben Klasszifikáció Klasszifikáció alatt a csomagok különböző osztályokba sorolását és megjelölését értjük, ami lehetővé teszi az átvitel során a megjelölt csomagoknak a többitől eltérő módon történő kezelését. Ez az osztályba sorolás az IP csomag fejrészében levő 3 bites Precedencia mező alapján valósul meg A klasszifikációt az adatátvitel esetében a Committed Access Rate (CAR), míg a hangátvitelnél az IP Precedence funkcionalitás biztosítja. 17 A klasszifikációt végezheti: 

az ügyfél,  a szolgáltató. Az ügyfél által végzett klasszifikáció esetében a CE routerekben csupán annak felügyeletére van szükség, hogy az IP csomagok precedencia értéke megfelelő-e. A szolgáltatási szerződésben foglaltaktól eltérő precedencia értékek esetében reklasszifikációt kell végezni. Amennyiben a klasszifikációt a szolgáltató végzi, akkor az ügyfélnek definiálnia kell az egyes osztályokba tartozó forgalom jellemzőit. A klasszifikáció jellemzően access-lista (ACL) alapján történik, ezért az ügyfél által definiált forgalom ACL révén leírható kell legyen. Policing A klasszifikáció révén a megfelelő osztályba kerülnek az egyes IP csomagok, azonban szükség van egy olyan funkcióra is, amely az előfizetővel megállapodott paraméter értékek (pl. az egyes osztályokba tartozó forgalom nagyságának) túllépését szankcionálja. E nélkül ugyanis egyfelől nem lehet méretezni az egyes osztályokhoz

tartozó erőforrás allokációt, illetve kontrollálhatatlanná válik a késleltetés és a csomagvesztés. A szankcionálás eredménye a túlzott (non-konform) forgalom eldobása Torlódás megelőzése Tekintettel arra, hogy a TCP/IP forgalom jellegéből adódóan „börsztös” karakterisztikát mutat, nem elegendő korlátozni a hálózati erőforrásokhoz való hozzáférést, mivel a korlátozás ellenére a forgalom statisztikus jellemzői miatt torlódás léphet fel a hálózatban. Szükség van tehát torlódásmenedzselő, illetve torlódás megelőző mechanizmusok implementálása is A megelőzés egyik eszköze az ún. WRED (Weighted Random Early Detection) Feladata – mint azt a neve is tükrözi – elébe menni a torlódásnak, és adott várakozási sorok küszöbértékének figyelésével már a torlódás kialakulása előtt egyes csomagok eldobása. A WRED kihasználja a TCP ablakozási technikáját, miszerint a forrás a tőle indult csomag eldobását

észlelve csökkenti az adási sebességét. Ezzel a mechanizmussal el lehet kerülni a TCP adatfolyamok „szinkronizáció”-ját, mely kontrollálhatatlan torlódási szituációhoz vezethet. A TCP folyamok szinkronizációja alatt a következő szituáció értendő: 18 I. egy hálózati szűk keresztmetszeten bekövetkező torlódás miatt csomagvesztés lép fel valamennyi TCP folyamban, II. a csomageldobás miatt valamennyi forrás csökkenti adási sebességét, III. a torlódás megszűnik, IV. a torlódás megszűnését minden forrás érzékeli és egyidejűleg növelni kezdik adási sebességüket, V. a megnövekedett forgalom miatt ismét torlódás lép fel és a folyamat kezdődik elölről. A szinkronizáció következtében a hálózaton az átvitel állandóan ingadozik és a forgalom jelentős részét az eldobott csomagok újraküldése teszi ki. Ennek megfelelően a hálózati átvitel /throughput/ jelentősen lecsökken Kézbentartott torlódás

A WRED együttműködik a többi, QoS biztosítására szolgáló mechanizmussal, képes – az IP csomag QoS osztályát figyelembe véve – az alacsonyabb precedenciájú csomagok „erősebb” szankcionálásával megelőzni a torlódás és a TCP folyamok szinkronizációjának kialakulását. Értelemszerűen az UDP alapú átvitelnél, mint pl. hangátvitel, nincs értelme a torlódásmegelőző megoldások használatának Ezen forgalmak esetében a megfelelő méretezéssel ill sávszélesség foglalással kell biztosítani a torlódás megelőzését Torlódás menedzsment A torlódás menedzselésére szolgáló megoldások alatt a különböző sorban állási (queueing) technikákat kell érteni. Ezek feladata, hogy szűkös hálózati erőforrások, azaz torlódás esetében is biztosítani lehessen, hogy a magasabb prioritású forgalom megfelelő mennyiségű erőforráshoz juthasson. Csomagkapcsolt hálózatról lévén szó a torlódás menedzsment a várakozási

sorok megfelelő vezérlésén keresztül valósul meg. 19 Az IP hálózatok építőelemeiben számos sorban állási technika alkalmazható (PQ: Priority Queueing, CQ: Custom Queueing, WFQ: Weighted Fair Queueing, CBWFQ: Class Based Weighted Fair Queueing). A szolgáltatói hálózatokban természetesen szóba sem jöhetnek az adatfolyam alapú (flow-based) technikák, melyek elsősorban felhasználói, kisméretű hálózatokban használatosak. Ehelyett a forgalmi osztály alapú (class-based), azaz az egyes forgalmi osztályokra érvényesített erőforrás allokációt megvalósító megoldásokat kell használni (DiffServ koncepció). A forgalmi osztály alapú technikák esetében relatív sávszélesség rendelhető az egyes szolgáltatási osztályokhoz tartozó várakozási sorokhoz. Így garantálható, hogy az egyik szolgáltatási osztályban fellépő torlódás nem hat ki a többi szolgáltatási osztályon belüli forgalomra. A torlódás menedzselés

konfigurációját célszerű úgy megválasztani, hogy amenynyiben egy magasabb prioritású osztály nem használja ki a számára garantált sávszélességet, akkor a többi osztály használhassa azt Ennek megfelelően egy integrált hang/adat szolgáltatói hálózatban, a PQ és a CBWFQ technikák ötvözetét kell alkalmazni. Sorbanállási modell a szolgáltatói hálózatokban (3 QoS osztályt feltételezve) QoS funkciók kiegészítése Az eddig bemutatott technikák elegendőek akár a hangátvitel igen szigorú késleltetés, illetve késleltetés ingadozási követelményeinek teljesítéséhez. Ugyanakkor kisebb sávszélességek esetében – konkrétan 768 kbps alatt – további technikák alkalmazására is szükség van Egy 1500 byte-os csomag továbbítása egy 128 kbps-os vonalon ugyanis mintegy 93 ms-ot vesz igénybe, ami gyakorlatilag lehetetlenné teszi az ITU-T G.114-es ajánlásában megfogalmazott 150 ms-os egyirányú átviteli késleltetés

teljesítését Ennek következtében a 768 kbps alatti vonalakon L2 szintű fregmentálást kell alkalmazni. Erre két lehetőség van: 20 I. Multilink PPP ill II. FRF12 alkalmazása A szolgáltatók jellemzően a Frame-relay alapú megoldást preferálják. Az adott vonali sebesség mellett használandó fregment méretét a táblázat tartalmazza. Csomagtovábbítás ideje a vonali sebesség függvényében Lévén, hogy a Frame-relay enkapszuláció csak a CE-PE router közti szakaszon értelmezett, a Frame-relay összeköttetés paramétereit speciális módon kell beállítani: CIR = vonali sebesség, CIRmin = CIR, Sorbanállási modell alacsony átviteli sebesség mellett 2.4 A VOIP technológia 2.41 Általános bemutatása 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 21 a telefonszámláit, de ez a megoldás is igen költséges. 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 64000 bps-ot (bit/sec) igényelnek, a hangcsomagok alkalmazásánál kevesebb, mint 10000 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 Azonban az adathálózatokon történő hangtovábbításnak is ára van. A jó minőségű hangátvitel csak olyan adathá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, például 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. TÁBLÁZAT 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 összeköttetéseket emulálják, néha szokták őket ATM Class A szolgálatnak is nevezni.  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. 22  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, például Európában. Ez inkább elméleti, mint gyakorlati lehetőség. 

Nyilvános IP hálózat, beleértve az Internetet is. 2.42 VOIP az IP hálózatokban Az IP típusú hálózatokban nincs garantált mértékű késleltetés, illetve késleltetésiidő váltakozás, így 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 - mint a TCP /Transmission Control Protocol/ is - folyamatvezérlést és hibajavítást is nyújtanak, melyek kombinációja azonban 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 a 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 erőforrásokat tartsanak fent bizonyos forgalom számára. 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 2.42 A H323 szabvány A Voice-over IP legegységesebb szabványa az ITU-T, a nemzetközi telekommunikációs szövetség H.323 nevű protokollcsaládján alapszik A H323 hang-, videó- és adatkonferenciát tesz lehetővé csomagkapcsolt hálózatokon A protokollcsalád ma legfontosabb felhasználási területe

a Voice-over IP, de jó tudni, hogy a komolyabb videokonferenciarendszerek és a legtöbb internetes hang- és videochat-rendszer is a H.323 protokollon ala- 23 pul, vagy legalábbis kompatibilis azzal. Ennek következménye, hogy egy megfelelően konfigurált, szabványos H323 alapú VoIP hálózatba akár egy Microsoft NetMeeting klienssel is be lehet lépni. A H.323 protokolljai A H.323 protokollcsalád komponenseit az ÁBRA szemlélteti. Mint látható, a H.323 IP alapú adatátvitelt támogat, mégpedig a TCP és az UDP szolgáltatásaira egyaránt támaszkodva A hívásvezérlő- és adatcsatornák megbízható szállítási protokollt igényelnek, ezért ezek a TCP-t használják szállítási protokollként. A valós idejű csatornák ezzel szemben az UDP-t részesítik előnyben A média csomagok forgalmának vezérlését az RTP és az RTCP protokoll végzi. A H.323 protokollcsalád főbb elemei A H.323 több protokoll és szabvány gyűjteménye, amely rugalmasan

bővíthető A legérdekesebb és legfontosabb részszabványok az alábbiak:  Belépés regisztráció és státusz (Registration Admission and Status – RAS): ez egy tranzakció-orientált protokoll egy H.323-as végpont (lehet TE vagy GW) és egy GK (Gatekeeper) között. Egy végpont a RAS-t használhatja, hogy felderítse a GK-t, beregisztrálja/kiregisztrálja magát a GK-nél, hívásengedélyezést és sávszélességet kérjen vagy kitöröljön egy hívást. A GK használhatja a RAS-t, hogy lekérdezze egy végpont állapotát A RAS csak akkor használt, ha egy GK van jelen a zónában. 24  RTP. A Real Time Protocolt különféle multimédiás tartalmak valós idejű átvitelére fejlesztették ki Követelmény volt, hogy a csomag tartalmazzon szinkronizációs információkat (például hányadik csomag és mikor keletkezett), lehetővé tegye a különböző adatfolyamok multiplexálását (például videokonferenciánál a hang és a kép egyidejű

átvitelét), valamint a hibajavítást. Az internet hagyományos átviteli protokolljai – a TCP és az UDP – önmagukban nem alkalmasak ezekre a feladatokra. A TCP megbízható kommunikációt valósít meg, de lehetetlen vele valós idejű adatfolyamokat átvinni. Az UDP, mint datagram alapú protokoll, megfelelő lenne, de nem biztosítja a szinkronizációs és multiplexálási információk átvitelét. Az RTP protokoll az UDP-csomagokat bővíti ki ezekkel az információkkal. Ez azt jelenti, hogy minden RTP-csomag olyan UDP-csomag, amely további, az RTP szabvány által meghatározott vezérlő információkat tartalmaz. Ezekből megtudható, hogy milyen multimédia-információk vannak a csomagban. Például, ha a csomag hangot és képet is tartalmaz, akkor azok hogyan helyezkednek el, és mikor kell lejátszani őket. Az RTP igen sikeres és elterjedt protokoll, nem csupán a VoIP rendszerek, de a RealAudio/Video is ezen alapszik.  Codecek. Az RTP csak az

adatfolyamok átvitelét végzi, a tartalmukkal nem foglalkozik Arról, hogy a hangból miképpen lesz adatfolyam, és viszont, nem szól a szabvány. A hang kódolását és tömörítését az úgynevezett codecek végzik A codec szó a kóder/dekóder angol rövidítése. A codec analóg jelből digitális jelet állít elő, majd a digitális jelet visszaalakítja analóg jellé. A kifejezést a multimédiában is használják, mivel az MPEG, MPEG2, DIVX, MP3 technológia is codeceket használ A G.722-es codec 64 kbit/s-os, tömörítetlen PCM jelfolyam, amely gyakorlatilag megegyezik a hagyományos távközlés által használt formátummal. Mivel nem tömörít, nem lép fel minőségvesztés, feldolgozása minimális kapacitást igényel Ott használják, ahol bővében vannak a sávszélességnek, például irodai hálózatokban. Az alap H.323 szabvány a G7231, G728 és G729 tömörített codeceket definiálja A G7231 5,3 és 6,3 kbit/s-os, a G728 és a G729 pedig 16 és 8

kbit/s-os átviteli sebességet igényel E sebességek nettó értékek Mire az IP/UDP/RTP fejlécekkel megnövelt csomagok a hálózatra kerülnek, sávszélességigényük megnő 25 A G.7231 codec 6,3 kbit/s-ából például 13 kbit/s lesz Ez még mindig közel ötszörös tömörítés a 65 kbit/s-hoz képest A videó kódolás területén a H261 és a H.263 kódolók ajánlottak  Vezérlés. Az említett protokollok megoldják a hang tömörítését és a hálózaton való átvitelét, de a hívásvezérléssel nem foglalkoznak A H2250 protokoll (az ISDN-hálózatok Q.931 szabványának egyszerűsített változata) szabályozza a hívásfelépítést és -lebontást, a H245 pedig arra szolgál, hogy a végpontok egyeztessék az átvitel módját, vagyis hogy mekkora sávszélességet használhatnak, milyen tömörítésre képesek, videót tudnak-e továbbítani stb. Az RTP/RTCP Az RTP (Real-time Transport Protocol) végpont-végpont közti adattovábbítási

szolgáltatásokat biztosít valós-idejű adatfolyamok számára. 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 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 H323 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. UDP protokoll táblázat 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 protokoll feladata a hálózat paramétereinek a figyelemmel kíséré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 Az RTP jellemző alkalmazásai 26 Az

RTP legjellemzőbb alkalmazásai közül az audió és videó üzenetszórást említhetjük meg. Audió alkalmazásoknál, minden egyes audió adatcsomag egy RTP fejléccel van ellátva, míg ez az egész egy UDP csomagban van elhelyezve Az RTP fejléc többek között tartalmazza az audió kódolás típusát, hogy minden egyes vevőnek lehetősége legyen azt megváltoztatni a felhasználónkénti jobb adaptáció érdekében. Az RTP fejléc ezenkívül még tartalmaz időzítési információkat és szekvencia számot, amelyek lehetővé teszik, hogy a vevő rekonstruálja a küldő által létrehozott időzítést. Így például lehetővé válik az, hogy a vevőnél minden 20 ms-ban (ahogyan a küldő generálta) legyen feldolgozva egy audió csomag. A kapcsolat ideje alatt minden egyes felhasználó időnként egy speciális üzenettel jelenti a küldőnek, hogy milyen minőségben veszi az adást, kilépéskor pedig egy másik üzenettel lekapcsolódik a küldőről. Az RTP

kapcsolatok ellenőrzése és vezérlése az RTCP (Real-time Transport Control Protocol) segítségével kerül megvalósításra. Minden egyes RTP kapcsolathoz tartozik egy kontroll RTCP kapcsolat is. Amikor audió és videó információt is továbbítunk, két különböző RTP kapcsolatot használunk. Különálló RTP és RTCP csomagokat továbbítunk, ráadásul nincs direkt kapcsolat RTP szinten a két folyam között. Ennek az az oka, hogy lehetővé kell tenni a felhasználók számára, hogy igény szerint csak az egyik médiaszolgáltatást használják. Az időzítési információ lehetővé teszi a média szinkronizált lejátszását Mostanig azt feltételeztük, hogy minden egyes vevő hasonló formátumban kívánja fogadni multimédiás adásunkat. Előfordulhat azonban, hogy egyes felhasználók sokkal gyengébb kapcsolattal rendelkeznek, és így csak csökkentett sávszélességű átvitelt tudnak fogadni. Ahelyett, hogy minden egyes felhasználónak ezt a

csökkentett sávszélességű szolgáltatást továbbítanánk, egy ún mixerrel csökkentve a kódolás minőségét az alacsony sávszélességű vonal előtt, lehetővé válik, hogy minden felhasználó a neki megfelelő minőséget kapja. A mixer újra-szinkronizálja a bejövő audió csomagokat a küldő által generált formára, a rekonstruált audió folyamokat egy folyamba ötvözi, majd egy alacsonyabb sávszélességet igénylő audió kódolást használva továbbítja a csomagokat az alacsonyabb sávszélességű útvonalon. Mulitcast esetére az RTP fejléc tartalmaz egy mezőt amellyel a mixerek jelezhetik, hogy milyen forrásokat mixeltek össze, hogy a vevő oldalon a beszélő feleket be lehessen azonosítani. Átalakítókat akkor használnak, amikor például egy tűzfalon kell a multicast csomagokat átjuttatni. Ebben az esetben a tűzfal mindkét oldalára egy-egy átalakító kerül, amely kódolja, illetve dekódolja a folyamokat, egy alagutat kialakítva a

tűzfalon ke27 resztül. A tűzfalon belül lévő átalakító már újra multicast csomagokként továbbítja a média folyamot. Az RTP csomag fejléce Az RTP fejléce V - verziószám P - kiegészítést jelző bit: ha be van kapcsolva, akkor a csomag egy vagy több kiegészítő bájtot tartalmaz. Ebben az esetben az utolsó bájt fogja megmutatni, hogy hány kiegészítő bájtot tartalmaz a csomag. X – kibővítés: ha 1, akkor a fix fejléc után még egy darab fejléc következik CC – CSRC számláló: a CSRC azonosítók számát tartalmazza M – jelző: interpretációfüggő PT – csomag formátuma: az alkalmazás által használt RTP csomag típusát azonosítja. Egy statikus leképzést jelenthet a csomag tartalmára vonatkozóan Seq. nr – szekvencia szám: (16 bit) minden egyes csomagnál növekszik, és használható a vevő által a csomagveszteség észlelésére és a csomagok sorrendiségének helyreállítására A kezdeti értéke véletlenszerű

Időbélyeg: (32 bit) a csomag első bájtjának a pillanatnyi mintavételezési értékét tartalmazza. A pillanatnyi mintavételezés egy monotonon és lineárisan növekvő órából kell időzíteni, hogy szinkronizációt és jitter számításokat lehessen megvalósítani. A kezdeti értéke véletlenszerű. SSRC – szinkronizáció forrás: (32 bit) a szinkronizációs forrást azonosítja. Ez a forrás címe, amely azért használatos, hogy hálózati cím függetlenséget érjünk el Az SSRC azonosító véletlenszerűen van kiválasztva egy RTP kapcsolat időtartamára. A résztvevők minden egyes RTP folyamuknak külön SSRC azonosítót adnak. CSRC – közreműködő források: (0-15 darab, 32 bit/db.) a CSRC lista azonosítja a csomag tartalmához közreműködő forrásokat. Ez a mixerek által, több folyam összemixelése esetén használt mező Az RTCP 28 Az RTCP (RTP Control Protocol) periódikus kontroll információk terjesztését teszi lehetővé minden

egyes résztvevőhöz. Hasonló továbbítási mechanizmust használ, mint az adattovábbításra az RTP. Az RTCP a következő feladatokat látja el:  elsődleges feladata, hogy visszajelzési lehetőséget nyújtson az adattovábbítás minőségéről. Ez a funkció a torlódásvezérléshez kapcsolódik, az RTP ezáltal egy szállítási rétegű protokoll által támasztott igényeket is kielégíti. A visszacsatolás direkt felhasználható a szesszió vezérlésére és az adaptív kódolásban, de a multicast fák hiba felderítésében is hasznos szerepet játszhat.  az RTCP minden RTP forrásnak egy prezisztens, szállítási rétegű azonosítóját szállítja (CNAME). Mivel az SSRC azonosító megváltozhat, például egy újraindítás miatt, a vevőknek szüksége van a CNAME-re, hogy nyilvántarthassanak minden egyes résztvevőt.  minden egyes résztvevő elküldi a kontroll csomagokat az összes többi résztvevőnek. Annak függvényében, hogy egy

résztvevő hány más résztvevőtől kap kontroll csomagot, kiszámítja, hogy milyen sűrűn kell terjeszsze a saját kontroll információját, hogy ne terhelje le a hálózatot A H.323 alapú VolP hálózat elemei Egy H.323-as hálózat a világháló segítségével összekötött zónák sokaságából épül fel. Egy tipikus zóna felépítését a ÁBRA szemlélteti. Minden egyes övezet tartal- maz egy kapuőrt, valamint tetszőleges számú terminált, átjárót és vezérlő egységet. A zóna több helyi hálózat összekötésével is előállhat. Tűzfal segítségével kapcsolódhat más adathálózatokhoz, illetve az átjárókon keresztül kommunikálhat PSTN hálózatokkal is A H.323 hálózat funkcionális egységeinek feladatai:  Terminál - TE: egy végpont a hálózatban, amely valós idejű, kétirányú multimédia kommunikációt tud létesíteni egy hasonló terminállal, Gateway-el vagy MCUval. Ez lehet egy hagyományos analóg vagy ISDN-telefon,

H323 kompatibilis IPtelefon, videokonferencia-végberendezés, vagy egy számítógép a megfelelő szoftverrel A kommunikáció két terminál között vezérlési, jelzési, audió, videó és adat típusú is lehet. Egy terminál kapcsolatot létesíthet egy másik terminállal direktben, vagy a GK segítségével. 29  Gateway – átjáró (GW): Amennyiben különböző protokollokat használó végpontokat (PSTN, H.323, ISDN) kell összekötni, ezek között a konverziót a gateway végzi. A VoIP-nál az a leggyakoribb eset, amikor a H323 szabványú hálózatot a hagyományos telefonhálózattal kívánjuk összekötni. A VolP és a hagyományos hálózat közötti kétirányú átjárást biztosító gateway olyan doboz, amelynek egyik oldalán egy Ethernet-port, másik oldalán pedig analóg vagy ISDN-vonalak vannak Két VolP hálózat között is lehet gateway, például ha azok eltérő protokollokat használnak, vagy más-más menedzseli őket. 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 H323 konferencia elemek és terminálok közötti konverzióra. Ez a funkció kiterjed a különböző formátumok (pl, H225-ről H.221-re), és a különböző kommunikációs eljárások (pl, H245-ről H242-re) közötti konvertálásra is A gateway képes az audió és videó codekek közötti konvertálásra, valamint a LAN és a WAN oldalon történő hívásfelépítésre és bontásra A H.323 gateway képes továbbá H310, H 321, H322, és V70 szabványú terminálok támogatására Az ábra egy H323/H320 gateway-t illusztrál Gatekeeper – zónavezérlő (GK): A gatekeeper a H.323 opcionális eleme, hívásvezérlő szolgáltatásokat nyújt a H323 végpontok számára Egy, vagy akár több gatekeeper is lehet egy hálózatban, ami 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 30 A gatekeeper szolgáltatásai a következők:  Address translationAlias 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.2250 ü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 managementA 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 signalinga gatekeeper vezérli a jelzéscsatornák (Q.931 protokoll) kiépülését a végpontok között

A végpontok között kiépülhet közvetlen vagy a gatekeeper-en keresztüli jelzéscsatorna  Call authorizationA 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 (például bizonyos eszközök csak bizonyos gateway terminálhoz férhetnek hozzá), vagy időkorlát jogokon.  Bandwith management A H.323 terminálok egyidejűleg, 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.2250 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, például azt, hogy a hívott terminál foglalt, vagy éppen információval lát el más erőforrás-menedzsment funkciókat  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 31  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 Proxyval együttműködve további erőforrás allokálási/menedzselési, hívásvezérlési, H323 traffic shaping és alkalmazás specifikus routing szolgáltatásokat képes nyújtani. Multipoint Control Unit – konferenciavezérlő (MCU): A multipoint control unit (MCU) teszi lehetővé a három, vagy több fél közötti konferenciát. A H323 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 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 H245 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 a 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én a terminálok multicast módon továbbítják az audió, videó folyamokat. Ebben az esetben is végezheti MCU a H245 jelzésinformáció feldolgozását 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ó. Két részegységből (melyek száma nulla, vagy több) áll:  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, kezeli a terminálok közötti H245-ös jelzéseket, vezérli a konferenciákat, és meghatározza, hogy mely hang és kép jelfolyamot sugározza szét a rendszer (multicast) 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 32 Az MC funkció fizikailag megvalósítható a gatekeeper, a gateway, a terminál, vagy az MCU eszközben. A H323 szerint egy multipont

konferenciában egyszerre egy MC lehet  Multipoint Processzor (MP) – A multipoint processor (MP) a LAN hálózaton elhelyezkedő H.323 eszköz, amely 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 és feldolgozását az MC utasításai alapján. A négy komponensből bármelyik el is maradhat. Kis és egyszerű hálózatoknál nincs szükség gatekeeper-re Ha a hálózat csak belső célú, akkor felesleges a gateway, ha pedig csak a távolsági hívásokat akarjuk kiváltani, akkor a hálózatot gyakran terminálok nélkül, csak gateway-ekből építjük fel. Amikor a hálózatban egy GK-t használunk akkor egy H.323 hívás a következő hét fázison megy keresztül: Hívásfázisok egy Gatekeeper beiktatása után Az első három fázis a hívás felállításának felel meg, az utolsó három pedig a hívás lebontásának. Amikor nincs GK

bevonva a hívás létrehozásába, akkor az első és az utolsó lépések kimaradnak. Egyszerű VoIP hívások számára a H.323 definiál egy gyors kapcsolódási lehetőséget, amely lecsökkenti a hét hívási fázist, összevonva a Q931 és a H245 fázisokat Két fajta hívásvezérlési módszer lehetséges a H.323-ban: a direkt hívás és a GK által kezdeményezett hívás. Hívási modellek a H.323 hálózatban: 33 GK által vezérelt hívások modellje A direkt hívási modellben minden Q.931-es és H245-ös jelzési üzenet direkt a két terminál között cserélődik ki. Mindaddig, amíg a hívó fél tudja a hívott fél szállítási címét, direkt hívást tud kezdeményezni a másik féllel. Ez a modell a régi PC-centrikus modellnek felel meg. Ez azonban nem túl vonzó a szolgáltatók számára, mivel nincs rálátásuk a kezdeményezett hívásokra, így előfordulhat az is, hogy esetlegesen nem tudnak elég erőforrást szolgáltatni, illetve nem

képesek azt megfelelően számlázni. A GK által vezérelt modellben minden jelzési üzenet a GK-n megy keresztül. Ebben az esetben szükséges a RAS használata Ekkor a GK-k által lehetővé válik az erőforrások lefoglalása, és a hívás engedélyezése A VoIP szolgáltatók ezt a modellt használják, hiszen így teljesen ellenőrzésük alá tudják vonni a H.323 hálózatot A H.323 szolgáltatásai A H.450-es sorozat definiálja az alap H323 v 1 kiterjesztett multimédia kontroll és vezérlési funkcióit. 34 Ilyenek lehetnek például: H.4502 hívás átadás, H4504 hívásvárakoztatás, H.4505 hívásparkolás, H4506 várakozó hívás jelzése A H4501 a Q931-re épül, és egy általános végpont-végpont típusú funkcionális protokollt definiál az összes kiegészítő szolgáltatásnak. Minden egyes H450X (X>1) egy kiegészítő szolgáltatásalkalmazást definiál egy specifikus szolgáltatásra, mint pl a fent említettek Ezeknek a protokolloknak az

adatai a Q.931-be lesznek becsomagolva Ezáltal lehetővé válik, hogy a hagyományos PSTN rendszerekkel ellentétben, a kiegészítő szolgáltatások végrehajtása a TE-k feladata legyen és nem egy hálózati elemé (például egy telefonközpont), mint a PSTN rendszerben. Így sokkal dinamikusabb rendszerek építhetőek fel, melyek szolgáltatásai könnyebben bővíthetőek lesznek. 3. A jelenlegi hálózat és az ügyfél igényének bemutatása Első lépésként az ügyfélnek ki kell jelölnie egy kellő tudással rendelkező, lehetőleg informatikus alkalmazottját. Ennek a megbízottnak ismernie kell a jelenlegi hálózatot, a rajta folyó kommunikációt, illetve jó becslést kell tudjon adni a telephelyek közötti forgalmak nagyságáról (adat és hang), típusairól (IP, IPX) és időbeni eloszlásáról. Minél pontosabb információval rendelkezünk a jelenlegi hálózatról, annál pontosabban lehet meghatározni a VPN hálózatot. A jelenlegi állapot

megismerése után szintén nagy hangsúlyt (ha nem nagyobbat) kell fektetni az új hálózattal kapcsolatos igények megismerésére Az ügyfél marketing információk alapján elképzel egy lehetséges kiépítést, de ez a legritkább esetben felel meg annak a valós igénynek, amire az ügyfél anyagiakat is tud fordítani. Általában hosszadalmas tárgyalások szükségesek mind a műszaki tartalom meghatározásához, mind a pénzügyi lehetőségek megvitatásához, beleértve az esetlegesen adható kedvezmények és fizetési módok meghatározását is. Az ügyfél az esetek többségében a hálózat vagy a hozzá szervesen kapcsolódó elemeket más szolgáltatótól vásárolná a fizetési könnyebbség, vagy a már meglevő szerződéseinek – eszközparkja homogenitásának – megtartása miatt. Az egyeztetések alatt megkezdődhet a műszaki tartalommal való feltöltés. Ez a kezdetekkor még csak vázlatokat tartalmaz, hogy mindkét fél lássa milyen

kötelezettségeket vállal a jövőre nézve. 35 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 Feladat az integrált hang adat hálózatok tervezésénél, az hogy, hogyan 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. 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 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. De adatforgalomban is lehet olyan forgalom ami érzékeny a késleltetésre. 3.1 Az

ügyfél jelenlegi hálózata Az esettanulmányban szereplő ügyfél jelenlegi hálózata csillag topológiájú. Tervezésekor fontosnak tartották a hálózat elemeinek függetlenségét Az egyes részeket esetlegesen érintő vonalszakadás, vagy más hálózati eszköz kiesése nem vonta maga után a teljes hálózat leállását. A központi telephelyre telepítették a végpontok által használt szervereket, adatbázisokat Az ügyfél 5 magyarországi telephellyel rendelkezik, ezek 256 kbit/sec MLLN vonallal vannak összekötve a központjukkal. A meglevő útvonalválasztók CISCO típusúak, a központban 2610-es, a végpontokon pedig 805-ös sorozatúak CISCO 2610 CISCO 805 CISCO 805 36 CISCO 805 CISCO 805 CISCO 805 A telephelyeken gyártás, raktározás és kereskedés is folyik, ehhez ügyviteli, levelezési és adatbázis szoftvereket használnak. Az adatbázisrendszerük régi dBase alapú, ami nagy hálózati forgalmat generált, az adatok mozgatását

szervezéssel, időzítéssel a nap 24 órájában széthúzva oldották meg. A hálózat fejlesztésével párhuzamosan korszerűbb gyártási és raktári adatbázisrendszert is bevezetnek. Vidéki kirendeltségeken 8 – 10 számítógépet és telefonkészüléket üzemeltetnek. A központban 25 – 27 munkahely van kialakítva Az ügyfél igény alapján a telefonálási szokások is felmérésre kerültek. Minden végponton van helyi és belföldi távolsági forgalom is, esetenként a másik telephely körzetébe is történnek hívások. Minden telephelyről indítanak mobilhálózatokba is hívásokat A telephelyek közötti, illetve egyéb forgalom aránya átlagosan 1:3 oszlik meg Ebből vidéki kirendeltségeknél 1:4 arányban oszlik meg a helyi és a távolsági irányában. A központ telefon forgalma 1:2 arányt mutatott a vidéki és a helyi hívások között A számítások szerint átlagosan fővonalanként naponta 1 – 2 órát töltenek telefonálással. Vidéken

2 – 2 ISDN fővonal (BRI), a központban pedig egy 30 fővonalat magába foglaló ISDN (PRI) van a központokra bekötve. 4. Az ügyfél hálózatának megtervezése 4.1 A hálózat Az ügyfél telephelyein nem csak hálózati rekonstrukciót hajt végre, hanem ezzel egy időben adatbázisát is átszervezi. Egy új ügyviteli szoftvert telepít, ami bármi nemű adat azonnali és könnyű elhívásán túl támogatja a belső levelezést, az intranetes közös munkát is. Ez az új szoftver kisebb adatforgalmat generál ezért a telephelyeit összekötő 256 kbpses összeköttetések sebességét le lehet csökkenteni A telepítő cég tapasztalataira támaszkodva az adatforgalom várható sávszélesség igényét 128 kbps-ben adta meg Ehhez adódik hozzá az igényelt 2 hangcsatorna, ami 64 kbps sávszélességet igényel 32 k-s tömörítettséggel számolva csatornánként Vagyis központi telephely kivételével elég 192 kbps MLLN vonalat kiépíteni a szolgáltató

Internetes gerinchálózatának egy Provider Edge (PE) router egy interfészével. Az adatforgalom esetleges aláméretezése sem jelent gondot, 37 mert a megvalósításkor Frame-relay áramköröket alakítunk ki mind a PE mind a Customer Edge (CE) oldali útvonalválasztókban. Erre azért van szükség, mert ezen az áramkör típuson lehet priorizált adatforgalmat tervezni (QoS). Így amikor nincs hang forgalom a teljes csatorna az adatforgalom rendelkezésére áll A központi telephelyén célszerű a vidéki telephelyek sávszélesség igényének az öszszegével számolni, de ügyfél igény alapján lehet kevesebb is. Ez azon a megfigyelésen alapul, hogy az összes végpont ritka esetben forgalmaz egyszerre a központ felé. Ekkor azért a figyelmet fel kell hívni erre az eshetőségre is. Ebben tervezett hálózatban az ügyfél kis végpontok összegének megfelelő kapacitást igényel a központi PE – CE linkre, vagyis 5 * 192 kbps = 960 kbps vonalat. Itt nem

igényel a hangszolgáltatás Frame-relay enkapszulációt, mert mint a QoS ismertetésekor láthattuk csak a 768 kbps alatti vonalakon szükséges fregmentálni a csomagokat 4.1 Az eszközök A jelenlegi hálózatában Cisco berendezéseket használ. Tervezés során ezt figyelembe véve alakítom ki a az eszközparkot. Végpontokon üzemelő Cisco 805-ös berendezések nincsenek kialakítva az ISDN BRI eszközök fogadására. Ezért ezekre a telephelyekre Cisco 1751-es routert kell telepíteni 12.2T IOS-el Cisco 1751 A központban üzemelő Cisco 2610-es interfészkártya bővítéssel és IOS cserével alkalmassá tehető ISDN PRI fogadására. Az Ügyfél igényel Internet kijáratot is, erre fellehet használni az egyik Cisco 805-ös berendezést A többi kieső berendezését feltudjuk vásárolni, illetve levonjuk az értékét a tervezett hálózat árából 38 2600/3600 család hang/fax modulja 5. Fejlesztési javaslatok 6. Összefoglalás 7. Irodalomjegyzék 8.

Mellékletek Router konfigurációk: core0-kecskemet# ! ip vrf vx2000xx rd 5483:30 route-target export 5483:30 route-target import 5483:30 ! ! policy-map CBWFQceg class voice priority 112 class class-default fair-queue random-detect ! ! interface Serial1/6:26.101 point-to-point description Interfruct ivd / 76xxxx / vx2000xx / VPN / vrf-voice bandwidth 128 ip vrf forwarding vx2000xx ip address 10.25412197 255255255252 frame-relay interface-dlci 101 class voipceg ! ! 39 address-family ipv4 vrf vx2000xx redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! ip route vrf vx2000xx 192.16804 255255255255 Serial1/6:26101 ip route vrf vx2000xx 192.16840 2552552550 Serial1/6:26101 ! map-class frame-relay voipceg no frame-relay adaptive-shaping frame-relay cir 192000 frame-relay mincir 192000 service-policy output CBWFQceg frame-relay fragment 160 ! ! end core0-sopron# ! ip vrf vx2000xx rd 5483:30 route-target export 5483:30 route-target

import 5483:30 ! ! policy-map CBWFQ56 class voice priority 56 class class-default fair-queue random-detect ! ! interface Serial1/6:5.101 point-to-point description Ceg sopron ivd / 99xxxx / vn200038 / VPN / vrf-voice bandwidth 192 ip vrf forwarding vx2000xx ip address 10.25412213 255255255252 frame-relay class voip56 frame-relay interface-dlci 101 class voip ! ! address-family ipv4 vrf vn200038 redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! ip route vrf vx2000xx 192.16805 255255255255 Serial1/6:5101 ip route vrf vx2000xx 192.16850 2552552550 Serial1/6:5101 ! map-class frame-relay voip56 no frame-relay adaptive-shaping frame-relay cir 192000 frame-relay mincir 192000 40 service-policy output CBWFQ56 frame-relay fragment 160 ! ! end pe0-debrecen# ! ! ip vrf vx2000xx rd 5483:30 route-target export 5483:30 route-target import 5483:30 ! ! policy-map CBWFQCeg class voice priority 112 class class-default fair-queue random-detect !

! interface Serial2/3:18.101 point-to-point description Ceg debrecen ivd / 52xxxx / vx2000xx / VPN / vrf-voice bandwidth 192 ip vrf forwarding vx2000xx ip address 10.25412189 255255255252 frame-relay interface-dlci 101 class voipCeg ! ! address-family ipv4 vrf vx2000xx redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! ! ip classless . . ip route vrf vx2000xx 192.16802 255255255255 Serial2/3:18101 ip route vrf vx2000xx 192.16820 2552552550 Serial2/3:18101 ! ! map-class frame-relay voipifr no frame-relay adaptive-shaping frame-relay cir 192000 frame-relay mincir 192000 service-policy output CBWFQCeg frame-relay fragment 160 ! . end pe-szekesfehervar# ! ! 41 ip vrf vx2000xx rd 5483:30 route-target export 5483:30 route-target import 5483:30 ! ! policy-map CBWFQ56 class voice priority 56 class class-default fair-queue random-detect . ! interface Serial2/3:22.101 point-to-point description Ceg szfvar ivd / 22xxxx / vx2000xx / VPN /

vrf-voice bandwidth 192 ip vrf forwarding vx2000xx ip address 10.25412165 255255255252 frame-relay interface-dlci 101 class voip56 frame-relay ip rtp header-compression ! ! address-family ipv4 vrf vx2000xx redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! ip classless . . ip route vrf vx2000xx 192.16803 255255255255 Serial2/3:22101 ip route vrf vx2000xx 192.16830 2552552550 Serial2/3:22101 . ! map-class frame-relay voip56 no frame-relay adaptive-shaping frame-relay cir 192000 frame-relay mincir 192000 service-policy output CBWFQ56 frame-relay fragment 160 ! ! end pe0-pecs# . ! ip vrf vx2000xx rd 5483:30 route-target export 5483:30 route-target import 5483:30 ! ! policy-map CBWFQ56 class voice priority 56 class class-default 42 fair-queue random-detect . ! interface Serial2/0:14.101 point-to-point description Ceg pecs ivd / 72xxxx / vx2000xx / VPN / vrf-voice bandwidth 192 ip vrf forwarding vx2000xx ip address 10.25412229

255255255252 frame-relay interface-dlci 101 class voip56 ! address-family ipv4 vrf vx2000xx redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! ip route vrf vx2000xx 192.16806 255255255255 Serial2/0:14101 ip route vrf vx2000xx 192.16860 2552552550 Serial2/0:14101 ! map-class frame-relay voip56 no frame-relay adaptive-shaping frame-relay cir 128000 frame-relay mincir 128000 service-policy output CBWFQ56 frame-relay fragment 160 ! ! end pe0-ip3# ! ip vrf vx2000xx rd 5483:30 route-target export 5483:30 route-target import 5483:30 ! ! policy-map CBWFQ900 class voice priority 900 class class-default fair-queue random-detect ! interface Serial1/7:0 description Ceg Giro ip-vpn / xxxxxx / vx2000xx / VPN / ip vrf forwarding vn200038 ip address 10.2541521 255255255252 ! ! interface Serial3/2:1 description Ceg ivd / xxxxxx / vx2000xx / VPN / vrf-voice bandwidth 1920 ip vrf forwarding vn200038 ip address 10.25412161 255255255252 ip mtu 1460

service-policy output CBWFQ900 43 ! ! address-family ipv4 vrf vx2000xx redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! ip route vrf vn200038 192.16801 255255255255 Serial3/2:1 ip route vrf vn200038 192.1680100 255255255255 102541522 ip route vrf vn200038 192.1680101 255255255255 Serial3/2:1 ip route vrf vn200038 192.16810 2552552550 Serial3/2:1 ! map-class frame-relay voip56 frame-relay cir 128000 frame-relay mincir 128000 no frame-relay adaptive-shaping service-policy output CBWFQ56 frame-relay fragment 160 ! map-class frame-relay voip112 frame-relay cir 256000 frame-relay mincir 256000 no frame-relay adaptive-shaping service-policy output CBWFQ112 frame-relay fragment 320 ! map-class frame-relay voip224 frame-relay cir 512000 frame-relay mincir 512000 no frame-relay adaptive-shaping service-policy output CBWFQ224 frame-relay fragment 640 ! map-class frame-relay voip no frame-relay adaptive-shaping ! map-class frame-relay

voip224 frag160 frame-relay cir 512000 frame-relay mincir 512000 no frame-relay adaptive-shaping service-policy output CBWFQ224 frame-relay fragment 160 ! end Ceg Kozpont#sh har Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-DS-M), Version 12.2(7b), RELEASE SOFTWARE (fc1) Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Tue 05-Mar-02 06:35 by pwade Image text-base: 0x80008088, data-base: 0x8119B1B4 ROM: System Bootstrap, Version 12.1(3r)T2, RELEASE SOFTWARE (fc1) Ceg Kozpont uptime is 5 days, 4 hours, 41 minutes System returned to ROM by power-on 44 System restarted at 00:00:02 UTC Mon Mar 1 1993 System image file is "flash:c2600-ds-mz.122-7bbin" cisco 2620 (MPC860) processor (revision 0x600) with 43008K/6144K bytes of memory. Processor board ID JAD05490WDU (1894683226) M860 processor: part number 0, mask 49 Channelized E1, Version 1.0 Bridging software. X.25 software, Version 300 Primary Rate ISDN software, Version 1.1 1

FastEthernet/IEEE 802.3 interface(s) 32 Serial network interface(s) 1 Channelized E1/PRI port(s) 32K bytes of non-volatile configuration memory. 16384K bytes of processor board System flash (Read/Write) Configuration register is 0x2102 Ceg Kozpont# Current configuration : 11062 bytes ! ! No configuration change since last restart ! version 12.2 service pad to-xot service pad from-xot service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption ! hostname Ceg Kozpont ! logging buffered 4096 debugging enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ! voice-card 1 ! ip subnet-zero ip cef ! ! no ip domain-lookup ! class-map match-all voice match access-group 105 ! ! policy-map CBWFQ class voice priority 900 45 class class-default fair-queue random-detect ! ! x29 profile prb1 4:10 1:0 3:0 5:0 7:0 2:0 12:0 16:0 17:0 18:0 19:0 6:5 isdn switch-type primary-net5 x25 routing call rsvp-sync voice

call send-alert voice call convert-discpi-to-prog ! ! ! ! ! ! controller E1 1/0 pri-group timeslots 1-15 ! ! ! interface Loopback0 ip address 192.16801 255255255255 h323-gateway voip bind srcaddr 192.16801 ! interface Loopback1 ip address 192.1680101 255255255255 ! interface Tunnel0 description To Szekesfehervar no ip address tunnel source FastEthernet0/0 tunnel destination 192.16831 ! interface Tunnel1 description To Sopron no ip address tunnel source FastEthernet0/0 tunnel destination 192.16851 ! interface Tunnel2 description To Kecskemet no ip address tunnel source FastEthernet0/0 tunnel destination 192.16841 ! interface Tunnel3 description To Pecs no ip address tunnel source FastEthernet0/0 tunnel destination 192.16861 ! interface Tunnel4 description to Debrecen no ip address tunnel source FastEthernet0/0 tunnel destination 192.16821 ! interface FastEthernet0/0 46 ip address 192.16811 2552552550 duplex auto speed auto no cdp enable ! interface Serial0/0 bandwidth 960 ip

address 10.25412162 255255255252 ip mtu 1460 service-policy output CBWFQ no cdp enable ! interface Serial1/0:15 no ip address no logging event link-status isdn switch-type primary-net5 isdn overlap-receiving isdn incoming-voice voice isdn map address 0.* plan isdn type unknown isdn T310 60000 no cdp enable ! ip classless ip route 0.000 0000 Serial0/0 no ip http server ip pim bidir-enable ! logging source-interface Serial0/0.1 logging 192.1681148 logging 192.16813 access-list 60 permit 192.1681150 access-list 105 permit ip any any precedence critical no cdp run snmp-server community netcool RW snmp-server community mrkprovrw RW 60 snmp-server host 192.1681150 mrkprovrw snmp-server host 192.1681161 netcool ! ! ! x25 route 121212123. xot 1921680100 xot-source Loopback1 x25 route 210400006. xot 1921680100 xot-source Loopback1 x25 route 111 xot 192.1680100 xot-source Loopback1 x25 host giro 111 ! voice-port 1/0:15 cptone HU ! dial-peer cor custom ! ! ! dial-peer voice 120 voip

destination-pattern 120. session target ipv4:192.16802 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 130 voip destination-pattern 130. session target ipv4:192.16803 47 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 140 voip destination-pattern 140. session target ipv4:192.16804 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 150 voip destination-pattern 150. session target ipv4:192.16805 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 160 voip destination-pattern 160. session target ipv4:192.16806 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 4 pots destination-pattern 4. direct-inward-dial port 1/0:15 prefix 4 ! dial-peer voice 5 pots destination-pattern 5. direct-inward-dial port 1/0:15 prefix 5 ! dial-peer voice 620 pots destination-pattern 00620. direct-inward-dial port 1/0:15 prefix 00620 ! dial-peer voice 630 pots destination-pattern 00630. direct-inward-dial port 1/0:15 prefix 00630 ! dial-peer voice 670 pots destination-pattern

00670. direct-inward-dial port 1/0:15 prefix 00670 ! dial-peer voice 111 pots destination-pattern 000.T direct-inward-dial port 1/0:15 prefix 000 ! dial-peer voice 6 pots destination-pattern 006[1-9][1-9]. direct-inward-dial port 1/0:15 48 prefix 006 ! dial-peer voice 12 voip destination-pattern 12[1-9]. session target ipv4:192.16802 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 13 voip destination-pattern 13[1-9]. session target ipv4:192.16803 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 14 voip destination-pattern 14[1-9]. session target ipv4:192.16804 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 15 voip destination-pattern 15[1-9]. session target ipv4:192.16805 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 16 voip destination-pattern 16[1-9]. session target ipv4:192.16806 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 1 pots destination-pattern 0[1-9]. direct-inward-dial port 1/0:15 prefix 0 ! dial-peer voice 640 pots

destination-pattern 00640. direct-inward-dial port 1/0:15 prefix 00640 ! dial-peer voice 660 pots destination-pattern 00660. direct-inward-dial port 1/0:15 prefix 00660 ! dial-peer voice 31 voip destination-pattern 31[1-9]. session target ipv4:192.1680100 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 32 voip destination-pattern 32[1-9]. session target ipv4:192.1680200 dtmf-relay cisco-rtp ip precedence 5 49 ! ! line con 0 password 7 xxxxxxxxxxxxxxxx login line aux 0 buffer-length 1024 modem Dialin autocommand x28 profile prb1 transport input pad transport output pad stopbits 1 line vty 0 4 password 7 xxxxxxxxxxxxxxxx login ! end Ceg debrecen#sh ver Cisco Internetwork Operating System Software IOS (tm) C1700 Software (C1700-NO3SV3Y7-M), Version 12.2(8)YM, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Synched to technology version 12.2(112u)T TAC Support: http://www.ciscocom/tac Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Fri 23-Aug-02 05:27 by ealyon Image text-base:

0x80008124, data-base: 0x81191CE4 ROM: System Bootstrap, Version 12.2(1r)XE1, RELEASE SOFTWARE (fc1) ROM: C1700 Software (C1700-NO3SV3Y7-M), Version 12.2(8)YM, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Ceg debrecen uptime is 1 weeks, 19 hours, 46 minutes System returned to ROM by power-on System restarted at 09:00:49 UTC Fri Feb 19 1993 System image file is "flash:c1700-no3sv3y7-mz.122-8YMbin" cisco 1751 (MPC860P) processor (revision 0x200) with 55706K/9830K bytes of memory. Processor board ID JAD06370HOQ (3359064015), with hardware revision 0000 MPC860P processor: part number 5, mask 2 Bridging software. X.25 software, Version 300 Basic Rate ISDN software, Version 1.1 1 FastEthernet/IEEE 802.3 interface(s) 1 Serial(sync/async) network interface(s) 3 ISDN Basic Rate interface(s) 4 Voice NT or TE BRI interface(s) 32K bytes of non-volatile configuration memory. 32768K bytes of processor board System flash (Read/Write) Configuration register is 0x2102 Ceg debrecen# Current

configuration : 11209 bytes ! ! No configuration change since last restart 50 ! version 12.2 service pad to-xot service pad from-xot service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption ! hostname Ceg debrecen ! logging buffered 4096 debugging enable secret 5 $1$iY.U$qWjcv0oEdV92MXAoaD0Es/ ! memory-size iomem 15 tdm clock bri-auto ip subnet-zero ! ! no ip domain lookup ! ip cef ip audit notify log ip audit po max-events 100 ! class-map match-all voice match access-group 105 ! ! policy-map CBWFQ class voice priority 112 class class-default fair-queue random-detect ! ! x29 profile prb1 4:10 1:0 3:0 5:0 7:0 2:0 12:0 16:0 17:0 18:0 19:0 6:5 ! isdn switch-type basic-net3 x25 routing ! voice call send-alert voice call convert-discpi-to-prog voice call carrier capacity active ! ! ! ! ! ! ! ! ! ! ! ! interface Loopback0 ip address 192.16802 255255255255 h323-gateway voip bind srcaddr

192.16802 ! interface Tunnel0 51 no ip address tunnel source FastEthernet0/0 tunnel destination 192.16811 ! interface FastEthernet0/0 ip address 192.16821 2552552550 speed auto no cdp enable ! interface Serial0/0 description ----Voip 192k FR---bandwidth 192 no ip address encapsulation frame-relay frame-relay traffic-shaping ! interface Serial0/0.1 point-to-point bandwidth 192 ip address 10.25412190 255255255252 no cdp enable frame-relay interface-dlci 101 class voip ! interface BRI1/0 no ip address no ip mroute-cache shutdown isdn switch-type basic-net3 no cdp enable ! interface BRI2/0 no ip address no ip mroute-cache isdn switch-type basic-net3 isdn overlap-receiving isdn protocol-emulate network isdn layer1-emulate network isdn incoming-voice voice isdn static-tei 0 isdn skipsend-idverify ! interface BRI2/1 no ip address no ip mroute-cache isdn switch-type basic-net3 isdn overlap-receiving isdn protocol-emulate network isdn layer1-emulate network isdn incoming-voice voice isdn

static-tei 0 isdn skipsend-idverify ! ip classless ip route 0.000 0000 1025412189 no ip http server ip pim bidir-enable ! ! ! map-class frame-relay voip frame-relay cir 192000 52 frame-relay mincir 192000 service-policy output CBWFQ frame-relay fragment 160 logging source-interface Serial0/0.1 logging 192.1681148 logging 192.16813 access-list 60 permit 192.1681150 access-list 105 permit ip any any precedence critical access-list 800 permit ABCDEABF access-list 800 permit CCCBBBBB access-list 800 permit 555 access-list 800 deny FFFFFFFF no cdp run ! ! ! ! snmp-server community netcool RW snmp-server community mrkprovrw RW 60 snmp-server enable traps tty snmp-server host 192.1681150 mrkprovrw snmp-server host 192.1681161 netcool x25 route 121212123. xot 1921680100 xot-source Loopback0 x25 route 210400006. xot 1921680100 xot-source Loopback0 x25 route 111 xot 192.1680100 xot-source Loopback0 x25 host giro 111 call rsvp-sync ! voice-port 2/0 compand-type a-law cptone HU timeouts

call-disconnect 5 timeouts wait-release 5 ! voice-port 2/1 compand-type a-law cptone HU timeouts call-disconnect 5 timeouts wait-release 5 ! dial-peer cor custom ! ! ! dial-peer voice 4 voip destination-pattern 4. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 170 pots destination-pattern 17[1-9]. progress ind alert strip 2 direct-inward-dial port 2/0 ! dial-peer voice 171 pots destination-pattern 17[1-9]. progress ind alert strip 2 53 direct-inward-dial port 2/1 ! dial-peer voice 1700 pots destination-pattern 170. progress ind alert strip 2 direct-inward-dial port 2/0 prefix 0 ! dial-peer voice 1701 pots destination-pattern 170. progress ind alert strip 2 direct-inward-dial port 2/1 prefix 0 ! dial-peer voice 6 voip destination-pattern 006[1-9][1-9]. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer

voice 620 voip destination-pattern 00620. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 630 voip destination-pattern 00630. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 670 voip destination-pattern 00670. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 111 voip destination-pattern 000.T progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 1 voip destination-pattern 0[1-9]. progress ind setup enable 3 signaling forward none 54 session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 640 voip destination-pattern 00640. progress ind setup enable 3 signaling forward none session

target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 660 voip destination-pattern 00660. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 513 voip description * mellek: 5210-5239 destination-pattern 52[1-3]. progress ind setup enable 3 signaling forward none session target ipv4:192.16803 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 514 voip description * mellek: 5240-5269 destination-pattern 52[4-6]. progress ind setup enable 3 signaling forward none session target ipv4:192.16804 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 515 voip description * mellek: 5360-5389 destination-pattern 53[6-8]. progress ind setup enable 3 signaling forward none session target ipv4:192.16805 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 516 voip description * mellek: 5480-5499 destination-pattern 54[8-9]. progress ind setup enable 3

signaling forward none session target ipv4:192.16806 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 5161 voip description * mellek: 5500-5509 destination-pattern 550. progress ind setup enable 3 signaling forward none 55 session target ipv4:192.16806 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 50 pots description * mellek: 5150-5179 destination-pattern 51[5-7]. progress ind alert strip 2 direct-inward-dial port 2/0 prefix 51 ! dial-peer voice 501 pots description * mellek: 5150-5179 destination-pattern 51[5-7]. progress ind alert strip 2 direct-inward-dial port 2/1 prefix 51 ! ! line con 0 exec-timeout 0 0 line aux 0 buffer-length 1024 modem Dialin autocommand x28 profile prb1 transport input pad transport output pad stopbits 1 line vty 0 4 password 7 xxxxxxxxxxxxxxxx login ! end Ceg pecs#sh ver Cisco Internetwork Operating System Software IOS (tm) C1700 Software (C1700-NO3SV3Y7-M), Version 12.2(8)YM, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

Synched to technology version 12.2(112u)T TAC Support: http://www.ciscocom/tac Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Fri 23-Aug-02 05:27 by ealyon Image text-base: 0x80008124, data-base: 0x81191CE4 ROM: System Bootstrap, Version 12.1(5r)T1, RELEASE SOFTWARE (fc1) ROM: C1700 Software (C1700-NO3SV3Y7-M), Version 12.2(8)YM, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Ceg pecs uptime is 1 weeks, 6 days, 6 hours, 37 minutes System returned to ROM by power-on System restarted at 22:11:34 UTC Sat Nov 21 1992 System image file is "flash:c1700-no3sv3y7-mz.122-8YMbin" cisco 1751 (MPC860P) processor (revision 0x101) with 55706K/9830K bytes of memory. Processor board ID JAD0539083R (3938861686), with hardware revision 4246 MPC860P processor: part number 5, mask 2 Bridging software. X.25 software, Version 300 Basic Rate ISDN software, Version 1.1 56 1 FastEthernet/IEEE 802.3 interface(s) 1 Serial(sync/async) network interface(s) 2 ISDN Basic Rate interface(s) 4 Voice NT

or TE BRI interface(s) 32K bytes of non-volatile configuration memory. 32768K bytes of processor board System flash (Read/Write) Configuration register is 0x2102 Ceg pecs# Current configuration : 10950 bytes ! ! Last configuration change at 04:42:47 UTC Fri Mar 19 1993 ! NVRAM config last updated at 04:42:47 UTC Fri Mar 19 1993 ! version 12.2 service pad to-xot service pad from-xot service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption ! hostname Ceg pecs ! logging buffered 4096 debugging enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ! memory-size iomem 15 tdm clock bri-auto ip subnet-zero ! ! no ip domain lookup ! ip cef ip audit notify log ip audit po max-events 100 ! class-map match-all voice match access-group 105 ! ! policy-map CBWFQ class voice priority 56 class class-default fair-queue random-detect ! ! x29 profile prb1 4:10 1:0 3:0 5:0 7:0 2:0 12:0 16:0 17:0 18:0 19:0 6:5 !

isdn switch-type basic-net3 x25 routing ! voice call send-alert 57 voice call convert-discpi-to-prog voice call carrier capacity active ! ! ! ! ! ! ! ! ! ! ! ! interface Loopback0 ip address 192.16806 255255255255 h323-gateway voip bind srcaddr 192.16806 ! interface Tunnel0 no ip address tunnel source FastEthernet0/0 tunnel destination 192.16811 ! interface FastEthernet0/0 ip address 192.16861 2552552550 speed auto no cdp enable ! interface Serial0/0 description ----Voip 192k FR---bandwidth 192 no ip address encapsulation frame-relay frame-relay traffic-shaping ! interface Serial0/0.1 point-to-point bandwidth 192 ip address 10.25412230 255255255252 no cdp enable frame-relay interface-dlci 101 class voip ! interface BRI1/0 no ip address no ip mroute-cache isdn switch-type basic-net3 isdn overlap-receiving isdn protocol-emulate network isdn layer1-emulate network isdn incoming-voice voice isdn static-tei 0 isdn skipsend-idverify ! interface BRI1/1 no ip address no ip mroute-cache

isdn switch-type basic-net3 isdn overlap-receiving isdn protocol-emulate network isdn layer1-emulate network isdn incoming-voice voice 58 isdn static-tei 0 isdn skipsend-idverify ! ip classless ip route 0.000 0000 1025412229 no ip http server ip pim bidir-enable ! ! ! map-class frame-relay voip frame-relay cir 192000 frame-relay mincir 192000 service-policy output CBWFQ frame-relay fragment 160 logging source-interface Serial0/0.1 logging 192.1681148 logging 192.16813 access-list 60 permit 192.1681150 access-list 105 permit ip any any precedence critical access-list 800 permit ABCDEABF access-list 800 permit CCCBBBBB access-list 800 permit 555 access-list 800 deny FFFFFFFF no cdp run ! ! ! ! snmp-server community netcool RW snmp-server community mrkprovrw RW 60 snmp-server enable traps tty snmp-server host 192.1681150 mrkprovrw snmp-server host 192.1681161 netcool x25 route 121212123. xot 1921680100 xot-source Loopback0 x25 route 210400006. xot 1921680100 xot-source Loopback0 x25

route 111 xot 192.1680100 xot-source Loopback0 x25 host giro 111 call rsvp-sync ! voice-port 1/0 compand-type a-law cptone HU timeouts initial 1 timeouts call-disconnect 5 timeouts wait-release 5 ! voice-port 1/1 compand-type a-law cptone HU timeouts initial 1 timeouts call-disconnect 5 timeouts wait-release 5 ! dial-peer cor custom ! ! ! dial-peer voice 4 voip destination-pattern 4. progress ind setup enable 3 59 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 280 pots destination-pattern 28[1-9]. progress ind alert strip 2 direct-inward-dial port 1/0 ! dial-peer voice 281 pots destination-pattern 28[1-9]. progress ind alert strip 2 direct-inward-dial port 1/1 ! dial-peer voice 2800 pots destination-pattern 280. progress ind alert strip 2 direct-inward-dial port 1/0 prefix 0 ! dial-peer voice 2801 pots destination-pattern 280. progress ind alert strip 2 direct-inward-dial port 1/1 prefix 0 ! dial-peer voice 6 voip

destination-pattern 006[1-9][1-9]. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 620 voip destination-pattern 00620. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 630 voip destination-pattern 00630. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 670 voip destination-pattern 00670. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp 60 ip qos dscp cs5 media ! dial-peer voice 111 voip destination-pattern 000.T progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 1 voip destination-pattern 0[1-9]. progress ind setup enable 3 signaling forward none session target

ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 640 voip destination-pattern 00640. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 660 voip destination-pattern 00660. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 512 voip description * mellek: 5150-5179 destination-pattern 51[5-7]. progress ind setup enable 3 signaling forward none session target ipv4:192.16802 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 513 voip description * mellek: 5210-5239 destination-pattern 52[1-3]. progress ind setup enable 3 signaling forward none session target ipv4:192.16803 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 514 voip description * mellek: 5240-5269 destination-pattern 52[4-6]. progress ind setup enable 3 signaling forward none session target

ipv4:192.16804 dtmf-relay cisco-rtp ip qos dscp cs5 media ! 61 dial-peer voice 515 voip description * mellek: 5360-5389 destination-pattern 53[6-8]. progress ind setup enable 3 signaling forward none session target ipv4:192.16805 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 50 pots description * mellek: 5480-5499 destination-pattern 54[8-9]. progress ind alert strip 2 direct-inward-dial port 1/0 prefix 54 ! dial-peer voice 51 pots description * mellek: 5500-5509 destination-pattern 550. progress ind alert strip 2 direct-inward-dial port 1/0 prefix 55 ! ! line con 0 exec-timeout 0 0 line aux 0 buffer-length 1024 modem Dialin autocommand x28 profile prb1 transport input pad transport output pad stopbits 1 line vty 0 4 password 7 xxxxxxxxxxxxxxxx login ! end Ceg kecskemet#sh ver Cisco Internetwork Operating System Software IOS (tm) C1700 Software (C1700-NO3SV3Y7-M), Version 12.2(8)YM, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Synched to technology version 12.2(112u)T

TAC Support: http://www.ciscocom/tac Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Fri 23-Aug-02 05:27 by ealyon Image text-base: 0x80008124, data-base: 0x81191CE4 ROM: System Bootstrap, Version 12.1(5r)T1, RELEASE SOFTWARE (fc1) ROM: C1700 Software (C1700-NO3SV3Y7-M), Version 12.2(8)YM, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Ceg kecskemet uptime is 1 weeks, 5 days, 22 minutes System returned to ROM by power-on System restarted at 04:27:56 UTC Mon Nov 16 1992 System image file is "flash:c1700-no3sv3y7-mz.122-8YMbin" cisco 1751 (MPC860P) processor (revision 0x101) with 55706K/9830K bytes of memory. 62 Processor board ID JAD054700WR (1398336030), with hardware revision 4246 MPC860P processor: part number 5, mask 2 Bridging software. X.25 software, Version 300 Basic Rate ISDN software, Version 1.1 1 FastEthernet/IEEE 802.3 interface(s) 1 Serial(sync/async) network interface(s) 2 ISDN Basic Rate interface(s) 4 Voice NT or TE BRI interface(s) 32K bytes of

non-volatile configuration memory. 32768K bytes of processor board System flash (Read/Write) Configuration register is 0x2102 Ceg kecskemet# Current configuration : 10964 bytes ! ! Last configuration change at 03:04:17 UTC Sun Mar 21 1993 ! NVRAM config last updated at 04:41:05 UTC Fri Mar 19 1993 ! version 12.2 service pad to-xot service pad from-xot service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption ! hostname Ceg kecskemet ! logging buffered 4096 debugging enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ! memory-size iomem 15 tdm clock bri-auto ip subnet-zero ! ! no ip domain lookup ! ip audit notify log ip audit po max-events 100 ! class-map match-all voice match access-group 105 ! ! policy-map CBWFQ class voice priority 112 class class-default fair-queue random-detect ! ! x29 profile prb1 4:10 1:0 3:0 5:0 7:0 2:0 12:0 16:0 17:0 18:0 19:0 6:5 ! 63 isdn switch-type basic-net3

x25 routing ! voice call send-alert voice call convert-discpi-to-prog voice call carrier capacity active ! ! ! ! ! ! ! ! ! ! ! ! interface Loopback0 ip address 192.16804 255255255255 h323-gateway voip bind srcaddr 192.16804 ! interface Tunnel0 no ip address tunnel source FastEthernet0/0 tunnel destination 192.16811 ! interface FastEthernet0/0 ip address 192.16841 2552552550 speed auto no cdp enable ! interface Serial0/0 description ----Voip 192k FR---bandwidth 192 no ip address encapsulation frame-relay frame-relay traffic-shaping ! interface Serial0/0.1 point-to-point bandwidth 128 ip address 10.25412198 255255255252 no cdp enable frame-relay interface-dlci 101 class voip ! interface BRI1/0 no ip address no ip mroute-cache isdn switch-type basic-net3 isdn overlap-receiving isdn protocol-emulate network isdn layer1-emulate network isdn incoming-voice voice isdn static-tei 0 isdn skipsend-idverify ! interface BRI1/1 no ip address no ip mroute-cache isdn switch-type basic-net3 64

isdn overlap-receiving isdn protocol-emulate network isdn layer1-emulate network isdn incoming-voice voice isdn static-tei 0 isdn skipsend-idverify ! ip classless ip route 0.000 0000 1025412197 no ip http server ip pim bidir-enable ! ! ! map-class frame-relay voip frame-relay cir 192000 frame-relay mincir 192000 frame-relay fair-queue frame-relay fragment 160 logging source-interface Serial0/0.1 logging 192.1681148 logging 192.16813 access-list 60 permit 192.1681150 access-list 105 permit ip any any precedence critical access-list 800 permit ABCDEABF access-list 800 permit CCCBBBBB access-list 800 permit 555 access-list 800 deny FFFFFFFF no cdp run ! ! ! ! snmp-server community netcool RW snmp-server community mrkprovrw RW 60 snmp-server enable traps tty snmp-server host 192.1681150 mrkprovrw snmp-server host 192.1681161 netcool x25 route 121212123. xot 1921680100 xot-source Loopback0 x25 route 210400006. xot 1921680100 xot-source Loopback0 x25 route 111 xot 192.1680100 xot-source

Loopback0 x25 host giro 111 call rsvp-sync ! voice-port 1/0 compand-type a-law cptone HU timeouts call-disconnect 5 timeouts wait-release 5 ! voice-port 1/1 compand-type a-law cptone HU timeouts call-disconnect 5 timeouts wait-release 5 ! dial-peer cor custom ! ! ! dial-peer voice 4 voip 65 destination-pattern 4. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 200 pots destination-pattern 20[1-9]. progress ind alert strip 2 direct-inward-dial port 1/0 ! dial-peer voice 201 pots destination-pattern 20[1-9]. progress ind alert strip 2 direct-inward-dial port 1/1 ! dial-peer voice 2000 pots destination-pattern 200. progress ind alert strip 2 direct-inward-dial port 1/0 prefix 0 ! dial-peer voice 2001 pots destination-pattern 200. progress ind alert strip 2 direct-inward-dial port 1/1 prefix 0 ! dial-peer voice 6 voip destination-pattern 006[1-9][1-9]. progress ind setup enable 3 signaling

forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 620 voip destination-pattern 00620. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 630 voip destination-pattern 00630. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 670 voip destination-pattern 00670. progress ind setup enable 3 signaling forward none 66 session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 111 voip destination-pattern 000.T progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 1 voip destination-pattern 0[1-9]. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice

640 voip destination-pattern 00640. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 660 voip destination-pattern 00660. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 512 voip description * mellek: 5150-5179 destination-pattern 51[5-7]. progress ind setup enable 3 signaling forward none session target ipv4:192.16802 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 513 voip description * mellek: 5210-5239 destination-pattern 52[1-3]. progress ind setup enable 3 signaling forward none session target ipv4:192.16803 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 515 voip description * mellek: 5360-5389 destination-pattern 53[6-8]. progress ind setup enable 3 signaling forward none session target ipv4:192.16805 dtmf-relay cisco-rtp 67 ip qos dscp cs5 media ! dial-peer

voice 516 voip description * mellek: 5480-5499 destination-pattern 54[8-9]. progress ind setup enable 3 signaling forward none session target ipv4:192.16806 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 5161 voip description * mellek: 5500-5509 destination-pattern 550. progress ind setup enable 3 signaling forward none session target ipv4:192.16806 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 50 pots description * mellek: 5240-5269 destination-pattern 52[4-6]. progress ind alert strip 2 direct-inward-dial port 1/0 prefix 52 ! ! line con 0 exec-timeout 0 0 line aux 0 buffer-length 1024 modem Dialin autocommand x28 profile prb1 transport input pad transport output pad stopbits 1 line vty 0 4 password 7 xxxxxxxxxxxxxxxx login ! end Ceg sopron#sh ver Cisco Internetwork Operating System Software IOS (tm) C1700 Software (C1700-NO3SV3Y7-M), Version 12.2(8)YM, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Synched to technology version 12.2(112u)T TAC Support:

http://www.ciscocom/tac Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Fri 23-Aug-02 05:27 by ealyon Image text-base: 0x80008124, data-base: 0x81191CE4 ROM: System Bootstrap, Version 12.1(5r)T1, RELEASE SOFTWARE (fc1) ROM: C1700 Software (C1700-NO3SV3Y7-M), Version 12.2(8)YM, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Ceg sopron uptime is 1 weeks, 9 hours, 14 minutes System returned to ROM by power-on System restarted at 19:29:48 UTC Fri Feb 5 1993 68 System image file is "flash:c1700-no3sv3y7-mz.122-8YMbin" cisco 1751 (MPC860P) processor (revision 0x200) with 55706K/9830K bytes of memory. Processor board ID JAD05480MBS (3164801934), with hardware revision 1187 MPC860P processor: part number 5, mask 2 Bridging software. X.25 software, Version 300 Basic Rate ISDN software, Version 1.1 1 FastEthernet/IEEE 802.3 interface(s) 1 Serial(sync/async) network interface(s) 2 ISDN Basic Rate interface(s) 4 Voice NT or TE BRI interface(s) 32K bytes of non-volatile

configuration memory. 32768K bytes of processor board System flash (Read/Write) Configuration register is 0x2102 Ceg sopron# Current configuration : 10959 bytes ! ! Last configuration change at 04:41:56 UTC Fri Mar 19 1993 ! NVRAM config last updated at 04:41:56 UTC Fri Mar 19 1993 ! version 12.2 service pad to-xot service pad from-xot service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption ! hostname Ceg sopron ! logging buffered 4096 debugging enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ! memory-size iomem 15 tdm clock bri-auto ip subnet-zero ! ! no ip domain lookup ! ip cef ip audit notify log ip audit po max-events 100 ! class-map match-all voice match access-group 105 ! ! policy-map CBWFQ class voice priority 56 class class-default fair-queue random-detect 69 ! ! x29 profile prb1 4:10 1:0 3:0 5:0 7:0 2:0 12:0 16:0 17:0 18:0 19:0 6:5 ! isdn switch-type basic-net3 x25 routing

! voice call send-alert voice call convert-discpi-to-prog voice call carrier capacity active ! ! ! ! ! ! ! ! ! ! ! ! interface Loopback0 ip address 192.16805 255255255255 h323-gateway voip bind srcaddr 192.16805 ! interface Tunnel0 no ip address tunnel source FastEthernet0/0 tunnel destination 192.16811 ! interface FastEthernet0/0 ip address 192.16851 2552552550 speed auto no cdp enable ! interface Serial0/0 description ----Voip 192k FR---bandwidth 192 no ip address encapsulation frame-relay frame-relay traffic-shaping ! interface Serial0/0.1 point-to-point bandwidth 192 ip address 10.25412214 255255255252 no cdp enable frame-relay interface-dlci 101 class voip ! interface BRI1/0 no ip address no ip mroute-cache isdn switch-type basic-net3 isdn overlap-receiving isdn protocol-emulate network isdn layer1-emulate network isdn incoming-voice voice isdn static-tei 0 isdn skipsend-idverify ! 70 interface BRI1/1 no ip address no ip mroute-cache shutdown isdn switch-type basic-net3 isdn

overlap-receiving isdn protocol-emulate network isdn layer1-emulate network isdn static-tei 0 isdn skipsend-idverify ! ip classless ip route 0.000 0000 1025412213 no ip http server ip pim bidir-enable ! ! ! map-class frame-relay voip frame-relay cir 128000 frame-relay mincir 128000 service-policy output CBWFQ frame-relay fragment 160 logging source-interface Serial0/0.1 logging 192.1681148 logging 192.16813 access-list 60 permit 192.1681150 access-list 105 permit ip any any precedence critical access-list 800 permit ABCDEABF access-list 800 permit CCCBBBBB access-list 800 permit 555 access-list 800 deny FFFFFFFF no cdp run ! ! ! ! snmp-server community netcool RW snmp-server community mrkprovrw RW 60 snmp-server enable traps tty snmp-server host 192.1681150 mrkprovrw snmp-server host 192.1681161 netcool x25 route 121212123. xot 1921680100 xot-source Loopback0 x25 route 210400006. xot 1921680100 xot-source Loopback0 x25 route 111 xot 192.1680100 xot-source Loopback0 x25 host giro 111

call rsvp-sync ! voice-port 1/0 compand-type a-law cptone HU timeouts call-disconnect 5 timeouts wait-release 5 ! voice-port 1/1 compand-type a-law cptone HU timeouts call-disconnect 5 timeouts wait-release 5 ! dial-peer cor custom 71 ! ! ! dial-peer voice 4 voip destination-pattern 4. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 240 pots destination-pattern 24[1-9]. progress ind alert strip 2 direct-inward-dial port 1/0 ! dial-peer voice 241 pots destination-pattern 24[1-9]. progress ind alert strip 2 direct-inward-dial port 1/1 ! dial-peer voice 2400 pots destination-pattern 240. progress ind alert strip 2 direct-inward-dial port 1/0 prefix 0 ! dial-peer voice 2401 pots destination-pattern 240. progress ind alert strip 2 direct-inward-dial port 1/1 prefix 0 ! dial-peer voice 6 voip destination-pattern 006[1-9][1-9]. progress ind setup enable 3 signaling forward none session target

ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 620 voip destination-pattern 00620. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 630 voip destination-pattern 00630. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! 72 dial-peer voice 670 voip destination-pattern 00670. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 111 voip destination-pattern 000.T progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 1 voip destination-pattern 0[1-9]. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 640 voip destination-pattern

00640. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 660 voip destination-pattern 00660. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 512 voip description * mellek: 5150-5179 destination-pattern 51[5-7]. progress ind setup enable 3 signaling forward none session target ipv4:192.16802 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 513 voip description * mellek: 5210-5239 destination-pattern 52[1-3]. progress ind setup enable 3 signaling forward none session target ipv4:192.16803 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 514 voip description * mellek: 5240-5269 destination-pattern 52[4-6]. 73 progress ind setup enable 3 signaling forward none session target ipv4:192.16804 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 516 voip description *

mellek: 5480-5499 destination-pattern 54[8-9]. progress ind setup enable 3 signaling forward none session target ipv4:192.16806 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 5161 voip description * mellek: 5500-5509 destination-pattern 550. progress ind setup enable 3 signaling forward none session target ipv4:192.16806 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 50 pots description * mellek: 5360-5389 destination-pattern 53[6-8]. progress ind alert strip 2 direct-inward-dial port 1/0 prefix 53 ! ! line con 0 exec-timeout 0 0 line aux 0 buffer-length 1024 modem Dialin autocommand x28 profile prb1 transport input pad transport output pad stopbits 1 line vty 0 4 password 7 xxxxxxxxxxxxxxxx login ! end Ceg szfvar#sh ver Cisco Internetwork Operating System Software IOS (tm) C1700 Software (C1700-NO3SV3Y7-M), Version 12.2(8)YM, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Synched to technology version 12.2(112u)T TAC Support: http://www.ciscocom/tac Copyright

(c) 1986-2002 by cisco Systems, Inc. Compiled Fri 23-Aug-02 05:27 by ealyon Image text-base: 0x80008124, data-base: 0x81191CE4 ROM: System Bootstrap, Version 12.1(5r)T1, RELEASE SOFTWARE (fc1) ROM: C1700 Software (C1700-NO3SV3Y7-M), Version 12.2(8)YM, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) 74 Ceg szfvar uptime is 1 weeks, 5 hours, 6 minutes System returned to ROM by power-on System restarted at 23:45:47 UTC Fri Nov 27 1992 System image file is "flash:c1700-no3sv3y7-mz.122-8YMbin" cisco 1751 (MPC860P) processor (revision 0x200) with 55706K/9830K bytes of memory. Processor board ID JAD0548033P (4159161245), with hardware revision 1187 MPC860P processor: part number 5, mask 2 Bridging software. X.25 software, Version 300 Basic Rate ISDN software, Version 1.1 1 FastEthernet/IEEE 802.3 interface(s) 1 Serial(sync/async) network interface(s) 2 ISDN Basic Rate interface(s) 4 Voice NT or TE BRI interface(s) 32K bytes of non-volatile configuration memory. 32768K bytes of

processor board System flash (Read/Write) Configuration register is 0x2101 Ceg szfvar# Current configuration : 11053 bytes ! ! Last configuration change at 04:40:53 UTC Fri Mar 19 1993 ! NVRAM config last updated at 04:40:53 UTC Fri Mar 19 1993 ! version 12.2 service pad to-xot service pad from-xot service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption ! hostname Ceg szfvar ! logging buffered 4096 debugging enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ! memory-size iomem 15 tdm clock bri-auto ip subnet-zero ! ! no ip domain lookup ! ip cef ip audit notify log ip audit po max-events 100 ! class-map match-all voice match access-group 105 ! ! policy-map CBWFQ class voice priority 56 class class-default fair-queue random-detect ! 75 ! x29 profile prb1 4:10 1:0 3:0 5:0 7:0 2:0 12:0 16:0 17:0 18:0 19:0 6:5 ! isdn switch-type basic-net3 x25 routing ! voice call send-alert voice call

convert-discpi-to-prog voice call carrier capacity active voice rtp send-recv ! ! ! ! ! ! ! ! ! ! ! ! interface Loopback0 ip address 192.16803 255255255255 h323-gateway voip bind srcaddr 192.16803 ! interface Tunnel0 no ip address tunnel source FastEthernet0/0 tunnel destination 192.16811 ! interface FastEthernet0/0 ip address 192.16831 2552552550 speed auto no cdp enable ! interface Serial0/0 description ----Voip 192k FR---bandwidth 192 no ip address encapsulation frame-relay frame-relay traffic-shaping ! interface Serial0/0.1 point-to-point bandwidth 192 ip address 10.25412166 255255255252 no cdp enable frame-relay interface-dlci 101 class voip frame-relay ip rtp header-compression ! interface BRI1/0 no ip address no ip mroute-cache isdn switch-type basic-net3 isdn overlap-receiving isdn protocol-emulate network isdn layer1-emulate network isdn incoming-voice voice isdn static-tei 0 isdn skipsend-idverify 76 ! interface BRI1/1 no ip address no ip mroute-cache isdn switch-type

basic-net3 isdn overlap-receiving isdn protocol-emulate network isdn layer1-emulate network isdn incoming-voice voice isdn static-tei 0 isdn skipsend-idverify ! ip classless ip route 0.000 0000 1025412165 no ip http server ip pim bidir-enable ! ! ! map-class frame-relay voip frame-relay cir 192000 frame-relay mincir 192000 service-policy output CBWFQ frame-relay fragment 160 logging source-interface Serial0/0.1 logging 192.1681148 logging 192.16813 access-list 60 permit 192.1681150 access-list 105 permit ip any any precedence critical access-list 800 permit ABCDEABF access-list 800 permit CCCBBBBB access-list 800 permit 555 access-list 800 deny FFFFFFFF no cdp run ! ! ! ! snmp-server community netcool RW snmp-server community mrkprovrw RW 60 snmp-server enable traps tty snmp-server host 192.1681150 mrkprovrw snmp-server host 192.1681161 netcool x25 route 121212123. xot 1921680100 xot-source Loopback0 x25 route 210400006. xot 1921680100 xot-source Loopback0 x25 route 111 xot

192.1680100 xot-source Loopback0 x25 host giro 111 call rsvp-sync ! voice-port 1/0 compand-type a-law cptone HU timeouts call-disconnect 5 timeouts wait-release 5 ! voice-port 1/1 compand-type a-law cptone HU timeouts call-disconnect 5 timeouts wait-release 5 ! 77 dial-peer cor custom ! ! ! dial-peer voice 4 voip destination-pattern 4. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 190 pots destination-pattern 19[1-9]. progress ind alert strip 2 direct-inward-dial port 1/0 ! dial-peer voice 191 pots destination-pattern 19[1-9]. progress ind alert strip 2 direct-inward-dial port 1/1 ! dial-peer voice 1900 pots destination-pattern 190. progress ind alert strip 2 direct-inward-dial port 1/0 prefix 0 ! dial-peer voice 1901 pots destination-pattern 190. progress ind alert strip 2 direct-inward-dial port 1/1 prefix 0 ! dial-peer voice 6 voip destination-pattern 006[1-9][1-9]. progress ind

setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 620 voip destination-pattern 00620. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 630 voip destination-pattern 00630. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media 78 ! dial-peer voice 670 voip destination-pattern 00670. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 111 voip destination-pattern 000.T progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 1 voip destination-pattern 0[1-9]. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5

media ! dial-peer voice 640 voip destination-pattern 00640. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 660 voip destination-pattern 00660. progress ind setup enable 3 signaling forward none session target ipv4:192.16801 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 50 pots description * mellek: 5210-5239 destination-pattern 52[1-3]. progress ind alert strip 2 direct-inward-dial port 1/0 prefix 52 ! dial-peer voice 512 voip description * mellek: 5150-5179 destination-pattern 51[5-7]. progress ind setup enable 3 signaling forward none session target ipv4:192.16802 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 514 voip description * mellek: 5240-5269 destination-pattern 52[4-6]. 79 progress ind setup enable 3 signaling forward none session target ipv4:192.16804 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 515 voip description * mellek:

5360-5389 destination-pattern 53[6-8]. progress ind setup enable 3 signaling forward none session target ipv4:192.16805 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 516 voip description * mellek: 5480-5499 destination-pattern 54[8-9]. progress ind setup enable 3 signaling forward none session target ipv4:192.16806 dtmf-relay cisco-rtp ip qos dscp cs5 media ! dial-peer voice 5161 voip description * mellek: 5500-5509 destination-pattern 550. progress ind setup enable 3 signaling forward none session target ipv4:192.16806 dtmf-relay cisco-rtp ip qos dscp cs5 media ! ! line con 0 exec-timeout 0 0 line aux 0 buffer-length 1024 modem Dialin autocommand x28 profile prb1 transport input pad transport output pad stopbits 1 line vty 0 4 password 7 xxxxxxxxxxxxxxxx login ! end 80