RTP și RTCP: protocoale pentru telefonie IP. Protocolul RTP

Dacă într-o zi trebuie să-ți dai seama rapid ce este VoIP (voice over IP) și ce înseamnă toate aceste abrevieri sălbatice, sper că acest tutorial te va ajuta. Aș dori să remarc imediat că problemele legate de configurarea unor tipuri suplimentare de servicii de telefonie (cum ar fi transferul de apeluri, mesageria vocală, apeluri conferință etc.) nu sunt luate în considerare aici.

Deci, cu ce ne vom ocupa sub tăietură:

1. Concepte de bază ale telefoniei: tipuri de dispozitive, scheme de conectare
2. O grămadă de protocoale SIP/SDP/RTP: cum funcționează
3. Cum sunt transmise informațiile despre butoanele apăsate
4. Cum funcționează transmisia de voce și fax
5. Procesarea semnalului digital și asigurarea calității audio în telefonia IP

1. Concepte de bază ale telefoniei

În general, schema de conectare a unui abonat local la un furnizor de telefonie conform obiceiului linie telefonică arata asa:

Pe partea furnizorului (PBX) este instalat un modul de telefon cu un port FXS (Foreign eXchange Subscriber). Acasa sau la birou, aveti un telefon sau un fax cu un port FXO (Foreign eXchange Office) si un modul de apelare.

De aspect Porturile FXS și FXO nu sunt diferite, acestea sunt conectori RJ11 obișnuiți. Dar folosind un voltmetru, este foarte ușor să le distingem - va exista întotdeauna o tensiune pe portul FXS: 48/60 V când receptorul este pornit sau 6–15 V în timpul unui apel. Pe FXO, dacă nu este conectat la linie, tensiunea este întotdeauna 0.

Pentru a transmite date printr-o linie telefonică, este necesară o logică suplimentară pe partea furnizorului, care poate fi implementată pe modulul SLIC (circuit de interfață a liniei de abonat), iar pe partea abonatului - folosind modulul DAA (Aranjament de acces direct).

În zilele noastre, telefoanele wireless DECT (Digital European Cordless Telecommunications) sunt destul de populare. În design, sunt similare cu telefoanele convenționale: au, de asemenea, un port FXO și un modul de apelare, dar adaugă și un modul comunicare fără fir stații și telefoane la o frecvență de 1,9 GHz.

Abonații sunt conectați la rețeaua PSTN (Public Switched Telephone Network) - o rețea publică de telefonie, cunoscută și sub numele de PSTN, PSTN. O rețea PSTN poate fi organizată folosind tehnologii diferite: ISDN, optic, POTS, Ethernet. Un caz special de PSTN atunci când este utilizată o linie obișnuită analogică/cupru este POTS (Serviciul telefonic vechi simplu) - un sistem telefonic vechi simplu.

Odată cu dezvoltarea internetului conexiune telefonică a trecut la un nou nivel. Telefoanele fixe sunt folosite din ce în ce mai puțin, în principal pentru nevoile de afaceri. Telefoanele DECT sunt ceva mai convenabile, dar sunt limitate la perimetrul casei. Telefoanele GSM sunt și mai convenabile, dar sunt limitate în țară (roamingul este scump). Dar pentru telefoanele IP, cunoscute și sub numele de softphone, nu există alte restricții decât accesul la Internet.

Skype este cel mai faimos exemplu de softphone. Poate face o mulțime de lucruri, dar are două dezavantaje importante: arhitectura închisă și interceptarea telefoanelor de către organe cunoscute. Din cauza primei, nu este posibil să vă creați propria microrețea telefonică. Și din cauza celui de-al doilea, nu este foarte plăcut când cineva te spionează, mai ales în timpul conversațiilor personale și comerciale.

Din fericire, există protocoale deschise pentru a vă crea propriile rețele de comunicații cu bunătăți - acestea sunt SIP și H.323. Există ceva mai multe telefoane soft bazate pe protocolul SIP decât pe H.323, ceea ce poate fi explicat prin simplitatea și flexibilitatea comparativă. Dar uneori această flexibilitate poate pune o spiță mare în roți. Atât SIP, cât și H.323 folosesc protocolul RTP pentru a transmite date media.

Să ne uităm la principiile de bază ale protocolului SIP pentru a înțelege cum se conectează doi abonați.

2. Descrierea pachetului de protocol SIP/SDP/RTP

SIP (Session Initiation Protocol) - protocol de stabilire a sesiunii (nu doar telefon) - este un protocol text peste UDP. De asemenea, este posibil să utilizați SIP peste TCP, dar acestea sunt cazuri rare.

SDP (Session Description Protocol) este un protocol de coordonare a tipului de date transmise (pentru audio și video acestea sunt codecuri și formatele acestora, pentru faxuri - viteza de transmisie și corectarea erorilor) și adresele lor de destinație (IP și port). Acesta este, de asemenea, un protocol text. Parametrii SDP sunt transmisi în corpul pachetelor SIP.

RTP (Real-time Transport Protocol) este un protocol pentru transmiterea datelor audio/video. Acesta este un protocol binar peste UDP.

Structura generală a pachetelor SIP:

• Start-Line: Un câmp care indică metoda SIP (comandă) la o cerere sau rezultatul executării unei metode SIP pe un răspuns.
• Anteturi: Informații suplimentare la Start-Line, formatat ca linii care conțin perechi ATRIBUT: VALUE.
• Corp: date binare sau text. Utilizat de obicei pentru a transmite parametrii sau mesajele SDP.

Iată un exemplu de două pachete SIP pentru o procedură comună - stabilirea apelului:

În stânga este conținutul pachetului SIP INVITE, în dreapta este răspunsul la acesta - SIP 200 OK.

Câmpurile principale sunt evidențiate cu cadre:

• Method/Request-URI conține metoda SIP și URI. În exemplu, se stabilește o sesiune - metoda INVITE, apelând un abonat [email protected].
• Status-Code - cod de răspuns la comanda SIP anterioară. ÎN în acest exemplu comanda a fost executată cu succes - codul 200, adică. abonatul 555 a ridicat telefonul.
• Via - adresa la care abonatul 777 așteaptă un răspuns. Pentru mesajul 200 OK, acest câmp este copiat din mesajul INVITARE.
• De la/Către - afișați numele și adresa expeditorului și destinatarului mesajului. Pentru mesajul 200 OK, acest câmp este copiat din mesajul INVITARE.
• Cseq conține numărul secvenței comenzii și numele metodei la care se aplică. acest mesaj. Pentru mesajul 200 OK, acest câmp este copiat din mesajul INVITARE.
• Content-Type - tipul de date care sunt transmise în blocul Body, în acest caz - date SDP.
• Informații de conectare - adresa IP la care pachetele RTP (sau pachetele UDPTL în cazul transmiterii faxului prin T.38) trebuie trimise celui de-al doilea abonat.
• Media Description - port către care al doilea abonat ar trebui să transmită datele specificate. În acest caz, acesta este sunet (audio RTP/AVP) și o listă de tipuri de date acceptate - PCMU, PCMA, codecuri GSM și semnale DTMF.

Un mesaj SDP constă din linii care conțin perechi FIELD=VALUE. Domeniile principale includ:

• o- Originea, numele organizatorului sesiunii și ID-ul sesiunii.
• Cu- Informații de conectare, câmpul este descris mai devreme.
• m- Media Description, câmpul a fost descris mai devreme.
• o- atribute media, specificați formatul datelor transmise. De exemplu, ele indică direcția sunetului - recepție sau transmisie (sendrecv), pentru codecuri indică frecvența de eșantionare și numărul de legare (rtpmap).

Pachetele RTP conțin date audio/video codificate într-un anumit format. Acest format indicat în câmpul PT (tip de sarcină utilă). Un tabel de corespondență între valoarea acestui câmp și un format specific este dat în https://wikipedia org wiki RTP audio video profile.

Pachetele RTP conțin, de asemenea, un identificator unic SSRC (identifică sursa fluxului RTP) și un marcaj de timp (utilizat pentru redarea uniformă a audio sau video).

Un exemplu de interacțiune între doi abonați SIP prin intermediul unui server SIP (asterisc):

De îndată ce telefonul SIP este lansat, primul lucru pe care îl face este să se înregistreze server la distanță(SIP Registar), îi trimite un mesaj SIP REGISTER.

La apelarea unui abonat, este trimis un mesaj SIP INVITE, al cărui corp conține un mesaj SDP, care indică parametrii de transmisie audio/video (ce codecuri sunt suportate, la ce IP și port pentru a trimite audio etc.).

Când abonatul de la distanță ridică telefonul, primim un mesaj SIP 200 OK tot cu parametri SDP, doar pentru abonatul de la distanță. Folosind parametrii SDP trimisi și recepționați, puteți configura o sesiune de transmisie audio/video RTP sau o sesiune de transmisie fax T.38.

Dacă parametrii SDP primiți nu ni se potrivesc, sau serverul SIP intermediar decide să nu treacă traficul RTP prin el însuși, atunci se efectuează procedura de renegociere SDP, așa-numita REINVITE. Apropo, tocmai din cauza acestei proceduri serverele proxy SIP gratuite au un dezavantaj - dacă ambii abonați se află în aceeași rețea locală, iar serverul proxy se află în spatele NAT, atunci după redirecționarea traficului RTP niciunul dintre abonați nu va auzi altul. .

După încheierea conversației, abonatul care închide trimite un mesaj SIP BYE.

3. Transmiterea de informații despre butoanele apăsate

Uneori, după stabilirea unei sesiuni, în timpul unei conversații, aveți nevoie de acces la tipuri suplimentare servicii (DVO) - apel în așteptare, transfer, mesagerie vocală etc. - care raspund la anumite combinatii de butoane apasate.

Deci, într-o linie telefonică obișnuită există două moduri de a forma un număr:

• Pulse - din punct de vedere istoric, primul, folosit în principal în telefoanele cu apelator rotativ. Apelarea are loc prin închiderea și deschiderea secvenţială a liniei telefonice conform cifrei formate.
• Ton - formarea unui număr cu coduri DTMF (Dual-Tone Multi-Frequency) - fiecare buton de telefon corespunde propriei combinații de două semnale sinusoidale (tonuri). Prin rularea algoritmului lui Goertzel, puteți determina pur și simplu ce buton este apăsat.

