Dobrý deň!

Celkom: monitorovací systém je komplex, ktorý je v nerušivom režime pripojený k n-tému počtu 10-gigabitových ethernetových liniek, ktorý nepretržite „monitoruje“ prenos všetkých RTP video streamov prítomných v prevádzke a vykonáva merania pri určitý časový interval, aby sa neskôr uložili na základňu. Podľa údajov z databázy sú pravidelne zostavované reporty pre všetky kamery.

A čo je také ťažké?

V procese hľadania riešenia sa okamžite vyriešilo niekoľko problémov:

• Nerušivé spojenie. Monitorovací systém sa pripája na už fungujúce kanály, v ktorých je väčšina spojení (cez RTSP) už vytvorená, server aj klient už vedia, na ktorých portoch výmena prebieha, ale nevieme to dopredu. Známy port je len pre protokol RTSP, ale UDP streamy môžu ísť cez ľubovoľné porty (okrem toho sa ukázalo, že často porušujú požiadavku na párny/nepárny port, pozri rfc3550). Ako zistiť, že ten či onen paket z nejakej IP adresy patrí do video streamu? Napríklad protokol BitTorrent sa správa podobne - vo fáze vytvárania spojenia sa klient a server dohodnú na portoch a všetka prevádzka UDP potom vyzerá ako „len bitový prúd“.
• Prepojené odkazy môžu obsahovať viac než len videostreamy. Môže existovať HTTP, BitTorrent a SSH a akékoľvek iné protokoly, ktoré dnes používame. Preto musí systém správne identifikovať video streamy, aby ich oddelil od zvyšku prevádzky. Ako to urobiť v reálnom čase s 8 desaťgigabitovými linkami? Samozrejme, väčšinou nie sú naplnené na 100%, takže celková prevádzka nebude 80 gigabitov/s, ale cca 50-60, ale to nie je až tak málo.
• Škálovateľnosť. Tam, kde už existuje veľa video streamov, ich môže byť ešte viac, pretože video sledovanie sa už dlho osvedčilo ako efektívny nástroj. To naznačuje, že by mala existovať rezerva pre výkon a rezerva pre odkazy.

Hľadá sa vhodné riešenie...

Prirodzene, snažili sme sa vyťažiť maximum z vlastných skúseností. V čase, keď bolo prijaté rozhodnutie, sme už mali implementáciu spracovania ethernetových paketov na zariadení Bercut-MX s FPGA (jednoduchšie - MX). S pomocou Bercut-MX sme boli schopní získať potrebné polia na analýzu z hlavičiek ethernetových paketov. Nanešťastie sme nemali žiadne skúsenosti so spracovaním takého objemu prevádzky pomocou „bežných“ serverov, takže sa na takéto riešenie pozerali s určitými obavami ...

Zdalo by sa, že zostalo len aplikovať metódu na RTP pakety a zlatý kľúč by sme mali vo vrecku, no MX dokáže spracovávať len prevádzku, neobsahuje možnosť zaznamenávať a ukladať štatistiky. V FPGA nie je dostatok pamäte na uloženie nájdených spojení (kombinácie IP-IP-port-port), pretože v 2x10-gigabitovom prepojení vstupujúcom na vstup môže byť približne 15 000 video streamov a pre každé je potrebné „ zapamätať si“ počet prijatých paketov, počet stratených paketov atď... Navyše vyhľadávanie takou rýchlosťou a takým množstvom dát, ktoré podlieha bezstratovému spracovaniu, sa stáva netriviálnou úlohou.

Aby sme našli riešenie, museli sme „pátrať hlbšie“ a zistiť, aké algoritmy použijeme na meranie kvality a identifikáciu video streamov.

Čo možno merať poliami paketu RTP?

Z popisu je vidieť, že z pohľadu merania kvality v RTP pakete nás zaujímajú nasledovné polia:

• poradové číslo - 16-bitové počítadlo, ktoré sa zvyšuje s každým odoslaným paketom;
• timestamp - timestamp, pre h.264 je veľkosť vzorky 1/90000 s (t.j. zodpovedá frekvencii 90 kHz);
• Marker bit V rfc3550 je vo všeobecnosti opísané, že tento bit je určený na označenie „významných“ udalostí a v skutočnosti kamery týmto bitom najčastejšie označujú začiatok snímky videa a špecializované pakety s informáciami SPS / PPS.

Je celkom zrejmé, že poradové číslo vám umožňuje definovať nasledujúce parametre toku:

• strata paketov (strata rámca);
• opätovné odoslanie paketu (duplikát);
• zmena poradia príchodu (zmena poradia);
• opätovné načítanie fotoaparátu s veľkou „medzerou“ v sekvencii.

Časová pečiatka vám umožňuje merať:

• zmena oneskorenia (nazývaná aj jitter). V tomto prípade by mal na prijímacej strane fungovať 90 kHz čítač;
• v princípe oneskorenie pri prechode paketu. Na to však musíte synchronizovať čas kamery s časovou pečiatkou, a to je možné, ak kamera prenáša správy odosielateľa (RTCP SR), čo vo všeobecnosti nie je pravda, pretože v reálnom živote mnohé kamery ignorujú správu RTCP SR (asi polovica kamier, s ktorými sme mali možnosť pracovať).

M-bit vám umožňuje merať snímkovú frekvenciu. Je pravda, že rámce SPS/PPS protokolu h.264 spôsobujú chybu, pretože nie sú snímky videa. Dá sa však vyrovnať pomocou informácií z hlavičky NAL-unit, ktorá vždy nasleduje po hlavičke RTP.

Podrobné algoritmy na meranie parametrov sú nad rámec článku, nebudem sa do toho vŕtať. V prípade záujmu má rfc3550 príklad kódu výpočtu straty a vzorec na výpočet jitteru. Hlavným záverom je, že na meranie základných charakteristík transportného toku stačí len niekoľko polí z RTP paketov a NAL jednotiek. A ostatné informácie nie sú zahrnuté v meraniach a môžu a mali by byť vyradené!

Ako identifikovať RTP streamy?

Na uchovávanie štatistík musia byť informácie získané z hlavičky RTP „pripojené“ k určitému identifikátoru kamery (video streamu). Fotoaparát možno jednoznačne identifikovať podľa nasledujúcich parametrov:

• Zdrojové a cieľové IP adresy
• Zdrojové a cieľové porty
• SSRC. Je to obzvlášť dôležité, keď sa z jednej IP vysiela niekoľko tokov, t.j. v prípade multiportového kódovača.

Zaujímavé je, že najprv sme robili identifikáciu kamier len podľa zdrojovej IP a SSRC, pričom sme sa spoliehali na to, že SSRC by malo byť náhodné, ale v praxi sa ukázalo, že veľa kamier nastavuje SSRC na pevnú hodnotu (povedzme 256). Zrejme je to kvôli šetreniu zdrojov. V dôsledku toho sme museli do ID kamery pridať porty. Tým sa problém jedinečnosti úplne vyriešil.

Ako oddeliť RTP pakety od ostatnej prevádzky?

Otázkou zostáva: ako Berkut-MX po prijatí paketu pochopí, že ide o RTP? Hlavička RTP nemá takú explicitnú identifikáciu ako IP, nemá kontrolný súčet, môže sa prenášať cez UDP s číslami portov, ktoré sa dynamicky vyberajú pri nadväzovaní spojenia. A v našom prípade je väčšina pripojení už dávno vytvorená a na preinštalovanie môžete čakať veľmi dlho.

Na vyriešenie tohto problému sa v rfc3550 (Príloha A.1) odporúča skontrolovať bity verzie RTP - to sú dva bity a pole Payload Type (PT) - sedem bitov, ktoré v prípade dynamického typu zaberá malý rozsah. V praxi sme zistili, že pre zostavu kamier, s ktorými pracujeme, sa PT zmestí do rozsahu od 96 do 100.

Existuje ešte jeden faktor - parita prístavu, ale ako ukázala prax, nie je vždy dodržaná, takže sa muselo upustiť.

Správanie Berkut-MX je teda nasledovné:

1. dostaneme balík, rozoberieme ho na polia;
2. ak je verzia 2 a typ užitočného zaťaženia je v rámci daných limitov, posielame hlavičky na server.

Je zrejmé, že pri tomto prístupe existujú falošné pozitíva, pretože. nielen RTP pakety môžu spadať pod takéto jednoduché kritériá. Pre nás je však dôležité, že RTP paket nám určite neunikne a server odfiltruje „nesprávne“ pakety.

