KANDÓ KÁLMÁN VILLAMOSMÉRNÖKI KAR HÍRADÁSTECHNIKA INTÉZET Infokommunikációs Hálózatok laboratóriumi mérési útmutató VoIP hálózati forgalom vizsgálata
Tartalomjegyzék VoIP forgalom vizsgálata a Wireshark hálózatelemző programmal... 2 IP alapú hangátvitel... 2 SIP Session Initiation Protocol... 10 Request típusú üzenetek... 12 Response típusú üzenetek... 12 SIP hívás felépítés és bontás folyamata... 13 RTP és RTCP... 15 RTP Real-time Transport Protocol... 15 Mérési feladatok... 18 VoIP forgalom vizsgálata a Wireshark hálózatelemző programmal A csomagkapcsolt hálózatokat elsősorban adatok továbbítására találták ki, és fejlesztették, ezért működésük elsősorban a best effort jellegű adatforgalomhoz illeszkedik. Ez azt feltételezi, hogy az adatok továbbítására nincsenek különösebb elvárásaink, a szolgáltatásminőség (QoS) nem elsődleges szempont. Az egyre nagyobb kapacitású és teljesítőképességű hálózat csábítóan hat, hogy valós idejű multimédiás tartalmakat is küldjünk rajta, illetve töltsünk le magunknak, azonban ehhez több ponton is szükséges volt a hálózatokat módosítani. Megjelentek a csomagok továbbítási módját befolyásolni képes módszerek, megszületett a Traffic Engineering, előtérbe kerültek a kis késleltetésű, UDP-re támaszkodó protokollok. A mérés célja megismertetni a hallgatókat a legnépszerűbb VoIP (Voice over IP) jelzésprotokoll, a SIP (Session Initiation Protocol) működésével. IP alapú hangátvitel Amíg a multimédiás tartalom lejátszás nem valós időben történik, addig nincs is igazán nagy probléma. A sikeres tartalom letöltést követően gond nélkül lejátszhatjuk azokat. Itt meg kell állnunk egy pillanatra, és tisztáznunk kell azt, hogy mit értünk valós időben történő lejátszásnak! Jelen esetben egy csomagokra bontott digitális jelfolyam vételéről van
szó, ahol az egyes információ egységek a csomagkapcsolt hálózaton a továbbítás közben sérülhetnek, valamint különböző késleltetést szenvedhetnek el. Előfordulhat olyan helyzet is, hogy a változó késleltetések és természetesen a más útvonal miatt a vétel helyén a csomagok sorrendje felcserélődik. A fenti okokból egyértelműen látszik, hogy igazi valós idejű adattovábbítás az IP hálózatokban nem valósulhat meg, csak a felhasználó számára tűnhet annak. A multimédiás tartalom letöltése közben történő lejátszást mégis sok esetben valós idejű lejátszásnak nevezzük, holott az csak egy bizonyos késleltetéssel történik. A letöltött tartalomtól függően a késleltetési idővel kapcsolatosan elvárásokat, konkrétan késleltetési idő maximumokat határozunk meg. A multimédiás adatátvitel minőségét természetesen több tényező együttese határozza meg. A hozzáférhető szolgáltatásokat úgynevezett minőségi mutatókkal jellemzik. A jellemzés egyértelművé tétele érdekében QoS kategóriákat definiáltak. A végfelhasználó multimédia QoS kategóriákat az ITU-T G.1010 ajánlás definiálja, mely a végfelhasználó (előfizető) szemszögéből nyolc különböző kategóriát jelent. A kategória meghatározás az információ felhasználási helyén előálló adatvesztés és az erre vonatkozó tolerancia, valamint a késleltetési idő alapján történik. A QoS kategóriák meghatározásánál az ajánlásban az alábbi átviteltechnikai kulcsparaméterek meghatározása történt: Késleltetés (Delay); Késleltetés változás (Delay variation); Információvesztés (Information loss); A késleltetés fogalom alatt definíciószerűen azt az időt értjük, mely a szolgáltatás igénybevétele során a felhasználó kéréstől a kért információ vételéig telik el. A csomagokra bontott adat esetében a késleltetés változás kiemelt fontosságú jellemző (transzport réteg vonatkozásában). A fogalom alatt az egyes csomagok késleltetés (megérkezési idejének) változását értjük. Olyan szolgáltatások esetén, melyek a késleltetés tekintetében magas toleranciával rendelkeznek, vagyis nagy késleltetést képesek elviselni, a
késleltetés változás alkalmasan megválasztott puffereléssel kiküszöbölhető. A pufferelés természetesen a konstans késleltetést növeli meg, ami a pufferelés mértékétől függ. Az információvesztés közvetlen hatással van a végfelhasználónál megjelenő információra, ami lehet hang, kép, videó vagy adat. Az ITU G.1010 ajánlás szemléletes ábrán foglalja össze azokat az elvárásokat, melyek teljesülése esetén az információ átvitel még elfogadható minőséget képvisel. A fenti ábrából látszik, hogy a párbeszéd átvitele esetén legkevésbé tolerálható a késleltetés, ugyanakkor néhány százalék adatinformáció veszteség megengedett. Bizonyos esetekben a párbeszéd átvitel során akár 400ms késleltetést is megengednek az ajánlások, de ezt kizárólag azért teszik, mert a rendelkezésre álló hálózatok, eszközök és protokollok nem teszik lehetővé kisebb késleltetési idők (például 150ms, vagy az alatti) elérését. A csomagkapcsolt hálózaton történő beszéd-, és egyéb hangátviteli kérdéseket az ITU-T G.1020 ajánlás tárgyalja részletesen (természetesen a G.1010 ajánlással összhangban). Az ajánlás elsősorban a csomagkapcsolt hálózat és a végberendezés paramétereit definiálja. A fókuszban a minőség romlás szerepel, melyet az időzítés változás és a csomagvesztés okoz. A beszédcélú hangátvitel esetén három egységet kell megkülönböztetni: Forrás terminál; Átviteli hálózat; Cél terminál. A hangátvitelt érintő egységeket és protokollokat a következő ábra szemlélteti. Az ITU-T G.1020 ajánlás a forrás előfizetői berendezés mikrofonjától egészen a cél végberendezés
hangszórójáig veszi figyelembe a beszédjel minőségromlását. Az ajánlás fókuszát a következő ábra szemlélteti: A valós idejű hangátvitel RTP-vel és az azt vezérlő RTCP-vel történik, melyeket UDP keretbe foglalnak és ezek fogják az IP számára a datagram -ot jelenteni. A forrás terminál az emberi száj által előállított hangnyomásból elektroakusztikus átalakítóval (mikrofonnal) elektromos jelet állít elő. A mérések elvégzéséhez az ajánlások száj referencia pontot definiálnak. A rendszer első elektromos mérőpontja az úgynevezett send electrical reference point (forrás oldali elektromos referencia pont), ahol idő- és halmaz folytonos (értelmezési tartományon és értékkészleten folytonos időfüggvény) analóg jel jelenik meg. A mintavételező és kvantáló, kódoló áramkör (A/D konverter) kimenetén diszkrét idejű és diszkrét értékkészletű jel (digitális jel) jelenik meg. Az A/D konverziónál alkalmazott mintavételi frekvencia 8000 Hz. Ez a mintavételi frekvencia természetesen megkívánja azt, hogy az elektroakusztikai átalakító (mikrofon) kimenetén megjelenő analóg jel sávkorlátozott legyen. Ha a jel 4000 Hz feletti frekvencia komponenst is tartalmaz, akkor a spektrum a mintavételezésnél átlapolódik (aliasing jelenség).
Nézzünk meg néhány definíciót, mely fogalmak általánosságban a VoIP átvitel esetén igazak. A definíciók az ITU-T G.1020 ajánlásból származnak: Csomag információs mező hossz (Packet information field size) megadja a beszéd, hullámforma kódolt mennyiségét, amelyet az adott csomag tartalmaz. A tipikus információs mező egy vagy kettő kódolt keretet tartalmaz (egy szimpla csomagban tipikusan 10 vagy 20 ms időszeletnek megfelelő kódot). Forrás terminál késleltetési időnek (Source terminal delay) nevezzük azt az időt, amely a száj referencia pont -on (mouth reference point) megjelenő analóg jel belépési időpontja és a terminál kimeneti referenciaponton e jel beszédmintájához tartozó adatcsomag első bitjének kilépési időpontja között telik el. Forrás terminál késleltetés változás (Source terminal delay variation) A forrás terminál késleltetés változásának ideje alatt definíciószerűen azt az időt értjük, ami a terminál kimeneti referencia ponton kilépő a hanginformáció elemeit szállító - csomagok kezdeti bitjei közti időzítés változása: Forrás terminál késleltetés változás = t(n-edik csomag) t(referencia csomag) A vételi oldal (cél terminál) késleltetése jelentős mértékben befolyásolja a továbbított hanginformáció minőségét. A fogalmak tisztázásához az ITU-T G.1020 ajánlás itt is három mérő referencia pontot definiált, melyek a következők: Terminál bemeneti referencia pont (Terminal input reference point);
Vételi elektromos referencia pont (Receive electrical reference point); Fül referencia pont (Ear reference point). A hálózaton továbbított adatok a vevő fizikai interfészén keresztül jutnak a berendezésbe. A kibontott keretekből a hanginformációt továbbító adatok az úgynevezett De-jittering pufferbe íródnak. A De-jittering puffer ad lehetőséget arra is, hogy sorrendbe állítsuk a hálózatban esetlegesen felcserélődött csomagokat. Erre természetesen csak akkor van lehetőség, ha egy késő csomag még azelőtt megérkezik, még mielőtt esedékes lenne annak lejátszása. Ellenkező esetben a csomag beillesztésére már nincs lehetőség, vagyis a nagy késleltetéssel megérkező csomag (hiába érkezik meg az hibátlanul), már vesztett csomagnak számít. A hálózati forgalom, valamint az esetleges pillanatnyi torlódások miatt késő csomagoknak akkor van a legjobb esélyük, hogy még a felhasználásuk (jelen esetben lejátszásuk) időpontja előtt megérkezzenek, ha minél nagyobb De-jittering puffert alkalmazunk. A nagyméretű puffer tehát kellemes a csomagvesztés szempontjából, de a késleltetett lejátszás jelkésleltetést jelent, ami (mint azt fent már láttuk) egy párbeszéd esetében igen zavaró, ezért azt 150 ms fölé vinni nem kívánatos. A De-jittering puffer kialakításánál tehát egymásnak ellentmondó szempontok alapján kell megtalálni az optimális kialakítást. Alapvetően kétféle de-jittering buffer típust különböztetünk meg: Fix hosszúságú; Adaptív hosszúságú.
A jelkésleltetés, ami minőség változást okoz alapvetően három paraméterből áll elő: Forrás késleltetés, Hálózat késleltetés (ennek részleteit később tárgyaljuk), Cél terminál késleltetés. Az egyes késleltetési időket az alábbi ábrán szemléltetjük: A fenti ábrán szemléltetett késleltetések a rendszerben akkumulálódnak. A késleltetések összege adja a végpont-végpont közti eredő késleltetést. A vétel oldali de-jittering puffernek olyan méretűnek kell lennie, ami képes kikompenzálni a forrásterminál késleltetés és a hálózat késleltetés változás időket, vagyis az aszinkron módon érkező csomagokból folyamatos, az eredeti digitalizálással azonos mintavételezési idejű és fázisú digitális jelfolyamot olvashatunk ki. Abban az esetben, ha az átvitel során véletlen bithiba áll elő, akkor az UDP keret ellenőrző összege jelzi a hibás kerettartalmat. A hibás keretek ilyenkor elvesznek, mert eldobásra kerülnek az OSI alkalmazási rétegben. A fenti okból tehát a veszteség kategorizálást beszédátviteli alkalmazás esetén, az alkalmazási rétegben kell meghatározni. Abban az esetben, ha a hálózat átlagos késleltetése ismert, akkor összegezni kell azt a dejittering puffer átlagos foglaltsági idővel, így kapjuk meg a teljes átlagos késleltetést. Amennyiben csak a hálózat minimum késleltetése ismert, akkor ehhez hozzá kell adnunk a maximális de-jitter puffer foglaltsági időt, ekkor ez fogja adni a teljes átlagos késleltetési időt.
Fix méretű de-jittering pufferrel felépített cél terminál modell szerint tudjuk legegyszerűbben értelmezni a kommunikáció során elveszett csomagokat. A legegyszerűbb modell esetén az összes olyan csomag eldobásra kerül, melyek késleltetése nagyobb, mint a hálózat minimális átviteli ideje plusz a fix hosszúságú de-jittering buffer tárolási ideje (vagyis a csomagot elveszettnek tekintjük, ha az később érkezik meg, mint azt a valós idejű alkalmazás felhasználná). Ebben az esetben a következő eljárás gondoskodik az IP és az alkalmazási rétegek közti leképzésről: Eldobásra jelöl minden olyan csomagot, mely UDP ellenőrző összeg hibát jelez. Eldobásra jelöl minden olyan csomagot, mely késleltetése nagyobb, mint a hálózat minimum késleltetése plusz a fix hosszúságú de-jittering buffer tároló képessége, vagy a késleltetése kisebb, mint egy megállapított minimum. Összegzi a hálózat átlagos késletetését (IPTD IP Packet Transfer Delay) a forrásterminál és a célterminál átlagos késleltetésével, hogy megkapja a teljes átlagos késleltetési időt, vagy összegzi a forrásterminál minimum időt a minimum hálózati késleltetési idővel, valamint a célterminál maximum késleltetéssel. Adaptív de-jittering buffer és a cél terminál modell szerint az eljárás egymástól kissé különbözik. Adaptív de-jittering buffer alkalmazásakor a buffer mérete változik, így a teljes késleltetés is változik a buffer méretétől függően. Ilyenkor ugyanis, ha egy sorrendben előbb álló csomag az IP hálózat késleltetése miatt később érkezik meg a sorrendben később lévő csomagoknál, a buffer csak akkor olvasható ki, ha már egy mintasorozathoz tartozó összes csomag megérkezett. A dekódoló ugyanis csak ilyenkor tudja a mintához tartozó csomagokat feldolgozni. Ez az alkalmazás esetenként megnöveli a teljes késleltetési időt, azonban a beszéd minősége jobb lesz, mint a fix bufferméret esetében. A fentiekben megszerzett ismereteink alapján a csomagvesztésre egyszerű leírást adhatunk. A csomagvesztés azt az arányt jelenti, amely megmutatja, hogy az elküldött csomagok hány százaléka nem éri el a célcsomópontot. Egy egyszerű példa: telefonáláskor az elvesztett
csomagokat a célállomás üres csomagokkal helyettesíti. Amennyiben túl sok üres csomag lesz a dekódolandó hangban, akkor akár szavak is hiányozhatnak az átvitt beszélgetésből. A csomagvesztés ( packet loss ) leggyakoribb okai a következők: Az átviteli berendezés meghibásodása (linkszakadás, csomóponthiba). Az útvonal csomópontjainak száma nagyobb, mint a csomag TTL (Time-To-Live) értéke, ilyenkor ugyanis az ezt érzékelő csomópont eldobja a csomagot. Torlódás (congestion): Az adatkommunikáció burst-ös jellege miatt gyakran előfordulnak esetek, amikor a router-ek pufferei megtelnek a kimenő linkek kis sávszélessége vagy a CPU túlterhelése miatt. Ilyenkor eldobják az összes várakozó csomagot a szállítási protokollnak megfelelően, vagy elvész a csomag (UDP), vagy újraküldi a forrás (TCP). Érdekes, hogy a torlódás nem növeli meg tartósan a késleltetést a hálózatban, mert a TCP forgalomszabályozás rögtön lecsökkenti az adás sebességét, ezért csak néhány csomagnak lesz nagy késleltetése, összességében az átbocsátóképesség csökken (ritkábban küldik a csomagokat). A mai kódolók 3-5%-os csomagvesztést is elviselnek a beszédminőség jelentős degradációja nélkül, különböző interpolációs technikákat használva a hiányzó minták közelítésére. Még 5-8%-os csomagvesztés mellett is kielégítő minőségű lehet a beszélgetés, de ilyenkor a beszédátvitel már nem alkalmas üzleti kommunikációra, inkább csak magánbeszélgetések lebonyolítására. Több lehetséges módszer is létezik az elvesztett csomagok kijavítására. Amennyiben a packet loss alacsony, akkor járható út az előző hangminta megismétlése. Létezik azonban jobb módszer a hiba kiküszöbölésére, mégpedig a Packet Loss Concealment (PLC). Ezzel a technikával a már fogadott beszédmintákból állítja elő azt a csomagot, ami valószínűleg következni fog (predikciós - jósló módszer). SIP Session Initiation Protocol A SIP-et az IETF dolgozta ki és az RFC3261 ajánlásban foglalta össze. A SIP úgynevezett text alapú protokoll (hasonlóan, mint például a HTTP), segítségével multimédiás tartalmak továbbítására alkalmas kapcsolatokat lehet felépíteni, lebontani és menedzselni. A SIP az alkalmazási (application) rétegben, a szállítási réteg felett helyezkedik el, ezért attól független, de a gyakorlatban a SIP üzenetek továbbítása TCP/UDP-vel történik. A hívásfelépítést követően a valós idejű adatok átvitele RTP/RTCP-vel megy végbe, a jelzésátviteltől függetlenül.
A SIP öt eszköztípust definiál, melyek a következők: SIP Proxy szerver, melynek szerepe a kliens és szerver ügyfél közötti jelzésváltások átvitelénél van. Feladata az, hogy megkeresse a célfelhasználóhoz legközelebb eső szervert, továbbá a hitelesítés és a házirend definiálása is. SIP redirect szerver, mely átirányító funkcióval rendelkezik. A kérések célcíme alapján (ha az szükséges) új célcímet határoz meg és azt visszaküldi az ügyfélnek. A Proxy számára más tartományok is ismertté válnak. SIP registrar szerver, melynek feladata a tartományon belüli kliensek adatainak tárolása, vagyis domain-en belül adatbázis szerverként működik. SIP user agent (UA), mely eszközök csoportja alkotja a felhasználói végberendezéseket (SIP-VoIP telefon, PDA, laptop stb.). SIP gateway, mely eszköz átjárást biztosíthat más hálózatok felé. Feladata a jelzés, és átviteli konverziók végrehajtása. A fent felsorolt elemek (elsősorban a szerveralkalmazások) akár ugyanazon a fizikai eszközön (szerver számítógép, router) is működhetnek. Az alap, leggyakrabban használt rendszer architektúra az alábbi ábrán látható (ez az úgynevezett trapézmodell ): A SIP jelzésüzeneteket két csoportba sorolhatjuk: Kérések (request); Válaszok (response). Mindkét jelzésüzenet típus úgynevezett start-line -nal (kezdő sorral) kezdődik, melyet egy, vagy több header mező követ. A header (fejléc) mező végét egy üres sor jelzi. Az üres sorban két vezérlő karakter található (CR kocsi vissza; LF - soremelés).
Ezen felül minden sort (start-line és message header line) a CR és az LF vezérlőkaraktereknek kell zárnia. A header mezőt opcionálisan egy üzenet törzs (message-body) követheti. Request típusú üzenetek generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line REGISTER INVITE ACK OPTIONS CANCEL BYE - A jelenlévő felhasználók ezzel az üzenettel regisztrálhatnak a szerverre. - Kapcsolatkezdeményezésre, és élő kapcsolat paramétereinek módosítására szolgáló üzenet. - Nyugtázó üzenet. - A szerver nyújtotta szolgáltatásokról tájékoztatja a kapcsolatban résztvevő feleket. - A teljesítetlen kérések kiszolgálását megakadályozó üzenet. - Hívásbontást kezdeményező jelző üzenet. Response típusú üzenetek A response üzeneteket három számjegyből álló státuszkód adja, a HTTP-hez hasonló módon. Az első karakter alapján a válaszüzenetek csoportosítottak, úgynevezett válasz osztályba (response-class) rendezettek, melyek a következők: 1xx Információs válaszok,a hívás folyamatban van. 100 -- Trying 180 -- Ringing 181 -- Call is being forwarded 182 -- Queued 2xx Sikeres végrehajtás 200 -- OK
3xx Átirányítás 300 -- Multiple choice 301 -- Moved permanently 302 -- Moved temporerly 305 -- Use Proxy 4xx Hiba az ügyfélnél 400 -- Bad Request 401-- Unathorized 405 -- Proxy Auth. Required 484 -- Address incomplete 486 -- Busy here 5xx Hiba a szervernél 500 -- Internal error 501 -- Not implemented 502 -- Bad Gateway 503 -- Service Unavailable 504 -- Gateway timeout SIP hívás felépítés és bontás folyamata
A fenti ábrán az A végberendezés egy INVITE üzenettel jelzi a szervernek, hogy hívást kíván kezdeményezni. A proxy szerver a példa szerint 407 üzenettel visszajelzi a hitelesítési igényt, melyet a végberendezés egy ACK elküldésével nyugtáz. Az ACK küldését követően az A végberendezés egy újabb INVITE üzenetet küld, melyben szerepelnek a hitelesítési adatok is (és természetesen a B végberendezés (UA) címe is). Erre a proxy egy TRYING üzenetet küld visszaigazolásképpen, miszerint megpróbálja B UA-t elérni, ugyanekkor a proxy egy INVITE üzenetküldéssel próbálja B UA-t elérni. Az INVITE üzenet törzse tartalmazza a felépíteni kívánt kapcsolat paramétereit is, mégpedig az SDP (Session Description Protocol, RFC 4566) követelményeinek megfelelő formátumban, tartalma így néz ki (példa): v=0 o=clarent 120386 120387 IN IP4 200.57.7.196 s=clarent C5CM c=in IP4 200.57.7.196 t=0 0 m=audio 40376 RTP/AVP 8 18 4 0 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:0 PCMU/8000 a=sendrecv Mivel a SIP válaszüzenetek törzsében ugyanígy elhelyezhető az SDP context leírása, segítségével a felek megállapodhatnak minden lényeges parraméterről (legfőképpen a használni kívánt kodek típusáról). A kicsengésről a hívó ( A UA) a 180 (RINGING) válasz alapján értesül. A 200 kódú válasz (OK) jelzi, hogy a B UA elfogadta a szerver meghívást, melyet a proxy egy ACK-val nyugtáz. A hívás tényleges megválaszolását a 200 (OK) fogja jelenteni, mely után felépül az RTP/RTCP csatorna és megkezdődik a beszédmintákat szállító csomagok átvitele a végpontok között.
A beszédkapcsolat bontását a példa szerint a hívó ( A UA) kezdeményezi, és ezt a BYE üzenet küldésével jelzi. RTP és RTCP Az RTP és RTCP protokoll páros az OSI szállítási (Transport) rétegében kapott helyet. Az RTP-t az RFC 1889, míg az RTCP-t az RFC 3550 definiálja. RTP Real-time Transport Protocol Az RTP valós idejű adatok átvitelére alkotott eljárás, ezért VoIP adatátvitelre előszeretettel alkalmazzuk. Ez a protokoll IP hálózaton történő időszinkronizált adatátvitelre képes unicast, vagy multicast csatornán. Az RTP tipikus alkalmazása a digitális hang, vagy videó jeltovábbítás, de folytonos adatfolyam szállítására is alkalmazható. Az RTP overhead tartalmaz egy payload típusazonosítót, ami megadja a továbbított adat típusát. A protokoll legfontosabb tulajdonsága, hogy minden keret tartalmaz egy időbélyeget ( payload timestamp ). Az RTP keret felépítését a következő ábrán tüntettük fel: V P X CC M PT SQ (2 byte) TStamp (4 byte) SSRC (4 byte) CSRC list (4 byte) Hasznos adat illetve helykitöltő (Padding)
Az egyes adategységek jelentését és méretét a következőkben foglaltuk össze: A V mező 2 bit hosszúságú ( Version ), a protokoll verziószám jelölésére szolgál, jelenleg az RTP 2-es verzió használatos. A P egybites ( Padding ). Ez a bit jelzi, hogy a csomag payload helytöltő padding byteokat is tartalmaz. Az X mező szintén egy bitből áll, jelentése Extension. Ez a bit lehetőséget biztosít az RTP fejléc opcionális kibővítésére. A CC mező 4 bites (CSRC Count). Az RTP csomagban előforduló CSRC azonosítók számát adja meg. A CSRC azonosítók az RTP fejlécben, annak CSRC mezőjében (32 bit) találhatóak. Az M egybites ( Marker ). Ennek a bitnek az aktuális jelentése a profiltól függ. Használható a felsőbb rétegek határvonalainak megjelölésére, vagy extra payload megjelölésre. Számos alkalmazásban ez a bit nem használatos. A PT (Payload Type) mező, mely 7 bitből áll a payload típus és a média típus azonosítására szolgál. Az SQ 16 bites mező (SeQuence number). Ez a sorszám minden egyes keret küldése során inkrementálódik (modulo 65536 módszerrel). A vevő ezen szám alapján képes felderíteni az esetleges csomagvesztést. Az adás megkezdésekor ez a szám egy véletlen szám. A TStamp (Timestamp) 32 bitből áll. Ez a szám reprezentálja az RTP csomag payload első byte-hoz tartozó mintavételi pillanatot. Erre az értékre alapozottan képes a vevő a vett adatokból (burst jellegű) helyreállítani a mintavételi ütemezésnek megfelelő folyamatos digitális jelfolyamot. Az egyes alkalmazások esetén a mintavételi frekvencia egymástól eltérő, melynek azonosítása a payload formátum specifikációban szerepel. Ennek a számnak a kezdeti értéke véletlen szám. Az SSRC (Syncronization Source) mező 32 bites. Tartalma egy véletlen számként generált azonosító, melynek feladata az RTP adatfolyam eredetének azonosítása. Az CSRC (Contributing Source list) mező szintén 32 bitből áll. A listában maximum 15 azonosító szerepelhet. Azt, hogy ebben a listában ténylegesen hány azonosító található, a CC mező száma adja meg.
A labor SIP rendszere A laborban kiépített rendszer egy SIP szervert tartalmaz (Asterisk), amelyet PBX üzemmódra konfiguráltunk. Ez a legegyszerűbb használati mód, mivel nem igényli DNS szerverek használatát, viszont ismerni kell a PBX szerver elérhetőségét (IP cím). A SIP hálózat számára a 10.11.12.0/24 IP címtartományt definiáltuk, a szerver ebből a tartományból a 10.11.12.1 címet kapta. A kliens gépek ethernet csatolója két IP címmel rendelkezik: az elsődleges címet az Egyetem DHCP szervere osztja ki, a másodlagos pedig egy statikus cím, a 10.11.12.2-10.11.12.3 tartományban. A kliensek egy Yate nevű VoIP alkalmazást tartalmaznak, ennek használatával lehet a hívásokat kezdeményezni. A kliensek számára a 7001-7012 hívószámokat osztottuk ki. Kialakítottunk hangpostát is, ezek leolvasása a 8001-8012 hívószámokon lehetséges.
Mérési feladatok 1. Indítsa el a Yate alkalmazást, majd néhány próba hívás segítségével győződjön meg a működéséről, ismerje meg használatát! 2. Indítsa el a Wiresharkon a rögzítést, majd kezdeményezzen hívást valamelyik kliensre. A hívott kliens válaszolja meg a hívást, majd a hívó fél bontásával fejezzék be a folyamatot. Vizsgálja meg a következőket: a. Keresse meg a SIP üzenetváltást, szűrje le a csomagokat! Milyen hordozóprotokollt és paramétereket (port cím) használ a SIP? b. Hogyan történik a session paraméterek megállapítása, az SDP context hogyan alakul ki? c. A hívás alatt történik-e SIP üzenetváltás? Milyen végpontok között közlekednek a SIP üzenetei? d. Hogyan történik a kapcsolat lebontása? e. Keresse meg a híváshoz tartozó RTP adatfolyamo(ka)t. Mikor történik az RTP folyam kialakítása? Hány RTP adatfolyamot talált? 3. Ismételje meg az előbbi mérést, de most a hívott fél bontsa a kapcsolatot. 4. A hívott fél jelentkezzen ki a PBX-ből. A hívó fél kezdeményezzen hívást a kijelentkezett kliens hívószámára. A hívás ilyenkor automatikusan hangpostára kerül. Rögzítse a hívás folyamatát Wiresharkkal, és vizsgálja meg az üzeneteket! 5. Olvassa le a hangpostát, és rögzítse a folyamatot Wiresharkkal. Milyen üzenetváltás zajlik le ilyen esetben?