În timpul unei conversații, metoda pulsului este incomodă pentru transmiterea butonului apăsat. Astfel, este nevoie de aproximativ 1 secundă pentru a transmite „0” (10 impulsuri a câte 100 ms fiecare: 60 ms - întrerupere de linie, 40 ms - scurtă linie) plus 200 ms pentru o pauză între cifre. În plus, în timpul apelării cu puls, se vor auzi adesea clicuri caracteristice. Prin urmare, în telefonia obișnuită, este utilizat doar modul de acces la tonul la VAS.

În telefonia VoIP, informațiile despre butoanele apăsate pot fi transmise în trei moduri:

1. DTMF Inband - generarea unui ton audio și transmiterea acestuia în interiorul datelor audio (canalul RTP curent) - acesta este un set de tonuri obișnuite.
2. RFC2833 - este generat un eveniment telefonic special de pachete RTP, care conține informații despre tasta apăsată, volum și durată. Numărul formatului RTP în care vor fi transmise pachetele DTMF RFC2833 este indicat în corpul mesajului SDP. De exemplu: a=rtpmap:98 telefon-eveniment/8000.
3. SIP INFO - se generează un pachet SIP INFO cu informații despre tasta apăsată, volum și durată.

Transmisia DTMF în interiorul datelor audio (Inband) are mai multe dezavantaje - acestea sunt resurse de supraîncărcare la generarea/încorporarea tonurilor și la detectarea acestora, limitările unor codecuri care pot distorsiona codurile DTMF și fiabilitatea slabă în timpul transmisiei (dacă unele pachete sunt pierdute, detectarea poate apar apăsând aceeași tastă de două ori).

Principala diferență dintre DTMF RFC2833 și SIP INFO: dacă serverul proxy SIP are capacitatea de a transmite RTP direct între abonați ocolind serverul însuși (de exemplu, canreinvite=yes în asterisc), atunci serverul nu va observa pachetele RFC2833, rezultând în servicii indisponibile DVO. Pachetele SIP sunt întotdeauna transmise prin serverele proxy SIP, astfel încât VAS va funcționa întotdeauna.

4. Transmitere voce și fax

După cum sa menționat deja, protocolul RTP este utilizat pentru a transmite date media. Pachetele RTP indică întotdeauna formatul datelor transmise (codec).

Există multe codec-uri diferite pentru transmisia vocală, cu rapoarte diferite de bitrate/calitate/complexitate, sunt deschise și închise. Orice softphone trebuie să aibă suport pentru codecuri G.711 alaw/ulaw implementarea lor este foarte simplă, calitatea sunetului este bună, dar necesită o lățime de bandă de 64 kbps; De exemplu, codecul G.729 necesită doar 8 kbps, dar este foarte consumator de procesor și nu este gratuit.

Pentru transmisia de fax, se utilizează de obicei fie codecul G.711, fie protocolul T.38. Transmiterea faxului prin codecul G.711 corespunde transmisiei faxului prin protocolul T.30, ca și cum faxul ar fi transmis pe o linie telefonică obișnuită, dar semnalul analogic de la linie este digitizat conform legii alaw/ulaw. Aceasta se mai numește și transmisie fax Inband T.30.

Faxurile care utilizează protocolul T.30 își negociază parametrii: viteza de transmisie, dimensiunea datagramei, tipul de corectare a erorilor. Protocolul T.38 se bazează pe protocolul T.30, dar spre deosebire de transmisia Inband, sunt analizate comenzile T.30 generate și primite. În acest fel, nu sunt transmise date brute, ci comenzi de control ale faxului recunoscute.

Pentru transmiterea comenzilor T.38, se folosește protocolul UDPTL, acesta este un protocol bazat pe UDP, este folosit doar pentru T.38. Pentru a transmite comenzi T.38, puteți utiliza și protocoalele TCP și RTP, dar acestea sunt folosite mult mai rar.

Principalele avantaje ale T.38 sunt încărcarea redusă a rețelei și fiabilitatea mai mare în comparație cu transmisia de fax în bandă.

Procedura pentru trimiterea unui fax în modul T.38 este următoarea:

1. O conexiune vocală normală este stabilită folosind orice codec.
2. Când hârtia este încărcată în aparatul de fax care trimite, acesta trimite periodic un semnal T.30 CNG (Ton de apelare), indicând că este gata să transmită un fax.
3. Semnalul T.30 CED (Called Terminal Identification) este generat pe partea de recepție - aceasta este disponibilitatea pentru a primi un fax. Acest semnal este trimis fie după ce faceți clic pe butonul „Primire fax”, fie faxul o face automat.
4. Pe partea de expediere, semnalul CED este detectat și are loc procedura SIP REINVITE, iar mesajul SDP indică tipul T.38: m=image 39164 udptl t38.

Este recomandabil să trimiteți faxuri prin Internet în T.38. Dacă trebuie să transmiteți un fax într-un birou sau între obiecte care au o conexiune stabilă, atunci puteți utiliza transmisia fax Inband T.30. În acest caz, înainte de a trimite un fax, procedura de anulare a ecoului trebuie dezactivată pentru a nu introduce distorsiuni suplimentare.

Informații foarte detaliate despre transmisia de fax sunt scrise în cartea „Fax, modem și text pentru telefonia IP”, autori - David Hanes și Gonzalo Salgueiro.

5. Procesarea semnalului digital (DSP). Asigurarea calității sunetului în telefonia IP, exemple de testare

Am descoperit protocoalele pentru stabilirea unei sesiuni de conversație (SIP/SDP) și metoda de transmitere a audio pe un canal RTP. Rămâne o problemă importantă - calitatea sunetului. Pe de o parte, calitatea sunetului este determinată de codecul selectat. Dar, pe de altă parte, sunt necesare proceduri suplimentare DSP (DSP - procesare digitală a semnalului). Aceste proceduri iau în considerare particularitățile telefoniei VoIP: un set cu cască de înaltă calitate nu este întotdeauna utilizat, există picături de pachete pe Internet, uneori pachetele sosesc neuniform și lățimea de bandă a rețelei nu este, de asemenea, cauciuc.

Proceduri de bază pentru îmbunătățirea calității sunetului:

VAD(Detector de activitate vocală) - o procedură pentru identificarea cadrelor care conțin voce (cadru vocal activ) sau tăcere (cadru vocal inactiv). Această separare vă permite să reduceți semnificativ încărcarea rețelei, deoarece transmiterea informațiilor despre tăcere necesită mult mai puține date (este suficient să transmiteți doar nivelul de zgomot sau să nu transmiteți nimic).

Unele codecuri conțin deja proceduri VAD (GSM, G.729), în timp ce altele (G.711, G.722, G.726) trebuie implementate.

Dacă VAD-ul este configurat să transmită informații despre nivelul de zgomot, atunci pachetele speciale SID (Silence Insertion Descriptor) sunt transmise în al 13-lea format RTP CN (Comfort Noise).

Este de remarcat faptul că pachetele SID pot fi aruncate de serverele proxy SIP, așa că pentru a verifica este recomandabil să configurați transmiterea traficului RTP dincolo de serverele SIP.

GNC(generare de zgomot de confort) - o procedură pentru generarea de zgomot confortabil pe baza informațiilor din pachetele SID. Astfel, VAD și CNG lucrează împreună, dar procedura CNG este mult mai puțin solicitată, deoarece nu este întotdeauna posibil să se observe funcționarea GNC, mai ales la volume mici.

PLC(ascunderea pierderii pachetelor) - o procedură pentru restabilirea unui flux audio atunci când pachetele sunt pierdute. Chiar și cu pierderi de pachete de 50%. un algoritm bun PLC vă permite să obțineți o calitate acceptabilă a vorbirii. Vor fi distorsiuni, desigur, dar cuvintele pot fi înțelese.

Cea mai simplă modalitate de a emula pierderea de pachete (pe Linux) este să utilizați utilitarul tc din pachetul iproute cu modulul netem. Efectuează modelarea numai a traficului de ieșire.

Un exemplu de rulare a emulării rețelei cu pierderi de pachete de 50%:

Tc qdisc change dev eth1 root netem pierdere 50%

Dezactivarea emulării:

Tc qdisc del dev eth1 root

Tampon de fluctuație- o procedură pentru a scăpa de efectul de jitter, când intervalul dintre pachetele recepționate variază foarte mult și că în cel mai rău caz duce la o ordine greșită a pachetelor primite. Acest efect duce, de asemenea, la întreruperi ale vorbirii. Pentru a elimina efectul de fluctuație, este necesar să se implementeze un buffer de pachete pe partea de recepție cu o dimensiune suficientă pentru a restabili ordinea inițială de trimitere a pachetelor la un interval dat.

De asemenea, puteți emula efectul de jitter folosind utilitarul tc (intervalul dintre momentul așteptat al sosirii pachetului și momentul real poate ajunge la 500 ms):

tc qdisc add dev eth1 root netem delay 500ms reorder 99%

L.E.C.(Line Echo Canceller) - o procedură pentru eliminarea ecoului local atunci când abonatul de la distanță începe să-și audă propria voce. Esența sa este de a scădea semnalul primit din semnalul transmis cu un anumit coeficient.

Ecourile pot apărea din mai multe motive:

• ecou acustic din cauza căii audio de proastă calitate (sunetul de la difuzor intră în microfon);
• ecou electric din cauza nepotrivirii impedanței dintre telefon și modulul SLIC. În cele mai multe cazuri, acest lucru se întâmplă în circuitele care convertesc o linie telefonică cu 4 fire într-o linie telefonică cu 2 fire.

Aflarea cauzei (ecou acustic sau electric) nu este dificilă: abonatul pe a cărui parte este creat ecoul trebuie să închidă microfonul. Dacă ecoul încă apare, înseamnă că este electric.

Mai multe informații despre procedurile VoIP și DSP sunt scrise în cartea VoIP Voice and Fax Signal Processing. Previzualizare disponibilă pe Google Cărți.

Pe această teoretică superficială Revizuire VoIP completat. Dacă sunteți interesat, un exemplu de implementare practică a unui mini-PBX pe o platformă hardware reală poate fi luat în considerare în articolul următor.

[!?] Întrebările și comentariile sunt binevenite. Autorul articolului, Dmitry Valento, inginer software la centrul de proiectare electronică Promwad, le va răspunde.

Etichete:

• pentru incepatori
• pentru incepatori

Adăugați etichete

Una dintre cele mai importante tendințe în evoluția telecomunicațiilor moderne este dezvoltarea telefoniei IP - o varietate de noi tehnologii care asigură transmiterea mesajelor multimedia (vorbire, date, video) prin intermediul rețelelor informatice și informatice (ICN), construite pe baza IP (Internet Protocol), inclusiv local, corporativ, global rețele de calculatoareși internetul. Conceptul de telefonie IP include telefonia prin Internet, care permite organizarea comunicațiilor telefonice între abonații Internet, între abonații rețelelor publice de telefonie (PSTN) prin intermediul Internetului, precum și comunicarea telefonică între abonații PSTN și Internet între ei.