Na filtrovanie falošných prípadov server používa mechanizmus, ktorý registruje zdroj video prenosu pre niekoľko sekvenčne prijatých paketov (v pakete je poradové číslo!). Ak prišlo niekoľko paketov s po sebe idúcimi číslami, tak to nie je náhoda a začíname pracovať s týmto prúdom. Tento algoritmus sa ukázal ako veľmi spoľahlivý.

Pohybujúce sa na…

Uvedomili sme si, že všetky informácie, ktoré prichádzajú v paketoch, nie sú potrebné na meranie kvality a identifikáciu tokov, rozhodli sme sa preniesť všetku veľkú záťaž a časovo kritickú prácu na prijímaní a izolácii polí RTP paketov do Berkut-MX, teda do FPGA. „Nájde“ tok videa, analyzuje paket, ponechá len povinné polia a odošle ho na bežný server v tuneli UDP. Server vykoná merania pre každú kameru a uloží výsledky do databázy.

Výsledkom je, že server nepracuje s 50-60 Gigabit/s, ale maximálne s 5% (to je presne pomer odoslaných dát k priemernej veľkosti paketu). To znamená, že na vstupe celého systému je 55 gigabitov/s a na server sa nedostane viac ako 3 gigabit/s!

V dôsledku toho sme dostali nasledujúcu architektúru:

A prvý výsledok v tejto konfigurácii sme získali dva týždne po nastavení počiatočného TOR!

Aký je konečný výsledok servera?

Čo teda robí server v našej architektúre? Jeho úlohy:

• počúvať na zásuvke UDP a čítať z nej polia so zbalenými hlavičkami;
• analyzovať prichádzajúce pakety a extrahovať odtiaľ polia hlavičky RTP spolu s identifikátormi kamier;
• korelovať prijaté polia s tými, ktoré boli prijaté predtým, a pochopiť, či sa pakety stratili, či sa pakety odosielali opakovane, či sa zmenilo poradie príchodu, aká bola zmena oneskorenia prenosu paketov (jitter) atď.;
• zaznamenávať namerané údaje do databázy s odkazom na čas;
• analyzovať základňu a generovať správy, posielať pasce o kritických udalostiach (vysoká strata paketov, strata paketov z niektorej kamery atď.).

Napriek tomu, že celková prevádzka na vstupe servera je cca 3 Gigabit/s, server si poradí, aj keď nepoužívame žiadne DPDK, ale jednoducho pracujeme cez linuxový socket (samozrejme po zväčšení vyrovnávacej pamäte pre socket) . Navyše bude možné pripojiť nové linky a MX, pretože výkonová rezerva zostáva.

Takto vyzerá horná časť servera (toto je horná časť iba jedného kontajnera lxc, zostavy sa generujú v inom):

Vidno z nej, že celá záťaž na výpočet parametrov kvality a účtovanie štatistík je rovnomerne rozdelená do štyroch procesov. Takéto rozdelenie sa nám podarilo dosiahnuť pomocou hashovania v FPGA: hašovacia funkcia je vypočítaná podľa IP a nízke bity prijatého hashu určujú číslo UDP portu, na ktorý pôjde štatistika. Podľa toho každý proces počúvajúci na svojom porte dostáva približne rovnaké množstvo prevádzky.

zápory a klady

Je čas pochváliť sa a priznať nedostatky riešenia.

Začnem plusmi:

• žiadna strata na križovatke s 10G prepojeniami. Keďže FPGA zaberie všetku „úder“, môžeme si byť istí, že každý paket bude analyzovaný;
• na monitorovanie 55 000 kamier (alebo viac) je potrebný iba jeden server s jednou 10G kartou. V súčasnosti používame servery založené na 2x Xeon so 4 jadrami po 2400 MHz. Dosť s rezervou: súbežne so zberom informácií sa generujú správy;
• monitorovanie 8 "desiatok" (10G odkazov) sa zmestí iba do 2-3 jednotiek: v stojane nie je vždy veľa miesta a energie pre monitorovací systém;
• pri pripájaní prepojení z MX cez prepínač môžete pridávať nové prepojenia bez zastavenia monitorovania, pretože do servera nemusíte vkladať žiadne dosky a nemusíte ho preto vypínať;
• server nie je preťažený údajmi, prijíma len to, čo je potrebné;
• hlavičky od MX prichádzajú v jumbo ethernetovom pakete, čo znamená, že procesor sa nebude dusiť prerušeniami (okrem toho nezabúdame na spájanie prerušení).

V záujme spravodlivosti zvážim nevýhody:

• z dôvodu náročnej optimalizácie pre konkrétnu úlohu si pridanie podpory pre nové polia alebo protokoly vyžaduje zmeny v kóde FPGA. To vedie k viac času, ako keby sme to isté urobili na procesore. Pri vývoji a testovaní, ako aj počas nasadenia;
• informácie o videu sa vôbec neanalyzujú. Kamera môže snímať cencúľ visiaci pred ňou alebo môže byť otočená nesprávnym smerom. Táto skutočnosť zostane nepovšimnutá. Samozrejme, poskytli sme možnosť nahrávať video z vybranej kamery, ale operátor nemôže prejsť cez všetkých 55 000 kamier!
• server a zariadenia napájané FPGA sú drahšie ako len jeden alebo dva servery;)

Zhrnutie

Nakoniec sme dostali softvérový a hardvérový komplex, v ktorom môžeme ovládať časť, ktorá analyzuje pakety na rozhraniach, aj časť, ktorá vedie štatistiky. Plná kontrola nad všetkými uzlami systému nás doslova zachránila, keď sa kamery začali prepínať do prekladaného režimu RTSP/TCP. Pretože v tomto prípade sa hlavička RTP už nenachádza v pakete s pevným posunom: môže byť kdekoľvek, dokonca aj na hranici dvoch paketov (prvá polovica v jednom, druhá v druhom). V súlade s tým prešiel algoritmus na získanie hlavičky RTP a jej polí zásadnými zmenami. Museli sme urobiť opätovné zostavenie TCP na serveri pre všetkých 50 000 pripojení - preto dosť vysoké zaťaženie v hornej časti.

Nikdy predtým sme nepracovali v oblasti vysoko zaťažených aplikácií, ale problém sa nám vďaka našim schopnostiam v FPGA podarilo vyriešiť a dopadlo to celkom dobre. Dokonca tam bola aj rezerva – napríklad ďalších 20 – 30 tisíc streamov sa dá napojiť na systém s 55 000 kamerami.

Ladenie linuxových subsystémov (rozdelenie frontov prerušeniami, zvýšenie prijímacích vyrovnávacích pamätí, priame prideľovanie jadier konkrétnym procesom a pod.) som nechal mimo rámca článku, pretože. táto téma je už veľmi dobre spracovaná.

Zďaleka nie všetko som popísal, hrablí sa nazbieralo veľa, tak sa kľudne pýtajte :)

Veľká vďaka všetkým, ktorí dočítali až do konca!

Rýchly rast internetu kladie nové nároky na rýchlosť a objem prenosu dát. A na uspokojenie všetkých týchto požiadaviek nestačí len zvýšiť kapacitu siete, sú potrebné rozumné a efektívne metódy riadenia prevádzky a preťaženia prenosových vedení.

V aplikáciách v reálnom čase odosielateľ generuje tok údajov konštantnou rýchlosťou a prijímač (alebo prijímače) musia tieto údaje poskytovať aplikácii rovnakou rýchlosťou. Medzi takéto aplikácie patria napríklad audio a video konferencie, živé video, medicínska diaľková diagnostika, počítačová telefónia, distribuovaná interaktívna simulácia, hry, monitorovanie v reálnom čase a iné.

Najpoužívanejším protokolom transportnej vrstvy je TCP. Hoci TCP môže podporovať širokú škálu distribuovaných aplikácií, nie je vhodný pre aplikácie v reálnom čase.

Túto úlohu má vyriešiť nový transportný protokol v reálnom čase - RTP(Real-Time Transport Protocol), ktorý zaručuje doručenie dát do jedného alebo viacerých cieľov s oneskorením v rámci stanovených limitov, t.j. dáta je možné prehrávať v reálnom čase.

Princípy konštrukcie protokolu RTP

RTP nepodporuje žiadny mechanizmus na doručovanie paketov, platnosť prenosu alebo spoľahlivosť pripojenia. Všetky tieto funkcie sú priradené transportnému protokolu. RTP beží nad UDP a môže podporovať prenos dát v reálnom čase medzi viacerými účastníkmi v relácii RTP.

Poznámka

Pre každého účastníka RTP je relácia definovaná dvojicou cieľových transportných adries paketov (jedna sieťová adresa - IP a dvojica portov: RTP a RTCP).

