Jó napot
Összefoglalva: a felügyeleti rendszer az n-edik számú 10 gigabites Ethernet-kapcsolathoz non-intruzív módban csatlakoztatott komplexum, amely folyamatosan „figyeli” a forgalomban jelenlévő összes RTP videó stream átvitelét, és meghatározott időközönként méréseket végez, hogy azokat később az adatbázisba mentse. Az adatbázisból származó adatok szerint minden kameráról rendszeresen készülnek riportok.
A megoldás keresése során számos probléma azonnal kijavításra került:
Természetesen igyekeztünk a legtöbbet kihozni saját tapasztalatainkból. Mire a döntés megszületett, már rendelkeztünk az ethernet-csomagok feldolgozásának megvalósításával az FPGA-val működő Bercut-MX (egyszerűbben - MX) eszközön. A Bercut-MX segítségével Ethernet-csomagok fejlécéből tudtuk megszerezni az elemzéshez szükséges mezőket. Sajnos nem volt tapasztalatunk ekkora forgalom feldolgozásával "rendes" szerverekkel, ezért némi aggodalommal néztek egy ilyen megoldást...
Úgy tűnik, csak az RTP-csomagokra való alkalmazása maradt, és a zsebünkben lenne az aranykulcs, de az MX csak forgalmat tud feldolgozni, nem tartalmazza a statisztika rögzítésének és tárolásának lehetőségét. Az FPGA-ban nincs elég memória a talált kapcsolatok (IP-IP-port-port kombinációk) tárolására, mert a bemenetre belépő 2x10 gigabites linken körülbelül 15 ezer videó folyam lehet, és mindegyikhez „emlékezni” kell a fogadott csomagok számára, az elveszett csomagok számára stb.
A megoldáshoz „mélyebbre kellett ásnunk”, és ki kellett találnunk, hogy milyen algoritmusokkal mérjük majd a minőséget és azonosítjuk a videofolyamokat.
A leírásból kitűnik, hogy az RTP-csomag minőségi mérése szempontjából a következő területekre vagyunk kíváncsiak:
Nyilvánvaló, hogy a sorszám lehetővé teszi a következő áramlási paraméterek meghatározását:
Az időbélyeg lehetővé teszi a következők mérését:
Nos, az M-bit lehetővé teszi a képkockasebesség mérését. Igaz, a h.264 protokoll SPS / PPS keretei hibát vezetnek be, mert nem videokockák. De szintezhető a NAL-egység fejlécéből származó információk felhasználásával, amely mindig az RTP fejlécet követi.
A paraméterek mérésének részletes algoritmusai túlmutatnak a cikk keretein, nem fogok ebbe belemenni. Ha érdekel, az rfc3550 tartalmaz egy példát a veszteségszámítási kódra és egy képletet a jitter kiszámítására. A fő következtetés az, hogy az RTP-csomagokból és a NAL-egységekből csak néhány mező elegendő egy transport stream alapvető jellemzőinek mérésére. A többi információ pedig nem vesz részt a mérésekben, és el is lehet és kell elvetni!
A statisztika vezetéséhez az RTP fejlécből nyert információkat egy bizonyos kamera (videofolyam) azonosítóhoz kell „csatolni”. A kamera egyedileg azonosítható a következő paraméterekkel:
Érdekes módon eleinte csak forrás IP és SSRC alapján végeztük a kameraazonosítást, bízva abban, hogy az SSRC véletlenszerű legyen, de a gyakorlatban kiderült, hogy sok kamera fix értékre (mondjuk 256-ra) állítja be az SSRC-t. Nyilvánvalóan ez az erőforrások megtakarításának köszönhető. Ennek eredményeként portokat kellett hozzáadnunk a kameraazonosítóhoz. Ezzel teljesen megoldódott az egyediség problémája.
A kérdés továbbra is fennáll: hogyan fogja megérteni a Berkut-MX, miután elfogadta a csomagot, hogy az RTP? Az RTP fejlécnek nincs olyan explicit azonosítója, mint az IP, nincs ellenőrző összege, UDP-n keresztül továbbítható a kapcsolat létrejöttekor dinamikusan kiválasztott portszámokkal. Esetünkben pedig a legtöbb kapcsolat már régóta létrejött, és nagyon sokáig lehet várni az újratelepítésre.
A probléma megoldásához ajánlott az rfc3550-ben (A.1. függelék) ellenőrizni az RTP verzió bitjeit - ez két bit, a Payload Type (PT) mezőben pedig - hét bit, ami dinamikus típus esetén kis tartományt vesz igénybe. A gyakorlatban azt tapasztaltuk, hogy ahhoz a kamerakészlethez, amellyel dolgozunk, a PT a 96-tól 100-ig terjedő tartományba illeszkedik.
Van még egy tényező - a kikötő paritása, de amint a gyakorlat azt mutatja, ezt nem mindig tartják be, ezért el kellett hagyni.
Így a Berkut-MX viselkedése a következő:
Nyilvánvaló, hogy ezzel a megközelítéssel vannak hamis pozitívumok, mert. nem csak az RTP-csomagok eshetnek ilyen egyszerű kritériumok alá. De fontos számunkra, hogy az RTP csomagot biztosan ne hagyjuk ki, és a szerver kiszűrje a „rossz” csomagokat.
A hamis esetek kiszűrésére a szerver egy olyan mechanizmust használ, amely több, egymás után érkezett csomag esetén regisztrálja a videoforgalom forrását (a csomagban sorszám található!). Ha több csomag egymás utáni számokkal érkezett, akkor ez nem véletlen, és ezzel az adatfolyammal kezdünk el dolgozni. Ez az algoritmus nagyon megbízhatónak bizonyult.
Felismertük, hogy a csomagokban érkező összes információra nincs szükség a minőség mérésére és a streamek azonosítására, úgy döntöttünk, hogy az RTP-csomagok fogadásával és mezőinek elkülönítésével kapcsolatos összes nagy terhelésű és időkritikus munkát átvisszük a Berkut-MX-re, azaz az FPGA-ra. „Megtalálja” a videofolyamot, elemzi a csomagot, csak a kötelező mezőket hagyja meg, és elküldi az UDP alagútban lévő szokásos szerverre. A szerver minden kameránál méréseket végez, és az eredményeket elmenti az adatbázisba.
Emiatt a szerver nem 50-60 Gigabit/s sebességgel dolgozik, hanem maximum 5%-kal (pontosan ennyi adatot küldenek az átlagos csomagmérethez). Vagyis a teljes rendszer bemenetén 55 Gigabit / s, és csak legfeljebb 3 Gigabit / s jut el a szerverhez!
Ennek eredményeként a következő architektúrát kaptuk:
És az első eredményt ebben a konfigurációban két héttel a kezdeti TOR beállítása után kaptuk meg!
Tehát mit csinál a szerver a mi architektúránkban? Feladatai:
Annak ellenére, hogy a teljes forgalom a szerver bemenetén körülbelül 3 Gigabit / s, a szerver akkor is megbirkózik, ha nem használunk DPDK-kat, hanem egyszerűen egy linux socketen keresztül dolgozunk (természetesen a socket pufferméretének növelése után). Sőt, lehetőség lesz új linkek és MX"-ek csatlakoztatására, mert a teljesítménytartalék megmarad.
Így néz ki a szerver teteje (ez csak egy lxc tároló teteje, a jelentések egy másikban jönnek létre):
Látható belőle, hogy a minőségi paraméterek számításának és a statisztikák elszámolásának teljes terhelése egyenletesen oszlik meg négy folyamaton. Ezt az eloszlást az FPGA-ban hash használatával sikerült elérni: a hash függvényt IP alapján számoljuk, a kapott hash alacsony bitjei pedig meghatározzák, hogy hány UDP portra kerüljön a statisztika. Ennek megfelelően minden, a portján figyelő folyamat megközelítőleg ugyanannyi forgalmat kap.
Ideje dicsekedni és beismerni a megoldás hiányosságait.
Kezdem a profikkal:
Az igazság kedvéért figyelembe veszem a hátrányokat:
Végül kaptunk egy szoftver-hardver komplexumot, amelyben az interfészeken lévő csomagokat elemző és a statisztikát vezető részt egyaránt vezérelhetjük. A rendszer összes csomópontja feletti teljes irányítás szó szerint megmentett minket, amikor a kamerák RTSP/TCP interleaved módba kezdtek váltani. Ugyanis ebben az esetben az RTP fejléc már nem fix eltolással helyezkedik el a csomagban: bárhol lehet, akár két csomag határán is (az egyikben az első fele, a másikban a második). Ennek megfelelően az RTP fejléc és mezőinek megszerzésére szolgáló algoritmus alapvető változásokon ment keresztül. Mind az 50 000 kapcsolathoz TCP-összeállítást kellett végeznünk a szerveren – innen ered a meglehetősen nagy terhelés a tetején.
Korábban soha nem dolgoztunk nagy terhelésű alkalmazások területén, de az FPGA-ban szerzett tudásunknak köszönhetően sikerült megoldanunk a problémát, és elég jól sikerült. Még árrés is volt - például egy 55 ezres kamerás rendszerre még 20-30 ezer stream köthető.
A linux alrendszerek hangolása (sorok elosztása megszakításokkal, vételi pufferek növelése, magok közvetlen kiosztása konkrét folyamatokhoz stb.) A cikk keretein kívül hagytam, mert. ezt a témát már nagyon jól lefedték.
Korántsem mindent leírtam, sok gereblye gyűlt össze, szóval kérdezz bátran :)
Nagyon köszönöm mindenkinek, aki a végéig elolvasta!
A legégetőbb probléma egyre inkább a címterület hiánya, ami a címformátum megváltoztatását igényli.
Egy másik probléma az IP-hálózatok alapját képező útválasztási eljárás nem kielégítő skálázhatósága. A hálózat rohamos növekedése túlterhelt útválasztókat okoz, amelyek ma kénytelenek több tíz- és százezer bejegyzést tartalmazó útválasztási táblákat karbantartani, valamint megoldani a csomagtöredezettség problémáit. A routerek munkája különösen az IP protokoll frissítésével könnyíthető meg.
Az új funkciók közvetlenül az IP protokollba történő bevezetése mellett célszerű az új protokollokkal való szorosabb interakcióját új mezők beiktatásával a csomagfejlécbe biztosítani.
Ennek eredményeként úgy döntöttek, hogy az IP protokollt korszerűsítik, a következő fő célokat követve:
Címtér bővítése. Az IP-protokoll a címhiány lehetséges problémáját úgy oldja meg, hogy a címhosszt 128-ra bővíti. A címhossz ilyen jelentős növelése azonban nagyrészt nem a címhiány problémájának megszüntetése, hanem az ezen a protokollon alapuló hálózatok hatékonyságának növelése érdekében történt. A fő cél a címzési rendszer szerkezeti átalakítása, funkcionalitásának bővítése volt.
A címhierarchia meglévő két szintje (hálózati szám és gazdagépszám) helyett az IPv6 négy szint használatát javasolja, ami háromszintű hálózati azonosítást és egy szintet a csomópont azonosításhoz jelent.
Most a címet hexadecimálisan írjuk, minden négy számjegyet kettősponttal választva el egymástól, például:
FEDC:0A96:0:0:0:0:7733:567A.
Azoknál a hálózatoknál, amelyek az IPv4 és az IPv6 protokoll mindkét verzióját támogatják, az alsó 4 bájtnál a hagyományos decimális jelölést, a magasabbaknál pedig hexadecimális jelölést lehet használni:
0:0:0:0:FFFF 194.135.75.104.
Az IPv6 címzési rendszeren belül van egy dedikált címterület is helyi felhasználás, azaz az interneten kívüli hálózatokhoz. Két fajta létezik helyi címek: nem alhálózatos "lapos" hálózatokhoz (Link-Local) és alhálózati hálózatokhoz (Site-Local), amelyek előtagértékükben különböznek egymástól.
A csomagfejlécek formátumának megváltoztatása. Ezt a "beágyazott fejlécek" új szervezési sémája valósíthatja meg, amely biztosítja a fejléc felosztását a főre, amely tartalmazza a szükséges minimális információkat, és további, esetleg hiányzókra. Ez a megközelítés gazdag lehetőségeket nyit meg a protokoll kiterjesztésére azáltal, hogy új opcionális fejléceket határoz meg, ami a protokollt nyitottá teszi.
A fő IPv6 datagram fejléc 40 bájt hosszú, és a következő formátumú (2.4. ábra).
Terület Forgalmi osztály célját tekintve egyenértékű a területtel Szolgáltatás típusa, és a mező Hop Limit- terület Itt az ideje élni IPv4 protokoll.
Terület Flow Label lehetővé teszi az egyes adatfolyamok elkülönítését és különleges módon történő feldolgozását anélkül, hogy a csomagok tartalmát elemezni kellene. Ez nagyon fontos az útválasztók terhelésének csökkentése szempontjából.
Terület Következő fejléc a Protokoll (Protokoll) IPv4 mező analógja, és meghatározza a fő fejléc típusát. Minden következő további fejléc tartalmaz egy Következő fejléc mezőt is.
Vezérlési protokoll A Transmission Control Protocolt (TCP) a számítógépek közötti interaktív kommunikáció támogatására fejlesztették ki. A TCP protokoll biztosítja a folyamatok közötti adatcsere megbízhatóságát és érvényességét a közös hálózat részét képező számítógépeken.
Sajnos a TCP protokoll nem alkalmas multimédiás információk továbbítására. Ennek fő oka a kézbesítés-ellenőrzés elérhetősége. A megfigyelés túl sokáig tart a késleltetésre érzékenyebb információk továbbításához. Ezenkívül a TCP sebességszabályozási mechanizmusokat biztosít a hálózati torlódások elkerülése érdekében. Az audio- és videoadatok azonban szigorúan meghatározott bitsebességet igényelnek, amelyet nem lehet önkényesen megváltoztatni.
Egyrészt a TCP protokoll kölcsönhatásba lép a felhasználói alkalmazás alkalmazásprotokolljával, másrészt azzal a protokollal, amely biztosítja a csomagok irányításának és címzésének "alacsony szintű" funkcióit, amelyeket általában az IP lát el.
A TCP / IP család protokolljait az internet minden csomópontjában megvalósító hálózati szoftver logikai felépítése a 1. ábrán látható. 2.5.
A téglalapok az adatokat feldolgozó modulokat, a téglalapokat összekötő vonalak pedig az adatátviteli útvonalakat jelölik. Vízszintes vonal az ábra alján egy Ethernet hálózatot jelöl, amelyet fizikai közeg példájaként használnak.
Rizs. 2.5.
Kapcsolat létrehozása két folyamat között különböző számítógépek A hálózatban nem csak a számítógépek internetcímét kell ismernie, hanem azoknak a TCP portoknak (socketeknek) a számát is, amelyeket a folyamatok ezeken a számítógépeken használnak. Az interneten található bármely TCP-kapcsolatot egyedileg azonosít két IP-cím és két TCP-portszám.
A TCP-protokoll képes kezelni a sérült, elveszett, megkettőzött vagy nem megfelelő csomagokat. Ezt egy olyan mechanizmussal érik el, amely minden továbbított csomaghoz sorszámot rendel, és egy olyan mechanizmussal, amely ellenőrzi a csomagok fogadását.
Amikor a TCP egy adatszegmenst továbbít, az adatok másolata az újraküldési sorba kerül, és elindul a nyugtázási időzítő.
A User Datagram Protocol (UDP) protokoll a datagramok cseréjére szolgál a számítógépes hálózatok integrált rendszerében elhelyezkedő számítógépek folyamatai között.
Az UDP protokoll az IP protokollon alapul, és az alkalmazási folyamatokat olyan szállítási szolgáltatásokkal látja el, amelyek kissé eltérnek az IP protokolltól. Az UDP protokoll nem garantált adattovábbítást biztosít, azaz nem igényli azok átvételének megerősítését; ezenkívül ez a protokoll nem követeli meg az információforrás és a vevő, azaz az UDP modulok közötti kapcsolat létrehozását.
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 forgalomtípus-felismerést, csomagsorrendet, időbélyegzést és átvitelvezérlést valósít meg.
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 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 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ókat megfelelően hallhassák és megtekinthessék a felhasználók.
Vegye figyelembe, hogy magának az RTP-nek nincs olyan mechanizmusa, amely garantálná az adatok időben történő továbbítását és szolgáltatás minősége, de ennek biztosítására alapul szolgáló szolgáltatásokat használ. 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.
Protokoll adatblokkok Az RTP/RTCP-t csomagoknak nevezzük. Az RTP protokoll szerint generált és multimédiás adatok továbbítására használt csomagokat információs csomagoknak vagy adatcsomagoknak ( adatcsomagoknak ) nevezik, és az RTCP protokoll szerint generált és a megbízható működéshez szükséges szolgáltatási információk továbbítására használt csomagokat. telekonferenciák vezérlőcsomagoknak vagy szervizcsomagoknak (control packets) nevezzük. 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 fix résszel kezdődik (hasonlóan az RTP információs csomagok fix részéhez), majd változó hosszúságú szerkezeti elemek következnek.
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 tartalmazza 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 használatát, forgalomtípusokat, fejléc- és fejléc-kiterjesztéseket, csomagtípusokat, kommunikációbiztonsági szolgáltatásokat és algoritmusokat, az alapul szolgáló protokoll használatának sajátosságait stb.. Minden alkalmazás általában csak egy profillal működik, a profiltípus beállítása a megfelelő alkalmazás kiválasztásával történik. A profil típusát nem jelzik kifejezetten portszám, protokollazonosító stb.
Í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.
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 csoport címére és portjára vonatkozó információkat átadjuk a leendő tagoknak telekonferenciák. Ha titoktartásra van szükség, az információ- és vezérlőcsomagok titkosíthatók, ebben az esetben a elosztott kulcs Titkosítás.
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, és különböző ideig 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 az RTP-csomagok minden egyes forrásához telekonferenciák. A sorszámot a vevő is használhatja az elveszett csomagok számának becslésére.
Mivel a résztvevők telekonferenciák alatt be- és kiléphet belőle, hasznos tudni, kik vesznek részt benne Ebben a pillanatbané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, üzeneteket küld a csomagok fogadásáról, amelyek jelzik 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 be telekonferenciák hang- és képjeleket egyaránt használnak, azokat külön továbbítják. Az egyes forgalomtípusok átviteléhez, a másiktól függetlenül, a protokoll specifikáció bevezeti az RTP kommunikációs munkamenet fogalmá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 ahhoz, hogy a munkamenetek társítható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 használatára kényszerítenénk és audio kódolás csökkentett minőség mellett egy RTP rétegű kommunikációs lehetőség, az úgynevezett mixer elhelyezhető egy kis sávszélességű területen. 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. Ahhoz, hogy a fogadó végpontokon a megfelelő jelzést tudjunk adni üzenetforrás, az RTP fejléc tartalmaz eszközöket a keverők számára a kevert csomag létrehozásában részt vevő források azonosítására.
Előfordulhat, hogy az audiokonferencia egyes résztvevői szélessávú kapcsolaton keresztül csatlakoznak, de előfordulhat, hogy nem érhetők el IP-csoportos (IPM) csoportos konferenciahíváson 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.
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.
Vezérlési protokoll Az RTCP (RTCP – Real-Time Control Protocol) periodikus csomagátvitelen alapul menedzsment a kommunikációs munkamenet minden résztvevőjének az RTP protokollal azonos elosztási mechanizmust használva. Az alapul szolgáló protokollnak biztosítania kell az információk és a vezérlőcsomagok multiplexálását, például különböző UDP portszámok használatával. Az RTCP protokoll négy fő funkciót lát el.
Az egytől háromig terjedő funkciók kötelezőek, ha RTP-t használnak IP csoportos küldésben, és minden más esetben ajánlott. Az RTP-alkalmazások fejlesztőit arra biztatjuk, hogy kerüljék az olyan mechanizmusokat, amelyek csak kétirányúak, és nem méreteződnek a felhasználók számának növelésére.
Az RTP-protokoll lehetővé teszi az alkalmazások számára, hogy a kommunikációs munkamenet reprezentativitását néhány résztvevőről több ezerre skálázza automatikusan. Például egy audiokonferencián az adatforgalom lényegében önkorlátozó, mert egyszerre csak egy-két ember beszélhet, és multicast elosztás esetén az adatátviteli sebesség bármely adott linken viszonylag állandó marad, függetlenül a résztvevők számától. A forgalomirányítás azonban nem önkorlátozó. Ha az egyes résztvevőktől kapott jelentéseket állandó sebességgel küldik, akkor a vezérlőforgalom lineárisan nő a résztvevők számának növekedésével. Ezért egy speciális mechanizmust kell biztosítani a vezérlőcsomagok átviteli gyakoriságának csökkentésére.
Feltételezzük, hogy minden munkamenet esetében az adatforgalom eléri a munkamenet sávszélességének nevezett összesített korlátot, amelyen minden résztvevő osztozik. Ez a sávszélesség lefoglalható, és a korlátot a hálózat határozza meg. A munkamenet sávszélessége független a médiakódolás típusától, de a kódolás típusának megválasztását korlátozhatja a munkamenet sávszélessége. A munkamenet sávszélesség beállítását a munkamenet-kezelő alkalmazásnak kell megadnia, amikor meghívja a médiaalkalmazást, de a médiaalkalmazások alapértelmezett értéket is beállíthatnak az adott munkamenethez kiválasztott kódolási típushoz tartozó egyetlen küldő adatsávszélessége alapján.
A szabályozás és az adatforgalom sávszélesség-számításait az alapul szolgáló szállítási és hálózati réteg protokollok (pl. UDP és IP) figyelembevételével végzik. Az adatkapcsolati réteg fejléceit (DLH-k) nem veszik figyelembe a számítások, mivel egy csomag továbbítása során különböző DLL-fejlécekkel lehet tokozva.
A vezérlési forgalmat a munkamenet sávszélességének egy kicsi és ismert részére kell korlátozni: elég kicsi ahhoz, hogy a szállítási protokoll fő funkciója, az adatátvitel ne legyen érintett; ismert, így a vezérlőforgalom beépíthető a protokollnak adott sávszélesség specifikációba erőforrás foglalás, és így minden résztvevő önállóan kiszámolhatja részesedését. Feltételezzük, hogy a munkamenet sávszélességének RTCP-hez allokált részét 5%-ra kell beállítani. Az összes munkamenet résztvevőjének ugyanannyi RTCP sávszélességet kell használnia, hogy a számított vezérlőcsomag átviteli intervallum értékei azonosak legyenek. Ezért ezeket az állandókat minden profilhoz be kell állítani.
Az RTCP gyűjtőcsomagok küldései közötti intervallum kiszámítására szolgáló algoritmus az irányítási forgalom számára kiosztott sávszélesség résztvevői között való megosztására a következő fő jellemzőkkel rendelkezik:
Több RTP protokoll csomag is szállítható egyetlen mögöttes protokoll adategységben, például egy UDP-csomagban. Ez csökkenti a fejléc redundanciáját, és leegyszerűsíti a különböző adatfolyamok közötti szinkronizálást.
Ha egy nap gyorsan rá kell jönnie, hogy mi az a VoIP (voice over IP), és mit jelentenek ezek a vad rövidítések, remélem, ez a kézikönyv segíteni fog. Azonnal megjegyzem, hogy a további típusú telefonos szolgáltatások konfigurálásával kapcsolatos problémák (például hívástovábbítás, hangposta, konferenciahívások stb.) itt nem vesszük figyelembe.
Tehát mivel foglalkozunk a vágás alatt:
Általánosságban elmondható, hogy a helyi előfizető és a telefonszolgáltató hagyományos telefonvonalon keresztül történő csatlakoztatásának sémája a következő:
A szolgáltató oldalán (PBX) egy FXS (Foreign eXchange Subscriber) porttal rendelkező telefonmodul van telepítve. FXO (Foreign eXchange Office) porttal és tárcsázó modullal rendelkező telefon vagy fax készülék otthonra vagy az irodában van telepítve.
Kinézetre az FXS és FXO portok semmiben sem különböznek, ezek közönséges 6 tűs RJ11 csatlakozók. Voltmérővel azonban nagyon könnyű megkülönböztetni őket - az FXS porton mindig lesz feszültség: 48/60 V, amikor a kézibeszélő le van rakva, vagy 6-15 V hívás közben. Az FXO-n, ha nincs a vezetékre kötve, a feszültség mindig 0.
A telefonvonalon történő adatátvitelhez további logika szükséges a szolgáltatói oldalon, amely az SLIC (előfizetői vonali interfész áramkör) modulon, az előfizetői oldalon pedig a DAA (Direct Access Arrangement) modul segítségével valósítható meg.
A vezeték nélküli DECT telefonok (Digital European Cordless Telecommunications) manapság meglehetősen népszerűek. Készüléket tekintve hasonlítanak a hagyományos telefonokhoz: van FXO port és tárcsázó modul is, de van bennük modul is vezeték nélküli kommunikációállomások és kézibeszélők 1,9 GHz-es frekvencián.
Az előfizetők csatlakoznak a PSTN-hálózathoz (nyilvános kapcsolt telefonhálózat) - telefonhálózatáltalános használatra, ez PSTN, PSTN. A PSTN hálózat segítségével megszervezhető különböző technológiák: ISDN, optika, POTS, Ethernet. A PSTN speciális esete, amikor egy normál analóg/réz vonalat használnak - POTS (Plain Old Telephone Service) - egy egyszerű régi telefonrendszer.
Az internet fejlődésével telefonos kommunikációátváltott új szint. A helyhez kötött telefonokat egyre ritkábban használják, elsősorban hatósági igényekre. A DECT telefonok egy kicsit kényelmesebbek, de csak a ház kerületére korlátozódnak. A GSM-telefonok még kényelmesebbek, de az ország határai korlátozzák őket (a roaming drága). De az IP-telefonok esetében ezek is softphone-ok (SoftPhone), nincs korlátozás, kivéve az internethez való hozzáférést.
A Skype a softphone leghíresebb példája. Sok mindenre képes, de két fontos hátránya van: a zárt architektúra és a lehallgatás mely hatóságok által ismert. Az első miatt nem lehet saját telefonos mikrohálózatot létrehozni. És a második miatt - nem túl kellemes, ha kémkednek, különösen személyes és kereskedelmi beszélgetések során.
Szerencsére léteznek nyitott protokollok saját kommunikációs hálózatok létrehozására, amelyek finomságokat tartalmaznak – ezek a SIP és a H.323. A SIP protokollon néhány softphone található, mint a H.323-on, ami viszonylagos egyszerűségével és rugalmasságával magyarázható. De néha ez a rugalmasság nagy botot üthet a kerékbe. Mind a SIP, mind a H.323 protokoll az RTP protokollt használja a médiaadatok átvitelére.
Fontolja meg a SIP protokoll alapelveit, hogy megértse, hogyan csatlakozik két előfizető.
SIP (Session Initiation Protocol) - a munkamenet létrehozására szolgáló protokoll (nem csak telefonos) egy UDP-n keresztüli szöveges protokoll. SIP-t is lehet használni TCP-n keresztül, de ezek ritka esetek.
Az SDP (Session Description Protocol) egy protokoll a továbbított adatok típusának (hang és kép esetében ezek kodekek és formátumaik, faxoknál - átviteli sebesség és hibajavítás) és célcímeik (IP és port) egyeztetésére. Ez is egy szöveges protokoll. Az SDP-paraméterek a SIP-csomagok törzsében kerülnek elküldésre.
Az RTP (Real-time Transport Protocol) egy audio/videó adatátviteli protokoll. Ez egy bináris protokoll UDP-n keresztül.
A SIP-csomagok általános felépítése:
Íme egy példa két SIP-csomagra egy közös hívásbeállítási eljáráshoz:
A bal oldalon a SIP INVITE csomag tartalma, a jobb oldalon a rá adott válasz - SIP 200 OK.
A fő mezők keretezve:
Az SDP üzenet MEZŐ=ÉRTÉK párokat tartalmazó sorokból áll. A főbb területek a következők:
Az RTP-csomagok meghatározott formátumban kódolt audio/video adatokat tartalmaznak. Ez a formátum a PT (payload type) mezőben megadott. Értékkereső táblázat adott mező Az adott formátumhoz lásd a https:// wikipedia org wiki RTP audio-video profilt.
Az RTP-csomagok tartalmaznak egy egyedi SSRC-azonosítót (meghatározza az RTP-adatfolyam forrását) és egy időbélyeget (időbélyegző, a hang vagy a videó egyenletes lejátszására szolgál).
Példa két SIP-előfizető közötti interakcióra egy SIP-kiszolgálón keresztül (csillag):
Amint egy SIP telefon elindul, először regisztrál egy távoli szerverre (SIP Regisztrátor), majd küld neki egy SIP REGISTER üzenetet.
Előfizető hívásakor egy SIP INVITE üzenet kerül kiküldésre, melynek törzsében egy SDP üzenet található, amely tartalmazza az audio/video átviteli paramétereket (mely kodekek támogatottak, melyik IP-re és portra kell hangot küldeni stb.).
Amikor a távoli előfizető felveszi a telefont, SIP 200 OK üzenetet kapunk szintén SDP paraméterekkel, csak a távoli előfizető. Az elküldött és fogadott SDP paraméterek segítségével beállíthat egy RTP audio/video munkamenetet vagy egy T.38 fax munkamenetet.
Ha a kapott SDP paraméterek nem feleltek meg nekünk, vagy a közbenső SIP szerver úgy döntött, hogy nem engedi át magán az RTP forgalmat, akkor az SDP újratárgyalási eljárás, az ún. REINVITE történik. Egyébként pontosan ennek az eljárásnak köszönhető, hogy az ingyenes SIP proxy szervereknek van egy hátránya - ha mindkét előfizető ugyanazon a helyi hálózaton van, és a proxyszerver a NAT mögött van, akkor az RTP forgalom átirányítása után egyik előfizető sem hallja a másikat.
A beszélgetés befejezése után a telefont leadó előfizető SIP BYE üzenetet küld.
Néha a munkamenet létrehozása után hívás közben további szolgáltatásokhoz (VAS) való hozzáférésre van szükség - hívástartás, átvitel, hangposta stb. - amelyek reagálnak a megnyomott gombok bizonyos kombinációira.
Tehát egy normál telefonvonalon kétféleképpen tárcsázhat egy számot:
Beszélgetés közben az impulzusos módszer kényelmetlen a megnyomott gomb továbbítására. Tehát körülbelül 1 másodpercet vesz igénybe a „0” átvitele (10 egyenként 100 ms-os impulzus: 60 ms – sortörés, 40 ms – vonalzárás), plusz 200 ms a számjegyek közötti szünet. Ezenkívül az impulzusos tárcsázás során gyakran jellegzetes kattanások hallhatók. Ezért a hagyományos telefonálásban csak a VAS eléréséhez használt hangmódot használják.
A VoIP telefonálásban a megnyomott gombokkal kapcsolatos információk háromféleképpen továbbíthatók:
A DTMF hangadatokon belüli átvitelének (Inband) számos hátránya van - ezek a hangok generálásakor / beágyazásakor és észlelésekor fellépő többletforrások, egyes kodekek korlátai, amelyek torzíthatják a DTMF kódokat, és rossz átviteli megbízhatóság (ha néhány csomag elveszik, akkor ugyanazon gomb kétszeri megnyomása észlelhető).
A fő különbség a DTMF RFC2833 és a SIP INFO között: ha a SIP proxyszerveren engedélyezve van az RTP közvetlen átvitele az előfizetők között magát a szervert megkerülve (például canreinvite=yes csillaggal), akkor a szerver nem veszi észre az RFC2833 csomagokat, aminek következtében a VAS szolgáltatások elérhetetlenné válnak. A SIP-csomagok továbbítása mindig SIP-proxyszervereken keresztül történik, így a VAS mindig működik.
Mint már említettük, az RTP protokollt használják a médiaadatok átvitelére. Az RTP-csomagok mindig meghatározzák a továbbított adatok (kodek) formátumát.
Sok különböző kodek létezik a hangátvitelhez, különböző bitráta / minőség / bonyolultság aránnyal, vannak nyitott és zárt kodekek. Minden softphonenak rendelkeznie kell a G.711 alaw/ulaw kodekekkel, megvalósításuk nagyon egyszerű, a hangminőség nem rossz, de 64 kbps sávszélességet igényelnek. Például a G.729 kodek csak 8 kbps-t igényel, de nagyon CPU-igényes, és nem ingyenes.
A faxátvitelhez általában a G.711 kodeket vagy a T.38 protokollt használják. A faxok G.711 kodekkel történő küldése megfelel a T.30 protokoll használatával történő faxküldésnek, mintha a faxot normál telefonvonalon küldenék, de ugyanakkor analóg jel sorból az alaw/ulaw törvény szerint digitalizálják. Ezt Inband T.30 faxolásnak is nevezik.
A T.30 protokollt használó faxok egyeztetik a paramétereiket: átviteli sebesség, datagram méret, hibajavítás típusa. A T.38 protokoll a T.30 protokollon alapul, de az Inband átvitellel ellentétben a generált és fogadott T.30 parancsokat elemzi. Így nem nyers adatok kerülnek továbbításra, hanem felismert faxvezérlő parancsok.
A T.38 parancsot az UDPTL protokoll segítségével továbbítják, amely UDP-alapú protokoll, és csak a T.38-hoz használatos. TCP és RTP protokollok is használhatók T.38 parancsok továbbítására, de sokkal ritkábban használják őket.
A T.38 fő előnyei a kisebb hálózati terhelés és az Inband faxátvitelhez képest nagyobb megbízhatóság.
A fax T.38 módban történő küldésének folyamata a következő:
Faxküldés az interneten keresztül lehetőleg T.38-ban. Ha a faxot az irodán belül vagy a stabil kapcsolattal rendelkező objektumok között kell továbbítani, akkor az Inband T.30 faxátvitel használható. Ebben az esetben a fax küldése előtt ki kell kapcsolni a visszhang törlési eljárást, hogy ne okozzon további torzulásokat.
Nagyon részletes információk találhatók a faxolásról David Hanes és Gonzalo Salgueiro "Fax, Modem és Text for IP Telephony" című könyvében.
Foglalkoztunk a beszélgetési munkamenet (SIP / SDP) létrehozásának protokolljaival és az RTP csatornán keresztüli hangátvitel módszerével. Volt egy fontos kérdés - a hangminőség. Egyrészt a hangminőséget a kiválasztott kodek határozza meg. Másrészt azonban további DSP eljárásokra (DSP - digitális jelfeldolgozás) továbbra is szükség van. Ezek az eljárások figyelembe veszik a VoIP-telefónia sajátosságait: nem mindig jó minőségű headsetet használnak, az interneten csomagleesések vannak, néha egyenetlenül érkeznek a csomagok, és a hálózati sávszélesség sem gumis.
A hangminőség javítására szolgáló alapvető eljárások:
VAD(Voice activity detector) - eljárás olyan keretek meghatározására, amelyek hangot (aktív hangkeret) vagy csendet (inaktív hangkeret) tartalmaznak. Ez a szétválasztás jelentősen csökkentheti a hálózati terhelést, mivel a csendről szóló információk továbbítása sokkal kevesebb adatot igényel (elegendő a zajszint átvitele vagy semmi).
Egyes kodekek már tartalmaznak VAD eljárásokat (GSM, G.729), míg másoknak (G.711, G.722, G.726) ezeket implementálni kell.
Ha a VAD úgy van beállítva, hogy a zajszinttel kapcsolatos információkat továbbítsa, akkor a speciális SID-csomagok (Silence Insertion Descriptor) továbbítása a 13. CN (Comfort Noise) RTP formátumban történik.
Érdemes megjegyezni, hogy a SID-csomagokat a SIP proxyszerverek eldobhatják, ezért az ellenőrzéshez célszerű beállítani az RTP-forgalom SIP-szervereken túli továbbítását.
CNG(komfortzaj-generálás) - eljárás komfortzaj generálására a SID-csomagokból származó információk alapján. Így a VAD és a CNG együtt működik, de a CNG-eljárás sokkal kevésbé keresett, mivel nem mindig lehet észrevenni a CNG munkáját, különösen alacsony hangerőn.
PLC(csomagvesztés elrejtése) - az audio stream visszaállításának eljárása csomagvesztés esetén. Egy jó PLC algoritmus még 50%-os csomagvesztés mellett is elfogadható beszédminőséget érhet el. Torzítások természetesen lesznek, de ki lehet találni a szavakat.
A csomagvesztés emulálásának legegyszerűbb módja (Linuxon) az iproute csomag tc segédprogramjának használata a netem modullal. Csak a kimenő forgalom alakítását végzi.
Példa hálózati emuláció futtatására 50%-os csomagveszteséggel:
Tc qdisc változás dev eth1 gyökér netem veszteség 50%
Emuláció letiltása:
Tc qdisc del dev eth1 gyökér
jitter puffer- eljárás a jitter-effektus megszüntetésére, amikor a fogadott csomagok közötti intervallum nagyon megváltozik, és ami a legrosszabb esetben a fogadott csomagok helytelen sorrendjéhez vezet. Ezenkívül ez a hatás beszédmegszakításokhoz vezet. A jitter-effektus kiküszöbölésére a fogadó oldalon egy olyan csomagpuffert kell megvalósítani, amelynek mérete elegendő ahhoz, hogy egy adott időközönként visszaállítsa az eredeti csomagküldési sorrendet.
A jitter hatást a tc segédprogrammal is emulálhatja (a csomag érkezésének várható pillanata és a tényleges pillanat közötti intervallum legfeljebb 500 ms lehet):
LEC(Line Echo Canceller) - eljárás a helyi visszhang kiküszöbölésére, amikor a távoli előfizető hallani kezdi a saját hangját. Lényege, hogy egy bizonyos együtthatóval kivonjuk a vett jelet a továbbított jelből.
A visszhangok több okból is előfordulhatnak:
Az ok (akusztikus vagy elektromos visszhang) kiderítése nem nehéz: annak az előfizetőnek, akinek oldalán a visszhang keletkezik, ki kell kapcsolnia a mikrofont. Ha a visszhang továbbra is fennáll, akkor az elektromos.
A VoIP- és DSP-eljárásokkal kapcsolatos további információkért lásd: VoIP hang- és faxjelfeldolgozás. Az előnézet elérhető a Google Könyveken.
Ezzel teljessé válik a VoIP felületes elméleti áttekintése. Ha érdekli, akkor a következő cikkben egy példa a mini-PBX gyakorlati megvalósítására egy valódi hardverplatformon.
[!?] Kérdéseket, észrevételeket szívesen fogadunk. A cikk szerzője, Dmitry Valento, a Promwad elektronikai tervezőközpont szoftvermérnöke válaszol rájuk.
Címkék:
A modern alkalmazások nem tolerálják, hogy csomagjaik későn érkezzenek. Két protokoll (RTP és PSVP) biztosítja az időben történő szállítást és a szolgáltatás minőségét.
Az internet és a magánhálózatok folyamatos növekedése új igényeket támaszt a sávszélességgel szemben. A kliens-szerver alkalmazások az átvitt adatok mennyiségét tekintve messze felülmúlják a Telnetet. Világ széles háló a grafikon óriási növekedéséhez vezetett grafikus információk. Manapság ráadásul a hang- és videoalkalmazások saját specifikus követelményeket támasztanak az amúgy is túlterhelt hálózatokkal szemben.
Mindezen igények kielégítéséhez nem elegendő a hálózati kapacitás egyszeri növelése. Valójában intelligens, hatékony ütemterv-kezelési és munkaterhelés-szabályozási módszerekre van szükség.
Történelmileg az IP-alapú hálózatok minden alkalmazást csak a lehető legegyszerűbb adattovábbítási szolgáltatással láttak el. Az igények azonban idővel változtak. Olyan szervezetek, amelyek több millió dollárt költöttek IP-alapú hálózat telepítésére az adatok átviteléhez helyi hálózatok, most szembesülnek azzal a ténnyel, hogy az ilyen konfigurációk nem képesek hatékonyan támogatni az új multicast valós idejű multimédiás alkalmazásokat.
ATM az egyetlen hálózati technológia, amelyet eredetileg a normál TCP és UDP forgalom, valamint a valós idejű forgalom támogatására terveztek. Az ATM bevezetése azonban vagy új hálózati infrastruktúra létrehozását jelenti a valós idejű forgalom számára, vagy egy meglévő IP-alapú konfiguráció lecserélését, mindkettő nagyon drága.
Ezért a TCP/IP architektúrán belül nagyon sürgős szükség van többféle forgalom támogatására, eltérő szolgáltatásminőségi követelményekkel. A probléma megoldására két kulcsfontosságú eszköz készült: a Real-Time Transport Protocol (RTP) és az Erőforrás-foglalási protokoll (RSVP).
Az RTP garantálja az adatok egy vagy több célállomásra történő kézbesítését, meghatározott határokon belüli késéssel. Ez azt jelenti, hogy az adatok valós időben visszajátszhatók. Az RSVP lehetővé teszi a végrendszerek redundanciáját hálózati erőforrások a szükséges szolgáltatásminőség eléréséhez, különösen az RTP protokollon keresztüli valós idejű forgalomhoz szükséges erőforrásokhoz.
A legszélesebb körben használt szállítási réteg protokoll a TCP. Bár a TCP sokféle elosztott alkalmazást támogat, valós idejű alkalmazásokhoz nem alkalmas.
A valós idejű alkalmazásokban a küldő állandó sebességgel generál adatfolyamot, és a vevő(k)nek ugyanazzal a sebességgel kell ezt az adatot eljuttatnia az alkalmazáshoz. Az ilyen alkalmazások közé tartozik az audio- és videokonferencia, az élő videó terjesztés (azonnali lejátszáshoz), a megosztott munkaterületek, az orvosi távdiagnosztika, a számítógépes telefonálás, az elosztott interaktív szimuláció, a játékok és a valós idejű monitorozás.
A TCP szállítási protokollként való használata ezekhez az alkalmazásokhoz több okból nem lehetséges. Először is, ez a protokoll csak két végpont közötti kapcsolatot tesz lehetővé, ezért nem alkalmas csoportos küldésre. Lehetővé teszi az olyan elveszett szegmensek újraküldését, amelyek akkor érkeznek, amikor a valós idejű alkalmazás már nem vár rájuk. Ezenkívül a TCP nem rendelkezik kényelmes mechanizmussal az időzítési információk szegmensekhez való társításához, ami szintén követelmény a valós idejű alkalmazásoknál.
Egy másik széles körben használt szállítási réteg protokoll, az UDP nem rendelkezik az első kettővel
korlátozások (pont-pont kapcsolat és elveszett szegmensek továbbítása), de nem ad kritikus szinkronizálási információkat. Tehát magának az UDP-nek nincsenek eszközei Általános rendeltetésű valós idejű alkalmazásokhoz.
Bár minden valós idejű alkalmazásnak megvannak a saját mechanizmusai a valós idejű átvitel támogatására, sok közös jellemzőjük van, amelyek miatt nagyon kívánatos egyetlen protokoll meghatározása. Az ilyen szabványos protokoll az RFC, amelyet az RFC 1889 határoz meg.
Egy tipikus valós idejű környezetben a küldő állandó sebességgel generál csomagokat. Rendszeres időközönként elküldik nekik, áthaladnak a hálózaton, és a vevő fogadja őket, és valós időben játssza le az adatokat, ahogy azok beérkeznek.
A csomagok hálózaton áthaladó késleltetése miatt azonban rendszertelen időközönként érkeznek meg. Ennek a hatásnak a kompenzálására a bejövő csomagokat puffereljük, egy ideig visszatartjuk, majd állandó sebességgel biztosítjuk. szoftver A kimenetet generáló. Ahhoz, hogy ez a séma működjön, minden csomagot időbélyeggel látnak el, hogy a fogadó a feladóval azonos sebességgel tudja visszajátszani a bejövő adatokat.
Az RTP támogatja a valós idejű adatátvitelt egy munkamenet több résztvevője között. (A munkamenet két vagy több RTP-felhasználó közötti logikai kapcsolat, amelyet az adatátvitel időtartama alatt fenntartanak. A munkamenet megnyitásának folyamata kívül esik az RTP hatókörén.)
Bár az RTP valós idejű unicasthoz is használható, erőssége a multicast támogatásban rejlik. Ehhez minden RTP adatblokk tartalmaz egy feladó azonosítót, amely jelzi, hogy melyik résztvevő generálja az adatokat. Az RTP adatblokkok tartalmaznak egy időbélyeget is, hogy az adatokat a megfelelő időközönként le tudja játszani a fogadó oldal.
Ezenkívül az RTP meghatározza a továbbított adatok hasznos adatformátumát. Közvetlenül ehhez kapcsolódik a szinkronizálás fogalma, amely részben a keverő – az RTP fordítási mechanizmus – felelőssége. Egy vagy több forrásból származó RTP-csomagok folyamának vételekor egyesíti azokat, és új RTP-csomagfolyamot küld egy vagy több címzettnek. A keverő egyszerűen kombinálhatja az adatokat, és megváltoztathatja a formátumát is.
Keverő alkalmazási példa - Több hangforrás kombinálása. Tegyük fel például, hogy egy adott audio munkamenetben egyes rendszerek mindegyike saját RTP adatfolyamot generál. Legtöbbször csak egy forrás aktív, bár néha több forrás "beszél" egyszerre.
Ha új rendszer részt akar venni egy munkamenetben, de a hálózathoz fűződő kapcsolata nem rendelkezik kellő pontossággal az összes RTP folyam támogatásához, akkor a keverő megkapja ezeket a streameket, egyesíti őket egybe, és az utolsót továbbítja az új szekciótagnak. Ha több adatfolyam érkezik, a keverő hozzáadja a PCM értékeket. A keverő által generált RTP fejléc tartalmazza azon feladó(k) azonosítóját/azonosítóit, akik(ek)nek az adatai jelen vannak a csomagban.
Egy egyszerűbb eszköz minden bejövő RTP-csomaghoz egy kimenő RTP-csomagot hoz létre. Ez a fordítónak nevezett mechanizmus megváltoztathatja a csomagban lévő adatok formátumát, vagy különböző alacsony szintű protokollokat használhat az adatok egyik tartományból a másikba való átviteléhez. Előfordulhat például, hogy egy potenciális címzett nem tudja feldolgozni a munkamenet többi résztvevője által használt nagy sebességű videojelet. A fordító ezután a videót alacsonyabb minőségű formátumba konvertálja, amely alacsonyabb bitsebességet igényel.
Minden RTP-csomagnak van egy alapfejléce és esetleg további alkalmazás-specifikus mezők. Rizs. A 4. ábra a fő fejléc szerkezetét szemlélteti. Az első 12 oktett a következő mezőket tartalmazza:
A fő fejlécet egy vagy több küldőazonosító mező követheti, amelyek adatai jelen vannak a hasznos adatban. Ezeket az azonosítókat a keverő illeszti be.
Az RTP protokoll csak a felhasználói adatok - általában multicast - átvitelére szolgál a munkamenet minden résztvevője számára. Egy különálló Real-Time Transport Control Protocol (RTCP) több céllal működik, hogy visszajelzést adjon az RTP adatküldőknek és a munkamenet többi résztvevőjének.
Az RTCP ugyanazt az alapvető szállítási protokollt használja, mint az RTP (általában UDP), de eltérő portszámot. A munkamenet minden résztvevője rendszeresen küld egy RTCP-csomagot a munkamenet többi résztvevőjének. Az RFC 1889 három, az RTCP által végrehajtott funkciót ír le.
Az első funkció a szolgáltatás minősége és visszacsatolás biztosítása torlódások esetén. Mivel az RTCP-csomagok csoportos küldés, a munkamenet minden résztvevője értékelheti, hogy a többi résztvevő milyen jól működik és hogyan fogadja. A feladó üzenetei lehetővé teszik a címzettek számára az adatsebesség és az átvitel minőségének értékelését. A címzettek üzenetei információkat tartalmaznak az általuk tapasztalt problémákról, beleértve a csomagvesztést és a túlzott hullámzást. Például egy audio/videó alkalmazás bitsebessége csökkenhet, ha a kapcsolat adott bitsebességgel nem biztosítja a kívánt szolgáltatásminőséget.
A címzettek visszajelzései a terjedési hibák diagnosztizálásához is fontosak.
A munkamenet összes résztvevőjétől érkező üzenetek elemzésével a hálózati rendszergazda megállapíthatja, hogy egy adott probléma egy résztvevőt érint-e, vagy általános jellegű.
Az RTCP második fő funkciója a küldő azonosítása. Az RTCP-csomagok szabványos szöveges leírást tartalmaznak a feladóról. Több információt nyújtanak az adatcsomagok feladójáról, mint egy véletlenszerűen kiválasztott szinkronizálási forrásazonosító. Ezenkívül segítik a felhasználót a különböző munkamenetekhez kapcsolódó szálak azonosításában. Például lehetővé teszik a felhasználó számára, hogy megállapítsa, hogy különálló audio- és videomunkamenetek vannak-e nyitva egy időben.
A harmadik funkció a munkamenet méretezése és méretezése. A szolgáltatás minőségének biztosítása és a torlódások ellenőrzésére szolgáló visszajelzések, valamint a feladó azonosítása érdekében minden résztvevő rendszeresen küld RTCP-csomagokat. Ezeknek a csomagoknak a továbbítási gyakorisága a résztvevők számának növekedésével csökken.
Kis számú résztvevő esetén legfeljebb öt másodpercenként küldenek egy RTCP-csomagot. Az RFC 1889 olyan algoritmust ír le, amelyben a résztvevők a résztvevők teljes száma alapján korlátozzák az RTCP-csomagok sebességét. A cél az, hogy az RTCP-forgalom a teljes munkamenet forgalom 5%-a alatt maradjon.
Bármely hálózat célja, hogy az adatokat garantált szolgáltatásminőség mellett eljuttassák a címzetthez, beleértve áteresztőképesség, késleltetés és a megengedett késleltetési eltérés határértéke. A felhasználók és alkalmazások számának növekedésével egyre nehezebb a szolgáltatások minőségének biztosítása.
Már nem elég a túlterhelésre reagálni. Szükség van egy olyan eszközre, amely teljesen elkerüli a torlódást, azaz lehetővé teszi az alkalmazások számára, hogy a szükséges szolgáltatásminőségnek megfelelően lefoglalják a hálózati erőforrásokat.
A megelőző intézkedések az unicast és a multicast esetén egyaránt hasznosak. Unicast esetén két alkalmazás megállapodik egy adott munkamenetre vonatkozó szolgáltatási színvonalban. Ha a hálózat erősen le van terhelve, előfordulhat, hogy nem tudja biztosítani a szükséges minőségű szolgáltatást. Ebben a helyzetben az alkalmazásoknak el kell halasztaniuk a munkamenetet jobb időkig, vagy meg kell próbálniuk csökkenteni a szolgáltatási követelmények minőségét, ha lehetséges.
A megoldás ebben az esetben az, hogy az unicast alkalmazások erőforrásokat foglalnak le a szükséges szolgáltatási szint biztosításához. Ezután a tervezett útvonalon lévő útválasztók lefoglalják az erőforrásokat (például egy helyet a sorban és a kimenő vonal kapacitásának egy részét). Ha az útválasztó korábbi kötelezettségvállalások miatt nem tud erőforrásokat lefoglalni, akkor értesíti az alkalmazást. Ebben az esetben az alkalmazás megpróbálhat újabb munkamenetet kezdeményezni alacsonyabb szolgáltatásminőségi követelményekkel, vagy átütemezni egy későbbi időpontra.
A csoportos küldés sokkal összetettebb erőforrás-foglalási problémákat vet fel. Ez hatalmas mennyiségű hálózati forgalom generálásához vezet - például olyan alkalmazások esetében, mint a videó, vagy ha a címzettek nagy és szétszórt csoportja van. A multicast forrásból érkező forgalom azonban elvileg jelentősen csökkenthető.
Ennek két oka van. Először is, előfordulhat, hogy a csoport egyes tagjainak nem kell adatokat szolgáltatniuk egy adott forrásból egy adott időszakban. Így egy csoport tagjai egyszerre két csatornán (két forrásból) kaphatnak információt, de a címzett csak egy csatorna vételében lehet érdekelt.
Másodszor, hogy a csoport egyes tagjai a küldő által továbbított információnak csak egy részét tudják feldolgozni. Például egy videofolyam két összetevőből állhat: az egyik gyenge képminőségű, a másik pedig jó képminőségű. Ennek a formátumnak számos videótömörítési algoritmusa van: ezek generálnak egy gyenge képminőségű alapkomponenst és egy nagyobb felbontású kiegészítő komponenst.
Előfordulhat, hogy egyes címzetteknek nincs elegendő feldolgozási teljesítménye az összetevők feldolgozásához nagy felbontású vagy olyan alhálózaton vagy linken keresztül kell csatlakozni a hálózathoz, amely nem rendelkezik elegendő kapacitással a teljes jel átviteléhez.
Az erőforrás-foglalás lehetővé teszi az útválasztók számára, hogy előre meghatározzák, hogy képesek-e a csoportos küldésű forgalmat eljuttatni az összes címzetthez.
A korábbi erőforrás-foglalási kísérletekben, valamint a kerettovábbításban és ATM-ben alkalmazott megközelítésekben a szükséges erőforrásokat az adatfolyam forrása kéri. Ez a módszer elégséges unicast átvitel esetén, mert a továbbító alkalmazás meghatározott sebességgel továbbítja az adatokat, és a szolgáltatás szükséges minőségi szintje az átviteli séma velejárója.
Ez a megközelítés azonban nem használható csoportos küldéshez. A különböző csoporttagoknak eltérő erőforrásigényük lehet. Ha az eredeti adatfolyam alfolyamokra osztható, akkor előfordulhat, hogy a csoport néhány tagja csak az egyiket szeretné megkapni. Egyes vevőkészülékek csak az alacsony felbontású videokomponenst képesek feldolgozni. Vagy ha több feladó sugároz ugyanahhoz a csoporthoz, akkor a címzett csak egy feladót vagy azok egy részét választhatja ki. Végül, a különböző címzettek szolgáltatásminőségi követelményei a kimeneti berendezéstől, a processzor teljesítményétől és a csatorna sebességétől függően változhatnak.
Emiatt a címzett erőforrás-foglalása előnyösebb. A küldők útválasztókat biztosíthatnak Általános jellemzők forgalom (pl. adatsebesség és változékonyság), de az igényelt szolgáltatási színvonal meghatározása a címzetteken múlik. Az útválasztók ezután összesítik az erőforrás-kiosztási kérelmeket a terjesztési fa közös részein.
Az RSVP három adatfolyam-koncepción alapul: munkamenet, folyamspecifikáció és szűrőspecifikáció. Ülés egy adatfolyam, amelyet a célállomás azonosít. Ne feledje, hogy ez a koncepció eltér az RTP-munkamenettől, bár az RSVP és az RTP-munkamenetek egy az egyhez megfelelhetnek. Miután egy útválasztó lefoglalja az erőforrásokat egy adott cél számára, ezt egy munkamenet kezdeteként kezeli, és erőforrásokat foglal le a munkamenet időtartamára.
A célvégrendszertől érkező foglalási kérés, amelyet folyamatleírónak neveznek, egy folyamspecifikációból és egy szűrőből áll. Áramlási specifikáció meghatározza a szolgáltatás szükséges minőségét, és a csomópont használja a csomagütemező paramétereinek beállítására. Az útválasztó adott preferenciakészlettel továbbítja a csomagokat az aktuális áramlási specifikáció alapján.
Szűrő specifikáció meghatározza a csomagok készletét, amelyek alatt erőforrásokat kérnek. A munkamenettel együtt meghatározza a csomagok (vagy folyamok) halmazát, amelyhez a szükséges szolgáltatásminőséget biztosítani kell. Minden más, erre a célra szánt csomag feldolgozásra kerül, amennyiben a hálózat képes rá.
Az RSVP nem határozza meg a folyamatspecifikáció tartalmát, egyszerűen átadja a kérést. Az áramlási specifikáció jellemzően tartalmaz egy szolgáltatási osztályt, az Rspec-et (R jelentése tartalék) és Tspec-et (T a forgalom). A másik két paraméter számok halmaza. Az Rspec paraméter határozza meg a szolgáltatás szükséges minőségét, a Tspec paraméter pedig az adatfolyamot. Az Rspec és a Tspec tartalma átlátszó az RSVP számára.
Elvileg a szűrőspecifikáció egyetlen munkamenetből származó csomagok tetszőleges részhalmazát írja le (vagyis azokat a csomagokat, amelyek célját az adott munkamenet határozza meg). Például egy szűrőspecifikáció csak meghatározott feladókat határozhat meg, vagy meghatározhat olyan protokollokat vagy csomagokat, amelyek protokollfejléc-mezői megegyeznek a megadottakkal.
Rizs. A 3. ábra a munkamenet, a folyamatspecifikáció és a szűrőspecifikáció közötti kapcsolatot szemlélteti. Minden bejövő csomag legalább egy munkamenethez tartozik, és az adott munkamenet logikai folyamatának megfelelően kerül figyelembevételre. Ha a csomag nem tartozik egy munkamenethez sem, akkor azt kézbesítik, amennyiben vannak szabad erőforrások.
Az RSVP fő nehézsége a csoportos küldéssel kapcsolatos. ábrán látható egy multicast konfiguráció példa. 6. Ez a konfiguráció négy útválasztóból áll. Bármely két útválasztó közötti kapcsolat, amelyet egy vonal jelöl, lehet közvetlen kapcsolat vagy alhálózat. Három gazdagép – Gl, G2 és G3 – ugyanabban a csoportban van, és a megfelelő multicast címmel fogadja a datagramokat. Ezen a címen az adatokat két gazdagép – S1 és S2 – továbbítja. A piros vonal az S1 és ennek a csoportnak az útválasztási fájának, a kék vonal pedig az S2 és ennek a csoportnak az útválasztási fájának felel meg. A nyílvonalak jelzik az S1-ből (piros) és az S2-ből (kék) érkező csomagok irányát.
Az ábra azt mutatja, hogy mind a négy útválasztónak tisztában kell lennie minden egyes címzett erőforrás-foglalásával. Így az erőforrás-kiosztási kérelmek visszafelé terjednek az útválasztási fán keresztül.
Az RSVP két fő üzenettípust használ: Resv és Path. A Resv üzeneteket a címzettek generálják, és felfelé terjednek a fában, miközben minden csomópont összefűzi és újra összeállítja a különböző címzettektől származó csomagokat, ha lehetséges. Ezek az üzenetek hatására az útválasztó erőforrás-foglalási állapotba lép az adott munkamenethez (multicast cím). Végül az összes kombinált Resv üzenet eljut a küldő gazdagéphez. A kapott információk alapján beállítják a megfelelő ütemezési vezérlési paramétereket az első ugráshoz.
Rizs. A 7. ábra a Resv üzenetfolyamot mutatja. Figyelem: az üzenetek összefűzve vannak; ezért csak egy üzenetet küldenek a kombinált kézbesítési fa bármely ágára. Ezeket az üzeneteket azonban rendszeresen újra el kell küldeni az erőforrás-foglalási időszak meghosszabbításához.
Az útvonal üzenet a fordított útvonal információinak terjesztésére szolgál. Minden modern multicast útválasztási protokoll csak a közvetlen útvonalat támogatja egy terjedési fa formájában (a küldőtől lefelé). De a Resv üzeneteket az összes köztes útválasztón keresztül vissza kell küldeni az összes küldő gazdagépnek.
Mivel az útválasztási protokoll nem ad fordított útvonalinformációt, azt az RSVP az útvonal üzenetekben hordozza. Bármely gazdagép, amely a feladó szeretne lenni, elérési út üzenetet küld a csoport minden tagjának. Útközben minden útválasztó és minden célállomás belép az elérési út állapotába, jelezve, hogy ennek a feladónak a csomagjait arra az ugrásra kell továbbítani, ahonnan a csomagot fogadták. Rizs. Az 5. ábra azt mutatja, hogy az elérési út csomagokat ugyanazokon az útvonalakon küldik el, mint az adatcsomagokat.
Fontolja meg az RSVP protokoll működését. A gazdagép szempontjából a protokoll működése a következő lépésekből áll (ennek a sorrendnek az első két lépése néha felcserélődik).
A nagy mennyiségű grafikával való munka tegnapi módszerei teljesen alkalmatlanok a modern rendszerek számára. Új eszközök nélkül nem lehet megfelelni a növekvő adatátviteli követelményeknek azok mennyiségének növekedése, a valós idejű alkalmazások terjedése és a multicast terjesztés miatt. Az RTP és az RSVP szilárd alapot biztosítanak a következő generációs LAN-ok számára.
E protokollok valós alkalmazásának példája a VoIP (Voice over IP) modell – hangátvitel IP-hálózatokon, amelyet a H.232 szabvány ír le, és amely audio-, video-információk és adatok IP-hálózaton keresztüli továbbítását biztosítja. Ebben az esetben az RTP valós idejű protokollt használja a kapcsolat létrehozására, az RSVP protokollt pedig a hálózati erőforrások lefoglalására.
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 megtörténik UDP protokoll, 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: egy 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 igényli), és egy X bitet, amely 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ót véletlenszerűen választják ki, í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 visszajelzést ad a küldőknek, a stream fogadóknak pedig néhány QoS fejlesztést, csomaginformációkat (vesztés, késleltetés, jitter) és felhasználót (alkalmazás, adatfolyam). 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.