Telefonia IP are o serie de avantaje indubitabile care îi asigură dezvoltarea și extinderea rapidă a pieței de telefonie pe computer. Este benefic pentru utilizatorii finali, cărora li se oferă comunicații telefonice la o taxă pe minut destul de scăzută. Pentru companiile cu filiale la distanță, tehnologia IP le permite să organizeze comunicațiile vocale folosind rețelele IP corporative existente. În loc de mai multe rețele de comunicație, se folosește una. Avantajul indubitabil al telefoniei IP față de un telefon obișnuit este, de asemenea, capacitatea de a oferi servicii suplimentare prin utilizarea unui computer multimedia și a diverselor aplicații de internet. Astfel, cu telefonia IP, companiile și persoanele fizice își pot extinde capacitățile de comunicații pentru a include videoconferințe avansate, partajarea aplicațiilor, instrumente de tip tablă și altele asemenea.

Care standarde internaționale iar protocoalele reglementează parametrii și algoritmii de bază pentru funcționarea hardware-ului și software comunicații utilizate în telefonia IP? Evident, după cum sugerează și numele, această tehnologie se bazează pe protocolul IP, care, totuși, este folosit nu numai pentru telefonie: a fost dezvoltat inițial pentru transmiterea datelor digitale către sistemele informaționale cu comutare de pachete.

În rețelele care nu oferă calitate garantată a serviciului (acestea includ rețelele construite pe protocolul IP), pachetele se pot pierde, ordinea sosirii lor se poate modifica, iar datele transmise în pachete pot fi distorsionate. Pentru a asigura livrarea fiabilă a informațiilor transmise în aceste condiții, sunt utilizate diferite proceduri de nivel de transport. La transmiterea datelor digitale, protocolul TCP (Transmission Control Protocol) este utilizat în acest scop. Acest protocol asigură livrarea fiabilă a datelor și restabilește ordinea inițială a pachetelor. Dacă este detectată o eroare în pachet sau dacă pachetul este pierdut, procedurile TCP trimit o cerere de retransmisie.

Pentru aplicațiile de conferințe audio și video, întârzierile de pachete au un impact mult mai mare asupra calității semnalului decât corupțiile individuale ale datelor. Diferențele de întârziere pot duce la pauze. Astfel de aplicații necesită un alt protocol de nivel de transport care asigură restabilirea secvenței inițiale de pachete, livrarea lor cu întârziere minimă, redare în timp real la momente precis specificate, recunoașterea tipului de trafic, comunicare de grup sau bidirecțională. Acest protocol este protocolul de transport în timp real RTP (Real-Time Transport Protocol). Acest protocol reglementează transferul de date multimedia în pachete prin IVS către strat de transportși este completat de protocolul de control al transmisiei de date în timp real RTCP (Real-Time Control Protocol). Protocolul RTCP, la rândul său, oferă controlul livrării media, controlul calității serviciului, comunicarea despre participanții la sesiunea curentă de comunicare, management și identificare și este uneori considerat parte a protocolului RTP.

Multe publicații despre telefonia IP notează că majoritatea echipamentelor de rețea și special software pentru această tehnologie este în curs de dezvoltare pe baza Recomandării Sectorului de Standardizare a Telecomunicațiilor al Uniunii Internaționale de Telecomunicații (ITU-T) H.323 (inclusiv TAPI 3.0, NetMeeting 2.0 etc.).

Cum se raportează H.323 la protocoalele RTP și RTCP? H.323 este un cadru conceptual larg care include multe alte standarde, fiecare acoperind diferite aspecte ale transferului de informații. Cele mai multe dintre aceste standarde, cum ar fi standardele de codec audio și video, sunt utilizate pe scară largă nu numai în telefonia IP.

În ceea ce privește protocoalele RTP/RTCP, acestea formează baza standardului H.323, sunt concentrate pe furnizarea de tehnologie IP și stau la baza organizării telefoniei IP. Acest articol este dedicat luării în considerare a acestor protocoale. 2. Concepte de bază Protocolul de transport în timp real RTP oferă transmisie în timp real de la capăt la capăt a datelor multimedia, cum ar fi audio și video interactiv. Acest protocol implementează recunoașterea tipului de trafic, numerotarea secvenței pachetelor și lucrul cu

marcajele de timp

și controlul transmisiei.

Protocolul RTP funcționează prin alocarea de marcaje temporale fiecărui pachet de ieșire. Pe partea de recepție, marcajele de timp ale pachetelor indică în ce secvență și cu ce întârzieri trebuie redate. Suportul pentru RTP și RTCP permite gazdei care primește să aranjeze pachetele primite în ordinea corectă, să reducă impactul variațiilor latenței rețelei asupra calității semnalului și să restabilească sincronizarea între audio și video, astfel încât informațiile primite să poată fi auzite și vizualizate corect de utilizatori. Rețineți că RTP în sine nu are niciun mecanism care să garanteze transmiterea în timp util a datelor și calitatea serviciului, dar utilizează serviciile subiacente pentru a asigura acest lucru. Nu previne pachetele necomandate, dar nu presupune că rețeaua de bază este complet fiabilă și transmite pachetele în ordinea corectă. Numerele de secvență incluse în RTP permit receptorului să reconstruiască secvența pachetelor expeditorului. Protocolul RTP acceptă atât comunicarea bidirecțională, cât și transferul de date către un grup de destinatari dacă multicast este acceptat de rețeaua de bază. RTP este conceput pentru a furniza informațiile necesare

Deși RTP este considerat un protocol de nivel de transport, acesta funcționează de obicei peste alt protocol de nivel de transport, UDP (User Datagram Protocol). Ambele protocoale contribuie la cota lor de funcționalitate a stratului de transport. Trebuie remarcat faptul că RTP și RTCP sunt independente de straturile de transport și de rețea subiacente, astfel încât RTP/RTCP poate fi utilizat cu alte protocoale de transport adecvate.

Unitățile de date de protocol RTP/RTCP sunt numite pachete. Pachetele generate în conformitate cu protocolul RTP și utilizate pentru a transmite date multimedia sunt numite pachete de informații sau pachete de date, iar pachetele generate în conformitate cu protocolul RTCP și utilizate pentru a transmite informațiile de serviciu necesare pentru funcționarea fiabilă a teleconferinței sunt numite pachete de control sau pachete de control. Un pachet RTP include un antet fix, o extensie opțională de antet cu lungime variabilă și un câmp de date. Un pachet RTCP începe cu o parte fixă ​​(similară cu partea fixă ​​a pachetelor de informații RTP), urmată de elemente structurale care au o lungime variabilă.

Pentru ca protocolul RTP să fie mai flexibil și să poată fi utilizat pentru diverse aplicații, unii dintre parametrii săi sunt făcuți în mod deliberat nedefiniti, dar prevede conceptul de profil. Un profil este un set de parametri ai protocoalelor RTP și RTCP pentru o anumită clasă de aplicații, care determină caracteristicile funcționării acestora. Profilul definește utilizarea câmpurilor individuale de antet de pachete, tipurile de trafic, adăugiri de antet și extensii de antet, tipuri de pachete, servicii și algoritmi de securitate a comunicațiilor, caracteristicile utilizării protocolului de bază etc. (de exemplu, secțiunea 11 îl consideră pe cel propus în profilul RFC 1890 RTP pentru conferințe audio și video cu control minim). Fiecare aplicație funcționează de obicei cu un singur profil, iar tipul de profil este setat prin selectarea aplicației corespunzătoare. Nicio indicație explicită a tipului de profil prin numărul de port, identificatorul de protocol etc. nu sunt furnizate.

Astfel, o specificație RTP completă pentru o anumită aplicație trebuie să includă documente suplimentare, care includ o descriere a profilului, precum și o descriere a formatului de trafic care definește modul în care un anumit tip de trafic, cum ar fi audio sau video, va fi procesat în RTP.

Caracteristicile transferului de date multimedia în timpul conferințelor audio și video sunt discutate în secțiunile următoare.

2.1. Conferințe audio de grup

Conferințele audio de grup necesită o adresă de grup cu mai mulți utilizatori și două porturi. În acest caz, un port este necesar pentru schimbul de date audio, iar celălalt este utilizat pentru pachetele de control al protocolului RTCP. Adresa grupului și informațiile de port sunt trimise participanților la teleconferință vizați. Dacă este necesară confidențialitatea, informațiile și pachetele de control pot fi criptate așa cum este definit în Secțiunea 7.1, caz în care trebuie generată și distribuită și o cheie de criptare.

Aplicația de conferință audio utilizată de fiecare participant la conferință trimite date audio în bucăți mici, cum ar fi 20 ms. Fiecare bucată de date audio este precedată de un antet RTP; Antetul RTP și datele sunt formate alternativ (încapsulate) într-un pachet UDP. Antetul RTP indică ce tip de codare audio (cum ar fi PCM, ADPCM sau LPC) a fost folosit pentru a genera datele din pachet. Acest lucru face posibilă schimbarea tipului de codificare în timpul conferinței, de exemplu, când apare un nou participant care utilizează o legătură cu lățime de bandă redusă sau când există congestie în rețea.

Pe Internet, ca și în alte rețele de date cu comutare de pachete, pachetele sunt uneori pierdute și reordonate și sunt întârziate pentru perioade diferite de timp. Pentru a contracara aceste evenimente, antetul RTP conține un marcaj de timp și un număr de secvență care le permite destinatarilor să resetați sincronizarea, astfel încât, de exemplu, porțiuni din semnalul audio să fie redate continuu de difuzor la fiecare 20 ms. Această reconstrucție a timpului este efectuată separat și independent pentru fiecare sursă de pachete RTP din grupul de știri. Numărul de secvență poate fi folosit și de destinatar pentru a estima numărul de pachete pierdute.

Deoarece participanții la o teleconferință se pot alătura și părăsi conferința în timp ce aceasta este în desfășurare, este util să știți cine participă în prezent la conferință și cât de bine primesc participanții la conferință date audio. În acest scop, fiecare instanță a aplicației audio în timpul conferinței emite periodic mesaje pe portul de control (portul RTCP) pentru aplicațiile tuturor celorlalți participanți despre recepția de pachete care indică numele utilizatorului său. Mesajul de primire indică cât de bine este auzit difuzorul curent și poate fi folosit pentru a controla codificatoarele adaptive. Pe lângă numele de utilizator, pot fi incluse și alte informații de identificare pentru controlul lățimii de bandă. La părăsirea conferinței, site-ul trimite un pachet RTCP BYE.