Pakety RTP obsahujú nasledujúce polia: ID odosielateľa označujúce, ktorá strana generuje dáta, časové pečiatky generovania paketov, aby mohla prijímajúca strana prehrávať dáta v správnych intervaloch, informácie o poradí prenosu a informácie o povahe obsah paketu, ako je typ kódovania videa (MPEG, Indeo atď.). Dostupnosť takýchto informácií umožňuje odhadnúť hodnotu počiatočného oneskorenia a veľkosť vyrovnávacej pamäte prenosu.

Poznámka

V typickom prostredí v reálnom čase odosielateľ generuje pakety konštantnou rýchlosťou. Posielajú sa v pravidelných intervaloch, prechádzajú sieťou a prijíma ich prijímač, ktorý prehráva dáta v reálnom čase tak, ako sú prijímané. V dôsledku zmien latencie pri prenose paketov cez sieť však môžu prichádzať v nepravidelných intervaloch. Na kompenzáciu tohto efektu sa prichádzajúce pakety ukladajú do vyrovnávacej pamäte, na chvíľu sa zadržia a potom sa poskytujú konštantnou rýchlosťou. softvér Ten, ktorý generuje výstup. Preto pre fungovanie protokolu v reálnom čase je potrebné, aby každý paket obsahoval časovú značku – príjemca tak môže reprodukovať prichádzajúce dáta rovnakou rýchlosťou ako odosielateľ.

Keďže RTP definuje (a reguluje) formát užitočného zaťaženia prenášaných dát, s tým priamo súvisí aj koncept synchronizácie, za ktorý je čiastočne zodpovedný mechanizmus prekladu RTP – mixér. Po prijatí tokov RTP paketov z jedného alebo viacerých zdrojov ich mixér skombinuje a pošle nový tok RTP paketov jednému alebo viacerým príjemcom. Mixér dokáže dáta jednoducho kombinovať, ako aj meniť ich formát, napríklad pri kombinácii viacerých zdrojov zvuku. Predstierajme to nový systém sa chce zúčastniť relácie, ale jej prepojenie so sieťou nemá dostatočnú kapacitu na podporu všetkých tokov RTP, potom mixér prijme všetky tieto toky, zlúči ich do jedného a posledný odovzdá novému členovi relácie. Pri príjme viacerých streamov mixér jednoducho pridá hodnoty PCM. Hlavička RTP vygenerovaná mixérom obsahuje identitu odosielateľa, ktorého dáta sú prítomné v pakete.

Jednoduchšie prenosové zariadenie vytvorí jeden odchádzajúci RTP paket pre každý prichádzajúci RTP paket. Tento mechanizmus môže zmeniť formát údajov v pakete alebo použiť inú sadu nízkoúrovňových protokolov na prenos údajov z jednej domény do druhej. Potenciálny príjemca napríklad nemusí byť schopný spracovať vysokorýchlostný video signál, ktorý používajú ostatní účastníci relácie. Prekladač prevedie video do formátu nižšej kvality, ktorý vyžaduje iný vysoká rýchlosť prenos dát.

Metódy kontroly práce

Protokol RTP sa používa iba na prenos používateľských údajov – zvyčajne multicast – všetkým účastníkom relácie. Spolu s RTP funguje protokol RTCP (Real-time Transport Control Protocol), ktorého hlavnou úlohou je zabezpečiť kontrolu nad prenosom RTP. RTCP používa rovnaký základný transportný protokol ako RTP (zvyčajne UDP), ale iné číslo portu.

RTCP vykonáva niekoľko funkcií:

1. Zabezpečenie a sledovanie kvality služieb a spätná väzba v prípade preťaženia. Keďže pakety RTCP sú multicast, všetci účastníci relácie môžu vyhodnotiť, ako dobre fungujú a prijímajú ostatní účastníci. Správy odosielateľa umožňujú príjemcom vyhodnotiť rýchlosť prenosu dát a kvalitu prenosu. Správy príjemcov obsahujú informácie o problémoch, s ktorými sa stretávajú, vrátane straty paketov a nadmerného zvlnenia. Spätná väzba príjemcu je dôležitá aj pre diagnostiku chýb šírenia. Analýzou správ všetkých účastníkov relácie môže správca siete určiť, či sa problém týka jedného účastníka alebo je všeobecného charakteru. Ak odosielajúca aplikácia dospeje k záveru, že problém je typický pre systém ako celok, napríklad výpadkom jedného z komunikačných kanálov, potom môže zvýšiť stupeň kompresie dát z dôvodu zníženia kvality resp. úplne odmietnuť prenos videa - to vám umožňuje prenášať dáta cez pripojenie s nízkou kapacitou.
2. Identifikácia odosielateľa. RTCP pakety obsahujú štandardný textový popis odosielateľa. Poskytujú viac informácií o odosielateľovi dátových paketov ako náhodne vybrané ID zdroja synchronizácie. Okrem toho pomáhajú používateľovi identifikovať vlákna súvisiace s rôznymi reláciami.
3. Veľkosť relácie a škálovanie. Na zabezpečenie kvality služieb a spätná väzba za účelom kontroly preťaženia, ako aj za účelom identifikácie odosielateľa, všetci účastníci pravidelne posielajú RTCP pakety. Frekvencia prenosu týchto paketov klesá so zvyšujúcim sa počtom účastníkov. Pri malom počte účastníkov sa odosiela jeden RTCP paket maximálne každých 5 sekúnd. RFC-1889 popisuje algoritmus, v ktorom účastníci obmedzujú rýchlosť paketov RTCP na základe celkového počtu účastníkov. Cieľom je udržať návštevnosť RTCP pod 5 % celkovej návštevnosti relácie.

Formát hlavičky protokolu RTP

RTP je stream orientovaný protokol. Hlavička RTP paketu bola navrhnutá s ohľadom na potreby prenosu v reálnom čase. Obsahuje informácie o poradí paketov, aby bol dátový tok správne zostavený na prijímacom konci, a časovú značku pre správne prekladanie snímok počas prehrávania a pre synchronizáciu viacerých dátových tokov, ako je video a audio.

Každý RTP paket má základnú hlavičku a prípadne ďalšie polia špecifické pre aplikáciu.

Použitie TCP ako transportného protokolu pre tieto aplikácie nie je možné z niekoľkých dôvodov:

1. Tento protokol umožňuje nadviazanie spojenia iba medzi dvoma koncovými bodmi, a preto nie je vhodný na multicasting.
2. TCP zabezpečuje retransmisiu stratených segmentov, ktoré prichádzajú, keď na ne aplikácia v reálnom čase už nečaká.
3. TCP nemá vhodný mechanizmus na priraďovanie časových informácií k segmentom, čo je ďalšia požiadavka pre aplikácie v reálnom čase.

Ďalší široko používaný protokol transportnej vrstvy, LJDP, nemá niektoré obmedzenia TCP, ale neposkytuje kritické informácie o synchronizácii.

Zatiaľ čo každá aplikácia v reálnom čase môže mať svoje vlastné mechanizmy na podporu prenosu v reálnom čase, zdieľajú mnohé spoločné črty, vďaka ktorým je definovanie jediného protokolu veľmi žiaduce.

Na vyriešenie tohto problému je navrhnutý nový prenosový protokol v reálnom čase RTP (Real-time Transport Protocol), ktorý zaručuje doručenie dát jednému alebo viacerým príjemcom s oneskorením v rámci stanovených limitov, t.j. dáta je možné reprodukovať v reálnom čase. .

Na obr. 1 prezentované pevná hlavička RTP, ktorý obsahuje množstvo polí identifikujúcich položky, ako napríklad formát balíka, sériové číslo, zdroje, hranice a typ užitočného zaťaženia. Za pevnou hlavičkou môžu nasledovať ďalšie polia obsahujúce dodatočné informácie o údajoch.

0

2

3

4

8

16

31

Identifikátor zdroja synchronizácie (SSRC).
Identifikátory prispievajúceho zdroja (CSRC).

Ryža. 1. Opravená hlavička RTP.

