Jó napot!

Összesen: 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 video stream átvitelét és méréseket végez egy bizonyos időintervallumot, hogy később elmentse őket a bázisra. Az adatbázisból származó adatok szerint minden kameráról rendszeresen készülnek riportok.

És mi olyan nehéz?

A megoldás keresése során számos probléma azonnal kijavításra került:

• Nem tolakodó kapcsolat. A felügyeleti rendszer már működő csatornákra csatlakozik, amelyekben a kapcsolatok nagy része (RTSP-n keresztül) már létrejött, a szerver és a kliens már tudja, hogy melyik portokon történik a csere, de ezt nem tudjuk előre. Egy jól ismert port csak az RTSP protokollhoz létezik, de az UDP streamek tetszőleges portokon keresztül tudnak menni (ráadásul kiderült, hogy gyakran sértik a SHOULD páros/páratlan port követelményt, lásd rfc3550). Hogyan állapítható meg, hogy ez vagy az a csomag valamilyen IP-címről videó adatfolyamhoz tartozik? Például a BitTorrent protokoll hasonlóan viselkedik - a kapcsolat létrehozásának szakaszában az ügyfél és a szerver megállapodik a portokban, majd az összes UDP-forgalom „csak egy bitfolyamnak” tűnik.
• Az összekapcsolt hivatkozások nem csupán videofolyamokat tartalmazhatnak. Lehetnek HTTP, BitTorrent és SSH, és bármilyen más protokoll, amit ma használunk. Ezért a rendszernek megfelelően azonosítania kell a videofolyamokat, hogy elkülönítse őket a forgalom többi részétől. Hogyan lehet ezt valós időben megtenni 8 tíz gigabites kapcsolattal? Természetesen általában nem 100%-ig vannak feltöltve, így a teljes forgalom nem 80 gigabit / s lesz, hanem körülbelül 50-60, de ez nem olyan kevés.
• Skálázhatóság. Ahol már sok a videó stream, ott még több is lehet, mivel a videó megfigyelés már régóta hatékony eszköznek bizonyult. Ez azt sugallja, hogy legyen egy tartalék a teljesítményre és egy tartalék a hivatkozásokra.

Megfelelő megoldást keresek...

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éztünk 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, statisztikák rögzítésére és tárolására nem képes. 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 " ne feledje” a fogadott csomagok számát, az elveszett csomagok számát, és így tovább... Ráadásul ilyen sebességgel és ekkora adatmennyiségen, veszteségmentes feldolgozás mellett keresni nem triviális feladattá válik.

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.

Mit lehet mérni egy RTP-csomag mezőivel?

A leírásból kitűnik, hogy az RTP csomagban a minőségmérés szempontjából a következő területekre vagyunk kíváncsiak:

• sorszám – 16 bites számláló, amely minden egyes elküldött csomaggal növekszik;
• timestamp - időbélyeg, h.264 esetén a minta mérete 1/90000 s (azaz 90 kHz-es frekvenciának felel meg);
• Marker bit Az rfc3550-ben általánosságban leírják, hogy ez a bit a „jelentős” események kijelölésére szolgál, és valójában a kamerák leggyakrabban ezzel a bittel jelzik egy videó keret és speciális csomagok kezdetét SPS / PPS információkkal.

Nyilvánvaló, hogy a sorszám lehetővé teszi a következő áramlási paraméterek meghatározását:

• csomagvesztés (frame loss);
• a csomag újraküldése (duplikáció);
• érkezési sorrend megváltoztatása (átrendelés);
• a kamera újratöltése, nagy "rés" a sorrendben.

Az időbélyeg lehetővé teszi a következők mérését:

• késleltetési változás (más néven jitter). Ebben az esetben egy 90 kHz-es számlálónak kell működnie a fogadó oldalon;
• elvileg a csomag áthaladásának késése. De ehhez szinkronizálni kell a kamera idejét az időbélyeggel, és ez akkor lehetséges, ha a kamera küldő jelentéseket (RTCP SR) továbbít, ami általában nem igaz, mert a való életben sok kamera figyelmen kívül hagyja az RTCP SR üzenetet (azoknak a kameráknak a fele, amelyekkel volt alkalmunk dolgozni).

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!