2.2. Conferinta video

Dacă atât semnalele audio cât și cele video sunt utilizate într-o teleconferință, acestea sunt transmise separat. Pentru a transmite fiecare tip de trafic independent de celălalt, specificația protocolului introduce conceptul de sesiune de comunicare RTP (vezi lista de abrevieri și termeni folosiți). O sesiune este definită de o pereche specifică de adrese de transport destinație (o adresă de rețea plus o pereche de porturi pentru RTP și RTCP). Pachetele pentru fiecare tip de trafic sunt trimise folosind două perechi diferite de porturi UDP și/sau adrese multicast. Nu există o conexiune RTP directă între sesiunile audio și video, cu excepția faptului că utilizatorul care participă la ambele sesiuni trebuie să folosească același nume canonic în pachetele RTCP pentru ambele sesiuni, astfel încât sesiunile să poată fi conectate.

Un motiv pentru această separare este acela că unor participanți la conferință trebuie să li se permită să primească un singur tip de trafic dacă doresc să facă acest lucru.

În ciuda separării, redarea sincronă a media sursă (audio și video) poate fi realizată prin utilizarea informațiilor de sincronizare care sunt transportate în pachetele RTCP pentru ambele sesiuni.

Nu toate site-urile pot primi întotdeauna date multimedia în același format. Luați în considerare cazul în care participanții dintr-o locație sunt conectați printr-o legătură de viteză redusă la majoritatea celorlalți participanți la conferință care au acces în bandă largă la rețea. În loc să forțeze toată lumea să folosească o lățime de bandă mai mică și o codificare audio de calitate inferioară, facilitatea de comunicații la nivel RTP, numită mixer, poate fi plasată într-o zonă cu lățime de bandă redusă. Acest mixer resincronizează pachetele audio primite pentru a restabili intervalele originale de 20 ms, amestecă aceste fluxuri audio reconstruite într-un singur flux, codifică semnalul audio pentru o lățime de bandă îngustă și transmite fluxul de pachete printr-o legătură de viteză mică. În acest caz, pachetele pot fi adresate unui singur destinatar sau unui grup de destinatari cu adrese diferite. Pentru a permite punctelor finale de recepție să furnizeze indicarea corectă a sursei mesajelor, antetul RTP include un mijloc pentru mixere de a identifica sursele care au contribuit la pachetul mixt.

Unii dintre participanții la conferința audio pot fi conectați prin legături în bandă largă, dar este posibil să nu fie accesibili prin intermediul conferințelor de grup IP multicast (IPM). De exemplu, ele pot fi în spatele unui firewall la nivel de aplicație care nu va permite transmiterea niciunui pachet IP. Pentru astfel de cazuri, nu aveți nevoie de mixere, ci de un alt tip de echipament de comunicație la nivel RTP, numit translatoare. Dintre cele două relee, unul este instalat în afara paravanului de protecție și redirecționează extern toate pachetele multicast primite printr-o conexiune securizată către celălalt releu instalat în spatele paravanului de protecție. Releul din spatele firewall-ului le transmite din nou ca pachete multicast către un grup multi-utilizator limitat la rețeaua internă a site-ului.

Mixerele și traductoarele pot fi proiectate pentru mai multe scopuri. Exemplu: un mixer video care scala imaginile video ale unor persoane individuale pe fluxuri video independente și le compune într-un singur flux video, simulând o scenă de grup. Exemple de traducere: conectarea unui grup de gazde numai IP/UDP la un grup de gazde numai ST-II sau transcodarea pachetului video cu pachet din surse individuale fără resincronizare sau amestecare. Detaliile despre funcționarea mixerelor și traducătorilor sunt discutate în secțiunea 5.

2.4. Ordinea octeților, alinierea și formatul marcajului de timp

Toate câmpurile pachetelor RTP/RTCP sunt transmise prin rețea în octeți (octeți); cel mai semnificativ octet este transmis mai întâi. Toate datele câmpului antet sunt aliniate în funcție de lungimea acestuia . Octeții desemnați ca opționali au valoarea zero.

Ora absolută (ora de ceas de pe ecran) în RTP este reprezentată utilizând formatul de marcaj temporal al Network Time Protocol (NTP), care este o referință de timp în secunde față de zero ore la 1 ianuarie 1900. Formatul complet al unui marcaj temporal NTP este un număr fix de 64 de biți fără semn, cu o parte întreagă în primii 32 de biți și o parte fracțională în ultimii 32 de biți. Unele câmpuri cu o reprezentare mai compactă folosesc doar cei 32 de biți din mijloc - cei 16 biți inferiori ai părții întregi și cei mai semnificativi 16 biți ai părții fracționale.

Următoarele două secțiuni ale acestui articol (3 și 4) discută formatele de pachete și caracteristicile de operare ale protocoalelor RTP și, respectiv, RTCP.

3. Protocol de transfer de date RTP

3.1. Câmpuri de antet fixe RTP

După cum sa menționat mai sus, un pachet RTP include un antet fix, o extensie opțională de antet cu lungime variabilă și un câmp de date. Antetul fix al pachetelor de protocol RTP are următorul format: .

Primii doisprezece octeți sunt prezenți în fiecare pachet RTP, în timp ce câmpul CSRC (sursa contributivă) este prezent doar atunci când este introdus de mixer. Câmpurile au următoarele scopuri.

Versiune (V): 2 biți. Acest câmp identifică versiunea RTP. Acest articol discută versiunea 2 a protocolului RTP (valoarea 1 a fost folosită în prima versiune a RTP).

Umplutură (P): 1 bit. Dacă bitul de umplutură este setat la unu, atunci pachetul de la sfârșit conține unul sau mai mulți octeți de umplutură care nu fac parte din trafic. Ultimul octet al umpluturii conține o indicație a numărului de astfel de octeți care ar trebui ulterior ignorați. Suplimentarea poate fi necesară de unii algoritmi de criptare cu dimensiuni de bloc fixe sau pentru a transporta mai multe pachete RTP într-un singur bloc de date de protocol subiacent.

Extensie (X): 1 bit. Dacă bitul de extensie este setat, atunci antetul fix este urmat de o extensie de antet cu formatul definit în .

Contor CSRC (CC): 4 biți. Contorul CSRC conține numărul de identificatori de sursă CSRC incluși (vezi lista de abrevieri și termeni folosiți) care urmează antetului fix.

Marker (M): 1 bit. Interpretarea markerului este determinată de profil. Este destinat să permită ca evenimente semnificative (cum ar fi limitele cadrelor video) să fie marcate într-un flux de pachete. Un profil poate introduce biți de marcare suplimentari sau poate determina că nu este prezent niciun bit de marcare prin schimbarea numărului de biți din câmpul tip de trafic (vezi ).

Tip de trafic (PT): 7 biți. Acest câmp identifică formatul de trafic RTP și determină modul în care îl interpretează aplicația. Profilul definește o mapare statică implicită între valorile PT și formatele de trafic. Codurile suplimentare de tip de trafic pot fi definite dinamic prin mijloace non-RTP. Expeditorul unui pachet RTP produce o singură valoare de tip de trafic RTP la un moment dat; Acest câmp nu este destinat multiplexării fluxurilor media individuale (vezi ).

Număr de secvență: 16 biți. Valoarea numărului de secvență crește cu una cu fiecare pachet de informații RTP trimis și poate fi folosită de destinatar pentru a detecta pierderile de pachete și a restabili secvența lor originală. Valoarea inițială a numărului de secvență este aleasă aleatoriu pentru a face dificilă spargerea cheii pe baza valorilor cunoscute ale acestui câmp (chiar dacă criptarea nu este utilizată de sursă, deoarece pachetele pot trece printr-un traducător care folosește criptarea) . Marca temporală: 32 de biți. Marca temporală reflectă punctul de eșantionare pentru primul octet din pachetul de informații RTP. Punctul de eșantionare trebuie obținut de la un cronometru care își mărește valorile în mod monoton și liniar în timp pentru a asigura sincronizarea și detecta jitterul (a se vedea secțiunea 4.3.1). Rezoluția temporizatorului trebuie să fie suficientă pentru precizia de sincronizare dorită și măsurarea fluctuației de sosire a pachetelor (un raport de temporizator per cadru video nu este de obicei suficient). Frecvența de sincronizare depinde de formatul traficului transmis și este setată static în profilul sau specificația formatului de trafic, sau poate fi setată dinamic pentru formatele de trafic definite prin „mijloace non-RTP”. Dacă pachetele RTP sunt generate periodic, timpii nominali de eșantionare determinati de temporizatorul de eșantionare trebuie să fie utilizați mai degrabă decât valorile temporizatorului de sistem. De exemplu, pentru un semnal audio cu rată fixă, este de dorit ca senzorul de marcaj temporal să fie incrementat cu unul pentru fiecare perioadă de eșantionare. Dacă o aplicație audio de la un dispozitiv de intrare citește blocuri care conțin 160 de eșantioane, atunci marcajul de timp trebuie să fie incrementat cu 160 pentru fiecare astfel de bloc, indiferent dacă blocul este transmis într-un pachet sau resetat ca o pauză. Valoarea inițială a marcajului de timp, ca și valoarea inițială a numărului de secvență, este o variabilă aleatorie. Mai multe pachete RTP consecutive pot avea marcaje temporale egale dacă sunt generate logic în același timp, de exemplu dacă aparțin aceluiași cadru video. Pachetele RTP consecutive pot conține marcaje temporale nemonotone dacă datele nu sunt transmise în ordinea eșantionării, așa cum este cazul cadrelor video MPEG interpolate (cu toate acestea, numerele secvenței pachetelor vor fi în continuare monotone atunci când sunt transmise).

SSRC: 32 de biți. Câmpul SSRC (sursă de sincronizare) identifică sursa de sincronizare (vezi lista de abrevieri și termeni utilizați). Acest identificator este ales aleatoriu, astfel încât să nu aibă două surse de sincronizare din cadrul aceleiași sesiuni RTP să aibă același identificator SSRC. Deși probabilitatea ca mai multe surse să aleagă același identificator este scăzută, toate implementările RTP trebuie să fie pregătite să detecteze și să rezolve astfel de coliziuni. Secțiunea 6 discută probabilitatea coliziunilor împreună cu un mecanism pentru rezolvarea acestora și detectarea buclelor de strat RTP pe baza unicității identificatorului SSRC. Dacă o sursă își schimbă adresa de transport sursă, trebuie să selecteze și un nou identificator SSRC pentru a evita interpretarea ca sursă de loopback.