V(2 bity). pole verzie. Aktuálna verzia je druhá.
R(1 bit). Vyplňte pole. Toto pole signalizuje prítomnosť výplňových oktetov na konci užitočného zaťaženia. Výplň sa aplikuje, keď aplikácia vyžaduje, aby veľkosť užitočného zaťaženia bola násobkom napríklad 32 bitov. V tomto prípade posledný oktet označuje počet oktetov výplne.
X(1 bit). Pole rozšírenia hlavičky. Keď je toto pole nastavené, za hlavnou hlavičkou nasleduje ďalšia hlavička používaná v experimentálnych rozšíreniach RTP.
SS(4 bity). Pole pre počet odosielateľov. Toto pole obsahuje počet identifikátorov odosielateľov, ktorých dáta sú v pakete, pričom samotné identifikátory nasledujú za hlavnou hlavičkou.
M(1 bit). Pole značky. Význam bitu markera závisí od typu užitočného zaťaženia. Marker bit sa zvyčajne používa na označenie hraníc dátového toku. V prípade videa nastavuje koniec snímky. V prípade hlasu špecifikuje začiatok reči po určitej dobe ticha.
RT(7 bitov). Pole typu užitočného zaťaženia. Toto pole identifikuje typ užitočného zaťaženia a formát údajov vrátane kompresie a šifrovania. V stacionárnom stave používa odosielateľ iba jeden typ užitočného zaťaženia na reláciu, ale môže ho zmeniť v reakcii na meniace sa podmienky, ak to signalizuje protokol riadenia prenosu v reálnom čase.
poradové číslo(16 bitov). Pole poradového čísla. Každý zdroj začína číslovať pakety od ľubovoľného čísla, potom sa zvyšuje o jeden s každým odoslaným dátovým paketom RTP. To vám umožňuje zistiť stratu paketov a určiť poradie paketov s rovnakou časovou pečiatkou. Niekoľko po sebe idúcich paketov môže mať rovnakú časovú značku, ak sú logicky generované v rovnakom okamihu, ako napríklad pakety patriace do rovnakého video rámca.
Časová značka(32 bitov). Pole časovej pečiatky. Toto pole obsahuje časový bod, v ktorom bol vytvorený prvý dátový oktet užitočného zaťaženia. Jednotky, v ktorých je čas špecifikovaný v tomto poli, závisia od typu užitočného zaťaženia. Hodnota je určená miestnymi hodinami odosielateľa.
Zdroj synchronizácie (SSRC) Identifikátor(32 bitov). Pole ID zdroja synchronizácie: Náhodne vygenerované číslo, ktoré jedinečne identifikuje zdroj v rámci relácie a je nezávislé od sieťovej adresy. Toto číslo hrá dôležitú úlohu pri spracovaní prichádzajúcej časti údajov z jedného zdroja.
Identifikátor prispievajúceho zdroja (CSRC).(32 bitov). Zoznam polí identifikátora zdroja „zmiešaných“ do hlavného streamu, napríklad pomocou mixéra. Mixér vloží celý zoznam SSRC identifikátorov zdrojov, ktoré sa podieľali na konštrukcii tohto RTP paketu. Tento zoznam sa nazýva CSRC. Počet prvkov v zozname: od 0 do 15. Ak je počet účastníkov vyšší ako 15, vyberie sa prvých 15. Príkladom je audiokonferencia, v ktorej RTP paketoch sa zhromažďujú prejavy všetkých účastníkov, pričom každý má svoje vlastné SSRC - tvoria zoznam CSRC. V tomto prípade má celá konferencia spoločný SSRC.

Protokol RTCP, ako každý riadiaci protokol, je oveľa zložitejší z hľadiska štruktúry aj funkcií, ktoré vykonáva (porovnaj napríklad protokoly IP a TCP). Hoci jadrom protokolu RTCP je RTP, obsahuje mnoho doplnkových polí, pomocou ktorých implementuje svoje funkcie.

Protokol rezervácie zdrojov - RSVP

Na vyriešenie prioritného problému pre dáta citlivé na oneskorenie, na rozdiel od tradičných dát, pre ktoré oneskorenie nie je také kritické, sa používa protokol rezervácie zdrojov - RSVP, ktorý v súčasnosti zvažuje Internet Engineering Task Force (IETF). RSVP umožňuje koncové systémy rezervovať sieťové zdroje na získanie požadovanej kvality služby, najmä zdroje pre grafiku v reálnom čase pomocou protokolu RTP. RSVP sa primárne týka smerovačov, aj keď aplikácie koncového uzla musia tiež vedieť, ako používať RSVP, aby si vyhradili požadovanú šírku pásma pre danú triedu služieb alebo úroveň priority.

RTP spolu s ostatnými opísanými štandardmi umožňuje úspešný prenos obrazu a zvuku cez konvenčné IP siete. RTP/RTCP/RSVP je štandardizované riešenie pre dátové siete v reálnom čase. Jeho jedinou nevýhodou je, že je určený len pre IP siete. Toto obmedzenie je však dočasné: siete sa budú rozvíjať týmto smerom tak či onak. Toto riešenie sľubuje vyriešiť problém prenosu dát citlivých na oneskorenie cez internet.

Literatúra

Popis protokolu RTP možno nájsť v RFC-1889.

Požiadavka na podporu niekoľkých typov prevádzky s rôznymi požiadavkami na kvalitu služby na základe zásobníka protokolov TCP/IP je teraz veľmi aktuálna. Tento problém rieši Real-Time Transport Protocol (RTP), čo je štandard IETF pre prenos dát v reálnom čase, ako je hlas alebo video cez sieť, ktorá nezaručuje kvalitu služby.

Protokol RTP zaručuje doručenie údajov jednému alebo viacerým príjemcom s oneskorením nepresahujúcim stanovenú hodnotu. Na tento účel hlavička protokolu poskytuje časové pečiatky potrebné na úspešnú obnovu zvukových a obrazových informácií, ako aj údaje o spôsobe kódovania informácií.

Aj keď protokol TCP zaručuje doručenie prenášaných údajov v správnom poradí, prevádzka je nerovnomerná, to znamená, že pri doručovaní datagramov dochádza k nepredvídateľným oneskoreniam. Keďže protokol RTP pozná obsah datagramov a má mechanizmy na detekciu straty údajov, môže znížiť latenciu na prijateľnú úroveň.

Schéma adresy IP protokolu

Schéma sieťového adresovania používaná v IP protokole je opísaná v RFC 990 a RFC 997. Je založená na oddelení adresovacích sietí od adresovacích zariadení v týchto sieťach. Táto schéma uľahčuje smerovanie. V tomto prípade musia byť adresy prideľované usporiadaným (po sebe idúcim) spôsobom, aby bolo smerovanie efektívnejšie.

Pri použití zásobníka protokolov TCP / IP v sieti dostávajú koncové zariadenia jedinečné adresy. Takéto zariadenia môžu byť osobné počítače, mediálne servery, smerovače atď. Niektoré zariadenia, ktoré majú viacero fyzických portov, ako napríklad smerovače, však musia mať na každom z portov jedinečnú adresu. Na základe schémy adresovania a skutočnosti, že niektoré zariadenia v sieti môžu mať viacero adries, môžeme usúdiť, že táto schéma adresovania nepopisuje samotné zariadenie v sieti, ale konkrétne pripojenie tohto zariadenia do siete. Táto schéma vedie k množstvu nepríjemností. Jednou z nich je nutnosť zmeniť adresu zariadenia pri presune do inej siete. Ďalšou nevýhodou je, že na prácu so zariadením, ktoré má niekoľko pripojení v distribuovanej sieti, musíte poznať všetky jeho adresy, ktoré tieto pripojenia identifikujú.

Takže pre každé zariadenie v sieťach IP môžeme hovoriť o adresách troch úrovní:

q Fyzická adresa zariadenie (presnejšie - špecifické rozhranie). V prípade zariadení v sieťach Ethernet je to adresa MAC internetová karta alebo port smerovača. Tieto adresy prideľujú výrobcovia hardvéru. Fyzická adresa má šesť bajtov: horné tri bajty sú identifikátorom výrobcu, spodné tri bajty prideľuje výrobca;

q IP adresa pozostávajúca zo štyroch bajtov. Táto adresa sa používa na sieťová vrstva referenčný model OSI;

q Identifikátor znaku – meno. Tento identifikátor môže administrátor prideliť ľubovoľne.

Keď bol protokol IP štandardizovaný v septembri 1981, jeho špecifikácia vyžadovala, aby každé zariadenie pripojené k sieti malo jedinečnú 32-bitovú adresu. Táto adresa je rozdelená na dve časti. Prvá časť adresy identifikuje sieť, v ktorej sa zariadenie nachádza. Druhá časť jednoznačne identifikuje samotné zariadenie v rámci siete. Táto schéma vedie k dvojúrovňovej hierarchii adries (obrázok 6.23).