Hogyan lehet azonosítani az RTP-folyamokat?

A statisztikák vezetése érdekében az RTP fejlécből nyert információkat valamilyen kamera (videofolyam) azonosítóhoz kell „csatolni”. A kamera a következő paraméterek alapján egyedileg azonosítható:

• Forrás és cél IP-címek
• Forrás és célportok
• SSRC. Különösen fontos, ha egy IP-ről több adatfolyamot sugároznak, pl. többportos kódoló esetén.

É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.

Hogyan lehet elkülöníteni az RTP-csomagokat a többi forgalomtól?

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 kifejezett 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 az rfc3550-ben (A.1. függelék) ajánlott 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 egy kis hatótávolság. 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ő:

1. csomagot kapunk, szétszedjük mezőkre;
2. ha a verzió 2 és a rakomány típusa a megadott határokon belül van, akkor a fejléceket elküldjük a szervernek.

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ében 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.

Továbblépni…

Felismerve, 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 nagy terhelésű és időkritikus munkát a Berkut-MX-re, azaz FPGA. „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.

Ennek eredményeként a szerver nem 50-60 Gigabit / s sebességgel működik, 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!

Mi a szerver végeredménye?

Tehát mit csinál a szerver a mi architektúránkban? Feladatai:

• hallgass egy UDP socketet, és olvass be a mezőket a csomagolt fejlécekkel;
• elemzi a bejövő csomagokat, és kivonja onnan az RTP fejlécmezőket a kameraazonosítókkal együtt;
• a kapott mezőket korrelálni a korábban kapottakkal, és megérteni, hogy elvesztek-e a csomagok, ismételten küldték-e a csomagokat, változott-e az érkezési sorrend, mi volt a csomagtovábbítási késleltetés (jitter) változása stb.;
• a mért adatokat időre vonatkoztatva rögzítse az adatbázisban;
• elemzi a bázist és jelentéseket készít, csapdákat küld a kritikus eseményekről (nagy csomagvesztés, csomagok elvesztése egyes kamerákból stb.).

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 socket-en 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 annak az UDP portnak a számát, amelyre a statisztika kerül. Ennek megfelelően minden, a portján figyelő folyamat megközelítőleg ugyanannyi forgalmat kap.

Pro és contra

Ideje dicsekedni és beismerni a megoldás hiányosságait.

Kezdem a profikkal:

• nincs veszteség a 10G-s kapcsolatok csomópontjában. Mivel az FPGA viszi a „csapást”, biztosak lehetünk benne, hogy minden csomagot elemezni fog;
• 55 000 (vagy több) kamera figyeléséhez csak egy szerverre van szükség egy 10G kártyával. Jelenleg 2x Xeon alapú szervereket használunk, 4 maggal, egyenként 2400 MHz-en. Elég egy margó: az információgyűjtéssel párhuzamosan készülnek a jelentések;
• 8 "tucat" (10G link) felügyelete csak 2-3 egységbe fér bele: nincs mindig sok hely és teljesítmény a rackben a felügyeleti rendszer számára;
• amikor az MX-ekről a kapcsolón keresztül linkeket csatlakoztat, új hivatkozásokat adhat hozzá a figyelés leállítása nélkül, mert ehhez nem kell táblákat behelyezni a szerverbe, és nem kell kikapcsolni;
• a szerver nincs túlterhelve adatokkal, csak azt kapja, ami szükséges;
• Az MX fejlécei egy jumbo Ethernet csomagban érkeznek, ami azt jelenti, hogy a processzort nem fojtják meg megszakítások (amellett nem feledkezünk meg a megszakítások összevonásáról sem).

Az igazság kedvéért figyelembe veszem a hátrányokat:

• az adott feladathoz való erőteljes optimalizálás miatt az új mezők vagy protokollok támogatásának hozzáadása az FPGA-kód módosítását igényli. Ez több időt vesz igénybe, mintha ugyanezt tennénk a processzoron. Mind a fejlesztés, mind a tesztelés, mind a telepítés során;
• a videoinformációkat egyáltalán nem elemzik. A kamera lőhet egy előtte lógó jégcsapot, vagy rossz irányba fordítható. Ez a tény észrevétlen marad. Természetesen lehetőséget biztosítottunk a kiválasztott kameráról videó rögzítésére, de a kezelő nem tudja végigmenni mind az 55 000 kamerán!
• egy szerver és az FPGA-val működő eszközök drágábbak, mint egy vagy két szerver;)

Összegzés

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. Mert ebben az esetben az RTP fejléc már nem fix eltoláson 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-t kellett újraösszeszerelnünk a szerveren – ebből fakad a túl magas terhelés.

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ását (sorok megszakítások szerinti elosztása, 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 körbejártá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!

Az internet gyors növekedése új követelményeket támaszt az adatátvitel sebességével és mennyiségével szemben. Mindezen igények kielégítéséhez pedig nem elég a hálózat kapacitásának növelése önmagában, ésszerű és hatékony módszerekre van szükség a forgalom és a távvezetékek torlódásainak kezelésére.

A valós idejű alkalmazásokban a küldő állandó sebességgel állít elő adatfolyamot, és a vevőnek (vagy vevőknek) ezeket az adatokat ugyanolyan sebességgel kell az alkalmazásnak átadnia. Ilyen alkalmazások például az audio- és videokonferenciák, az élő videó, az orvosi távdiagnosztika, a számítógépes telefonálás, az elosztott interaktív szimuláció, a játékok, a valós idejű megfigyelés és mások.

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.

Ezt a feladatot az új valós idejű szállítási protokoll hivatott megoldani - RTP(Real-Time Transport Protocol), amely garantálja, hogy egy vagy több célállomásra késéssel, meghatározott határokon belül kézbesítsék az adatokat, azaz az adatok valós időben lejátszhatók.

Az RTP protokoll felépítésének elvei

Az RTP nem támogat semmilyen mechanizmust a csomagküldésre, az átvitel érvényességére vagy a kapcsolat megbízhatóságára. Mindezek a funkciók a szállítási protokollhoz vannak rendelve. Az RTP az UDP-n fut, és támogatja a valós idejű adatátvitelt egy RTP-munkamenet több résztvevője között.

jegyzet

Minden egyes RTP-résztvevő számára egy munkamenetet egy csomag célállomás-átviteli címpár határoz meg (egy hálózati cím - IP és egy portpár: RTP és RTCP).

Az RTP-csomagok a következő mezőket tartalmazzák: küldőazonosító, amely jelzi, hogy melyik fél generálja az adatokat, a csomaggenerálás időbélyegei, hogy a fogadó fél a megfelelő időközönként le tudja játszani az adatokat, az átviteli sorrend információi, valamint az adatátvitel jellegére vonatkozó információk. a csomag tartalma, például a videó kódolási típusa (MPEG, Indeo stb.). Az ilyen információk elérhetősége lehetővé teszi a kezdeti késleltetés értékének és az átviteli puffer méretének becslését.

jegyzet

Egy tipikus valós idejű környezetben a küldő állandó sebességgel generál csomagokat. Rendszeres időközönként elküldik őket, áthaladnak a hálózaton, és a vevő fogadja őket, és valós időben játssza le az adatokat a fogadáskor. A csomagok hálózaton keresztüli továbbításakor bekövetkező késleltetési idő változásai miatt azonban előfordulhat, hogy szabálytalan 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 továbbítjuk. szoftver A kimenetet generáló. Ezért a valós idejű protokoll működéséhez szükséges, hogy minden csomag tartalmazzon egy időbélyeget – így a címzett ugyanolyan sebességgel tudja reprodukálni a bejövő adatokat, mint a küldő.

Mivel az RTP határozza meg (és szabályozza) az átvitt adatok hasznos adatformátumát, ezért közvetlenül kapcsolódik ehhez a szinkronizálás fogalma, amiért részben az RTP fordítómechanizmus, a mixer a felelős. Az RTP-csomagok egy vagy több forrásból érkező folyamainak vételekor a keverő egyesíti azokat, és új RTP-csomagfolyamot küld egy vagy több címzettnek. A keverő egyszerűen kombinálhatja az adatokat, valamint megváltoztathatja a formátumát, például több hangforrás kombinálásakor. Tegyünk úgy, mintha új rendszer részt kíván venni a munkamenetben, de a hálózathoz fűződő kapcsolata nem rendelkezik elegendő kapacitással 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. Több adatfolyam fogadásakor a keverő egyszerűen összeadja a PCM értékeket. A keverő által generált RTP fejléc tartalmazza annak a küldőnek az azonosítóját, akinek az adatai jelen vannak a csomagban.

Egy egyszerűbb közvetítőeszköz minden bejövő RTP-csomaghoz egy kimenő RTP-csomagot hoz létre. Ez a mechanizmus megváltoztathatja a csomagban lévő adatok formátumát, vagy más alacsony szintű protokollokat használhat az adatok egyik tartományból a másikba való átviteléhez. Például előfordulhat, 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ó a videót gyengébb minőségű formátumba konvertálja, amely mást igényel Magassebesség adatátvitel.

Munkaellenőrzési módszerek

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. Az RTP-vel együtt működik az RTCP (Real-time Transport Control Protocol) protokoll, melynek fő feladata az RTP átvitelének ellenőrzése. Az RTCP ugyanazt az alapvető szállítási protokollt használja, mint az RTP (általában UDP), de eltérő portszámot.

Az RTCP számos funkciót lát el:

1. A szolgáltatások minőségének, visszacsatolásnak biztosítása, figyelemmel kísérése torlódás esetén. Mivel az RTCP-csomagok csoportos küldés, a munkamenet minden résztvevője értékelheti a többi résztvevő teljesítményét és fogadását. 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 a tapasztalt problémákról, beleértve a csomagvesztést és a túlzott hullámzást. A címzettek visszajelzései a terjedési hibák diagnosztizálásához is fontosak. A munkamenet összes résztvevőjének üzeneteinek elemzésével a hálózati rendszergazda megállapíthatja, hogy a probléma egy résztvevőt érint-e, vagy általános jellegű. Ha a küldő alkalmazás arra a következtetésre jut, hogy a probléma a rendszer egészére jellemző, például valamelyik kommunikációs csatorna meghibásodása miatt, akkor a minőségromlás, ill. teljesen megtagadja a videó továbbítását - ez lehetővé teszi az adatok átvitelét alacsony kapacitású kapcsolaton keresztül.
2. Feladó 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.
3. Munkamenet méretezése és méretezése. A szolgáltatások minőségének biztosítása és Visszacsatolás a torlódások elhárítása, valamint a küldő azonosítása céljából minden résztvevő időszakonként RTCP csomagokat küld. 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 maximum 5 másodpercenként egy RTCP csomag kerül elküldésre. Az RFC-1889 egy 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.

RTP protokoll fejléc formátuma

Az RTP egy adatfolyam-orientált protokoll. Az RTP-csomag fejléce a valós idejű átvitel igényeit szem előtt tartva lett kialakítva. Információkat tartalmaz a csomagok sorrendjéről, hogy az adatfolyam helyesen kerüljön összeállításra a vevő oldalon, valamint egy időbélyeget a lejátszás közbeni megfelelő keretbeillesztéshez és több adatfolyam, például videó és hang szinkronizálásához.

Minden RTP-csomagnak van egy alapfejléce és esetleg további alkalmazás-specifikus mezők.

A TCP szállítási protokollként való használata ezekhez az alkalmazásokhoz több okból nem lehetséges:

1. Ez a protokoll csak két végpont között teszi lehetővé a kapcsolat létrehozását, ezért nem alkalmas csoportos küldésre.
2. A TCP biztosítja az elveszett szegmensek újraküldését, amelyek akkor érkeznek, amikor a valós idejű alkalmazás már nem vár rájuk.
3. A TCP nem rendelkezik kényelmes mechanizmussal az időzítési információk szegmensekhez való társításához, ami további követelmény a valós idejű alkalmazásokhoz.

Egy másik széles körben használt szállítási réteg protokoll, az LJDP nem rendelkezik a TCP korlátozásaival, de nem nyújt kritikus információk a szinkronizálásról.

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.

Ezt a problémát hivatott megoldani az új valós idejű szállítási protokoll, az RTP (Real-time Transport Protocol), amely garantálja az adatok egy vagy több címzetthez a megadott határokon belüli késéssel történő kézbesítését, azaz az adatok valós időben reprodukálhatóak. .

ábrán. 1 bemutatott rögzített RTP fejléc, amely számos tételt azonosító mezőt tartalmaz, például a csomag formátumát, sorozatszám, források, határok és hasznos teher típusa. A rögzített fejlécet további mezők követhetik, amelyek további információkat tartalmaznak az adatokról.

0

2

3

4

8

16

31

Szinkronizálási forrás (SSRC) azonosítója
Közreműködő forrás (CSRC) azonosítók

Rizs. 1. Javítva az RTP fejléc.

V(2 bit). verzió mezőben. A jelenlegi verzió a második.
R(1 bit). Töltse ki a mezőt. Ez a mező jelzi a kitöltő oktettek jelenlétét a hasznos teher végén. A kitöltés akkor kerül alkalmazásra, ha egy alkalmazás megköveteli, hogy a hasznos adat mérete például 32 bit többszöröse legyen. Ebben az esetben az utolsó oktett jelzi a kitöltő oktettek számát.
x(1 bit). Fejléc kiterjesztés mező. Ha ez a mező be van állítva, a fő fejlécet egy további fejléc követi, amelyet a kísérleti RTP-bővítményekben használnak.
SS(4 bit). A feladók számát tartalmazó mező. Ez a mező azon feladók azonosítóinak számát tartalmazza, akiknek az adatai benne vannak a csomagban, maguk az azonosítók a fő fejléc után.
M(1 bit). Marker mező. A marker bit jelentése a hasznos teher típusától függ. A markerbit általában az adatfolyam határainak jelzésére szolgál. Videó esetén a képkocka végét állítja be. Hang esetében a beszéd kezdetét adja meg egy néma időszak után.
RT(7 bit). A rakomány típusa mező. Ez a mező azonosítja a hasznos adat típusát és az adatformátumot, beleértve a tömörítést és a titkosítást. Álló állapotban a küldő munkamenetenként csak egy rakománytípust használ, de a valós idejű szállítási vezérlőprotokoll által jelezve megváltoztathatja azt a változó feltételeknek megfelelően.
sorszám(16 bites). Sorozatszám mező. Minden forrás egy tetszőleges számtól kezdi a csomagok számozását, majd minden egyes elküldött RTP-adatcsomaggal eggyel növeli. Ez lehetővé teszi a csomagvesztés észlelését és a csomagok sorrendjének meghatározását azonos időbélyeggel. Több egymást követő csomag ugyanazzal az időbélyeggel rendelkezhet, ha logikailag ugyanabban a pillanatban jön létre, például az azonos videokockához tartozó csomagok.
Időbélyeg(32 bites). Időbélyeg mező. Ez a mező azt az időpontot tartalmazza, amikor az első hasznosadat-oktett létrejött. Az ebben a mezőben megadott idő mértékegységei a hasznos teher típusától függenek. Az értéket a küldő helyi órája határozza meg.
Szinkronizálási forrás (SSRC) Azonosító(32 bites). Szinkronizálás Forrásazonosító mező: Véletlenszerűen generált szám, amely egyedileg azonosítja a forrást egy munkameneten belül, és független a hálózati címtől. Ez a szám fontos szerepet játszik az egy forrásból érkező adatok feldolgozásakor.
Közreműködő forrás (CSRC) azonosítója(32 bites). A fő adatfolyamba „keverve” a forrásazonosító mezők listája, például keverővel. A keverő beilleszti az RTP-csomag felépítésében részt vevő források SSRC-azonosítóinak teljes listáját. Ezt a listát CSRC-nek hívják. A lista elemeinek száma: 0-tól 15-ig. Ha a résztvevők száma meghaladja a 15-öt, akkor az első 15 kerül kiválasztásra. Példa erre egy audiokonferencia, amelynek RTP-csomagjaiban az összes résztvevő beszédeit összegyűjtik, mindegyik saját beszédével saját SSRC - ezek alkotják a CSRC listát. Ebben az esetben az egész konferencia közös SSRC-vel rendelkezik.

Az RTCP protokoll, mint minden vezérlőprotokoll, sokkal összetettebb mind felépítésében, mind az általa ellátott funkciók tekintetében (hasonlítsa össze például az IP és TCP protokollokat). Bár az RTCP protokoll magja az RTP, számos további mezőt tartalmaz, amelyekkel megvalósítja funkcióit.

Erőforrás-foglalási protokoll – RSVP

A késleltetésre érzékeny adatok prioritási problémájának megoldására a hagyományos adatokkal szemben, amelyeknél a késések nem olyan kritikusak, az RSVP erőforrás-foglalási protokollt hívják, amelyet jelenleg az Internet Engineering Task Force (IETF) vizsgál. Az RSVP lehetővé teszi végrendszerek hálózati erőforrások lefoglalása a szükséges szolgáltatásminőség elérése érdekében, különösen az RTP protokollt használó valós idejű grafikus erőforrások. Az RSVP elsősorban az útválasztókra vonatkozik, bár a végcsomópont-alkalmazásoknak tudniuk kell az RSVP használatát is, hogy lefoglalják a szükséges sávszélességet egy adott szolgáltatási osztályhoz vagy prioritási szinthez.

Az RTP a többi leírt szabvány mellett lehetővé teszi a kép és a hang sikeres továbbítását hagyományos IP-hálózatokon. Az RTP/RTCP/RSVP szabványos megoldás valós idejű adathálózatokhoz. Egyetlen hátránya, hogy csak IP hálózatokhoz használható. Ez a korlátozás azonban átmeneti: a hálózatok így vagy úgy ebbe az irányba fognak fejlődni. Ez a megoldás azt ígéri, hogy megoldja a késleltetésre érzékeny adatok interneten történő továbbításának problémáját.

Irodalom

Az RTP protokoll leírása az RFC-1889-ben található.

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 a 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 visszaá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ő hálózatok és az ezekben a hálózatokban található címzési eszközök elkülöníté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, hogy a hálózat egyes eszközei több címmel is rendelkezhetnek, arra a következtetésre juthatunk, hogy ez a címzési séma 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 Fizikai cím eszköz (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 használják hálózati réteg az OSI referenciamodell;

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. Ugyanakkor rendelkezniük kell egyedi számok eszközöket. A különböző hálózatokon elhelyezkedő két munkaállomásnak eltérő hálózati előtaggal kell rendelkeznie, de továbbra is rendelkezhet ugyanazzal az eszközszámmal.

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 csatlakozáskor meg kell változtatni a hálózati címet további eszközök. Például ha teljes szám A C osztályú hálózatban lévő eszközök száma meghaladja a 255-öt, akkor a címeit B osztályú címekre kell cserélni. A hálózati rendszergazdák nem tudják sima átmenetúj címosztályba, mivel az osztályok egyértelműen elkülönülnek. 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. NÁL NÉL 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. NÁL NÉL Ebben a pillanatban minden 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, a 4-es IP-verzió pedig legfeljebb 232 (4294967296) címet, 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 könnyebb leolvasása érdekében a szakirodalomban, alkalmazási programokban stb. az IP-címek négyből állnak decimális számok 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 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 szórás lehetővé teszi egy távoli hálózaton lévő eszköz számára, hogy datagramot küldjön ugyanazon a hálózaton lévő összes eszközre. jelenlegi hálózat. 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 szórás esetén a célcím egy meghatározott hálózatszá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 helyi hálózat(és például egy másik hálózatot útválasztókkal továbbítanak), akkor a globális hálózatnak jelentős sávszélességgel kell rendelkeznie. 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 van nagy csoport az interneten futó alkalmazásokhoz kiosztott címek. A legfelső címtartomány (körülbelül 16 millió cím) adminisztratív célokra szolgál a LAN-okon. 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 csoportos küldés támogatására 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 küldő és a vevő ugyanahhoz a fizikai hálózathoz tartozik, a kapcsolati rétegben a multicast keretek küldésének és fogadásának folyamata 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).

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:

1. A telefonálás alapfogalmai: eszköztípusok, csatlakozási sémák
2. SIP/SDP/RTP protokollcsomag: hogyan működik
3. A megnyomott gombokkal kapcsolatos információk továbbítása
4. Hogyan működik a hang- és faxátvitel?
5. Digitális jelfeldolgozás és hangminőség-biztosítás az IP-telefóniában

1. A telefonálás alapfogalmai

Á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.

Által megjelenés Az FXS és FXO portok nem különböznek egymástól, ezek hagyományos 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 keresztüli 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, 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óúj szintre lépett. 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.

Fontolgat alapelvek SIP protokoll, hogy megértse, hogyan történik két előfizető kapcsolata.

2. A SIP/SDP/RTP protokollköteg leírása

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:

• Start-Line: Egy mező, amely jelzi a SIP metódust (parancsot) kérésre, vagy a SIP metódus végrehajtásának eredményét válasz közben.
• fejlécek: további információ a Start-Line-ba, ATTRIBUTE: VALUE párokat tartalmazó karakterláncok formájában.
• Törzs: bináris vagy szöveges adat. Általában SDP-paraméterek vagy üzenetek küldésére szolgál.

Í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:

• A Method/Request-URI tartalmazza a SIP metódust és az URI-t. A példában a munkamenet létrejön - az INVITE metódus, az előfizető meghívása [e-mail védett]
• Status-Code – válaszkód az előző SIP parancshoz. NÁL NÉL ezt a példát parancs sikeresen befejeződött - 200-as kód, azaz. Az 555-ös előfizető felvette a telefont.
• Via - cím, ahol a 777-es előfizető választ vár. A 200 OK üzenet esetében ez a mező az INVITE üzenetből másolódik.
• Feladó/Címzett – az üzenet feladójának és címzettjének megjelenített neve és címe. A 200 OK üzenet esetében ez a mező az INVITE üzenetből másolódik.
• A Cseq tartalmazza a parancs sorszámát és annak a metódusnak a nevét, amelyre az adott üzenet hivatkozik. A 200 OK üzenet esetében ez a mező az INVITE üzenetből másolódik.
• Content-Type - a Body blokkban továbbított adatok típusa, ebben az esetben az SDP adatok.
• Connection Information – IP-cím, amelyre a második előfizetőnek RTP-csomagokat kell küldenie (vagy T.38-on keresztüli faxátvitel esetén UDPTL-csomagokat).
• Médialeírás - az a port, amelyre a második előfizetőnek továbbítania kell a megadott adatokat. Ebben az esetben ezek az audio (audio RTP/AVP) és a támogatott adattípusok listája - PCMU, PCMA, GSM kodekek és DTMF jelek.

Az SDP üzenet MEZŐ=ÉRTÉK párokat tartalmazó sorokból áll. A főbb területek a következők:

• o- Eredet, munkamenet szervező neve és munkamenet azonosítója.
• Val vel- Csatlakozási információ, a mezőt korábban leírtuk.
• m- Médialeírás, a mezőt korábban leírtuk.
• a- média attribútumok, adja meg a továbbított adatok formátumát. Például jelzik a hang irányát - vétel vagy adás (sendrecv), kodekeknél a mintavételi sebességet és a kötési számot (rtpmap).

Az RTP-csomagok meghatározott formátumban kódolt audio/video adatokat tartalmaznak. Ez a formátum a PT (payload type) mezőben megadott. A https://wikipedia org wiki RTP audio-video profilban található táblázat arról, hogy ennek a mezőnek az értéke hogyan felel meg egy adott formátumnak.

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 kép 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, az első dolga, hogy regisztrálja magát távoli szerver(SIP Regisztrátor), SIP REGISTER üzenetet küld neki.

Előfizető hívásakor SIP INVITE üzenet kerül elküldésre, melynek törzse egy SDP üzenetet tartalmaz, 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 megtörténik az SDP újraegyeztetési eljárás, az ún. REINVITE. Egyébként pont 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 proxy szerver a NAT mögött van, akkor az RTP forgalom átirányítása után egyik előfizető sem hallja. egy másik.

A beszélgetés befejezése után a telefont leadó előfizető SIP BYE üzenetet küld.

3. Információ átvitele a megnyomott gombokról

Néha a munkamenet létrejötte 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:

• Pulse - történelmileg az első, főleg a forgó tárcsázós telefonokban használták. A tárcsázás a telefonvonal egymás utáni zárása és nyitása miatt történik a tárcsázott számjegy szerint.
• Tone - tárcsázás DTMF kódokkal (Dual-Tone Multi-Frequency) - a telefon minden gombjának két szinuszos jel (hang) kombinációja van. A Goertzel-algoritmus végrehajtásával meglehetősen könnyű meghatározni a lenyomott gombot.

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:

1. DTMF Inband - hangjelzés generálása és továbbítása az audioadatokon belül (aktuális RTP-csatorna) egy normál hangtárcsázás.
2. RFC2833 - egy speciális telefonos esemény RTP csomag jön létre, amely információkat tartalmaz a lenyomott gombról, hangerőről és időtartamról. Az RTP formátum száma, amelyben az RFC2833 DTMF csomagok továbbításra kerülnek, az SDP üzenet törzsében van megadva. Például: a=rtpmap:98 phone-event/8000.
3. SIP INFO - egy SIP INFO csomag jön létre a megnyomott gombbal, hangerővel és időtartammal kapcsolatos információkkal.

A hangadatokon belüli DTMF átvitelnek (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 a csomagok egy része elveszik, akkor észlelés történhet ugyanazon gomb kétszeri megnyomásával).

A fő különbség a DTMF RFC2833 és a SIP INFO között: ha a SIP proxy szerver képes az RTP-t közvetlenül az előfizetők között továbbítani, megkerülve magát a szervert (például canreinvite=yes a csillaggal), akkor a szerver nem veszi észre az RFC2833 csomagokat. aminek az eredménye lesz nem elérhető szolgáltatások DVO. A SIP-csomagok továbbítása mindig SIP-proxyszervereken keresztül történik, így a VAS mindig működik.

4. Hang- és faxátvitel

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 támogatnia kell a G.711 alaw/ulaw kodekeket, megvalósításuk nagyon egyszerű, a hangminőség jó, 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 továbbítaná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ő:

1. A normál hangkapcsolat bármely kodek használatával jön létre.
2. Amikor papírt töltenek be a küldő faxkészülékbe, az időnként T.30 CNG (Calling Tone) jelet küld, jelezve, hogy készen áll a fax küldésére.
3. A fogadó oldalon a CED (Called Terminal Identification) T.30 jel generálódik - ez a készenlét a fax fogadására. Ez a jel vagy a "Fax fogadása" gomb megnyomása után kerül elküldésre, vagy a fax automatikusan megteszi.
4. A CED jel észlelése a küldő oldalon történik, és a SIP REINVITE eljárás megtörténik, és a T.38 típust jelzi az SDP üzenet: m=image 39164 udptl t38.

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.

5. Digitális jelfeldolgozás (DSP). Hangminőség biztosítása IP-telefóniában, tesztpéldák

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 telefonálás sajátosságait: nem mindig használnak jó minőségű headsetet, az interneten csomagleesések vannak, néha egyenetlenül érkeznek a csomagok, áteresztőképesség a hálózatok sem gumik.

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- egy 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 effektust a tc segédprogrammal is emulálhatja (a csomag érkezésének várható pillanata és a tényleges pillanat között legfeljebb 500 ms lehet):

tc qdisc add dev eth1 gyökér netem késleltetés 500ms átrendezés 99%

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:

• akusztikus visszhang a rossz minőségű hangút miatt (a hangszóró hangja belép a mikrofonba);
• közötti impedancia eltérés miatt elektromos visszhang telefonés SLIC modul. A legtöbb esetben ez olyan áramkörökben fordul elő, amelyek egy 4 vezetékes telefonvonalat alakítanak át 2 vezetékessé.

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:

• kezdőknek
• kezdőknek

Címkék hozzáadása