Lista CSRC: de la 0 la 15 articole, 32 de biți fiecare. Lista CSRC (sursa contributivă) identifică sursele incluse ale traficului conținut în pachet.

Numărul de identificatori este specificat de câmpul CC. Dacă există mai mult de cincisprezece surse incluse, atunci doar 15 dintre ele pot fi identificate. ID-urile CSRC sunt inserate de mixere atunci când se folosesc ID-uri SSRC pentru surse comutate. De exemplu, pentru pachetele audio, ID-urile SSRC ale tuturor surselor care au fost amestecate atunci când pachetul a fost creat sunt listate în lista CSRC, oferind destinatarului o indicație corectă a surselor de mesaje.

3.2. Sesiuni de comunicare RTP După cum am menționat mai sus, conform protocolului RTP, diferite tipuri de trafic trebuie transmise separat, în diferite sesiuni de comunicare RTP. O sesiune este definită de o pereche specifică de adrese de transport destinație (o adresă de rețea plus o pereche de porturi pentru RTP și RTCP). De exemplu, într-o teleconferință compusă din audio și video codificate separat, fiecare tip de trafic trebuie trimis într-o sesiune RTP separată cu propria sa adresă de transport destinație. Nu se intenționează ca audio și video să fie transmise în aceeași sesiune RTP și separate în funcție de tipul de trafic sau câmpurile SSRC. Intercalarea pachetelor care au diverse tipuri

1. trafic, dar folosirea aceluiași SSRC ar cauza unele probleme:
2. SSRC identifică o singură valoare a intervalului de timp și un spațiu de număr de secvență. Intercalarea mai multor tipuri de trafic ar necesita intervale de sincronizare diferite dacă ratele de ceas ale diferitelor fluxuri sunt diferite și spații de numere de secvență diferite pentru a indica tipul de trafic la care se referă pierderea de pachete.
3. Mesajele expeditorului și receptorului RTCP (a se vedea secțiunea 4.3) descriu doar o valoare a intervalului de timp și un spațiu de număr de secvență pentru SSRC și nu poartă un câmp de tip de trafic.
4. Mixerul RTP nu este capabil să combine fluxuri intercalate ale diferitelor tipuri de trafic într-un singur flux.
5. Următorii factori împiedică transmiterea mai multor tipuri de trafic într-o singură sesiune RTP: utilizarea diferitelor căi de rețea sau alocarea resurselor de rețea; primirea unui subset de date multimedia atunci când este necesar, de exemplu, numai audio dacă semnalul video depășește lățimea de bandă disponibilă; implementări de ascultător care utilizează procese separate pentru diferite tipuri de trafic, în timp ce utilizarea sesiunilor RTP separate permite implementări atât cu un singur proces, cât și cu mai multe procese.

Folosind SSRC-uri diferite pentru fiecare tip de trafic, dar transmitându-le în aceeași sesiune RTP, puteți evita primele trei probleme, dar nu puteți evita ultimele două. Prin urmare, specificația protocolului RTP necesită ca fiecare tip de trafic să folosească propria sa sesiune RTP.

3.3. Se modifică antetul RTP definit de profil

Antetul pachetului de informații RTP existent este complet pentru setul de funcții necesare în general pentru toate clasele de aplicații care ar putea suporta RTP. Cu toate acestea, pentru a se potrivi mai bine unor scopuri specifice, antetul poate fi modificat prin modificări sau completări definite în specificația profilului.

Bitul de marcare și câmpul de tip de trafic transportă informații specifice profilului, dar sunt localizate într-un antet fix, deoarece se așteaptă ca multe aplicații să aibă nevoie de ele. Octetul care conține aceste câmpuri poate fi redefinit de profil pentru a se potrivi diferitelor cerințe, de exemplu cu mai mulți sau mai puțini biți de marcare. Dacă există biți de marcare, aceștia ar trebui să fie plasați în cei mai semnificativi biți ai octetului, deoarece monitoarele independente de profil pot fi capabile să observe o corelație între modelele de pierdere a pachetelor și bitul de marcare.

Informațiile suplimentare care sunt necesare pentru un anumit format de trafic (de exemplu, tipul de codificare video) trebuie să fie transportate în câmpul de date al pachetului. Poate fi plasat într-o locație specifică la început sau în interiorul matricei de date.

Dacă o anumită clasă de aplicații necesită funcționalitate suplimentară care este independentă de formatul de trafic, atunci profilul cu care operează acele aplicații trebuie să definească câmpuri fixe suplimentare situate imediat după câmpul SSRC al antetului fix existent. Aceste aplicații vor putea accesa rapid câmpuri suplimentare direct, în timp ce monitoarele sau loggerele independente de profil vor putea în continuare să proceseze pachetele RTP interpretând doar primii doisprezece octeți.

Dacă se crede că suplimentar funcţionalitate necesar în general pentru toate profilurile, atunci trebuie definit noua versiune RTP de făcut schimbare constantă antet fix.

3.4. Extensie antet RTP

Pentru a permite implementărilor individuale să experimenteze cu funcții noi, independente de format, care necesită informații suplimentare care să fie transportate în antetul pachetului de date, RTP oferă un mecanism de extensie a antetului de pachet. Acest mecanism este conceput astfel încât extensia antetului să poată fi ignorată de alte aplicații care comunică care nu o necesită.

Dacă bitul X din antetul RTP este setat la unu, atunci o extensie de antet cu lungime variabilă este atașată antetului RTP fix (urmând lista CSRC, dacă există). Rețineți că această extensie de antet este doar pentru utilizare limitată. Extensia antet pachetului RTP are următorul format:

Extensia conține un câmp de lungime de 16 biți care indică numărul de cuvinte de 32 de biți din el, excluzând antetul extensiei de patru octeți (deci lungimea poate fi zero). Doar o extensie poate fi adăugată la un antet fix de pachet de informații RTP. Pentru a permite fiecăreia dintre implementările multiple interoperabile să experimenteze în mod independent cu diferite extensii de antet sau pentru a permite unei anumite implementări să experimenteze cu mai mult de un tip de extensie de antet, utilizarea primilor 16 biți ai extensiei este nespecificată, rezervată pentru distingerea identificatorilor sau parametrii.

1999

2000

Formatul acestor 16 biți trebuie să fie determinat de specificația profilului cu care funcționează aplicațiile. Când noi, vorbind pe un telefon IP, auzim vocea interlocutorului pe receptor sau, folosind un sistem de videoconferință, comunicăm cu colegii și rudele noștri, schimbăm un flux continuu de date. Când transmiteți date cum ar fi voce și video over rețea de pachete

• , este foarte important să folosiți mecanisme care ar rezolva următoarele probleme:
• Eliminarea efectului pierderii pachetelor
• Restabilirea ordinii și controlul sosirii pachetelor

Efect de întârziere de netezire (jitter) A fost dezvoltat în aceste scopuri RTP

(Real-time Transport Protocol) este un protocol de transmisie în timp real despre care va fi discutat în articolul de astăzi. Protocolul a fost dezvoltat de IETF Audio-Video Transport Working Group și este descris în recomandarea RFC 3550.

De regulă, RTP funcționează pe lângă protocolul UDP (User Datagram Protocol), deoarece la transmiterea datelor multimedia este foarte important să se asigure livrarea la timp.

RTP include capacitatea de a determina tipul de încărcare utilă și de a atribui un număr de secvență de pachet într-un flux, precum și utilizarea marcajelor de timp.

O altă funcție RTP este asociată cu posibile pierderi de pachete la trecerea printr-o rețea IP, care se exprimă în apariția unor pauze de scurtă durată în conversație. Tăcerea bruscă în receptor are, de regulă, un efect foarte negativ asupra ascultătorului, prin urmare, cu capacitățile protocolului RTP, astfel de perioade de liniște sunt umplute cu așa-numitul „zgomot de confort”

RTP funcționează împreună cu un alt protocol IETF, și anume RTCP (Protocol de control al transportului în timp real), care este descris în RFC 3550. RTCP este conceput pentru a colecta informații statistice, a determina calitatea serviciului QoS (Calitatea serviciului) și, de asemenea, pentru sincronizare între fluxurile media ale sesiunilor RTP.

Funcția principală a RTCP este de a stabili feedback cu o anexă pentru un raport privind calitatea informațiilor primite. Participanții la o sesiune RTCP schimbă informații despre numărul de pachete primite și pierdute, valoarea jitterului, întârzierea etc. Pe baza analizei acestor informații, se ia decizia de a modifica parametrii de transmisie, de exemplu, pentru a reduce raportul de compresie a informațiilor pentru a îmbunătăți calitatea transmisiei acesteia.

Pentru a îndeplini aceste funcții, RTCP trimite mesaje speciale de anumite tipuri:

• S.R. - Raport expeditor - raport sursă cu informații statistice despre sesiunea RTP
• R.R. - Receiver Report - raport destinatar cu informații statistice despre sesiunea RTP
• SDES - conține o descriere a parametrilor sursei, inclusiv cname (nume de utilizator)
• Adio – Declanșează încetarea apartenenței la grup
• APP - Descrierea funcțiilor aplicației

RTP este un protocol unidirecțional, astfel încât pentru a organiza comunicația bidirecțională sunt necesare două sesiuni RTP, câte una pe fiecare parte.

Sesiunea RTP este determinată de adresele IP ale participanților, precum și de o pereche de porturi UDP nerezervate din intervalul 16384 - 32767. În plus, pentru a organiza feedback-ul cu aplicația, este, de asemenea, necesar să se stabilească un RTCP bidirecțional sesiune. Pentru sesiunile RTCP, sunt utilizate porturi cu un număr unu mai mare decât RTP. De exemplu, dacă portul 19554 este selectat pentru RTP, atunci sesiunea RTCP va ocupa portul 19555. Formarea unei sesiuni RTP/RTCP este prezentată clar în figura de mai jos.

Cerința de a suporta mai multe tipuri de trafic cu cerințe diferite de calitate a serviciului bazate pe stiva de protocoale TCP/IP este acum foarte relevantă. Această problemă este rezolvată de Real-Time Transport Protocol (RTP), care este un standard IETF pentru transmiterea de date precum voce sau video în timp real printr-o rețea care nu garantează calitatea serviciului.