Teraz sa zavolá pole čísla siete v adrese sieťová predvoľba, pretože identifikuje sieť. Všetky pracovné stanice v sieti zdieľajú rovnakú predponu siete. Zároveň musia mať jedinečné čísla zariadení. Dve pracovné stanice umiestnené v rôznych sieťach musia mať rôzne sieťové predvoľby, ale stále môžu mať rovnaké číslo zariadenia.

Pre flexibilitu pri adresovaní počítačové siete Dizajnéri protokolu určili, že priestor IP adries by mal byť rozdelený do troch rôznych tried - A, B a C. Keď poznáte triedu, viete, kde leží hranica medzi predponou siete a číslom zariadenia v 32-bitovej adrese. . Na obr. Obrázok 6.24 zobrazuje formáty adries týchto základných tried.

Jednou z hlavných výhod používania tried je, že z triedy adresy môžete určiť, kde je hranica medzi predvoľbou siete a číslom zariadenia. Ak sú napríklad dva najvýznamnejšie bity adresy 10, potom je bod rozdelenia medzi bitmi 15 a 16.

Nevýhodou tohto spôsobu je nutnosť zmeny sieťovej adresy pri pripájaní prídavné zariadenia. Napríklad ak celkový počet zariadení v sieti triedy C presiahne 255, potom bude potrebné nahradiť ich adresy adresami triedy B. Zmena sieťových adries si vyžiada dodatočné úsilie správcu na odladenie siete. Správcovia siete nemôžu hladký prechod do novej triedy adries, pretože triedy sú jasne oddelené. Musíte zakázať používanie celej skupiny sieťových adries, zmeniť všetky adresy zariadení v tejto skupine súčasne a až potom znova povoliť ich používanie v sieti. Zavedením tried adries sa navyše výrazne znižuje teoreticky možný počet jednotlivých adries. AT aktuálna verzia IP protokol (verzia 4) celkový počet adries môže byť 2 32 (4 294 967 296), keďže protokol umožňuje použitie 32 bitov na určenie adresy. Prirodzene, použitie niektorých bitov na servisné účely znižuje dostupný počet jednotlivých adries.

Trieda A je určená pre veľké siete. Každá adresa triedy A má 8-bitovú sieťovú predponu s najvýznamnejším bitom nastaveným na 1 a nasledujúcich sedem bitov použitých pre číslo siete. Zvyšných 24 bitov sa používa pre číslo zariadenia. AT tento moment všetky adresy triedy A sú už pridelené. Siete triedy A sa tiež označujú ako „/8“, pretože adresy triedy A majú 8-bitovú sieťovú predponu.

Maximálny počet sietí triedy A je 126 (2 7 -2 - odčítajú sa dve adresy pozostávajúce len z núl a jednotiek). Každá sieť tejto triedy podporuje až 16 777 214 (2 24 -2) zariadení. Keďže blok adries triedy A môže obsahovať maximálne 231 (2 147483648) jednotlivých adries a verzia IP 4 môže podporovať maximálne 232 (4294967296) adries, trieda A zaberá 50 % celkového priestoru adries IP.

Trieda B je určená pre stredne veľké siete. Každá adresa triedy B má 16-bitovú predponu siete, kde dva najvýznamnejšie bity sú 10 a ďalších 14 bitov sa používa pre číslo siete. Pre číslo zariadenia je pridelených 16 bitov. Siete triedy B sa tiež označujú ako „/16“, pretože adresy triedy B majú 16-bitovú predponu siete.

Maximálny počet sietí triedy B je 16 382 (2 14 -2). Každá sieť tejto triedy podporuje až 65 534 (2 16 -2) zariadení. Keďže celý blok adries triedy B môže obsahovať maximálne 230 (1 073 741 824) jednotlivých adries, zaberá 25 % celkového priestoru adries IP.

Adresy triedy C sa používajú v sieťach s malým počtom zariadení. Každá sieť triedy C má 24-bitovú predponu siete, v ktorej sú tri najvýznamnejšie bity 110 a ďalších 21 bitov sa používa pre číslo siete. Zvyšných 8 bitov je alokovaných pre čísla zariadení. Siete triedy C sa tiež označujú ako „/24“, pretože adresy triedy C majú 24-bitovú predponu siete.

Maximálny počet sietí triedy C je 2 097 152 (221). Každá sieť tejto triedy podporuje až 254 (2 8 -2) zariadení. Trieda C zaberá 12,5 % z celkového priestoru IP adries.

V tabuľke. 6.9 sumarizuje našu analýzu sieťových tried.

Tabuľka 6.9. Sieťové triedy

Okrem týchto troch tried adries existujú ďalšie dve triedy. V triede D sú najvýznamnejšie štyri bity 1110. Táto trieda sa používa na multicasting. V triede E sú horné štyri bity 1111. Je vyhradená na experimentovanie.

Pre uľahčenie čítania adries v technickej literatúre, aplikačných programoch atď. sú adresy IP reprezentované ako štyri desatinné čísla oddelené bodkami. Každé z týchto čísel zodpovedá jednému oktetu (8 bitov) IP adresy. Tento formát sa nazýva bodkovaný desiatkový zápis (Decimal-Point Notation) alebo bodkovaný desiatkový zápis (obrázok 6.25).

V tabuľke. 6.10 uvádza rozsahy desatinných hodnôt pre tri triedy adries. V tabuľke. 6.10 Zadanie XXX znamená ľubovoľné pole.

Tabuľka 6.10. Rozsahy hodnôt adries

Niektoré IP adresy nie je možné priradiť zariadeniam v sieti (tabuľka 6.11).

Ako je uvedené v tejto tabuľke, v rezervovaných IP adresách všetky bity nastavené na nulu zodpovedajú jednému z nich toto zariadenie, alebo táto sieť a adresy IP, ktorých všetky bity sú nastavené na 1, sa používajú pri vysielaní informácií. Na označenie celej siete IP ako celku sa používa adresa s číslom zariadenia so všetkými bitmi nastavenými na „0“. Sieťová adresa triedy A 127.0.0.0 je vyhradená pre spätnú slučku a je zavedená na testovanie komunikácie medzi procesmi na rovnakom počítači. Keď aplikácia používa adresu spätnej slučky, zásobník protokolu TCP/IP vráti tieto údaje aplikácii bez toho, aby čokoľvek posielal do siete. Okrem toho môže byť táto adresa použitá na interakciu samostatných procesov v rámci toho istého stroja. Preto je v IP sieťach zakázané prideľovať zariadeniam IP adresy začínajúce na 127.

Okrem smerovaného prenosu dát na konkrétnu pracovnú stanicu sa aktívne využíva broadcast prenos, pri ktorom informácie prijímajú všetky stanice v aktuálnej alebo zadanej sieti. V protokole IP existujú dva typy vysielania: riadené a obmedzené.

Riadené vysielanie umožňuje zariadeniu vo vzdialenej sieti odoslať datagram všetkým zariadeniam v rovnakej sieti. aktuálna sieť. Datagram s adresou preposlaného vysielania môže prejsť cez smerovače, ale bude doručený iba všetkým zariadeniam v zadanej sieti, nie všetkým zariadeniam. V riadenom vysielaní sa cieľová adresa skladá zo špecifického čísla siete a čísla zariadenia, ktorých všetky bity sú 0 alebo 1. Napríklad adresy 185.100.255.255 a 185.100.0.0 by sa považovali za adresy riadeného vysielania pre triedu B sieť 185.100.xxx.xxx Z hľadiska adresovania je hlavnou nevýhodou smerového vysielania to, že je potrebná znalosť čísla cieľovej siete.

Druhá forma vysielania, nazývaná obmedzené vysielanie, vysiela v rámci aktuálnej siete (siete, v ktorej sa nachádza odosielajúce zariadenie). Datagram s obmedzenou vysielacou adresou nikdy neprejde cez smerovač. Pri obmedzenom vysielaní sú číslo siete a bity čísla zariadenia nuly alebo jednotky. Všetkým zariadeniam v sieti tak bude doručený datagram s cieľovou adresou 255.255.255.255 alebo 0.0.0.0. Na obr. Obrázok 6.26 zobrazuje siete prepojené smerovačmi. V tabuľke. Obrázok 6.12 obsahuje zoznam príjemcov vysielaných datagramov odoslaných pracovnou stanicou A.

IP protokol podporuje tri spôsoby adresovania: single (unicast), broadcast (broadcast) a skupinový (multicast).

Tabuľka 6.12. Vysielacie datagramové prijímače

Pri jedinom adresovaní sa datagramy posielajú na konkrétne jedno zariadenie. Implementácia tohto prístupu nie je náročná, ale ak pracovná skupina obsahuje veľa staníc, priepustnosť nemusí byť dostatočná, pretože rovnaký datagram sa bude prenášať mnohokrát.

