2.1 Egy VoIP kapcsolat létesítésének szükséges lépései:

1. Analóg hang átalakítása ADC segítségével digitális formára (bitsorozat)
2. A kapott bitsorozat tömörítése az átvitel meggyorsítására (erre számos szabvány biztosít lehetõséget)
3. A tömörített, digitalizált hang adatcsomagokra való bontása és küldése valamilyen un. valós idejû protokoll (real-time protocol) használatával. ( pl. RTP UDP-n vagy IP-n keresztül)
4. Signaling protocol használatával kapcsolatot teremtünk a hívni kívánt felhasználóval ( pl. ITU-T H323)
5. A célgépen össze kell fûznünk az átküldött, csomagokra darabolt digitalizált jelet, ki kell tömörítenünk, majd a hangkártyának vagy telefonnak átadva analóg formára kell alakítanunk.
6. Mindennek valós idõben, idegesítõ várakozáaokat elkerülve kell történnie. (QoS fejezet)

Hang )) ADC Tömörítés RTP csomaküldés TCP/IP vagy UDP/IP-vel Csomagok Összeállítás RTP TCP/IP vagy UDP-bõl Kitömörítés DAC (( Hang

2.2 Analóg-Digitál jelátalakítás

Ez hardware-es úton történik, általában hangkártyába integrált ADC-vel. Manapság minden hangkártya lehetõséget biztosít 16 bites jel 22050 Hz-en történõ mintavételezésre ( a mintavételezés frekvenciájának 22050 Hz-nél Nyquist törvénye alapján 44100 Hz kell legyen, hogy a mintavételezett jelbõl vissza lehesse állítani az eredeti jelet). Ezek következtében az így kapott jel átviteléhez 2 byte * 44100 (minta/sec) = 88200 Bytes/s, vagyis176.4 kBytes/s átviteli sebességre van szükség (ez a stereo hang átviteli igénye). A VoIP alkalmazások használatánál legtöbb esetben ez a sávszélesség nem elérhetõ, de nem is cél annak használata. A szükséges sávszélesség csökkentésére tömörítési algoritmusokat illetve kodekeket használunk.

2.3 Tömörítési algoritmusok

A digitalizált jel átvitel elõtti méretcsökkentésére szolgáló eljárások.
Az alábbiakban néhány megoldást tekintünk át.

PCM, Pulse Code Modulation, ITU-T G.711 szabvány:
Mivel a hang frekvenciatartománya 4 kHz, a mintavételezés tartományának 8 kHz-esnek
   kell lennie (Nyquist törvénye).
1 mintát 8 biten reprezentálunk (256 lehetséges érték).
Átvitel: 8000 Hz *8 bit = 64 kbit/s, hagyományos digitális telefonvonal.

ADPCM, Adaptive differential PCM, ITU-T G.726 szabvány:
Az aktuális és az elõzõ hangcsomag közötti különbséget konvertálja (sávszélességigény 32 kbits/sec).

További gyakran használt szabványok:
LD-CELP, ITU-T G.728 szabvány
CS-ACELP, ITU-T G.729 és G.729a szabvány
MP-MLQ, ITU-T G.723.1 szabvány, 6.3kbps, Truespeech
ACELP, ITU-T G.723.1 szabvány, 5.3kbps, Truespeech
LPC-10, akár 2.5 kbps-ot is elérhet!!

A fentiekben felsorolt szabványok közül a legfontosabb a legutolsó, mivel ezt alkalmazva a minimális sávszélesség igény következtében közelebb kerülünk a VoIp-hez kapcsolódó probléma megoldásához.

Mivel a sávszélesség az interneten egy értékes készlet, a fejlesztõk mindent megtesznek annak érdekében, hogy a hangot a legoptimálisabban tömörítsék. Többfajta eljárás létezik, a takarékos, 16 kbit-es ADPCM (Adaptiv Differential PCM) és az inteligens, 8 kbit-es CELP (Codebook Excited Linear Prediction) eljárás.
Sajnos tudnunk kell, hogy minél kissebb a codec értéke, annál bonyolultabb a kodolás folyamata és nagyobb a késleltetés (delay).

A gyakorlatban a G.729A terjedt el a legjobban, mely még jó hangminõség mellett is csak a G.711-es codec-nek az 1/8 részét teszi ki.
A digitális kódolás segítségével az analog beszédhang másodpercenként 8000-szer van "lehalhatva" és adatok formájában rögzítve. Ez 8 bit/sec. esetén (8000x8 bit) 64 kbit/sec. Ez a PCM (Pulse Code Modulation) szerint G.711 ITU standardnak felel meg. A sávszélesség csökkentése érdekében további tömörítési algoritmusokat vezettek be és további kódolási standardokat fogadtak el. Ilyen pl. a G. 723.1, G.728 vagy a G.729, ami már 1/10-re csökkenti az igényelt sávszélességet. Ugyanakkor a Silence Suppression eljárás (a csend elnyomása) további 60%-al csökkenti ezeket az értékeket. A Silence Suppression alkalmazása lehetõvé teszi, hogy azokban az idõszakaszokban mikor nincs beszélgetés, ne történjen adatrögzítés.

A legújabb ITU standard a G.723.1-et a MP-MLQ eljárással 64 kbit/sec.-ról 6,4 kbit/sec.-ra csökkenti le, amihez még csak egy Overhead jön, így ennek összértéke 15,9 kbit/sec. A Silence Suppression ezt az értéket is még tovább csökkenti. A G.929 standard a CS-ACELP algoritmussal már kimondottan kis 8 kbit/sec. sávszélességet igér és felhasználására ott kerül, ahol a hálózati sávszélesség nagyon korlátozott.
Az Overhead az adatcsomagokhoz tartozó információt tartalmazza és sok esetben nagyobb is lehet, mint maga a digitalizát és tömörített hang. A header nagysága csomagonként 368 bit, ami 100 pps esetén 36,8 kbit/s-et jelent. Ez a G.729A codec-hez viszonyítva óriási, de a header tömörítéssel ez csomagonként 72 bitre, azaz 7,2 kbit/s-ra csökkenthetõ.

Az IntTalk által alkalmazokk kodekek:

GSM 6.10
G.711 A
G.711 U
iLBC

2.4 RTP - Valósidejû átviteli protokoll (Real Time Transport Protocol)

A hang digitalizálását és tömörítését követõ feladat az csomagok átküldése.

A VoIP adatcsomagok átküldésére nem használhatjuk kellõ hatékonysággal a TCP/IP protokollt, mivel a TCP/IP túlságosan körülményes valósidejû alkalmazásokkal való munka esetén. Helyette az UDP/IP (datagram) protokollt kell használnunk.
További probléma, hogy az UDP nem viszont nem rendelkezik irányítással az adatcsomagok érkezési sorrendje illetve átviteli ideje felett (datagram concept). Mindkét elõbb említett eset nagyon fontos, mivel mindkettõ az adatcsomagok összekeveredését eredményezheti, ami az átvitt hangot érthetetlenné tenné.

Az RTP a fogadott csomagok sorrendjének helyreállítását lehetõvé téve megoldja ezt a problémát. Ezáltal nem kell várakozni, továbbá ha egy csomag túl sokára érkezne meg vagy elveszne, lehetõség van a 1-1 csomag kihagyására (az úgysem vehetõ észre) és a fõ feladat (az adatcsomagok folyamatos és helyes sorrendû biztosítása) meg lesz oldva.

Az említett problémák kezelésére az IntTalk rendelkezik u.n. 'LAG Remover' mechanizmussal.

2.5 Szolgáltatás minõsége - Quality of Service (QoS)

Már említettük, hogy a VoIP alkalmazások esetén valósidejû adatfolyamra van szükség, mivel a hangátvitelnek interaktívnak kell lennie.
Sajnos a TCP/IP ezt nem biztosítja, így más megközelítésre, eljárásra, apróbb trükkökre van szükség az adatcsomagok folyamatos átjátszására. (ezen trükköket az átjátszást végzõ routereken kell megvalósítanunk):

1. A TOS mezõ (field) az IP protokollban a szolgáltatás fajtáját írja le: magas értékek alacsony sürgõsségi fokozatot jelöl, amíg az értékek fokozatos csökkentésével egyre közelebb hozzák a valósidejû átvitelt.

2. Csomagok sorbaállításának módszerei (Queuing packets methods):
     2.1. FIFO (First in First Out), a legprimitívebb eljárás, melynek lényege, hogy
         a csomagokat érkezési sorrendjükben kerülnek átjátszásra
     2.2. WFQ (Weighted Fair Queuing)
     2.3. CQ (Custom Queuing), a prioritást a user határozza meg.
     2.4. PQ (Priority Queuing
     2.5. CB-WFQ (Class Based Weighted Fair Queuing

3. Shaping capability

4. Torlódásfeloldás (Congestion Avoidance, mint pl. a RED (Random Early Detection)).

2.6 H323 Signaling Protokoll

H323 protokoll számos alkalmazásnál megtalálható, melynek célja a hangkapcsolat létesítése.

Ez a protokoll különbözõ elemek közötti beszélgetést tesz lehetõvé: Terminálok, kliensek akik VoIP kapcsolatot létesítenek.

További fontos elemek:

1. Gatekeeper-ek, melyek legfontosabb funkciói:
     1.1. address translation service, hogy IP címek helyett neveket használhassunk
     1.2. admission control (belépés ellenõrzés), userek és hostok engedélyezése vagy letiltása
     1.3. sávszélesség irányítása (bandwidth management)

2. Gateway-ek (átjárók), TCP/IP - PSTN közötti átjárhatóság megvalósítására.

3. Multipoint Control Units (MCUs) konferenciakapcsolat létesítésére.

4. Proxies szerverek

A H323 nem csak VoIP, hanem általános adat vagy videókommunikációt is lehetõvé tesz. VoIP-ra vonatkozóan, a h323 a G.711, G.722, G.723, G.728 és G.729 audió kodekeket használva képes átvitelre, míg videókapcsolat esetén a h261 és h263 használandó.