Amikor IP-telefonon beszélünk a kagylóban a beszélgetőpartner hangját halljuk, vagy videokonferencia rendszer segítségével kommunikálunk kollégáinkkal, hozzátartozóinkkal, folyamatos adatfolyamot cserélünk. Streaming adatok, például hang és videó csomaghálózaton keresztüli továbbításakor nagyon fontos olyan mechanizmusok alkalmazása, amelyek a következő feladatokat oldják meg:
Erre a célra fejlesztették ki RTP(Real-time Transport Protocol) egy valós idejű átviteli protokoll, amelyről a mai cikkben lesz szó. A protokollt az IETF fejlesztette ki az Audio-Video Transport Working Group által, és az RFC 3550 írja le.
Az RTP rendszerint az UDP-n (User Datagram Protocol) felül működik, mivel a multimédiás adatok továbbításakor nagyon fontos biztosítani azok időben történő kézbesítését.
Az RTP magában foglalja a hasznos teher típusának meghatározását és a folyamban lévő csomag sorszámának hozzárendelését, valamint időbélyegek használatát.
Az adó oldalon minden csomag egy időbélyeggel van megjelölve, a fogadó oldal fogadja és meghatározza a teljes késleltetést, ami után kiszámítja a teljes késleltetések különbségét és meghatározza a jittert. Így lehetővé válik, hogy állandó késleltetést állítsunk be a csomagok kézbesítésében, és ezáltal csökkentsük a jitter hatását.
Az RTP másik funkciója az IP-hálózaton való áthaladás közbeni esetleges csomagvesztéshez kapcsolódik, amely rövid szünetek megjelenésében fejeződik ki a beszélgetésben. A kézibeszélőben fellépő hirtelen csend általában nagyon negatív hatással van a hallgatóra, ezért az RTP protokoll képességeivel az ilyen néma időszakokat úgynevezett „komfortzaj” tölti ki.
Az RTP egy másik IETF protokollal, nevezetesen az RTCP-vel (Real-time Transport Control Protocol) együtt működik, amelyet az RFC 3550 ír le. Az RTCP statisztikai adatok gyűjtésére, a szolgáltatás minőségének meghatározására, a QoS (Quality of Service) meghatározására szolgál. szinkronizálni az RTP-munkamenet médiafolyamai között.
Az RTCP fő funkciója, hogy visszajelzést adjon az alkalmazással a kapott információ minőségéről. Az RTCP-munkamenet résztvevői információt cserélnek a fogadott és elveszett csomagok számáról, a jitter értékéről, a késleltetésről stb. Ezen információk elemzése alapján döntés születik az átviteli paraméterek megváltoztatásáról, például az információ tömörítési arányának csökkentéséről az átvitel minőségének javítása érdekében.
Ezen funkciók végrehajtásához az RTCP bizonyos típusú speciális üzeneteket küld:
Az RTP egy egyirányú protokoll, így a kétirányú kommunikációhoz két RTP-munkamenetre van szükség, mindkét oldalon egy-egy.
Az RTP-munkamenetet a résztvevők IP-címei, valamint a 16384 - 32767 tartományból származó, nem fenntartott UDP-portok határozzák meg. Ezen túlmenően az alkalmazással való visszacsatolás megszervezéséhez szükséges egy két- módon RTCP munkamenet. Az RTCP-munkameneteknél az RTP-nél eggyel nagyobb portok foglaltak. Így például, ha az 19554-es portot választotta ki az RTP-hez, akkor az RTCP-munkamenet az 19555-ös portot veszi át. Vizuálisan az RTP/RTCP munkamenet kialakítását az alábbi ábra mutatja.
Ez a rész az RTP-csomagok hálózati és szállítási protokollok általi szállításának néhány szempontját tárgyalja. Hacsak más protokollok specifikációi másként nem rendelkeznek, a csomagok továbbítására a következő alapvető szabályok érvényesek.
Az RTP alsóbb rétegbeli protokollokra támaszkodik az RTP-adatfolyamok és az RTCP-vezérlési információk elkülönítésére. UDP és hasonló protokollok esetén az RTP páros portszámot, a megfelelő RTCP adatfolyam pedig egynél nagyobb portszámot használ.
Az RTP információs csomagok nem tartalmaznak hosszmezőt, ezért az RTP az alapul szolgáló protokollra támaszkodik a hosszjelzés biztosításához. Az RTP-csomagok maximális hosszát csak az alsóbb rétegbeli protokollok korlátozzák.
Egy alsóbb rétegbeli protokoll adategységben több RTP protokoll csomag is továbbítható, például egy UDP csomagban. Ez csökkenti a fejléc redundanciáját, és leegyszerűsítheti a különböző adatfolyamok közötti szinkronizálást.
Ez a szakasz az RTP protokoll specifikációjában meghatározott állandók listáját tartalmazza.
Az RTP (PT - payload type) forgalmi típusú állandók profilokban vannak meghatározva. Az RTP fejléc oktettje azonban, amely tartalmazza a jelölőbit(eke)t és a forgalomtípus mezőt, nem tartalmazhatja a 200 és 201 (tizedes) fenntartott értéket, hogy megkülönböztesse az RTP csomagokat az RTCP SR és RR csomagoktól. Egy jelölőbittel és egy hétbites forgalomtípusmezővel rendelkező szabványos formátum esetén ez a korlátozás azt jelenti, hogy a 72-es és 73-as forgalomtípust nem szabad használni.
Az RTCP csomagtípusok értékei (lásd az 1. táblázatot) a 200 és 204 közötti tartományban vannak kiválasztva, hogy jobban ellenőrizzék az RTCP csomagfejléc helyességét az RTP csomagokhoz képest. Ha az RTCP csomagtípus mezőt összehasonlítjuk az RTP fejléc megfelelő oktettjével, ez a tartomány egy egyes jelölőbitnek felel meg (ami az információs csomagoknál általában nem így van), és a szabványos forgalomtípus mező legjelentősebb bitjének egy. (míg a statikusan meghatározott forgalomtípusok általában PT-értékekkel rendelkeznek, és a legjelentősebb számjegyben nulla szerepel). Ezt a tartományt is úgy választottuk, hogy távolabb legyen a 0 és 255 értékektől, mivel a teljesen nullákból vagy egyesekből álló mezők többnyire jellemzőek az adatokra.
Más típusú RTCP-csomagokat az IANA közösség határozza meg. A fejlesztőknek lehetőségük van regisztrálni a kísérleti kutatáshoz szükséges értékeket, majd törölni a regisztrációt, ha már nincs szükség ezekre az értékekre.
Az SDES-csomag érvényes elemtípusait a táblázat mutatja be. 2. A többi SDES-elemtípust az IANA közösség rendeli hozzá. A fejlesztőknek lehetőségük van regisztrálni a számukra szükséges értékeket, amikor kísérleti tanulmányokat végeznek, majd törölhetik a regisztrációt, amikor már nincs szükségük ezekre az értékekre.
Ahogy fentebb megjegyeztük (lásd a 2. szakaszt), a teljes leírás Az RTP protokoll egy adott alkalmazáshoz további kétféle dokumentumot igényel: profilleírást és forgalmi formátumot.
Az RTP számos alkalmazási osztályhoz használható, nagyon eltérő követelményekkel. Az ezekhez a követelményekhez való alkalmazkodás rugalmasságát a különböző profilok használata biztosítja (lásd ). Egy alkalmazás általában csak egy profilt használ, és nincs kifejezett jelzés arra vonatkozóan, hogy melyik profilban van Ebben a pillanatban használatban, sz.
A második típusú opcionális dokumentum, a forgalmi formátum specifikáció határozza meg, hogyan kell egy adott típusú forgalmat (pl. H.261 kódolású videó) továbbítani az RTP szerint. Ugyanaz a forgalmi formátum több profilhoz is használható, ezért a profiltól függetlenül is meghatározható. A profildokumentumok csak azért felelősek, hogy ez a formátum megfeleljen a PT értéknek .
A profilleírás a következő elemeket határozhatja meg, de ez a lista nem teljes.
Az RTP adatcsomag fejléce. Az RTP adatcsomag fejlécében lévő oktett, amely a token bitet és a forgalomtípus mezőt tartalmazza, a profilnak megfelelően újradefiniálható, hogy megfeleljen a különböző követelményeknek, például több vagy kevesebb token bitet biztosítson (3.3. szakasz).
forgalmi típusok. A profil általában meghatározza a forgalmi formátumok készletét (pl. médiakódolási algoritmusok), valamint ezen formátumok és PT értékek alapértelmezett statikus leképezését. Egyes forgalmi formátumok az egyes forgalmi formátumok leírása alapján határozhatók meg. Minden meghatározott forgalomtípushoz a profilnak meg kell adnia a szükséges RTP időbélyegző órajelet (3.1. szakasz).
RTP adatcsomag fejléc kiegészítések. Ha néhány további funkcionalitás a forgalom típusától nem függő profilalkalmazás osztályon belül, akkor az RTP adatcsomag fix fejlécéhez további mezők csatolhatók .
RTP adatcsomag fejléc kiterjesztések. Az RTP Data Packet Header Extension struktúra első 16 bitjének tartalmát meg kell adni, ha a profil lehetővé teszi ennek a mechanizmusnak a használatát. .
Az RTCP-csomagok típusai. Új, alkalmazásosztály-specifikus típusú RTCP-csomagok definiálhatók (és regisztrálhatók az IANA-nál).
RTCP jelentési intervallum. A profilnak meg kell határoznia az RTCP jelentési intervallum kiszámításához használt értékeket: az RTCP munkamenet sávszélességének hányadát, a minimális jelentési intervallumot és a sávszélesség felosztását a küldők és a fogadók között.
SR/RR csomagkiterjesztés. Ha van további információ a rendszeresen továbbítandó feladóról vagy vevőről egy kiterjesztési szakasz definiálható az RTCP SR és RR csomagokhoz.
SDES használata. A profil relatív prioritásokat határozhat meg a továbbítandó vagy kizárandó RTCP SDES elemekhez (lásd a 4.2.2 szakaszt); alternatív szintaxis vagy szemantika a CNAME záradékhoz (4.4.1. szakasz); LOC tételformátum (4.4.5. szakasz); a NOTE záradék (4.4.7. szakasz) és az IANA-nál regisztrálandó új SDES záradék szemantikája és használata.
Biztonság. A profil meghatározhatja, hogy az alkalmazások mely biztonsági szolgáltatásokat és algoritmusokat használjanak, és irányítást biztosíthat a használatuk felett (7. szakasz).
Jelszó-kulcs egyezés. A profil meghatározhatja, hogy a felhasználó által beírt jelszó hogyan alakul át titkosítási kulccsá.
Az alapul szolgáló protokoll. Az RTP-csomagok továbbítása megkövetelheti egy adott mögöttes hálózat vagy szállítási réteg protokoll használatát.
Szállítási megfelelőség. Az RTP és RTCP szabványos leképezésétől eltérő, a 8. szakaszban meghatározott szállítási rétegcímekhez, például UDP-portokhoz, más is meghatározható.
Egységbezárás. Az RTP-csomagok alakítása úgy definiálható, hogy lehetővé tegye több RTP információs csomag továbbítását egyetlen mögöttes protokoll adategységben (8. szakasz).
Minden általad fejlesztett alkalmazás nem igényel új profilt. Célszerűbb egy meglévő profilt bővíteni ugyanazon az alkalmazásosztályon belül, mint újat létrehozni. Ez megkönnyíti az alkalmazások interakcióját, mivel minden alkalmazás általában csak egy profil alatt fut. Az egyszerű kiterjesztések, például további PT-értékek vagy RTCP-csomagtípusok megadása úgy végezhető el, hogy regisztrálja őket az IANA-nál, és közzéteszi a leírásukat egy profilspecifikációban vagy a forgalmi formátum specifikációjában.
Az RFC 1890 egy profilt ír le az RTP 2. verziójú valós idejű szállítási protokoll és a hozzá tartozó RTCP vezérlőprotokoll használatához egy csoportos audio- vagy videokonferencián belül, az úgynevezett RTP Profile for Audio and Video Conferences (RTP Profile for Audio and Video Conferences) Minimális vezérléssel). Ez a profil az RTP azon szempontjait határozza meg, amelyek nem szerepelnek az RTP protokoll 2. verziójának specifikációjában (RFC 1889). A minimális vezérlés azt jelenti, hogy nincs szükség a paraméteregyeztetés vagy a tagságvezérlés támogatására (pl. statikus forgalomtípus-leképezések és az RTCP által biztosított tagsági jelzések használatakor). Vegye figyelembe a főbb rendelkezéseket ezt a profilt.
Ez a szakasz számos olyan elem leírását tartalmazza, amelyek egy profilban meghatározhatók vagy módosíthatók.
Az RTP információs csomag fejléce. Az RTP információs csomagok szabványos rögzített fejlécformátuma (egy bit marker) használatos.
forgalmi típusok. A forgalomtípusok statikus értékeit a 11.3 és 11.4 pontok határozzák meg.
RTP információs csomagfejléc-kiterjesztések. Az RTP információs csomag fejlécéhez nincsenek további rögzített mezők csatolva.
RTP információs csomagfejléc-kiterjesztések. Nincsenek RTP információs csomagfejléc-kiterjesztések definiálva, de ezt a profilt használó alkalmazások használhatják ezeket a kiterjesztéseket. Vagyis az alkalmazásoknak nem szabad azt feltételezniük, hogy az RTP fejléc X bitje mindig nulla. Az alkalmazásoknak fel kell készülniük a fejlécbővítés figyelmen kívül hagyására. Ha a jövőben fejléc-kiterjesztés kerül meghatározásra, akkor az első 16 bit tartalmát meg kell adni, hogy sok különböző kiterjesztést lehessen azonosítani.
Az RTCP-csomagok típusai. Ebben a profilspecifikációban nincsenek további RTCP-csomagtípusok definiálva.
RTCP jelentési intervallum. Az RTCP jelentési intervallum kiszámításakor az RFC 1889-ben javasolt állandókat kell használni.
SR/RR csomagkiterjesztések. Az RTCP SR és RR csomagok kiterjesztései nincsenek meghatározva.
SDES használata. Az alkalmazások használhatják a leírt SDES záradékok bármelyikét. Míg a kanonikus név (CNAME) információ minden jelentési intervallumban elküldésre kerül, a többi elemet csak minden ötödik jelentési intervallumban kell elküldeni.
Biztonság. Az alapértelmezett RTP biztonsági szolgáltatásokat is alapértelmezés szerint ez a profil határozza meg.
Jelszó-kulcs egyezés. A felhasználó által beírt jelszót az MD5 algoritmus segítségével 16 oktettes kivonattá alakítja. Egy N bites kulcsot kapunk a kivonatból az első N bitek felhasználásával. A jelszó csak ASCII betűket, számokat, kötőjeleket és szóközöket tartalmazhat, hogy csökkentse a sérülés lehetőségét a jelszavak telefonon, faxon, telexen vagy e-mailben történő továbbításakor. A jelszót megelőzheti egy titkosítási algoritmus specifikációja. Az első perjelig (ASCII-kód: 0x2f) minden karakter a titkosítási algoritmus neve lesz. Ha nincs perjel, akkor az alapértelmezett titkosítási algoritmus a DES-CBC.
A felhasználó által beírt jelszót a rendszer a záró algoritmus alkalmazása előtt kanonikus formájába konvertálja. Ehhez a jelszót a rendszer az ISO/IEC 10646-1:1993 szabvány P mellékletében meghatározott UTF-8 kódolással az ISO 10646 karakterkészletre konvertálja (az ASCII karakterek nem igényelnek átalakítást); a szóközök törlődnek a jelszó elején és végén; két vagy több szóközt egy szóköz helyettesít (ASCII vagy UTF-8 0x20); minden betűt kisbetűvé alakítunk
az alapul szolgáló protokoll. A profil határozza meg az RTP használatát UDP-n keresztül kétirányú és csoportos küldés módban.
Szállítási megfelelőség. Az RTP és az RTCP szabványos leképezése szállítási rétegcímekre használatos.
Egységbezárás. Az RTP-csomagok tokozása nincs meghatározva.
Ez a profil határozza meg az RTP-vel használt szabványos kódolási típusokat. Az egyéb kódolási típusokat használat előtt regisztrálni kell az IANA-nál. Új kódtípus regisztrálásakor a következő információkat kell megadni:
Azoknál az alkalmazásoknál, amelyek nem küldenek csomagokat szünetek alatt, az aktív beszéd első sorozatát (a szünet utáni első csomagot) úgy különböztetjük meg, hogy az RTP információs csomag fejlécében lévő jelölőbitet egyre állítjuk. A csend-elnyomás nélküli alkalmazások ezt a bitet nullára állítják.
Az RTP időbélyegző generálásakor használt RTP óra független a csatornák számától és a kódolás típusától; egyenlő a másodpercenkénti mintavételi periódusok számával. N-csatornás kódolásnál (sztereó, négyes, stb.) minden mintavételi periódus (mondjuk 1/8000 másodperc) N mintát generál. A másodpercenként generált minták teljes száma megegyezik a mintavételi sebesség és a csatornák számának szorzatával.
Ha több hangcsatornát használ, akkor azok balról jobbra vannak számozva, az elsővel kezdve. Az RTP audiocsomagokban az alacsonyabb számú csatornákból származó adatok megelőzik a magasabb számú csatornák adatait. Kettőnél több csatorna esetén a következő jelölést kell használni:
| Csatornák száma | Rendszer neve | Csatornaszámok | |||||
|---|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | ||
| 2 | sztereó | l | r | ||||
| 3 | l | r | c | ||||
| 4 | quad | fl | Fr | Rl | Rr | ||
| 4 | l | c | r | S | |||
| 5 | fl | Fr | Fc | Sl | Sr | ||
| 6 | l | lc | c | r | rc | S | |
Az azonos mintavételi pillanathoz tartozó összes csatorna mintájának ugyanabban a csomagban kell lennie. A különböző csatornákból származó minták interleavelése a kódolás típusától függ.
A mintavételezési frekvenciát a következő készletből kell kiválasztani: 8000, 11025, 16000, 22050, 24000, 32000, 44100 és 48000 Hz (a Macintosh Apple számítógépeknek saját mintavételi frekvenciájuk van: 22254.524, amely 5000 és 52111124-re alakítható át. 025 s elfogadható minőség négy vagy két minta kihagyásával egy 20 ms-os keretben). A legtöbb hangkódoló algoritmus azonban korlátozottabb mintavételi frekvenciához van definiálva. A vevőkészülékeknek fel kell készülniük a többcsatornás hang vételére, de választhatnak monót is.
Hangcsomagolás esetén az alapértelmezett csomagozási intervallum 20 ms, hacsak a kódolás leírása másként nem rendelkezik. A csomagozási intervallum határozza meg a minimális végpontok közötti késleltetést. A hosszabb csomagok fejlécének viszonylag kisebb része van a bájtoknak, de nagyobb késleltetést okoznak, és jelentősebbé teszik a csomagvesztést. Nem interaktív alkalmazások, például előadások vagy jelentős sávszélesség-korlátozással rendelkező csatornák esetében magasabb csomagolási késleltetés is elfogadható lehet. A címzettnek 0 és 200 ms közötti késleltetésű hangjelzéssel ellátott csomagokat kell fogadnia. Ez a korlát elfogadható pufferméretet biztosít a vevő számára.
A minta alapú kódolásokban minden jelmintát meghatározott számú bit reprezentál. A tömörített hangadatokon belül az egyes mintakódok átléphetik az oktett határait. Az audiocsomagban továbbított jel időtartamát a csomagban lévő minták száma határozza meg.
A mintánként egy vagy több oktettet előállító minta alapú kódolási típusok esetében a különböző csatornákból származó minták egyidejűleg mintavételezésre kerülnek a szomszédos oktettekbe. Például a sztereó kódolásnál az oktetek sorrendje a következő: bal csatorna, első minta; jobb csatorna, első szám; bal csatorna, másodpercek száma; jobb csatorna, második minta stb. Több oktett kódolás esetén először a legjelentősebb oktett kerül továbbításra. A mintánként egy oktettnél kevesebbet előállító mintaalapú kódolások csomagolását a kódolási algoritmus határozza meg.
A keret alapú kódolási algoritmus egy rögzített hosszúságú audioblokkot egy másik tömörített adatblokkká alakít át, általában szintén rögzített hosszúságú. Keret alapú kódolás esetén a küldő több ilyen keretet is kombinálhat egyetlen üzenetbe.
A keret alapú kodekeknél a csatorna sorrend a teljes blokkra van meghatározva. Vagyis sztereó hang esetén a bal és a jobb csatorna mintái egymástól függetlenül vannak kódolva; ahol a bal csatorna kódoló kerete megelőzi a jobb csatorna keretét.
Minden keretorientált audiokodeknek képesnek kell lennie több, egy csomagon belül továbbított egymás utáni képkocka kódolására és dekódolására. Mivel a keretorientált kodekek keretmérete meg van adva, nincs szükség külön jelölés használatára ugyanazon kódoláshoz, de csomagonként eltérő számú képkockához.
táblázatban. A 3. ábra mutatja a forgalomtípusok (PT) értékeit, amelyeket ez a profil definiált az audiojelekhez, ezekhez egyezményekés fő specifikációk kódolási algoritmusok.
táblázatban. A 4. ábra a kódolási típusok (PT) értékeit, a kódolási algoritmusok szimbólumait és a videó kódoló algoritmusok ezen profil által meghatározott műszaki jellemzőit, valamint a hozzá nem rendelt, fenntartott és dinamikusan hozzárendelt PT értékeket mutatja.
A 96-tól 127-ig terjedő forgalomtípus értékek dinamikusan határozhatók meg a konferenciavezérlő protokollon keresztül, amelyre ez a cikk nem tér ki. Például a munkamenet-könyvtár megadhatja, hogy egy adott munkamenethez a 96-os forgalomtípus PCMU kódolást jelöl, kétcsatornás 8000 Hz-en. A "fenntartott" forgalmi típusok tartománya nem használatos, így az RTCP és az RTP protokollcsomagok megbízhatóan megkülönböztethetők .
Egy RTP-forrás egy adott időpontban csak egyfajta forgalmat bocsát ki; különböző típusú forgalom összeillesztése egy RTP-munkamenetben nem megengedett. Több RTP-munkamenet is használható párhuzamosan különböző típusú forgalom szállítására. Az ebben a profilban meghatározott forgalomtípusok hangra vagy videóra vonatkoznak, de mindkettőre nem. Lehetőség van azonban olyan kombinált forgalomtípusok meghatározására, amelyek kombinálják például a hangot és a videót, a forgalmi formátum megfelelő elválasztásával.
Az ezt a profilt használó audioalkalmazásoknak képesnek kell lenniük legalább 0 (PCMU) és 5 (DVI4) típusú forgalom küldésére és fogadására. Ez lehetővé teszi az együttműködést formátum egyeztetés nélkül.
Az RTP protokoll leírásában meghatározottak szerint az RTP-adatokat páros számú UDP-porton, a megfelelő RTCP-csomagokat pedig egynél nagyobb portszámon (páratlan szám) kell továbbítani.
Az ezzel a profillal futó alkalmazások bármelyik ilyen UDP-portpárt használhatják. Például egy portpárt véletlenszerűen hozzárendelhet a munkamenet-kezelő program. Egyetlen rögzített portszámpár nem adható meg, mert bizonyos esetekben több, ezt a profilt használó alkalmazásnak megfelelően kell futnia ugyanazon a gazdagépen, és egyes operációs rendszerek nem teszik lehetővé, hogy több folyamat ugyanazt az UDP-portot használja különböző csoportos küldési címekkel.
Az alapértelmezett portszám azonban lehet 5004 és 5005. A több profilt használó alkalmazások ezt a portpárt választhatják a profil jelzőjeként. De az alkalmazások azt is megkövetelhetik, hogy a portpárt kifejezetten meg kell adni.
A modern távközlés fejlődésének egyik legfontosabb irányzata az IP-telefónia fejlődése – olyan új technológiák összessége, amelyek biztosítják a multimédiás üzenetek (hang, adat, videó) továbbítását információs és számítógépes hálózatokon (ICN) keresztül. az IP (Internet Protocol) protokoll alapján, beleértve a helyi, vállalati, globális számítógépes hálózatokat és az internetet. Az IP-telefónia fogalma magában foglalja az internetes telefonálást, amely lehetővé teszi az internet-előfizetők közötti, az előfizetők közötti telefonos kommunikáció megszervezését. telefonhálózatokáltalános használat (PSTN) az interneten, valamint a PSTN és az Internet előfizetők közötti telefonos kommunikáció.
Az IP-telefónia számos tagadhatatlan előnnyel rendelkezik, amelyek biztosítják gyors fejlődését és a számítógépes telefónia piacának bővülését. Előnyös azoknak a végfelhasználóknak, akik meglehetősen alacsony percdíj mellett kapnak telefonos kommunikációt. A távoli fiókokkal rendelkező vállalatok számára az IP technológia lehetővé teszi a hangkommunikáció megszervezését a meglévő vállalati IP-hálózatok használatával. Több kommunikációs hálózat helyett egyet használnak. Az IP-telefónia kétségtelen előnye egy hagyományos telefonnal szemben az is, hogy képes biztosítani további szolgáltatások multimédiás számítógép és különféle internetes alkalmazások használatával. Így az IP-telefónia révén a vállalkozások és magánszemélyek bővíthetik kommunikációs képességeiket fejlett videokonferencia, alkalmazásmegosztás, tábla típusú eszközök és egyebek beépítésével.
Milyen nemzetközi szabványok és protokollok szabályozzák az IP-telefóniában használt hardveres és szoftveres kommunikáció működésének főbb paramétereit és algoritmusait? Nyilvánvalóan, ahogy a neve is sugallja, ez a technológia az IP protokollon alapul, amelyet azonban nem csak telefonálásra használnak: eredetileg digitális adatok csomagkapcsolt IVS-re való továbbítására fejlesztették ki.
A nem garantált szolgáltatásminőséget biztosító hálózatokban (ide tartoznak az IP protokoll alapján épített hálózatok is) a csomagok elveszhetnek, megérkezésük sorrendje megváltozhat, a csomagokban továbbított adatok torzulhatnak. Különféle szállítási réteg-eljárásokat alkalmaznak a továbbított információk megbízható kézbesítésének biztosítására ilyen feltételek mellett. Digitális adatok továbbításakor erre a célra a TCP protokollt (Transmission Control Protocol) használják. Ez a protokoll megbízható adattovábbítást biztosít, és visszaállítja az eredeti csomagsorrendet. Ha hibát észlel egy csomagban, vagy a csomag elveszett, a TCP eljárások újraküldési kérést küldenek.
Az audio- és videokonferencia-alkalmazások esetében a csomagok késleltetése sokkal nagyobb hatással van a jelminőségre, mint az egyedi adattorzítások. A késések közötti különbségek hiányosságokhoz vezethetnek. Az ilyen alkalmazások eltérő szállítási réteg protokollt igényelnek, amely biztosítja a csomagok újrasorolását, minimális késleltetésű kézbesítést, valós idejű lejátszást pontosan meghatározott pillanatokban, forgalomtípus felismerést, csoportos küldést vagy kétirányú kommunikációt. Ilyen protokoll az RTP valós idejű szállítási protokoll (Real-Time Transport Protocol). Ez a protokoll szabályozza a multimédiás adatok csomagokban történő továbbítását az IVS-en keresztül szállítási szinten, és kiegészíti az RTCP (Real-Time Control Protocol) valós idejű adatátvitelt vezérlő protokollal. Az RTCP protokoll viszont biztosítja a multimédiás adatok kézbesítését, a szolgáltatás minőségének ellenőrzését, az aktuális kommunikációs munkamenet résztvevőiről szóló információk továbbítását, vezérlést és azonosítást, és néha az RTP protokoll részének tekintik.
Az IP-telefóniáról szóló számos publikáció megjegyzi, hogy a legtöbb hálózati berendezés és speciális szoftver ehhez a technológiához a Nemzetközi Távközlési Unió (ITU-T) távközlési szabványosítási ágazatának H.323 ajánlása alapján került kifejlesztésre (beleértve a TAPI 3.0-t, NetMeeting 2.0-t stb.). Hogyan kapcsolódik a H.323 az RTP-hez és az RTCP-hez? A H.323 egy tág fogalmi keret, amely sok más szabványt is tartalmaz, amelyek mindegyike az információátadás különböző aspektusaival foglalkozik. A legtöbb ilyen szabvány, például az audio- és videokodek szabványok rendelkeznek széles körű alkalmazás nem csak az IP-telefóniában. Ami az RTP / RTCP protokollokat illeti, ezek képezik a H.323 szabvány alapját, pontosan az IP technológia biztosítására összpontosítanak, és az IP-telefónia megszervezésének alapját képezik. Ez a cikk ezeknek a protokolloknak a figyelembevételével foglalkozik.
Az RTP valós idejű átviteli protokoll multimédiás adatok, például interaktív hang és videó végpontok közötti valós idejű átvitelét biztosítja. Ez a protokoll megvalósítja a forgalom típusának felismerését, a csomagok sorszámozását és a vele való munkát időbélyegekés sebességváltó vezérlés.
Az RTP protokoll művelete minden kimenő csomaghoz időbélyeget rendel. A fogadó oldalon a csomagok időbélyegei jelzik, hogy milyen sorrendben és milyen késleltetéssel kell lejátszani őket. Az RTP és az RTCP támogatása lehetővé teszi a fogadó gazdagép számára, hogy a fogadott csomagokat a megfelelő sorrendbe rendezze, csökkentse a csomagok késleltetésének a jelminőségre gyakorolt hatását a hálózaton, és helyreállítsa a hang és a kép közötti szinkronizálást, hogy a bejövő információ megfelelően hallható és megtekinthető legyen. felhasználók által.
Vegye figyelembe, hogy maga az RTP nem rendelkezik olyan mechanizmussal, amely garantálja az időszerű adatátvitelt és a szolgáltatás minőségét, de ennek biztosítására használja a mögöttes szolgáltatásokat. Nem akadályozza meg a soron kívüli csomagokat, de nem feltételezi, hogy az alapul szolgáló hálózat abszolút megbízható, és a csomagokat a megfelelő sorrendben továbbítja. Az RTP-ben szereplő sorszámok lehetővé teszik a fogadó számára, hogy újra szekvenciálja a küldő csomagjait.
RTP protokoll támogatja mind a kétirányú kommunikációt, mind az adatátvitelt a célállomások csoportjába, ha a csoportos küldést támogatja az alapul szolgáló hálózat. Az RTP-t úgy tervezték, hogy biztosítsa a szükséges információkat egyedi alkalmazások, és a legtöbb esetben integrálva van az alkalmazásba.
Bár az RTP-t szállítási réteg protokollnak tekintik, általában egy másik szállítási réteg protokollon, az UDP-n (User Datagram Protocol) felül működik. Mindkét protokoll hozzájárul a szállítási réteg funkcionalitásához. Megjegyzendő, hogy az RTP és az RTCP függetlenek az alapul szolgáló szállítási és hálózati rétegektől, így az RTP/RTCP protokollok más megfelelő szállítási protokollokkal is használhatók.
Az RTP/RTCP protokoll adategységeit csomagoknak nevezzük. Az RTP protokoll szerint előállított és multimédiás adatok továbbítására használt csomagokat információs csomagoknak vagy adatcsomagoknak (adatcsomagoknak), az RTCP protokoll szerint generált és a telekonferencia megbízható működéséhez szükséges szolgáltatási információk továbbítására használt csomagokat pedig nevezzük. csomagoknak nevezzük.vezérlő vagy szervizcsomagok (vezérlőcsomagok). Az RTP-csomag egy rögzített fejlécet, egy választható változó hosszúságú fejléc-kiterjesztést és egy adatmezőt tartalmaz. Az RTCP-csomag egy rögzített résszel kezdődik (hasonlóan az RTP információs csomagok rögzített részéhez), majd változó hosszúságú építőelemekkel.
Annak érdekében, hogy az RTP protokoll rugalmasabb és alkalmazható legyen a különböző alkalmazásokban, néhány paramétere szándékosan nincs meghatározva, de megadja a profil fogalmát. A profil (profil) az RTP és RTCP protokollok paramétereinek halmaza egy adott alkalmazásosztályhoz, amely meghatározza azok működésének jellemzőit. A profil meghatározza az egyes csomagfejléc-mezők, forgalomtípusok, fejléc-kiegészítések és fejléc-kiterjesztések, csomagtípusok, kommunikációs biztonsági szolgáltatások és algoritmusok használatát, az alapul szolgáló protokoll használatának jellemzőit stb. RTP-profil audio- és videokonferenciákhoz minimális vezérléssel ). Minden alkalmazás általában csak egy profillal működik, és a profiltípus beállítása a megfelelő alkalmazás kiválasztásával történik. A profil típusának nincs kifejezett jelzése portszám, protokollazonosító stb. szerint. nem biztosított.
Így egy adott alkalmazás teljes RTP-specifikációjának tartalmaznia kell további dokumentumokat, amelyek tartalmazzák a profilleírást, valamint a forgalmi formátum leírását, amely meghatározza, hogy egy adott típusú forgalom, például hang vagy videó hogyan kerül feldolgozásra az RTP-ben.
Az audio- és videokonferenciák során a multimédiás adatátvitel jellemzőit a következő fejezetek tárgyalják.
A csoportos audiokonferenciákhoz többfelhasználós csoportcímre és két portra van szükség. Ebben az esetben az egyik port szükséges az audio adatok cseréjéhez, a másik pedig az RTCP protokoll vezérlőcsomagjaihoz. A csoportcímet és a portinformációkat elküldik a telekonferencia tervezett résztvevőinek. Ha a titkosításra van szükség, akkor az információs és vezérlőcsomagok a 7.1. szakaszban meghatározottak szerint titkosíthatók, ebben az esetben a titkosítási kulcsot is elő kell állítani és el kell osztani.
A konferencia minden résztvevője által használt audiokonferencia-alkalmazás kis, például 20 ms-os sorozatokban küldi el a hangadatokat. Minden hangadatot egy RTP fejléc előz meg; az RTP fejlécet és az adatokat egy UDP-csomagba formálják (becsomagolják). Az RTP fejléc jelzi, hogy milyen típusú hangkódolást (pl. PCM, ADPCM vagy LPC) használtak a csomagban lévő adatok kialakításához. Ez lehetővé teszi a kódolás típusának megváltoztatását a konferencia során, például új résztvevő érkezésekor, aki alacsony sávszélességű kapcsolatot használ, vagy hálózati torlódások idején.
Az interneten, más csomagkapcsolt adathálózatokhoz hasonlóan, a csomagok időnként elvesznek, átrendeződnek, illetve különböző időre késnek. Ezen események ellensúlyozására az RTP fejléc tartalmaz egy időbélyeget és egy sorszámot, amely lehetővé teszi a vevők számára az újraidőzítést, így például egy hangjel egyes részeit a hangszóró folyamatosan játssza le 20 ms-onként. Ezt az időzítési rekonstrukciót külön-külön és függetlenül hajtják végre a telekonferencia RTP-csomagjainak minden egyes forrásához. A sorszámot a vevő is használhatja az elveszett csomagok számának becslésére.
Mivel a telekonferencia résztvevői csatlakozhatnak és kiléphetnek a telekonferencia során, hasznos tudni, hogy éppen kik vesznek részt a konferencián, és milyen jól fogadják a konferencia résztvevői a hangadatokat. Ebből a célból az audioalkalmazás minden egyes példánya a konferencia során rendszeresen kiad a vezérlőporton (RTCP port) az összes többi résztvevő alkalmazásai számára, csomagfogadási üzeneteket jelezve a felhasználónevüket. A fogadási üzenet jelzi, hogy mennyire jól hallható az aktuális hangszóró, és az adaptív kódolók vezérlésére használható. A felhasználónéven kívül a sávszélesség-szabályozáshoz egyéb azonosító információk is szerepelhetnek. A konferencia elhagyásakor a webhely RTCP BYE csomagot küld.
Ha egy telekonferencia során audio- és videojeleket is használnak, akkor azokat külön továbbítják. Az egyes forgalomtípusok átviteléhez, a másiktól függetlenül, a protokollspecifikáció bevezeti az RTP-munkamenet fogalmát (lásd a használt rövidítések és kifejezések listáját). A munkamenetet egy meghatározott célátviteli címpár határozza meg (egy hálózati cím plusz egy portpár RTP és RTCP számára). Az egyes forgalomtípusokhoz tartozó csomagok továbbítása két különböző pár UDP porton és/vagy csoportos küldési címen keresztül történik. Az audio- és videomunkamenetek között nincs közvetlen RTP-réteg-kapcsolat, kivéve, hogy a mindkét munkamenetben részt vevő felhasználónak ugyanazt a kanonikus nevet kell használnia az RTCP-csomagokban mindkét munkamenethez, hogy a munkamenetek összekapcsolhatók legyenek.
Ennek az elválasztásnak az egyik oka, hogy a konferencia egyes résztvevőinek csak egyfajta forgalom fogadását kell engedélyezni, ha akarják. Az elválasztás ellenére a forrás médiaadatok (audió és videó) szinkron lejátszása elérhető az RTCP-csomagokban lévő időzítési információk felhasználásával mindkét munkamenethez.
Nem mindig minden webhely képes ugyanabban a formátumban fogadni a multimédiás adatokat. Tekintsük azt az esetet, amikor az azonos helyről érkező résztvevők kis sebességű kapcsolaton keresztül csatlakoznak a konferencia többi résztvevőjének többségéhez, akik szélessávú hálózati hozzáféréssel rendelkeznek. Ahelyett, hogy mindenkit szűkebb sávszélesség és gyengébb minőségű hangkódolás használatára kényszerítenénk, egy RTP rétegű kommunikációs eszközt, amelyet keverőnek neveznek, elhelyezhetünk egy alacsony sávszélességű régióban. Ez a keverő újraszinkronizálja a bejövő audiocsomagokat, hogy visszaállítsa az eredeti 20 ms-os intervallumot, ezeket a visszaállított hangfolyamokat egyetlen adatfolyamba keveri, alacsony sávszélességű hangkódolást hajt végre, és a csomagfolyamot alacsony sebességű kapcsolaton keresztül továbbítja. Ebben az esetben a csomagok egy címzettnek vagy különböző címzettek csoportjának címezhetők. Annak érdekében, hogy a vételi végpontok helyesen jelezzék az üzenetek forrását, az RTP fejléc tartalmaz eszközöket a keverők számára, amelyek azonosítják a kevert csomag létrehozásában részt vevő forrásokat.
Előfordulhat, hogy az audiokonferencia egyes résztvevői szélessávú kommunikációs vonalakon csatlakoznak, de előfordulhat, hogy nem érhetők el IP multicast csoportkonferencián (IPM) keresztül. Például előfordulhat, hogy egy alkalmazási réteg tűzfala mögött vannak, amely nem engedélyezi az IP-csomagok továbbítását. Ilyen esetekben nem keverőkre van szükség, hanem egy másik típusú RTP rétegű kommunikációra, az úgynevezett fordítókra. A két fordító közül az egyik a tűzfalon kívül van telepítve, és kívülről továbbítja az összes, biztonságos kapcsolaton keresztül kapott multicast csomagot a másik, a tűzfal mögé telepített fordítónak. A tűzfal mögötti fordító ismét multicast csomagként sugározza őket egy többfelhasználós csoportnak belső hálózat webhely.
A keverőket és a fordítókat számos célra lehet tervezni. Példa: Videókeverő, amely független videofolyamokban skálázza az egyének videoképét, és egyetlen videófolyamba állítja össze őket, szimulálva egy csoportos jelenetet. Példák a szórásra: Csak IP/UDP-állomások csoportjának csatlakoztatása csak ST-II-t használó gazdagépek csoportjához, vagy videó csomagonkénti átkódolása az egyes forrásokból újratöltés vagy keverés nélkül. A keverők és fordítók működésének részleteit az 5. szakasz tárgyalja.
Az RTP/RTCP csomagok összes mezője bájtokban (oktettekben) kerül továbbításra a hálózaton; a legjelentősebb bájt kerül először továbbításra. Minden fejlécmezőadat a hosszának megfelelően igazodik . Az opcionálisként megjelölt okettek értéke nulla.
Az abszolút időt (Wallclock time) az RTP-ben az NTP (Network Time Protocol) időbélyegző formátuma adja meg, amely az 1900. január 1-jei nulla órához viszonyított másodpercben megadott visszaszámlálás. A teljes NTP időbélyeg formátuma egy 64 bites előjel nélküli fixpontos szám, amelynek az első 32 bitben egy egész szám, az utolsó 32 bitben pedig egy tört rész található. Néhány kompaktabb megjelenítésű mezőben csak a középső 32 bitet használják - az egész rész alsó 16 bitjét és a tört rész magas 16 bitjét.
A cikk következő két része (3. és 4.) az RTP és az RTCP protokollok csomagformátumait és működési jellemzőit tárgyalja.
Ahogy fentebb megjegyeztük, az RTP-csomag tartalmaz egy rögzített fejlécet, egy opcionális változó hosszúságú fejléc-kiterjesztést és egy adatmezőt. Az RTP protokoll csomagok rögzített fejlécének formátuma a következő: .
Az első tizenkét oktett minden RTP csomagban megtalálható, míg a közreműködő forrás CSRC (contributing source) azonosító mező csak akkor van jelen, ha a keverő beilleszti. A mezőknek a következő céljai vannak.
Verzió (V): 2 bites. Ez a mező azonosítja az RTP verziót. Ez a cikk az RTP-protokoll 2-es verziójára összpontosít (az RTP első vázlatos verziójában az 1-es értéket használták).
Komplement (P): 1 bit. Ha a kitöltőbit egyre van állítva, akkor a végén lévő csomag egy vagy több olyan kitöltési oktettet tartalmaz, amelyek nem részei a forgalomnak. Az utolsó kitöltő oktett jelzi a később figyelmen kívül hagyandó ilyen oktettek számát. Egyes, rögzített blokkmérettel rendelkező titkosítási algoritmusok vagy több RTP-csomag egyetlen mögöttes protokoll-adattartalomban történő szállításához kitöltésre lehet szükség.
Kiterjesztés (X): 1 bit. Ha a kiterjesztési bit be van állítva, akkor a rögzített fejlécet egy fejlécbővítmény követi, amelynek formátuma a -ban van definiálva.
CSRC számláló (CC): 4 bit. A CSRC-számláló a rögzített fejlécet követő CSRC-forrásazonosítók számát tartalmazza (lásd a használt rövidítések és kifejezések listáját).
Marker (M): 1 bit. A marker értelmezését a profil határozza meg. Célja, hogy lehetővé tegye jelentős események (pl. videó kerethatárok) megjelölését a csomagfolyamban. A profil további jelölőbiteket vezethet be, vagy meghatározhatja, hogy nincs jelen jelölőbit a bitek számának megváltoztatásával a forgalomtípus mezőben (lásd ).
Forgalom típusa (PT): 7 bit. Ez a mező azonosítja az RTP forgalom formátumát, és meghatározza, hogy az alkalmazás hogyan értelmezze azt. A profil a PT értékek és a forgalmi formátumok alapértelmezett statikus leképezését határozza meg. További forgalomtípus kódok dinamikusan definiálhatók nem RTP eszközökön keresztül. Az RTP-csomag küldője bármely adott időpontban egyetlen RTP forgalomtípus értéket bocsát ki; ez a mező nem egyedi médiafolyamok multiplexelésére szolgál (lásd ).
Sorozatszám: 16 bit. A sorszám értéke eggyel növekszik minden egyes elküldött RTP információs csomaggal, és a vevő felhasználhatja az elveszett csomagok észlelésére és az eredeti sorrend visszaállítására. A sorszám kezdeti értékét véletlenszerűen választják ki, hogy megnehezítsék a kulcs feltörését a mező ismert értékei alapján (még akkor is, ha a forrás nem használ titkosítást, mivel a csomagok áthaladhatnak egy titkosítást használó közvetítőn). Időbélyeg: 32 bit. Az időbélyeg az RTP információs csomag első oktettjének mintavételi idejét tükrözi. A mintavételezési időt egy időzítőből kell származtatni, amely monoton és lineárisan növekszik az idő függvényében a szinkronizálás és a jitter észlelése érdekében (lásd a 4.3.1. szakaszt). Az időzítő felbontásának elegendőnek kell lennie a kívánt időzítési pontossághoz és a csomagérkezési jitter méréshez (videókockánként általában nem elegendő egy időzítő jelentés). Az időzítési frekvencia az átvitt forgalom formátumától függ, és statikusan van beállítva a forgalmi formátum profiljában vagy specifikációjában, vagy dinamikusan beállítható a "nem RTP eszközökön keresztül" meghatározott forgalmi formátumokhoz. Ha az RTP-csomagokat periodikusan generálják, akkor a mintavételi időzítő által meghatározott névleges mintavételi időket kell használni, nem a rendszeridőzítő értékeit. Például egy rögzített sebességű audiojel esetében kívánatos, hogy az időbélyegző kódoló értéke eggyel növekedjen minden mintaperiódushoz. Ha egy audioalkalmazás egy bemeneti eszközről 160 mintát tartalmazó blokkokat olvas be, akkor az időbélyeget minden egyes ilyen blokknál 160-al kell növelni, függetlenül attól, hogy a blokkot csomagban küldték-e el, vagy szünetként hagyták el. Az időbélyeg kezdőértéke, akárcsak a sorszám kezdőértéke, egy valószínűségi változó. Több egymást követő RTP csomag azonos időbélyeggel rendelkezhet, ha logikailag egyidejűleg generálódik, pl. ugyanahhoz a videokockához tartoznak. Az egymást követő RTP-csomagok nem monoton időbélyegeket tartalmazhatnak, ha az adatok nem minta sorrendben kerülnek továbbításra, mint az interpolált MPEG videokockák esetében (a csomagok sorszámai azonban továbbra is monotonok lesznek átvitelkor).
SSRC: 32 bit. Az SSRC (szinkronizálási forrás) mező azonosítja a szinkronizálási forrást (lásd a használt rövidítések és kifejezések listáját). Ezt az azonosítót véletlenszerűen választják ki, hogy egyetlen RTP-munkameneten belül ne legyen két óraforrásnak ugyanaz az SSRC azonosítója. Bár kicsi annak a valószínűsége, hogy több forrás ugyanazt az azonosítót választja, minden RTP-megvalósításnak fel kell készülnie az ilyen ütközések észlelésére és megoldására. A 6. szakasz tárgyalja az ütközések valószínűségét, valamint a megoldásukra és az RTP-réteg hurkok észlelésére szolgáló mechanizmust az SSRC azonosító egyedisége alapján. Ha egy forrás megváltoztatja az eredeti szállítási címét, akkor új SSRC azonosítót is kell választania, hogy ne legyen hurkolt forrásként értelmezve.
CSRC lista: 0-15 elem, mindegyik 32 bit. A hozzájáruló források (CSRC) listája azonosítja a csomagban található forgalom forrásait. Az azonosítók számát a CC mező adja meg. Ha több mint tizenöt forrás szerepel, akkor ezek közül csak 15 azonosítható. A CSRC azonosítókat a keverők illesztik be, amikor SSRC azonosítókat használnak kapcsolt forrásokhoz. Például a hangcsomagok esetében a csomag létrehozásakor kevert összes forrás SSRC azonosítója szerepel a CSRC listában, amely helyes jelzést ad az üzenetforrásokról a címzettnek.
Mint fentebb említettük, az RTP protokollnak megfelelően a különböző típusú forgalmat külön-külön, különböző RTP munkamenetekben kell továbbítani. A munkamenetet egy meghatározott célátviteli címpár határozza meg (egy hálózati cím plusz egy portpár RTP és RTCP számára). Például egy külön kódolt hangból és videóból álló telekonferencia esetén minden egyes forgalomtípust külön RTP-munkamenetben kell elküldeni saját célszállítási címmel. A hang és a kép nem várható ugyanabban az RTP-munkamenetben, és nem különül el egymástól a forgalom típusa vagy az SSRC mezők alapján. Csomagok átlapolása Különféle típusok forgalom, de ugyanazon SSRC használata problémákat okozhat:
Ha az egyes forgalomtípusokhoz különböző SSRC-ket használunk, de azokat ugyanabban az RTP-munkamenetben küldjük el, az első három probléma elkerülhető, az utolsó kettő viszont nem. Ezért az RTP-protokoll specifikációja megköveteli, hogy minden forgalomtípus saját RTP-munkamenetet használjon.
A meglévő RTP Information Packet fejléc teljes az összes olyan alkalmazás-osztályhoz általánosan szükséges szolgáltatásokhoz, amelyek támogathatják az RTP-t. A konkrét feladatokhoz való jobb alkalmazkodás érdekében azonban a fejléc módosítható a profilspecifikációban meghatározott módosításokkal vagy kiegészítésekkel.
A jelölőbit és a forgalomtípus mező profilspecifikus információkat hordoz, de rögzített fejlécben találhatók, mivel sok alkalmazásnak szüksége van rájuk. Az ezeket a mezőket tartalmazó oktett a profillal újradefiniálható, hogy megfeleljen a különböző követelményeknek, például több vagy kevesebb jelölőbittel. Ha vannak jelölőbitek, azokat az oktett magasabb rendű bitjeibe kell helyezni, mivel a profilfüggetlen monitorok képesek lehetnek megfigyelni a korrelációt a csomagvesztési minta és a markerbit között.
Egy adott forgalmi formátumhoz (pl. videó kódolási típus) szükséges további információkat KELL a csomag adatmezőjében vinni. Elhelyezhető egy adott helyen az adattömb elején vagy belsejében.
Ha egy adott alkalmazásosztálynak a forgalmi formátumtól független további funkcionalitásra van szüksége, akkor a profilnak, amellyel ezek az alkalmazások működnek, további rögzített mezőket kell meghatároznia, amelyeket közvetlenül a meglévő rögzített fejléc SSRC mezője után kell elhelyezni. Ezek az alkalmazások gyorsan képesek lesznek közvetlenül elérni további mezőket, míg a profilfüggetlen monitorok vagy felvevők továbbra is képesek lesznek RTP-csomagok feldolgozására, csak az első tizenkét oktett értelmezésével.
Ha úgy ítéljük meg, hogy általánosságban minden profilhoz további funkciókra van szükség, akkor a egy új verzió RTP állandó, rögzített címmódosításhoz.
Az RTP csomagfejléc-bővítési mechanizmust biztosít annak érdekében, hogy az egyes megvalósítások kísérletezzenek új, forgalmi formátumtól független szolgáltatásokkal, amelyek további információkat igényelnek az információs csomag fejlécében. Ezt a mechanizmust úgy alakították ki, hogy a fejlécbővítményt figyelmen kívül hagyhassák más együttműködő alkalmazások, amelyek nem igénylik azt.
Ha az RTP-fejléc X bitje 1-re van állítva, akkor a rögzített RTP-fejléchez egy változó hosszúságú fejlécbővítmény kerül (a CSRC-lista nyomán, ha van ilyen). Vegye figyelembe, hogy ez a fejlécbővítmény csak korlátozottan használható. Az RTP csomagfejléc-kiterjesztés a következő formátumú:
A kiterjesztés tartalmaz egy 16 bites hosszúságú mezőt, amely a benne lévő 32 bites szavak számát jelzi, kivéve a négy oktettből álló fejlécet (ezért a hossza nulla is lehet). Egy rögzített RTP információs csomag fejlécéhez csak egy kiterjesztés adható hozzá. Annak érdekében, hogy az együttműködő megvalósítások mindegyike egymástól függetlenül kísérletezzen különböző fejléc-kiterjesztésekkel, vagy hogy egy adott implementáció egynél több típusú fejlécbővítménnyel kísérletezzen, a kiterjesztés első 16 bitjének használata nincs meghatározva, a megkülönböztetéstől függően. azonosítók vagy paraméterek. Ennek a 16 bitnek a formátumát annak a profilspecifikációnak kell meghatároznia, amellyel az alkalmazások dolgoznak.
| 1999 | ||||||||||||
| 2000 |
A TCP / IP protokollveremen alapuló többféle forgalom támogatásának követelménye a szolgáltatás minőségének eltérő követelményeivel most nagyon fontos. Ezt a problémát a Real-Time Transport Protocol (RTP) oldja meg, amely egy IETF-szabvány az adatok, például hang vagy videó valós idejű továbbítására hálózaton keresztül, amely nem garantálja a szolgáltatás minőségét.
Az RTP protokoll garantálja az adatok egy vagy több címzetthez történő eljuttatását a megadott értéket meg nem haladó késéssel. Ehhez a protokoll fejléce tartalmazza a hang- és képinformáció sikeres helyreállításához szükséges időbélyegeket, valamint az információ kódolási módjára vonatkozó adatokat.
Bár a TCP protokoll garantálja a továbbított adatok megfelelő sorrendben történő kézbesítését, a forgalom nem egyenletes, vagyis a datagramok kézbesítése során előre nem látható késések lépnek fel. Mivel az RTP protokoll ismeri a datagramok tartalmát, és rendelkezik adatvesztés-észlelő mechanizmusokkal, a késleltetést elfogadható szintre tudja csökkenteni.
IP protokoll címséma
Az IP-protokollban használt hálózati címzési sémát az RFC 990 és az RFC 997 írja le. Ez a címzési hálózatok és az ezekben a hálózatokban található címzési eszközök elválasztásán alapul. Ez a séma megkönnyíti az útválasztást. Ebben az esetben a címeket rendezetten (egymást követve) kell kiosztani az útválasztás hatékonyabbá tétele érdekében.
Ha a hálózaton a TCP / IP protokollvermet használja, a végeszközök egyedi címeket kapnak. Ilyen eszközök lehetnek személyi számítógépek, médiaszerverek, útválasztók stb. Azonban néhány több fizikai porttal rendelkező eszköz, például útválasztó, mindegyik porton egyedi címmel kell rendelkeznie. A címzési séma és az a tény alapján, hogy a hálózat egyes eszközei több címmel is rendelkezhetnek, arra következtethetünk ezt a sémát A címzés nem magát az eszközt írja le a hálózaton, hanem ennek az eszköznek a hálózathoz való konkrét csatlakozását. Ez a rendszer számos kellemetlenséggel jár. Az egyik az, hogy meg kell változtatni az eszköz címét egy másik hálózatba való áthelyezéskor. Egy másik hátránya, hogy egy elosztott hálózaton több kapcsolattal rendelkező eszközzel való munkavégzéshez ismernie kell az összes olyan címet, amely azonosítja ezeket a kapcsolatokat.
Tehát az IP-hálózatok minden egyes eszközéhez három szintű címről beszélhetünk:
q Az eszköz fizikai címe (pontosabban egy adott interfész). Az Ethernet hálózaton lévő eszközök esetében ez a MAC-cím hálózati kártya vagy router port. Ezeket a címeket a hardvergyártók osztják ki. A fizikai cím hat bájtból áll: a felső három bájt a gyártó azonosítója, az alsó három bájt a gyártó által hozzárendelt;
q Négy bájtból álló IP-cím. Ezt a címet a hálózati réteg használja referencia modell OSI;
q Karakterazonosító - név. Ezt az azonosítót az adminisztrátor tetszőlegesen hozzárendelheti.
Amikor az IP protokollt 1981 szeptemberében szabványosították, a specifikációja megkövetelte, hogy minden hálózathoz csatlakoztatott eszköznek egyedi 32 bites címe legyen. Ez a cím két részre oszlik. A cím első része azonosítja a hálózatot, ahol az eszköz található. A második rész magát az eszközt egyedileg azonosítja a hálózaton belül. Ez a séma kétszintű címhierarchiához vezet (6.23. ábra).
Most a címben található hálózati szám mezőt hívják meg hálózati előtag, mert azonosítja a hálózatot. A hálózaton lévő összes munkaállomás ugyanazt a hálózati előtagot használja. Azonban egyedi eszközszámmal kell rendelkezniük. Két munkaállomás található különböző hálózatok, különböző hálózati előtagokkal kell rendelkezniük, de lehet, hogy ugyanaz az eszközszám.
A rugalmasságért a címzésben számítógépes hálózatok A protokoll tervezői megállapították, hogy az IP-címteret három különböző osztályra kell osztani - A, B és C. Az osztály ismeretében tudja, hol van a határ a hálózati előtag és az eszközszám között egy 32 bites címben. . ábrán. A 6.24. ábra mutatja ezen alaposztályok címformátumait.
Az osztályok használatának egyik fő előnye, hogy a cím osztályából megállapítható, hogy hol van a határ a hálózati előtag és az eszközszám között. Például, ha a cím két legjelentősebb bitje 10, akkor a felosztási pont a 15 és 16 bit között van.
Ennek a módszernek a hátránya, hogy további eszközök csatlakoztatásakor meg kell változtatni a hálózati címet. Például, ha egy C osztályú hálózatban az összes eszköz száma meghaladja a 255-öt, akkor a címeit ki kell cserélni B osztályú címekre. A hálózati rendszergazdák nem tudnak zökkenőmentesen áttérni egy új címosztályra, mert az osztályok egyértelműen el vannak választva. Meg kell tiltania a hálózati címek egy teljes csoportjának használatát, egyszerre kell módosítania az ebbe a csoportba tartozó eszközök összes címét, és csak ezután engedélyeznie kell azok használatát a hálózaton. Emellett a címosztályok bevezetése jelentősen csökkenti az egyes címek elméletileg lehetséges számát. BAN BEN jelenlegi verzió IP protokoll (4-es verzió) a címek teljes száma 2 32 (4 294 967 296) lehet, mivel a protokoll 32 bit használatát írja elő a cím megadásához. Természetesen egyes bitek szolgáltatási célú felhasználása csökkenti a rendelkezésre álló egyedi címek számát.
Az A osztály a nagy hálózatokhoz való. Minden A osztályú címnek van egy 8 bites hálózati előtagja, a legjelentősebb bit 1-re van állítva, a következő hét bit pedig a hálózati számhoz használatos. A fennmaradó 24 bit az eszközszámhoz lesz felhasználva. Jelenleg az összes A osztályú cím már ki van osztva. Az A osztályú hálózatokat "/8"-nak is nevezik, mivel az A osztályú címek 8 bites hálózati előtaggal rendelkeznek.
Az A osztályú hálózatok maximális száma 126 (2 7 -2 - két címet levonunk, amelyek csak nullákból és egyesekből állnak). Ennek az osztálynak minden hálózata legfeljebb 16 777 214 (2 24 -2) eszközt támogat. Mivel egy A osztályú címblokk legfeljebb 231 (2 147483648) egyedi címet tartalmazhat, az IP 4-es verzió pedig legfeljebb 232 (4 294 967 296) címet támogathat, az A osztály a teljes IP-címterület 50%-át foglalja el.
A B osztály közepes méretű hálózatokhoz készült. Minden B osztályú címnek van egy 16 bites hálózati előtagja, ahol a két legjelentősebb bit 10, a következő 14 bit pedig a hálózati számot használja. Az eszközszámhoz 16 bit van lefoglalva. A B osztályú hálózatokat "/16"-nak is nevezik, mivel a B osztályú címek 16 bites hálózati előtaggal rendelkeznek.
A B osztályú hálózatok maximális száma 16 382 (2 14 -2). Ennek az osztálynak minden hálózata legfeljebb 65 534 (2 16 -2) eszközt támogat. Mivel egy teljes B osztályú címblokk legfeljebb 230 (1 073 741 824) egyedi címet tartalmazhat, a teljes IP-címterület 25%-át foglalja el.
A C osztályú címeket kis számú eszközzel rendelkező hálózatokban használják. Minden C osztályú hálózatnak van egy 24 bites hálózati előtagja, amelyben a három legjelentősebb bit 110, a következő 21 bit pedig a hálózat számának felel meg. A fennmaradó 8 bit az eszközszámokhoz van lefoglalva. A C osztályú hálózatokat "/24"-nek is nevezik, mivel a C osztályú címek 24 bites hálózati előtaggal rendelkeznek.
A C osztályú hálózatok maximális száma 2 097 152 (221). Ennek az osztálynak minden hálózata legfeljebb 254 (2 8 -2) eszközt támogat. A C osztály a teljes IP-címterület 12,5%-át foglalja el.
táblázatban. A 6.9 összefoglalja a hálózati osztályok elemzését.
6.9. táblázat. Hálózati osztályok
Ezen a három címosztályon kívül van még két osztály. A D osztályban a legjelentősebb négy bit az 1110. Ezt az osztályt csoportos küldésre használják. Az E osztályban a felső négy bit 1111. Kísérletezésre van fenntartva.
A címek olvashatósága érdekében a szakirodalomban, az alkalmazási programokban stb. az IP-címeket négy tizedes számmal jelöljük, pontokkal elválasztva. Ezen számok mindegyike az IP-cím egy oktettjének (8 bit) felel meg. Ezt a formátumot pontozott decimális (Decimal-Point Notation) vagy pontozott decimális jelölésnek (6.25. ábra) nevezik.
táblázatban. A 6.10 felsorolja a decimális értékek tartományait a három címosztályhoz. táblázatban. 6.10 Az XXX bejegyzés tetszőleges mezőt jelent.
6.10. táblázat. Cím értéktartományok
Egyes IP-címek nem rendelhetők hozzá a hálózaton lévő eszközökhöz (6.11. táblázat).
Amint az ebben a táblázatban látható, a fenntartott IP-címekben minden nullára állított bit megfelel bármelyiknek ez az eszköz, vagy ez a hálózat, és az IP-címek, amelyeknek minden bitje 1-re van állítva, az információk továbbítására szolgál. A teljes IP-hálózat egészére való hivatkozáshoz egy címet használunk egy eszközszámmal, és minden bitet „0”-ra állítunk. Az A osztályú 127.0.0.0 hálózati cím a visszahurkoláshoz van fenntartva, és az ugyanazon a gépen lévő folyamatok közötti kommunikáció tesztelésére szolgál. Amikor egy alkalmazás hurokcímet használ, a TCP/IP protokollverem visszaküldi ezeket az adatokat az alkalmazásnak anélkül, hogy bármit is küldene a hálózatnak. Ezenkívül ez a cím használható különálló folyamatok interakciójára ugyanazon a gépen belül. Ezért az IP hálózatokban tilos 127-tel kezdődő IP-címeket rendelni az eszközökhöz.
Az egy adott munkaállomásra irányított adatátvitel mellett aktívan használják a broadcast átvitelt, amelyben az aktuális vagy meghatározott hálózat összes állomása információt kap. Az IP-protokollban kétféle adás van: irányított és korlátozott.
Az irányított sugárzás lehetővé teszi egy távoli hálózaton lévő eszköz számára, hogy datagrammot küldjön az aktuális hálózat összes eszközére. A továbbított broadcast címmel rendelkező datagram áthaladhat az útválasztókon, de csak a megadott hálózaton lévő összes eszközre érkezik, nem minden eszközre. Irányított üzenetszórás esetén a célcím egy meghatározott hálózati számból és egy eszközszámból áll, amelyek minden bitje 0 vagy 1. Például a 185.100.255.255 és 185.100.0.0 címeket a B osztály irányított szórási címeként kezeljük. 185.100.xxx.xxx hálózat Címzési szempontból az irányított sugárzás fő hátránya, hogy a célhálózat számának ismerete szükséges.
A sugárzás második formája, az úgynevezett korlátozott broadcast, az aktuális hálózaton belül sugároz (a küldő eszköz hálózatán belül). A korlátozott szórási címmel rendelkező datagram soha nem megy át az útválasztón. Korlátozott sugárzás esetén a hálózatszám és az eszközszám bitjei mind nullák vagy egyesek. Így egy 255.255.255.255 vagy 0.0.0.0 célcímű datagram a hálózat összes eszközére kerül. ábrán. A 6.26. ábra az útválasztókkal összekapcsolt hálózatokat mutatja. táblázatban. A 6.12 ábra felsorolja az A munkaállomás által küldött broadcast datagramok címzettjeit.
Az IP-protokoll három címzési módot támogat: egyszeri (egyedi küldés), broadcast (broadcast) és csoportos (multicast).
6.12. táblázat. Broadcast Datagram vevők
Egyetlen címzés esetén a datagramok egy adott eszközre kerülnek elküldésre. Ennek a megközelítésnek a megvalósítása nem nehéz, de ha munkacsoport sok állomást tartalmaz, előfordulhat, hogy az átviteli sebesség nem lesz elegendő, mivel ugyanazt a datagramot sokszor továbbítják.
A szórásos címzéssel az alkalmazások egyetlen datagrammot küldenek, amely a hálózat összes eszközére eljut. Ez a megközelítés még egyszerűbb megvalósítani, de ha ebben az esetben a broadcast forgalom nem korlátozódik a helyi hálózatra (és például egy másik hálózatot továbbítanak routerek segítségével), akkor globális hálózat jelentősnek kell lennie áteresztőképesség. Ha az információ csak eszközök egy kis csoportjára vonatkozik, akkor ez a megközelítés irracionálisnak tűnik.
A csoportos küldés során a datagramok az eszközök meghatározott csoportjához kerülnek. Ugyanakkor (ami nagyon fontos elosztott hálózatokban végzett munka során) nem keletkezik többletforgalom. A multicast és az egycímű datagramok címben különböznek. A multicastot tartalmazó IP-datagramok fejlécében az A, B, C osztályú IP-címek helyett D osztályú cím, azaz csoportcím található.
Egy csoportcím van hozzárendelve néhány címzett eszközhöz vagy más szóval egy csoporthoz. A feladó ezt a multicast címet írja be az IP datagram fejlécébe. A datagramot a csoport minden tagja megkapja. A D osztályú cím első négy bitje 1110. A cím többi részét (28 bitet) a csoportazonosító foglalja el (6.27. ábra).
Pontozott decimális formátumban a csoportcímek 224.0.0.0 és 239.255.255.255 között mozognak. táblázatban. A 6.13. ábra a D osztályú címkiosztási sémát mutatja.
6.13. táblázat. D osztályú címkiosztás
Amint az a táblázatból látható. 6.13, az első 256 cím le van foglalva. Ez a tartomány különösen az útválasztási protokollok és más alacsony szintű protokollok számára van fenntartva. táblázatban. A 6.14 tartalmaz néhány fenntartott D osztályú IP-címet.
E tartomány felett található az interneten futó alkalmazások számára fenntartott címek nagy csoportja. A legfelső címtartomány (körülbelül 16 millió cím) adminisztratív célokat szolgál helyi hálózatok. A D osztályú csoportcímeket az IANA nevű speciális szervezet központilag kezeli és regisztrálja.
A multicast az OSI modell két szintjén valósítható meg - csatorna (Data-Link Layer) és hálózat (Network Layer). A kapcsolati réteg átviteli protokolljai, mint például az Ethernet és az FDDI, támogatják az egyszeri, broadcast és multicast címzést. A kapcsolati rétegű csoportos küldés különösen akkor hatékony, ha a hálózati kártyán a hardver támogatja.
Az IANA multicasting támogatása érdekében csoportos Ethernet címek blokkját osztották ki, 01-00-5E-től kezdve (hexadecimális jelöléssel). A csoportos küldés IP-címe lefordítható ebben a blokkban található címre. A fordítás elve meglehetősen egyszerű: az IP-csoport azonosító alsó 23 bitje az Ethernet cím alsó 23 bitjébe másolódik. Vegye figyelembe, hogy ez a séma legfeljebb 32 különböző IP-csoportot társít ugyanazzal az Ethernet-címmel, mivel az IP-csoport azonosítójának következő 5 bitje figyelmen kívül marad.
6.14. táblázat. Fenntartott D osztályú címek
| Cím | Célja |
| 224.0.0.1 | Minden eszköz az alhálózaton |
| 224.0.0.2 | Az összes útválasztó az alhálózaton |
| 224.0.0.4 | Minden DVMRP router |
| 224.0.0.5 | Minden MOSPF router |
| 224.0.0.9 | RIP IP Verzió II |
| 224.0.1.7 | hangos hírek |
| 224.0.1.11 | IEFT audio |
| 224.0.1.12 | IEFT videó |
Ha a feladó és a címzett ugyanahhoz tartozik fizikai hálózat, a multicast keretek küldésének és fogadásának folyamata a kapcsolati rétegen meglehetősen egyszerű. A feladó megadja a címzettek csoportjának IP-címét, a hálózati kártya pedig ezt a címet a megfelelő csoport Ethernet-címévé alakítja, és elküldi a keretet.
Ha a küldő és a fogadó különböző, útválasztókkal összekapcsolt alhálózatokon van, a datagramok szállítása nehézkes. Ebben az esetben az útválasztóknak támogatniuk kell az egyik csoportos küldési útválasztási protokollt (DVMRP, MOSPF, PIM – lásd alább). E protokollok szerint az útválasztó létrehoz egy kézbesítési fát, és megfelelően továbbítja a csoportos küldést. Ezenkívül minden útválasztónak támogatnia kell a Group Management Protocol (IGMP) protokollt, hogy meghatározza a csoporttagok jelenlétét a közvetlenül kapcsolódó alhálózatokon (6.28. ábra).
A multimédiás alkalmazások fő szállítási protokollja az RTP (Real-Time Protocol) valós idejű protokoll lett, amelyet a kódolt beszédjeleket tartalmazó csomagok IP-hálózaton történő továbbításának megszervezésére terveztek. Az RTP csomagok továbbítása UDP protokollon keresztül történik, amely viszont IP-n keresztül működik (1.5. ábra).
Rizs. 1.5.
Valójában az a szint, amelyhez az RTP tartozik, nincs olyan egyértelműen meghatározva, mint az ábra mutatja. 1.5 és ahogy azt a szakirodalom általában leírja. Egyrészt UDP-n felül tényleg működik a protokoll, implementálva van alkalmazási programokés minden jel szerint egy alkalmazási protokoll. Ugyanakkor, amint az e bekezdés elején is szerepel, az RTP a multimédiás alkalmazásoktól függetlenül nyújt szállítási szolgáltatásokat, és ebből a szempontból csupán egy szállítási protokoll. Legjobb definíció: Az RTP az alkalmazási rétegben megvalósított szállítási protokoll.
A beszéd (multimédiás) forgalom továbbítására az RTP csomagokat használ, amelyek felépítését az ábra mutatja. 1.6.
Egy RTP-csomag legalább 12 bájtból áll. Az RTP fejléc első két bitje (verzió bitmező, V) az RTP protokoll verzióját jelzi (jelenleg 2. verzió).
Nyilvánvaló, hogy ezzel a fejlécszerkezettel legfeljebb egy RTP-verzió lehetséges. Az őket követő mező két bitet tartalmaz: a P bitet, amely jelzi, hogy a hasznos adatmező végére kerültek-e kitöltési karakterek (ezeket általában akkor adják hozzá, ha a szállítási protokoll vagy a kódoló algoritmus fix méretű blokkok használatát írja elő), és az X bit, amely azt jelzi, hogy kiterjesztett fejlécet használnak-e.
Rizs. 1.6.
Ha használjuk, a kiterjesztett fejléc első szava tartalmazza a kiterjesztés teljes hosszát. Továbbá a négy CC bit határozza meg a CSRC mezők számát az RTP fejléc végén, azaz. az áramlást alkotó források száma. Az M jelölőbit lehetővé teszi, hogy megjelölje azt, amit a szabvány jelentős eseményként határoz meg, például egy videó képkocka elejét, egy szó elejét egy hangcsatornában stb. Ezt követi egy PT adattípus mező (7 bit), amely a hasznos adatmező tartalmát meghatározó hasznos adattípus kódot jelöli - alkalmazásadatok (Application Data), például tömörítetlen 8 bites MP3 hang stb. Ebből a kódból az alkalmazás megtanulhatja, mit kell tennie az adatok dekódolásához. A rögzített hosszúságú fejléc többi része egy Sorozatszám mezőből, egy Időbélyeg mezőből áll, amely rögzíti a csomag első szavának létrehozását, és egy SSRC időzítési forrásmezőt, amely azonosítja ezt a forrást. Az utolsó mező lehet egyetlen eszköz egyetlen hálózati címmel, több forrás, amely különböző médiát (hang, videó stb.) képviselhet, vagy ugyanazon média különböző adatfolyamait. Mivel a források lehetnek különböző eszközök, az SSRC azonosító véletlenszerűen kerül kiválasztásra, így minimális az esélye annak, hogy egy RTP-munkamenet során egyszerre két forrásból kapjanak adatokat. Meghatározzák azonban a konfliktusok feloldásának mechanizmusát is, ha azok felmerülnek. Az RTP fejléc rögzített részét legfeljebb 15 különálló 32 bites CSRC mező követheti, amelyek azonosítják az adatforrásokat.
Az RTP-t a Real-Time Transport Control Protocol (RTCP) támogatja, amely további, az RTP-munkamenetekről szóló információkat tartalmazó jelentéseket állít elő. Emlékezzünk vissza, hogy sem az UDP, sem az RTP nem foglalkozik QoS (Quality of Service) biztosításával. Az RTCP protokoll biztosítja Visszacsatolás küldőkkel, a stream vevők esetében pedig néhány QoS fejlesztést, csomaginformációkat (vesztés, késleltetés, jitter) és felhasználói (alkalmazás, adatfolyam) információkat biztosít. Az áramlásvezérléshez kétféle jelentés létezik – a feladók és a címzettek. Például az elveszett csomagok százalékos arányára és a veszteségek abszolút számára vonatkozó információ lehetővé teszi a küldő számára, hogy a jelentés fogadásakor észlelje, hogy a csatorna torlódása miatt a vevők nem kapják meg a várt csomagfolyamokat. Ebben az esetben a küldőnek lehetősége van csökkenteni a kódolási sebességet a torlódások csökkentése és a vétel javítása érdekében. A feladó jelentés információkat tartalmaz arról, hogy mikor jött létre az utolsó RTP-csomag (egy belső időbélyeget és valós időt is tartalmaz). Ez az információ lehetővé teszi a címzett számára, hogy koordináljon és szinkronizáljon több adatfolyamot, például videót és hangot. Ha az adatfolyamot több címzetthez irányítják, akkor mindegyikből származó RTCP-csomagok folyamai kerülnek megszervezésre. Ez lépéseket tesz a sávszélesség korlátozására – fordítottan arányosan az RTCP-jelentések generálási sebességével és a címzettek számával.
Megjegyzendő, hogy bár az RTCP az RTP-től elkülönülten működik, maga az RTP/UDP/IP lánc jelentős többletterheléshez vezet (a fejlécek formájában). A G.729 kodek 10 bájtos csomagokat generál (80 bit 10 ms-onként). Egy RTP fejléc, 12 bájt méretű, nagyobb, mint ez a teljes csomag. Ezen kívül egy 8 bájtos UDP-fejlécet és egy 20-bájtos IP-fejlécet (IPv4-ben) kell hozzá adni, ami a továbbított adatok négyszeresének megfelelő fejlécet hoz létre.