Pri adresovaní vysielania aplikácie odosielajú jeden datagram, ktorý je doručený všetkým zariadeniam v sieti. Tento prístup je ešte jednoduchší na implementáciu, ale ak v tomto prípade nie je vysielaná prevádzka obmedzená na lokálna sieť(a napríklad iná sieť je presmerovaná pomocou smerovačov), potom musí mať globálna sieť značnú šírku pásma. Ak sú informácie určené len pre malú skupinu zariadení, potom sa tento prístup javí ako iracionálny.

Pri multicast sa datagramy doručujú do určitej skupiny zariadení. Zároveň (čo je veľmi dôležité pri práci v distribuovaných sieťach) nevzniká nadmerná prevádzka. Multicastové a jednoadresové datagramy sa líšia adresou. V hlavičke IP datagramu s multicastom je namiesto IP adries tried A, B, C adresa triedy D, teda skupinová adresa.

Skupinová adresa je priradená niektorým prijímajúcim zariadeniam alebo, inými slovami, skupine. Odosielateľ zapíše túto multicast adresu do hlavičky IP datagramu. Datagram bude doručený všetkým členom skupiny. Prvé štyri bity adresy triedy D sú 1110. Zvyšok adresy (28 bitov) zaberá identifikátor skupiny (obrázok 6.27).

V desiatkovom formáte s bodkami sú skupinové adresy v rozsahu od 224.0.0.0 do 239.255.255.255. V tabuľke. Obrázok 6.13 zobrazuje schému prideľovania adries triedy D.

Tabuľka 6.13. Pridelenie adresy triedy D

Ako je možné vidieť z tabuľky. 6.13 je rezervovaných prvých 256 adries. Tento rozsah je vyhradený najmä pre smerovacie protokoly a iné nízkoúrovňové protokoly. V tabuľke. 6.14 obsahuje niektoré vyhradené IP adresy triedy D.

Nad týmto rozsahom je veľká skupina adresy pridelené pre aplikácie bežiace na internete. Najvyšší rozsah adries (približne 16 miliónov adries) je určený na administratívne účely v sieťach LAN. Skupinové adresy triedy D sú centrálne riadené a registrované špeciálnou organizáciou IANA.

Multicast je možné implementovať na dvoch úrovniach modelu OSI – kanálovej (Data-Link Layer) a sieťovej (Network Layer). Prenosové protokoly spojovej vrstvy, ako je Ethernet a FDDI, môžu podporovať jednoduché, vysielacie a viacsmerové adresovanie. Multicast linkovej vrstvy je obzvlášť účinný, ak je podporovaný hardvérom na NIC.

Na podporu IANA multicastingu bol pridelený blok multicastových ethernetových adries, začínajúci od 01-00-5E (v hexadecimálnom zápise). Multicast IP adresa môže byť preložená na adresu v tomto bloku. Princíp prekladu je pomerne jednoduchý: spodných 23 bitov identifikátora skupiny IP sa skopíruje do spodných 23 bitov ethernetovej adresy. Upozorňujeme, že táto schéma spája až 32 rôznych skupín IP s rovnakou ethernetovou adresou, pretože ďalších 5 bitov identifikátora skupiny IP sa ignoruje.

Tabuľka 6.14. Vyhradené adresy triedy D

Adresa	Účel
224.0.0.1	Všetky zariadenia v podsieti
224.0.0.2	Všetky smerovače v podsieti
224.0.0.4	Všetky smerovače DVMRP
224.0.0.5	Všetky smerovače MOSPF
224.0.0.9	RIP IP verzia II
224.0.1.7	audio novinky
224.0.1.11	Zvuk IEFT
224.0.1.12	IEFT video

Ak odosielateľ a prijímač patria do rovnakej fyzickej siete, proces odosielania a prijímania rámcov multicast na spojovacej vrstve je pomerne jednoduchý. Odosielateľ špecifikuje IP adresu skupiny príjemcov a NIC preloží túto adresu na zodpovedajúcu skupinovú ethernetovú adresu a odošle rámec.

Ak sú odosielateľ a príjemca v rôznych podsietiach prepojených smerovačmi, doručovanie datagramov je zložité. V tomto prípade musia smerovače podporovať jeden zo smerovacích protokolov multicast (DVMRP, MOSPF, PIM – pozri nižšie). Podľa týchto protokolov router vybuduje doručovací strom a správne prepošle multicastovú prevádzku. Okrem toho musí každý smerovač podporovať protokol IGMP (Group Management Protocol) na určenie prítomnosti členov skupiny v priamo pripojených podsieťach (obrázok 6.28).

Ak jedného dňa budete musieť rýchlo zistiť, čo je VoIP (voice over IP) a čo znamenajú všetky tieto divoké skratky, dúfam, že vám táto príručka pomôže. Okamžite si všimnem, že problémy s konfiguráciou ďalších typov telefónnych služieb (ako je prenos hovorov, hlasová pošta, konferenčné hovory atď.) sa tu neberú do úvahy.

Takže, čím sa budeme zaoberať pod rezom:

1. Základné pojmy telefonovania: typy zariadení, schémy pripojenia
2. Balík protokolov SIP/SDP/RTP: ako to funguje
3. Ako sa prenášajú informácie o stlačených tlačidlách
4. Ako funguje prenos hlasu a faxu?
5. Digitálne spracovanie signálu a zabezpečenie kvality zvuku v IP telefónii

1. Základné pojmy telefonovania

Vo všeobecnosti je schéma pripojenia miestneho účastníka k telefónnemu poskytovateľovi prostredníctvom bežnej telefónnej linky nasledovná:

Na strane poskytovateľa (PBX) je nainštalovaný telefónny modul s portom FXS (Foreign eXchange Subscriber). Doma alebo v kancelárii je nainštalovaný telefón alebo fax s portom FXO (Foreign eXchange Office) a modulom dialer.

Autor: vzhľad Porty FXS a FXO sa nelíšia, ide o bežné 6-pinové konektory RJ11. Ale pomocou voltmetra je veľmi ľahké ich rozlíšiť - na porte FXS bude vždy nejaké napätie: 48/60 V pri zavesenom slúchadle alebo 6-15 V počas hovoru. Na FXO, ak nie je pripojený k linke, je napätie vždy 0.

Na prenos dát cez telefónnu linku je potrebná dodatočná logika na strane poskytovateľa, ktorá môže byť implementovaná na module SLIC (obvod rozhrania účastníckej linky) a na strane účastníka - pomocou modulu DAA (Direct Access Arrangement).

Bezdrôtové telefóny DECT (Digital European Cordless Telecommunications) sú v súčasnosti veľmi populárne. Prístrojovo sú podobné bežným telefónom: majú tiež FXO port a modul dialer, ale majú aj modul bezdrôtová komunikácia stanice a slúchadlá na frekvencii 1,9 GHz.

Predplatitelia sa pripájajú k PSTN sieti (Public Switched Telephone Network) - telefónnu sieť všeobecné použitie, je to PSTN, PSTN. PSTN sieť je možné organizovať pomocou rôzne technológie: ISDN, optika, POTS, Ethernet. Špeciálny prípad PSTN, keď sa používa bežná analógová/medená linka - POTS (Plain Old Telephone Service) - jednoduchý starý telefónny systém.

S rozvojom internetu telefonickú komunikáciu posunuli na novú úroveň. Stacionárne telefóny sa používajú čoraz menej, hlavne pre služobné potreby. Telefóny DECT sú o niečo pohodlnejšie, ale obmedzené na obvod domu. GSM telefóny sú ešte pohodlnejšie, ale sú obmedzené hranicami krajiny (roaming je drahý). Ale pre IP telefóny sú to aj softvérové ​​​​telefóny (SoftPhone), neexistujú žiadne obmedzenia, okrem prístupu na internet.

Skype je najznámejším príkladom softvérového telefónu. Môže robiť veľa vecí, ale má dve dôležité nevýhody: uzavretú architektúru a odpočúvanie, ktoré orgány poznajú. Kvôli prvému nie je možné vytvoriť si vlastnú telefónnu mikrosieť. A kvôli druhému - nie je veľmi príjemné, keď vás špehujú, najmä v osobných a komerčných rozhovoroch.

Našťastie existujú otvorené protokoly na vytváranie vlastných komunikačných sietí s vychytávkami – sú to SIP a H.323. Na protokole SIP je o niečo viac softvérových telefónov ako na protokole H.323, čo možno vysvetliť jeho relatívnou jednoduchosťou a flexibilitou. Niekedy však táto flexibilita môže dať do kolesa veľkú palicu. Protokoly SIP aj H.323 používajú na prenos mediálnych údajov protokol RTP.