Protocolul RTP garantează livrarea datelor către unul sau mai mulți destinatari cu o întârziere care nu depășește valoarea specificată. În acest scop, antetul protocolului conține marcajele temporale necesare pentru recuperarea cu succes a informațiilor audio și video, precum și date despre metoda de codificare a informațiilor.

Deși protocolul TCP garantează livrarea datelor transmise în secvența necesară, traficul este neuniform, adică apar întârzieri imprevizibile în livrarea datagramelor. Deoarece RTP este conștient de datagramă și are mecanisme de detectare a pierderii de date, poate reduce latența la un nivel acceptabil.

Schema de adrese IP

Schema de adresare a internetworking utilizată în protocolul IP este descrisă în RFC 990 și RFC 997. Se bazează pe separarea rețelelor de adresare de dispozitivele de adresare din aceste rețele. Această schemă face rutarea mai ușoară. În acest caz, adresele trebuie alocate într-o manieră ordonată (secvențial) pentru a face rutarea mai eficientă.

Când se utilizează stiva de protocoale TCP/IP într-o rețea, dispozitivele finale primesc adrese unice. Astfel de dispozitive pot fi calculatoare personale, servere de comunicații, routere etc. Cu toate acestea, unele dispozitive care au mai multe porturi fizice, cum ar fi routerele, trebuie să aibă o adresă unică pe fiecare port. Pe baza schemei de adresare și a faptului că unele dispozitive din rețea pot avea mai multe adrese, putem concluziona că această schemă de adresare nu descrie dispozitivul în sine în rețea, ci o conexiune specifică a acestui dispozitiv la rețea. Această schemă duce la o serie de inconveniente. Una dintre ele este necesitatea de a schimba adresa dispozitivului atunci când îl mutați într-o altă rețea. Un alt dezavantaj este că pentru a lucra cu un dispozitiv care are conexiuni multiple într-o rețea distribuită, trebuie să cunoști toate adresele sale care identifică aceste conexiuni.

Deci, pentru fiecare dispozitiv din rețelele IP putem vorbi despre adrese de trei niveluri:

q Adresa fizică a dispozitivului (mai precis, o interfață specifică). Pentru dispozitivele din rețele Ethernet, aceasta este adresa MAC a plăcii de rețea sau a portului routerului. Aceste adrese sunt atribuite de producătorii de echipamente. Adresa fizică are șase octeți: cei trei octeți superiori sunt identificatorul producătorului, cei trei octeți inferiori sunt alocați de producător;

q Adresă IP constând din patru octeți. Această adresă este utilizată la nivelul de rețea al modelului de referință OSI;

q Identificator de caracter - nume. Acest identificator poate fi atribuit în mod arbitrar de către administrator.

Când protocolul IP a fost standardizat în septembrie 1981, specificația sa impunea ca fiecare dispozitiv conectat la o rețea să aibă o adresă unică de 32 de biți. Această adresă este împărțită în două părți. Prima parte a adresei identifică rețeaua pe care se află dispozitivul. A doua parte identifică în mod unic dispozitivul în sine în cadrul rețelei. Această schemă conduce la o ierarhie de adrese pe două niveluri (Fig. 6.23).

Acum este apelat câmpul pentru numărul de rețea din adresă prefix de rețea, deoarece identifică rețeaua. Toate stațiile de lucru din rețea au același prefix de rețea. Cu toate acestea, trebuie să aibă numere unice de dispozitiv. Două stații de lucru situate pe rețele diferite trebuie să aibă prefixe de rețea diferite, dar pot avea aceleași numere de dispozitiv.

Pentru a oferi flexibilitate în atribuirea adreselor rețele de calculatoare Dezvoltatorii de protocol au stabilit că spațiul de adrese IP ar trebui împărțit în trei clase diferite - A, B și C. Cunoscând clasa, știți unde se află, în adresa pe 32 de biți, granița dintre prefixul rețelei și numărul dispozitivului. În fig. Figura 6.24 prezintă formatele de adrese ale acestor clase de bază.

Unul dintre principalele avantaje ale utilizării claselor este că clasa de adrese poate determina unde se află granița dintre prefixul rețelei și numărul dispozitivului. De exemplu, dacă cei mai semnificativi doi biți ai adresei sunt 10, atunci punctul de tăiere este între biții 15 și 16.

Dezavantajul acestei metode este necesitatea de a schimba adresa de rețea la conectare dispozitive suplimentare. De exemplu, dacă numărul total de dispozitive dintr-o rețea de clasă C depășește 255, atunci adresele sale vor trebui înlocuite cu adrese de clasă B. Schimbarea adreselor de rețea va necesita eforturi suplimentare din partea administratorului pentru a depana rețeaua. Administratorii de rețea nu pot implementa tranziție lină la o nouă clasă de adrese, deoarece clasele sunt clar separate. Trebuie să interziceți utilizarea unui întreg grup de adrese de rețea, să schimbați simultan adresele tuturor dispozitivelor din acest grup și numai apoi să permiteți din nou utilizarea lor în rețea. În plus, introducerea claselor de adrese reduce semnificativ numărul posibil teoretic de adrese individuale. În versiunea actuală a protocolului IP (versiunea 4), numărul total de adrese ar putea fi 232 (4.294.967.296), deoarece protocolul folosește 32 de biți pentru a specifica adresa. Desigur, utilizarea unor biți în scopuri oficiale reduce numărul disponibil de adrese individuale.

Clasa A este destinată rețelelor mari. Fiecare adresă de clasă A are un prefix de rețea de 8 biți în care bitul cel mai semnificativ este setat la 1 și următorii șapte biți sunt utilizați pentru numărul de rețea. Restul de 24 de biți sunt utilizați pentru numărul dispozitivului. ÎN momentul prezent toate adresele de clasa A sunt deja alocate. Rețelele de clasă A sunt, de asemenea, desemnate „/8” deoarece adresele de clasă A au un prefix de rețea de 8 biți.

Numărul maxim de rețele de clasa A este 126 (2 7 -2 - se scad două adrese formate din zerouri și unu). Fiecare rețea din această clasă acceptă până la 16.777.214 (2 24 -2) dispozitive. Deoarece un bloc de adrese de clasă A poate conține maximum 2 31 (2.147483648) adrese unicast, iar versiunea IP 4 poate suporta maximum 2 32 (4.294.967.296) adrese, clasa A ocupă 50% din spațiul total de adrese IP .

Clasa B este destinată rețelelor de dimensiuni medii. Fiecare adresă de clasă B are un prefix de rețea de 16 biți în care cei mai importanți doi biți sunt 10, iar următorii 14 biți sunt utilizați pentru numărul de rețea. Pentru numărul de dispozitiv sunt alocați 16 biți. Rețelele de clasă B sunt denumite și „/16” deoarece adresele de clasă B au un prefix de rețea de 16 biți.

Numărul maxim de rețele de clasa B este 16.382 (2 14 -2). Fiecare rețea din această clasă acceptă până la 65.534 (2 16 -2) dispozitive. Deoarece un întreg bloc de adrese de clasă B poate conține maximum 230 (1073741824) adrese unicast, acesta ocupă 25% din spațiul total de adrese IP.

Adresele de clasa C sunt utilizate în rețelele cu un număr mic de dispozitive. Fiecare rețea de clasă C are un prefix de rețea de 24 de biți în care cei mai importanți trei biți sunt 110, iar următorii 21 de biți sunt utilizați pentru numărul rețelei. Restul de 8 biți sunt alocați numerelor de dispozitiv. Rețelele de clasă C sunt denumite și „/24” deoarece adresele de clasă C au un prefix de rețea de 24 de biți.

Numărul maxim de rețele de clasă C este 2.097.152 (2 21). Fiecare rețea din această clasă acceptă până la 254 (2 8 -2) dispozitive. Clasa C ocupă 12,5% din spațiul total de adrese IP.

În tabel Secțiunea 6.9 rezumă analiza noastră a claselor de rețele.

Tabelul 6.9. Clasele de rețea

Pe lângă aceste trei clase de adrese, mai există două clase. În clasa D, cei mai semnificativi patru biți sunt 1110. Această clasă este utilizată pentru transmisia de date multicast. În clasa E, cei mai semnificativi patru biți sunt 1111. Este rezervat experimentelor.

Pentru a face adresele mai ușor de citit în literatura tehnică, programele de aplicații etc., adresele IP sunt reprezentate ca patru numere zecimale separate prin puncte. Fiecare dintre aceste numere corespunde unui octet (8 biți) din adresa IP. Acest format se numește punct-zecimal (Decimal-Point Notation) sau punct-zecimal (Fig. 6.25).

În tabel Figura 6.10 listează intervalele de valori zecimale ale celor trei clase de adrese. În tabel 6.10 intrarea XXX înseamnă un câmp personalizat.

Tabelul 6.10. Intervalele de valori ale adresei

Unele adrese IP nu pot fi atribuite dispozitivelor din rețea (Tabelul 6.11).

După cum se arată în acest tabel, în adresele IP rezervate, toți biții setați la zero corespund oricăreia dintre ele acest dispozitiv, sau această rețea și adresele IP, toți biții setați la 1, sunt utilizate la difuzarea informațiilor. Pentru a face referire la întreaga rețea IP în ansamblu, se folosește o adresă cu un număr de dispozitiv, cu toți biții setați la „0”. Adresa de rețea de clasă A - 127.0.0.0 este rezervată pentru feedback și a fost introdusă pentru a testa interacțiunea dintre procesele de pe aceeași mașină. Când o aplicație folosește o adresă de loopback, stiva de protocol TCP/IP returnează aceste date aplicației fără a trimite nimic în rețea. În plus, această adresă poate fi utilizată pentru a comunica între procese individuale din cadrul aceleiași mașini. Prin urmare, în rețelele IP este interzisă atribuirea adreselor IP dispozitivelor care încep cu 127.

Pe lângă transmiterea direcționată a datelor către o anumită stație de lucru, este utilizată în mod activ transmisia de difuzare, în care toate stațiile din rețeaua curentă sau specificată primesc informații. Protocolul IP face distincție între două tipuri de difuzare: direcționată și limitată.

Difuzarea direcționată permite unui dispozitiv dintr-o rețea la distanță să trimită o datagramă către toate dispozitivele din rețeaua curentă. O datagramă cu o adresă de difuzare direcționată poate trece prin routere, dar va fi livrată numai către toate dispozitivele din rețeaua specificată și nu către toate dispozitivele. Într-o difuzare direcționată, adresa de destinație constă dintr-un anumit număr de rețea și un număr de dispozitiv, toți biții fiind 0 sau 1. De exemplu, adresele 185.100.255.255 și 185.100.0.0 ar fi considerate adrese de difuzare direcționată pentru clasa B. rețeaua 185.100.xxx.xxx Din punct de vedere al adresei, principalul dezavantaj al difuzării direcționate este că necesită cunoașterea numărului rețelei țintă.