Zvážte základné princípy Protokol SIP, aby ste pochopili, ako dochádza k spojeniu dvoch účastníkov.

2. Popis zväzku protokolov SIP/SDP/RTP

SIP (Session Initiation Protocol) - protokol na nadviazanie relácie (nielen telefonickej) je textový protokol cez UDP. Je tiež možné použiť SIP cez TCP, ale to sú zriedkavé prípady.

SDP (Session Description Protocol) je protokol na dojednanie typu prenášaných dát (pre zvuk a video sú to kodeky a ich formáty, pre faxy - prenosová rýchlosť a oprava chýb) a ich cieľové adresy (IP a port). Je to tiež textový protokol. Parametre SDP sa odosielajú v tele paketov SIP.

RTP (Real-time Transport Protocol) je protokol na prenos audio/video dát. Je to binárny protokol cez UDP.

Všeobecná štruktúra SIP paketov:

• Start-Line: Pole označujúce metódu SIP (príkaz) pri požiadavke alebo výsledok vykonania metódy SIP pri odpovedi.
• hlavičky: Ďalšie informácie na začiatočný riadok, naformátovaný ako reťazce obsahujúce dvojice ATTRIBUTE: VALUE.
• Telo: binárne alebo textové údaje. Zvyčajne sa používa na odosielanie parametrov alebo správ SDP.

Tu je príklad dvoch paketov SIP pre jeden spoločný postup nastavenia hovoru:

Vľavo je obsah paketu SIP INVITE, vpravo odpoveď naň - SIP 200 OK.

Hlavné polia sú orámované:

• Method/Request-URI obsahuje metódu SIP a URI. V príklade je nadviazaná relácia - metóda INVITE, volá sa účastník [chránený e-mailom]
• Status-Code - kód odpovede na predchádzajúci príkaz SIP. AT tento príklad príkaz úspešne dokončený - kód 200, t.j. Účastník 555 zdvihol telefón.
• Cez - adresa, kde účastník 777 čaká na odpoveď. Pre správu 200 OK sa toto pole skopíruje zo správy INVITE.
• Od/Do – zobrazuje meno a adresu odosielateľa a príjemcu správy. Pre správu 200 OK sa toto pole skopíruje zo správy INVITE.
• Cseq obsahuje poradové číslo príkazu a názov metódy, na ktorú sa daná správa vzťahuje. Pre správu 200 OK sa toto pole skopíruje zo správy INVITE.
• Content-Type – typ údajov, ktoré sa prenášajú v bloku Body, v tomto prípade údaje SDP.
• Informácie o pripojení - IP adresa, na ktorú potrebuje druhý účastník posielať RTP pakety (alebo UDPTL pakety v prípade faxového prenosu cez T.38).
• Popis média - port, na ktorý musí druhý účastník preniesť špecifikované údaje. V tomto prípade ide o audio (audio RTP/AVP) a zoznam podporovaných dátových typov – PCMU, PCMA, GSM kodeky a DTMF signály.

Správa SDP pozostáva z riadkov obsahujúcich páry FIELD=VALUE. Medzi hlavné polia patria:

• o- Pôvod, názov organizátora relácie a ID relácie.
• s- Informácie o pripojení, pole je popísané vyššie.
• m- Popis média, pole je popísané vyššie.
• a- atribúty médií, špecifikujú formát prenášaných dát. Napríklad udávajú smer zvuku - príjem alebo vysielanie (sendrecv), pri kodekoch udávajú vzorkovaciu frekvenciu a číslo väzby (rtpmap).

RTP pakety obsahujú audio/video dáta zakódované v špecifickom formáte. Tento formátšpecifikované v poli PT (typ užitočného zaťaženia). Tabuľka, ako hodnota tohto poľa zodpovedá konkrétnemu formátu, je uvedená v https://wikipedia org wiki RTP audio video profile .

RTP pakety tiež obsahujú jedinečný identifikátor SSRC (definuje zdroj RTP streamu) a časovú pečiatku (časovú pečiatku, ktorá sa používa na rovnomerné prehrávanie zvuku alebo videa).

Príklad interakcie medzi dvoma účastníkmi SIP prostredníctvom servera SIP (hviezdička):

Hneď ako sa telefón SIP spustí, prvá vec, ktorú urobí, je registrácia vzdialený server(SIP Registristar), odošle na ňu správu SIP REGISTER.

Pri volaní účastníka je odoslaná správa SIP INVITE, ktorej telo obsahuje správu SDP obsahujúcu parametre prenosu zvuku / videa (aké kodeky sú podporované, na ktorú IP a port sa má poslať zvuk atď.).

Keď vzdialený účastník zdvihne telefón, dostaneme správu SIP 200 OK aj s parametrami SDP, iba vzdialený účastník. Pomocou odoslaných a prijatých parametrov SDP môžete nastaviť audio/video reláciu RTP alebo faxovú reláciu T.38.

Ak nám prijaté parametre SDP nevyhovovali alebo sa medziľahlý SIP server rozhodol, že cez seba neprepustí RTP prevádzku, vykoná sa postup opätovného vyjednávania SDP, takzvané REINVITE. Mimochodom, práve kvôli tomuto postupu majú bezplatné SIP proxy servery jednu nevýhodu - ak sú obaja účastníci v rovnakej lokálnej sieti a proxy server je za NAT, potom po presmerovaní RTP prevádzky nikto z účastníkov nepočuje ďalší.

Po skončení konverzácie odošle účastník, ktorý zavesil, správu SIP BYE.

3. Prenos informácií o stlačených tlačidlách

Niekedy sa po nadviazaní relácie počas hovoru vyžaduje prístup k ďalším službám (VAS) - podržanie hovoru, prenos, hlasová pošta atď. - ktoré reagujú na určité kombinácie stlačených tlačidiel.

Takže na bežnej telefónnej linke existujú dva spôsoby, ako vytočiť číslo:

• Pulz – historicky prvý, sa používal najmä v telefónoch s otočným voličom. K vytáčaniu dochádza v dôsledku postupného zatvárania a otvárania telefónnej linky podľa zvolenej číslice.
• Tónová - vytáčanie pomocou DTMF kódov (Dual-Tone Multi-Frequency) - každé tlačidlo telefónu má vlastnú kombináciu dvoch sínusových signálov (tónov). Spustením Goertzelovho algoritmu je celkom jednoduché určiť stlačené tlačidlo.

Počas rozhovoru je pulzná metóda nepohodlná na prenos stlačeného tlačidla. Takže prenos "0" trvá približne 1 sekundu (10 impulzov po 100 ms: 60 ms - prerušenie riadku, 40 ms - zatvorenie riadku) plus 200 ms prestávka medzi číslicami. Okrem toho bude počas pulzného vytáčania často počuť charakteristické kliknutia. Preto sa v konvenčnom telefonovaní používa iba tónový režim prístupu k VAS.

Pri telefonovaní VoIP sa informácie o stlačených tlačidlách môžu prenášať tromi spôsobmi:

1. DTMF Inband - generovanie zvukového tónu a jeho prenos v rámci zvukových dát (aktuálny RTP kanál) je normálna tónová voľba.
2. RFC2833 - vygeneruje sa špeciálny RTP paket telefónneho udalosti, ktorý obsahuje informácie o stlačenom klávese, hlasitosti a trvaní. Číslo formátu RTP, v ktorom sa budú vysielať pakety DTMF RFC2833, je uvedené v tele SDP správy. Napríklad: a=rtpmap:98 telefónna udalosť/8000.
3. SIP INFO - vytvorí sa paket SIP INFO s informáciami o stlačenom klávese, hlasitosti a trvaní.

Prenos DTMF vo vnútri audio dát (Inband) má niekoľko nevýhod - sú to režijné zdroje pri generovaní/vkladaní tónov a pri ich detekcii, obmedzenia niektorých kodekov, ktoré môžu skresľovať DTMF kódy, a slabá spoľahlivosť prenosu (ak dôjde k strate časti paketov, potom môže dôjsť k detekcii dvojitým stlačením toho istého tlačidla).

Hlavný rozdiel medzi DTMF RFC2833 a SIP INFO: ak má SIP proxy server schopnosť prenášať RTP priamo medzi účastníkmi obchádzaním samotného servera (napríklad canreinvite=yes v hviezdičke), potom server nezaznamená pakety RFC2833 ako výsledkom ktorých sa stávajú nedostupné služby DVO. SIP pakety sa vždy prenášajú cez SIP proxy servery, takže VAS bude vždy fungovať.