A doua formă de difuzare, numită difuzare limitată, difuzează în cadrul rețelei curente (rețeaua în care se află dispozitivul de trimitere). O datagramă cu o adresă de difuzare limitată nu va trece niciodată printr-un router. În difuzarea limitată, numărul rețelei și biții numărul dispozitivului sunt toți 0 sau 1. Astfel, o datagrama cu adresa de destinatie 255.255.255.255 sau 0.0.0.0 va fi livrata tuturor dispozitivelor din retea. În fig. Figura 6.26 prezintă rețelele conectate prin routere. În tabel Figura 6.12 listează destinatarii datagramelor transmise de stația de lucru A.

Protocolul IP acceptă trei metode de adresare: unică (unicast), broadcast (broadcast) și grup (multicast).

Tabelul 6.12. Destinatari ai datagramelor difuzate

Cu o singură adresare, datagramele sunt trimise către un singur dispozitiv specific. Implementarea acestei abordări nu este dificilă, dar dacă grup de lucru conține multe stații, lățimea de bandă poate să nu fie suficientă deoarece aceeași datagramă va fi transmisă de mai multe ori.

Cu adresarea de difuzare, aplicațiile trimit o singură datagramă care este livrată tuturor dispozitivelor din rețea. Această abordare este și mai simplu de implementat, dar dacă în acest caz, traficul de difuzare nu este limitat la rețeaua locală (și, de exemplu, o altă rețea este redirecționată folosind routere), atunci retea globala trebuie să aibă semnificative debitului. Dacă informațiile sunt destinate doar unui grup mic de dispozitive, atunci această abordare pare irațională.

În multicast, datagramele sunt livrate unui anumit grup de dispozitive. În același timp (ceea ce este foarte important când se lucrează în rețele distribuite) nu se generează trafic în exces. Datagramele cu un multicast și o singură adresă diferă ca adresă. Antetul unei datagrame IP multicast conține o adresă de clasă D, adică o adresă multicast, în loc de adrese IP din clasele A, B, C.

O adresă de grup este atribuită unor dispozitive destinatare sau, cu alte cuvinte, unui grup. Expeditorul scrie această adresă multicast în antetul datagramei IP. Datagrama va fi livrată tuturor membrilor grupului. Primii patru biți ai adresei de clasă D sunt 1110. Restul adresei (28 de biți) este ocupat de identificatorul de grup (Figura 6.27).

În format zecimal punctat, adresele de grup variază de la 224.0.0.0 la 239.255.255.255. În tabel Figura 6.13 prezintă o diagramă de distribuție a adresei de clasa D.

Tabelul 6.13. Clasa D Alocarea adresei

După cum se vede din tabel. 6.13, primele 256 de adrese sunt rezervate. În special, acest interval este rezervat protocoalelor de rutare și altor protocoale de nivel scăzut. În tabel 6.14 conține câteva adrese IP rezervate de clasă D.

Peste acest interval există un grup mare de adrese alocate pentru aplicațiile care rulează pe Internet. Gama superioară de adrese (aproximativ 16 milioane de adrese) este destinată scopurilor administrative în rețele locale. Gestionarea și înregistrarea centralizată a adreselor grupurilor de clasa D este realizată de o organizație specială numită IANA.

Adresarea multicast poate fi implementată la două niveluri ale modelului OSI - stratul de legătură de date și stratul de rețea. Protocoalele de legătură de date, cum ar fi Ethernet și FDDI, pot suporta adresare unică, adresare de difuzare și adresare multicast. Adresarea multicast la nivel de legătură este eficientă în special dacă este suportată de placa de rețea în hardware.

Pentru a suporta multicast IANA, este alocat un bloc de adrese Ethernet multicast, începând cu 01-00-5E (în hexazecimal). Adresa IP multicast poate fi tradusă la adresa din acest bloc. Principiul traducerii este destul de simplu: cei 23 de biți inferiori ai identificatorului de grup IP sunt copiați în cei 23 de biți inferiori ai adresei Ethernet. Rețineți că această schemă asociază până la 32 de grupuri IP diferite cu aceeași adresă Ethernet, deoarece următorii 5 biți ai identificatorului de grup IP sunt ignorați.

Tabelul 6.14. Adrese rezervate clasa D

Adresa	Scop
224.0.0.1	Toate dispozitivele de pe subrețea
224.0.0.2	Toate routerele de pe subrețea
224.0.0.4	Toate routerele DVMRP
224.0.0.5	Toate routerele MOSPF
224.0.0.9	RIP IP versiunea II
224.0.1.7	Știri audio
224.0.1.11	IEFT audio
224.0.1.12	Video IEFT

Dacă expeditorul și receptorul aparțin aceleiași rețele fizice, procesul de trimitere și primire a cadrelor multicast la nivelul de legătură de date este destul de simplu. Expeditorul specifică adresa IP a grupului de destinatari, iar NIC-ul traduce această adresă în adresa de grup Ethernet corespunzătoare și trimite cadrul.

Dacă expeditorul și destinatarul se află pe subrețele diferite conectate prin routere, livrarea datagramelor este dificilă. În acest caz, routerele trebuie să accepte unul dintre protocoalele de rutare multicast (DVMRP, MOSPF, PIM - vezi mai jos). Conform acestor protocoale, routerul va construi un arbore de livrare și va redirecționa corect traficul multicast. În plus, fiecare router trebuie să accepte Group Management Protocol (IGMP) pentru a determina prezența membrilor grupului pe subrețelele conectate direct (Figura 6.28).

Bună ziua

Total: sistemul de monitorizare este un complex conectat într-un mod non-intruziv la numărul n de legături Ethernet de 10 gigabit, care „monitorizează” continuu transmisia tuturor fluxurilor video RTP prezente în trafic și efectuează măsurători la un anumit moment. interval pentru a le salva ulterior în baza de date. Pe baza datelor din baza de date, rapoartele sunt generate în mod regulat pentru toate camerele.

Ce este atât de greu în asta?

În procesul de căutare a unei soluții, au fost identificate imediat câteva probleme:

• Conexiune non-intruzivă. Sistemul de monitorizare se conectează la canalele deja operaționale în care majoritatea conexiunilor (prin RTSP) au fost deja stabilite, serverul și clientul știu deja ce porturi sunt schimbate, dar nu știm acest lucru dinainte. Portul binecunoscut este doar pentru Protocolul RTSP, dar fluxurile UDP pot trece prin porturi arbitrare (în plus, s-a dovedit că adesea încalcă cerința TREBUIE pentru paritatea pară/impară a porturilor, vezi rfc3550). Cum să determinați că un anumit pachet de la o anumită adresă IP aparține unui flux video? De exemplu, protocolul BitTorrent se comportă în mod similar - în etapa de stabilire a conexiunii, clientul și serverul sunt de acord cu porturile, iar apoi tot traficul UDP arată ca „doar un flux de biți”.
• Linkurile conectate pot conține mai mult decât fluxuri video. Ar putea exista HTTP, BitTorrent, SSH și orice alte protocoale pe care le folosim astăzi. Prin urmare, sistemul trebuie să identifice corect fluxurile video pentru a le separa de alt trafic. Cum să faci asta în timp real cu 8 link-uri de zece gigabiți? Desigur, de obicei nu sunt pline 100%, deci traficul total nu va fi de 80 gigabiți/s, ci de aproximativ 50-60, dar acesta nu este atât de puțin.
• Scalabilitate. Acolo unde există deja o mulțime de fluxuri video, pot fi chiar mai multe, deoarece supravegherea video s-a dovedit de mult timp a fi un instrument eficient. Acest lucru sugerează că trebuie să existe o rezervă pentru productivitate și o rezervă pentru legături.

Cautam o solutie potrivita...

În mod firesc, am căutat să profităm la maximum de propria noastră experiență. În momentul în care a fost luată decizia, aveam deja o implementare a procesării pachetelor Ethernet pe dispozitivul alimentat cu FPGA Berkut-MX (mai simplu - MX). Folosind Berkut-MX, am putut obține câmpurile necesare pentru analiză din anteturile pachetelor Ethernet. Din păcate, nu aveam experiență în procesarea unui astfel de volum de trafic folosind servere „obișnuite”, așa că am privit o astfel de soluție cu oarecare precauție...

S-ar părea că tot ce trebuia să facem a fost pur și simplu să aplicăm metoda pachetelor RTP și cheia de aur ar fi în buzunarul nostru, dar MX poate procesa doar traficul, nu are capabilități de contabilizare și stocare a statisticilor. Nu există suficientă memorie în FPGA pentru a stoca conexiunile găsite (combinații IP-IP-port-port), deoarece într-o legătură de 2x10 gigabiți care intră în intrare pot exista aproximativ 15 mii de fluxuri video și pentru fiecare trebuie să „ amintiți-vă” numărul de pachete primite, numărul de pachete pierdute și așa mai departe... Mai mult, căutarea cu o asemenea viteză și pentru o asemenea cantitate de date, supuse procesării fără pierderi, devine o sarcină nebanală.

Pentru a găsi o soluție, a trebuit să „săpăm mai adânc” și să ne dăm seama ce algoritmi vom folosi pentru a măsura calitatea și a identifica fluxurile video.

Ce se poate măsura folosind câmpurile unui pachet RTP?

Din descriere reiese clar că din punct de vedere al măsurătorilor de calitate într-un pachet RTP, ne interesează următoarele domenii:

• număr de secvență - un numărător de 16 biți care crește cu fiecare pachet trimis;
• timestamp - timestamp, pentru h.264 valoarea de eșantionare este 1/90000 s (adică corespunde unei frecvențe de 90 KHz);
• Bit marker. În rfc3550 se descrie în general că acest bit este destinat să indice evenimente „semnificative”, dar, de fapt, camerele de luat vederi folosesc cel mai adesea acest bit pentru a marca începutul unui cadru video și pachete specializate cu informații SPS/PPS.

Este destul de evident că numărul de ordine vă permite să determinați următorii parametri flux:

• pierderea cadrului;
• retrimite pachetul (duplicat);
• modificarea ordinii de sosire (reordonare);
• repornirea camerei dacă există un „decalaj” mare în secvență.

Timpul vă permite să măsurați:

• variație de întârziere (numită și jitter). În acest caz, pe partea de recepție trebuie să funcționeze un contor de 90 KHz;
• în principiu, o întârziere în trecerea pachetului. Dar pentru a face acest lucru, trebuie să sincronizați ora camerei cu marcajul de timp, iar acest lucru este posibil dacă camera transmite rapoarte de expeditor (RTCP SR), ceea ce este în general incorect, deoarece V viata reala multe camere ignoră mesajul RTCP SR (aproximativ jumătate din camerele cu care am lucrat).

Ei bine, M-bit vă permite să măsurați rata de cadre. Adevărat, cadrele SPS/PPS ale protocolului h.264 introduc o eroare, deoarece nu sunt cadre video. Dar poate fi atenuat prin utilizarea informațiilor din antetul unității NAL, care urmează întotdeauna antetul RTP.

Algoritmii detaliați pentru măsurarea parametrilor depășesc domeniul de aplicare al articolului. Dacă sunteți interesat, rfc3550 are un exemplu de cod pentru calcularea pierderilor și o formulă pentru calcularea jitterului. Concluzia principală este că pentru a măsura caracteristicile de bază ale unui flux de transport sunt suficiente doar câteva câmpuri din pachetele RTP și unități NAL. Dar restul informațiilor nu sunt implicate în măsurători și pot și trebuie aruncate!

Cum se identifică fluxurile RTP?

Pentru a menține statisticile, informațiile obținute din antetul RTP trebuie să fie „legate” la un identificator de cameră (flux video). Camera poate fi identificată în mod unic prin următorii parametri:

• Adresele IP sursă și destinație
• Porturile sursă și destinație
• SSRC. Este de o importanță deosebită atunci când mai multe fluxuri sunt difuzate de la un IP, adică. în cazul unui encoder multiport.

Ceea ce este interesant este că inițial am identificat camerele doar după IP-ul sursă și SSRC, bazându-ne pe ideea că SSRC ar trebui să fie aleatoriu, dar în practică s-a dovedit că multe camere setează SSRC la o valoare fixă ​​(să zicem 256). Se pare că acest lucru se datorează economisirii resurselor. Drept urmare, a trebuit să adăugăm porturi la ID-ul camerei. Acest lucru a rezolvat complet problema unicității.

Cum se separă pachetele RTP de alt trafic?

Rămâne întrebarea: cum va înțelege Berkut-MX, după ce a primit pachetul, că este RTP? Antetul RTP nu are o identificare atât de explicită precum IP, nu are o sumă de control, poate fi transmis prin UDP cu numere de porturi care sunt selectate dinamic la stabilirea unei conexiuni. Dar în cazul nostru, majoritatea conexiunilor au fost deja stabilite de mult timp și puteți aștepta foarte mult timp pentru reinstalare.

Pentru a rezolva această problemă, rfc3550 (Anexa A.1) recomandă verificarea biților versiunii RTP - aceasta este de doi biți, iar câmpul Payload Type (PT) este de șapte biți, care în cazul unui tip dinamic ia un interval mic. Am aflat în practică că, pentru numeroasele camere cu care lucrăm, PT se încadrează în intervalul de la 96 la 100.

Există un alt factor - paritatea portuară, dar, așa cum a arătat practica, nu este întotdeauna respectată, așa că a trebuit să fie abandonată.

Astfel, comportamentul lui Berkut-MX este următorul:

1. Primim pachetul, îl analizăm în câmpuri;
2. dacă versiunea este 2 și tipul de încărcare utilă este în limitele specificate, atunci trimitem anteturile către server.

Evident, cu această abordare există false pozitive, pentru că Nu numai pachetele RTP se pot încadra sub criterii atât de simple. Dar este important pentru noi că cu siguranță nu vom rata pachetul RTP, iar serverul va filtra pachetele „greșite”.

Pentru a filtra cazurile false, serverul folosește un mecanism care înregistrează sursa traficului video în mai multe pachete primite secvențial (pachetul conține un număr de secvență!). Dacă au sosit mai multe pachete cu numere consecutive, atunci aceasta nu este o coincidență întâmplătoare și începem să lucrăm cu acest flux. Acest algoritm s-a dovedit a fi foarte fiabil.

Să mergem mai departe...

După ce ne-am dat seama că toate informațiile conținute în pachete nu sunt necesare pentru a măsura calitatea și a identifica fluxurile, am decis să punem toată munca de încărcare mare și critică de timp de a primi și izola câmpurile pachetelor RTP pe Berkut-MX, adică pe FPGA. Acesta „găsește” fluxul video, analizează pachetul, lasă doar câmpurile necesare și îl trimite într-un tunel UDP către un server obișnuit. Serverul face măsurători pentru fiecare cameră și salvează rezultatele în baza de date.

Ca urmare, serverul nu funcționează cu 50-60 Gigabit/s, ci cu maximum 5% (aceasta este exact proporția datelor trimise față de dimensiunea medie a pachetului). Adică, intrarea întregului sistem este de 55 Gigabit/s și doar nu mai mult de 3 Gigabit/s ajunge la server!

Ca rezultat, am ajuns la următoarea arhitectură:

Și am primit primul rezultat în această configurație la două săptămâni după stabilirea specificațiilor tehnice inițiale!

Ce face serverul până la urmă?

Deci, ce face un server în arhitectura noastră? Sarcinile lui:

• ascultați un socket UDP și citiți câmpurile cu anteturi împachetate de pe acesta;
• analizați pachetele primite și extrageți câmpurile antet RTP împreună cu identificatorii camerei;
• corelați câmpurile primite cu cele primite anterior și înțelegeți dacă pachetele s-au pierdut, dacă pachetele au fost trimise din nou, dacă ordinea de sosire s-a schimbat, care a fost variația întârzierii pachetelor (jitter) etc.;
• înregistrați datele măsurate în baza de date cu referință de timp;
• analizează baza de date și generează rapoarte, trimite alerte despre evenimente critice (pierdere mare de pachete, pierdere de pachete de la o cameră etc.).

Având în vedere că traficul total la intrarea serverului este de aproximativ 3 Gigabit/s, serverul se descurcă chiar dacă nu folosim niciun DPDK, ci pur și simplu lucrăm printr-un socket Linux (mărind anterior dimensiunea buffer-ului pentru socket, desigur). Mai mult, va fi posibil să se conecteze noi legături și MX-uri, deoarece marja de performanță rămâne.

Iată cum arată partea de sus a serverului (aceasta este partea de sus a unui singur container lxc, rapoartele sunt generate în altul):

Acesta arată că întreaga sarcină pentru calcularea parametrilor de calitate și luarea în considerare a statisticilor este distribuită uniform în patru procese. Am reușit să realizăm o astfel de distribuție folosind hashing-ul în FPGA: o funcție hash este calculată prin IP, iar biții de ordin inferior ai hash-ului rezultat determină numărul portului UDP către care vor merge statisticile. În consecință, fiecare proces care ascultă pe portul său primește aproximativ aceeași cantitate de trafic.

Contra și argumente pro

Este timpul să ne lăudăm și să recunoaștem neajunsurile soluției.

Voi începe cu aspectele pozitive:

• fără pierderi la interfața cu legături 10G. Deoarece FPGA preia întregul „impact”, putem fi siguri că fiecare pachet va fi analizat;
• pentru a monitoriza 55.000 de camere (sau mai multe) aveți nevoie de un singur server cu un card 10G. În prezent folosim servere bazate pe 2 Xeon cu 4 nuclee de 2400 MHz fiecare. Destul de economisit: în paralel cu colectarea informațiilor, sunt generate rapoarte;
• monitorizarea a 8 „zeci” (linkuri 10G) se potrivește doar în 2-3 unități: nu există întotdeauna mult spațiu și putere în rack pentru un sistem de monitorizare;
• atunci când conectați legături de la MX-uri prin comutator, puteți adăuga noi legături fără a opri monitorizarea, deoarece nu trebuie să inserați nicio placă în server și nu trebuie să o opriți pentru a face acest lucru;
• serverul nu este supraîncărcat cu date, primește doar ceea ce este necesar;
• anteturile de la MX vin într-un pachet Ethernet jumbo, ceea ce înseamnă că procesorul nu va fi copleșit de întreruperi (în plus, nu uităm de coalescerea întrerupurilor).

Pentru a fi corect, voi lua în considerare și dezavantajele:

• datorită optimizării stricte pentru o anumită sarcină, adăugarea de suport pentru noi câmpuri sau protocoale necesită modificări ale codului FPGA. Acest lucru duce la mai mult timp petrecut decât dacă am face același lucru pe procesor. Atât în ​​dezvoltare și testare, cât și în implementare;
• informațiile video nu sunt analizate deloc. Camera poate filma un țurțuri atârnat în fața lui sau poate fi îndreptat greșit. Acest fapt va trece neobservat. Noi, desigur, am oferit posibilitatea de a înregistra video de la o cameră selectată, dar operatorul nu poate trece prin toate cele 55.000 de camere!
• un server și dispozitivele alimentate cu FPGA sunt mai scumpe decât doar unul sau două servere;)

Relua

În final, am ajuns cu un complex software și hardware în care putem controla atât partea care analizează pachetele de pe interfețe, cât și partea care ține statisticile. Control total peste toate nodurile sistemului ne-a salvat literalmente când camerele au început să treacă la modul intercalat RTSP/TCP. Pentru că în acest caz, antetul RTP nu se mai află în pachet la un offset fix: poate fi localizat oriunde, chiar și la limita a două pachete (prima jumătate într-unul, a doua în celălalt). În consecință, algoritmul pentru obținerea antetului RTP și a câmpurilor sale a suferit modificări dramatice. A trebuit să facem reasamblarea TCP pe server pentru toate cele 50.000 de conexiuni - de aici și sarcina destul de mare în partea de sus.

Nu mai lucrasem niciodată în domeniul aplicațiilor de mare încărcare, dar am reușit să rezolvăm problema folosind abilitățile noastre FPGA și a ieșit destul de bine. A mai rămas chiar o rezervă - de exemplu, alte 20-30 de mii de fluxuri pot fi conectate la un sistem cu 55.000 de camere.

Am lăsat reglarea subsistemelor Linux (distribuirea cozilor de întrerupere, creșterea bufferelor de primire, alocarea directă a nucleelor ​​unor procese specifice etc.) în afara domeniului de aplicare al articolului, deoarece Acest subiect este deja foarte bine acoperit.

Nu am descris totul, am adunat o mulțime de greble, așa că nu ezitați să puneți întrebări :)

Multumesc mult tuturor celor care au citit pana la sfarsit!