4. Prenos hlasu a faxu

Ako už bolo spomenuté, na prenos mediálnych údajov sa používa protokol RTP. RTP pakety vždy špecifikujú formát prenášaných dát (kodek).

Existuje mnoho rôznych kodekov na prenos hlasu, s rôznymi pomermi bitovej rýchlosti / kvality / zložitosti, existujú otvorené a uzavreté. Každý softphone musí mať podporu pre kodeky G.711 alaw/ulaw, ich implementácia je veľmi jednoduchá, kvalita zvuku je dobrá, vyžadujú si však šírku pásma 64 kbps. Napríklad kodek G.729 vyžaduje iba 8 kbps, ale je veľmi náročný na CPU a nie je zadarmo.

Pre faxový prenos sa zvyčajne používa buď kodek G.711 alebo protokol T.38. Odosielanie faxov pomocou kodeku G.711 zodpovedá odoslaniu faxu pomocou protokolu T.30, ako keby bol fax odoslaný cez bežnú telefónnu linku, ale súčasne analógový signál z linky je digitalizovaný podľa zákona/ulaw zákona. Nazýva sa to aj faxovanie Inband T.30.

Faxy využívajúce protokol T.30 si dohadujú svoje parametre: prenosovú rýchlosť, veľkosť datagramu, typ opravy chýb. Protokol T.38 je založený na protokole T.30, ale na rozdiel od vnútropásmového prenosu sú generované a prijímané príkazy T.30 analyzované. Neprenášajú sa teda nespracované dáta, ale rozpoznané príkazy na ovládanie faxu.

Príkaz T.38 sa prenáša pomocou protokolu UDPTL, čo je protokol založený na UDP a používa sa iba pre T.38. Na prenos príkazov T.38 možno použiť aj protokoly TCP a RTP, ale používajú sa oveľa menej často.

Hlavnými výhodami T.38 sú znížené zaťaženie siete a väčšia spoľahlivosť v porovnaní s Inband faxovým prenosom.

Postup na odoslanie faxu v režime T.38 je nasledujúci:

1. Normálne hlasové spojenie sa vytvorí pomocou akéhokoľvek kodeku.
2. Keď je papier vložený do odosielajúceho faxového prístroja, pravidelne odosiela signál T.30 CNG (volací tón), ktorý signalizuje, že je pripravený na odoslanie faxu.
3. Na prijímacej strane sa generuje signál T.30 CED (Called Terminal Identification) - ide o pripravenosť na príjem faxu. Tento signál sa odošle buď po stlačení tlačidla "Prijať fax", alebo to fax vykoná automaticky.
4. Signál CED je detegovaný na odosielajúcej strane a prebehne procedúra SIP REINVITE a v správe SDP je uvedený typ T.38: m=image 39164 udptl t38.

Odosielanie faxov cez internet najlepšie v T.38. Ak je potrebné preniesť fax v rámci kancelárie alebo medzi objektmi, ktoré majú stabilné pripojenie, možno použiť prenos faxu Inband T.30. V tomto prípade musí byť pred odoslaním faxu vypnutá procedúra zrušenia ozveny, aby nedošlo k ďalšiemu skresleniu.

Veľmi podrobné informácie o faxovaní sú napísané v knihe „Fax, modem a text pre IP telefóniu“ od Davida Hanesa a Gonzala Salgueira.

5. Digitálne spracovanie signálu (DSP). Zabezpečenie kvality zvuku v IP telefónii, testovacie príklady

Zaoberali sme sa protokolmi na vytvorenie konverzačnej relácie (SIP / SDP) a spôsobom prenosu zvuku cez RTP kanál. Bola tu jedna dôležitá otázka – kvalita zvuku. Na jednej strane kvalitu zvuku určuje zvolený kodek. Ale na druhej strane sú stále potrebné ďalšie DSP procedúry (DSP - digital signal processing). Tieto postupy zohľadňujú zvláštnosti VoIP telefónie: nie vždy sa používa kvalitná náhlavná súprava, na internete dochádza k vypadávaniu paketov, niekedy pakety prichádzajú nerovnomerne, priepustnosť siete tiež nie sú gumené.

Základné postupy, ktoré zlepšujú kvalitu zvuku:

VAD(Detektor hlasovej aktivity) - postup na určenie rámcov, ktoré obsahujú hlas (aktívny hlasový rámec) alebo ticho (neaktívny hlasový rámec). Toto oddelenie môže výrazne znížiť zaťaženie siete, pretože prenos informácií o tichu vyžaduje oveľa menej dát (stačí preniesť úroveň šumu alebo vôbec nič).

Niektoré kodeky už obsahujú procedúry VAD (GSM, G.729), zatiaľ čo iné (G.711, G.722, G.726) ich musia implementovať.

Ak je VAD nakonfigurovaný na prenos informácií o úrovni šumu, potom sa špeciálne pakety SID (Silence Insertion Descriptor) prenášajú vo formáte RTP 13. CN (Comfort Noise).

Stojí za zmienku, že SID proxy servery môžu zahodiť pakety SID, takže pre overenie je vhodné nakonfigurovať prenos RTP prevádzky cez SIP servery.

CNG(comfort noise generation) - postup generovania komfortného hluku na základe informácií z paketov SID. VAD a CNG teda fungujú v spojení, ale postup CNG je oveľa menej žiadaný, pretože nie vždy je možné zaznamenať prácu CNG, najmä pri malom objeme.

PLC(zakrytie straty paketov) - postup na obnovenie toku zvuku v prípade straty paketov. Aj pri 50 % strate paketov môže dobrý algoritmus PLC dosiahnuť prijateľnú kvalitu reči. Skreslenia, samozrejme, budú, ale dokážete rozoznať slová.

Najjednoduchší spôsob, ako napodobniť stratu paketov (v systéme Linux), je použiť utilitu tc z balíka iproute s modulom netem. Vykonáva iba tvarovanie odchádzajúcej prevádzky.

Príklad spustenej emulácie siete s 50% stratou paketov:

Tc qdisc change dev eth1 root netem strata 50 %

Zakázať emuláciu:

Tc qdisc del dev eth1 root

jitter buffer- postup na zbavenie sa efektu jitter, kedy sa interval medzi prijatými paketmi veľmi mení, čo v najhoršom prípade vedie k nesprávnemu poradiu prijatých paketov. Tento efekt tiež vedie k prerušeniam reči. Pre elimináciu efektu jitteru je potrebné implementovať paketovú vyrovnávaciu pamäť na prijímacej strane s veľkosťou dostatočnou na obnovenie pôvodného poradia odosielania paketov v danom intervale.

Efekt jitteru môžete napodobniť aj pomocou nástroja tc (interval medzi očakávaným okamihom príchodu paketu a skutočným okamihom môže byť až 500 ms):

tc qdisc add dev eth1 root netem oneskorenie 500 ms zmena poradia 99 %

LEC(Line Echo Canceller) - postup na odstránenie lokálnej ozveny, keď vzdialený účastník začne počuť svoj vlastný hlas. Jeho podstatou je odčítanie prijatého signálu od vysielaného signálu s určitým koeficientom.

Ozveny sa môžu vyskytnúť z niekoľkých dôvodov:

• akustická ozvena v dôsledku nekvalitnej zvukovej cesty (zvuk z reproduktora vstupuje do mikrofónu);
• elektrické echo v dôsledku nesúladu impedancie medzi telefón a modul SLIC. Vo väčšine prípadov sa to vyskytuje v obvodoch, ktoré premieňajú 4-drôtovú telefónnu linku na 2-drôtovú.

Zistenie dôvodu (akustická alebo elektrická ozvena) nie je ťažké: účastník, na ktorého strane sa ozvena vytvára, musí vypnúť mikrofón. Ak sa ozvena stále vyskytuje, potom je elektrická.

Ďalšie informácie o postupoch VoIP a DSP nájdete v časti Spracovanie hlasového a faxového signálu VoIP. Ukážka je k dispozícii v službe Knihy Google.

Týmto je dokončený povrchný teoretický prehľad VoIP. Ak máte záujem, príklad praktickej implementácie mini-PBX na skutočnej hardvérovej platforme si môžete pozrieť v ďalšom článku.

[!?] Otázky a pripomienky sú vítané. Odpovie na ne autor článku Dmitrij Valento, softvérový inžinier v centre dizajnu elektroniky Promwad.

Značky:

• pre začiatočníkov
• pre nováčikov

Pridať značky