Protocoale RTSP, RTP, UDP și TCP în sistemele de supraveghere video. Telefonie IP: de la fire de cupru la procesarea semnalului digital

2. Concepte de bază

3. Protocol de transfer de date RTP

2. Concepte de bază

3. Protocol de transfer de date RTP

Principii de construire a protocolului RTP

Metode de control al muncii

Format antet protocol RTP

Protocolul de rezervare a resurselor - RSVP

Literatură

2.1. Conferințe audio de grup

2.2. Videoconferinta

2.3. Conceptul de mixere și traducători

2.4. Ordinea octetilor, alinierea și formatul marcajului de timp

3.1. Câmpuri de antet fixe RTP

3.2. Sesiuni de comunicare RTP

3.3. Se modifică antetul RTP definit de profil

3.4. Extensie antet RTP

2.1. Conferințe audio de grup

2.2. Videoconferinta

2.3. Conceptul de mixere și traducători

2.4. Ordinea octetilor, alinierea și formatul marcajului de timp

3.1. Câmpuri de antet fixe RTP

3.2. Sesiuni de comunicare RTP

3.3. Se modifică antetul RTP definit de profil

3.4. Extensie antet RTP

Ce este atât de greu în asta?

Cautam o solutie potrivita...

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

Cum se identifică fluxurile RTP?

Cum se separă pachetele RTP de alt trafic?

Sa trecem peste...

Ce face serverul până la urmă?

Contra și argumente pro

rezumat

17.09.2020

Creșterea rapidă a internetului impune noi cerințe privind viteza și volumul transferului de date. Și pentru a satisface toate aceste cerințe, pur și simplu creșterea capacității rețelei nu este suficientă metode rezonabile și eficiente de gestionare a traficului și a congestionării liniilor de transport.

În aplicațiile în timp real, expeditorul generează un flux de date la o rată constantă, iar receptorul (sau destinatarii) trebuie să furnizeze acele date aplicației la aceeași rată. Astfel de aplicații includ, de exemplu, conferințe audio și video, video live, diagnosticare la distanță în medicină, telefonie pe computer, simulare interactivă distribuită, jocuri, monitorizare în timp real etc.

Cel mai utilizat protocol de nivel de transport este TCP. Deși TCP poate suporta o mare varietate de aplicații distribuite, nu este potrivit pentru aplicații în timp real.

Noul protocol de transport în timp real este conceput pentru a rezolva această problemă - RTP(Real-Time Transport Protocol), care garantează livrarea datelor către unul sau mai mulți destinatari cu o întârziere în limitele specificate, adică datele pot fi reproduse în timp real.

RTP nu acceptă niciun mecanism pentru livrarea pachetelor, integritatea transmisiei sau fiabilitatea conexiunii. Toate aceste funcții sunt alocate protocolului de transport. RTP rulează peste UDP și poate suporta transferul de date în timp real între mai mulți participanți într-o sesiune RTP.

Notă

Pentru fiecare participant RTP, o sesiune este determinată de o pereche de adrese de transport destinație pachet (o adresă de rețea - IP și o pereche de porturi: RTP și RTCP).

Pachetele RTP conțin următoarele câmpuri: un ID de expeditor care indică ce parte generează datele, marcaje de timp când pachetul a fost generat, astfel încât datele să poată fi redate la intervalele corecte de către partea care primește, informații despre ordinea transmisiei și informații despre natura conținutului pachetului, de exemplu tipul de codificare a datelor video (MPEG, Indeo etc.). Prezența unor astfel de informații ne permite să estimăm valoarea întârzierii inițiale și dimensiunea buffer-ului de transmisie.

Notă

Într-un mediu tipic în timp real, expeditorul generează pachete la o rată constantă. Acestea sunt trimise la intervale regulate, călătoresc prin rețea și sunt primite de destinatar, care redă datele în timp real pe măsură ce sunt primite. Cu toate acestea, din cauza modificărilor latenței pe măsură ce pachetele călătoresc prin rețea, acestea pot ajunge la intervale neregulate. Pentru a compensa acest efect, pachetele de intrare sunt stocate în tampon, păstrate pentru o perioadă de timp și apoi furnizate la o rată constantă software-ului generator de ieșiri. Prin urmare, pentru ca protocolul în timp real să funcționeze, este necesar ca fiecare pachet să conțină un marcaj de timp, astfel încât destinatarul să poată reproduce datele primite la aceeași viteză ca și expeditorul.

Deoarece RTP definește (și reglementează) formatul de încărcare utilă a datelor transmise, direct legat de acesta este conceptul de sincronizare, care este parțial responsabil pentru mecanismul de traducere RTP - mixerul. Primind fluxuri de pachete RTP de la una sau mai multe surse, mixerul le combină și trimite un nou flux de pachete RTP către unul sau mai mulți destinatari. Mixerul poate combina pur și simplu date și, de asemenea, își poate schimba formatul, de exemplu, atunci când combină mai multe surse audio. Să ne prefacem că sistem nou dorește să participe la sesiune, dar legătura sa la rețea nu are suficientă capacitate pentru a suporta toate fluxurile RTP, atunci mixerul primește toate aceste fluxuri, le combină într-unul singur și îl transmite pe ultimul noului membru al sesiunii. Când primește mai multe fluxuri, mixerul adaugă pur și simplu valorile de modulare a codului de impuls. Antetul RTP generat de mixer include identitatea expeditorului ale cărui date sunt prezente în pachet.

Un dispozitiv mai simplu, un traducător, creează un pachet RTP de ieșire pentru fiecare pachet RTP de intrare. Acest mecanism poate schimba formatul datelor din pachet sau poate utiliza un set diferit de protocoale de nivel scăzut pentru a transfera date de la un domeniu la altul. De exemplu, este posibil ca un potențial destinatar să nu poată procesa semnalul video de mare viteză folosit de alți participanți la sesiune. Traducătorul convertește videoclipul într-un format de calitate inferioară, care necesită mai puțin de mare viteză transmiterea datelor.

Protocolul RTP este folosit doar pentru a transmite datele utilizatorului - de obicei multicast - către toți participanții la sesiune. Protocolul RTCP (Protocol de control al transportului în timp real) funcționează împreună cu RTP, a cărui sarcină principală este de a oferi control asupra transmisiei RTP. RTCP utilizează același protocol de transport subiacent ca RTP (de obicei UDP), dar un număr de port diferit.

RTCP îndeplinește mai multe funcții:

Asigurarea si monitorizarea calitatii serviciilor si feedback-ului in caz de supraincarcare. Deoarece pachetele RTCP sunt multicast, toți participanții la sesiune pot evalua cât de bine performează și primesc ceilalți participanți. Mesajele expeditorului permit destinatarilor să evalueze viteza datelor și calitatea transmisiei. Mesajele destinatarilor conțin informații despre problemele pe care le întâmpină, inclusiv pierderea de pachete și fluctuația excesivă. Feedback-ul de la destinatari este, de asemenea, important pentru diagnosticarea erorilor în distribuție. Analizând mesajele de la toți participanții la o sesiune, administratorul de rețea poate determina dacă o anumită problemă se referă la un participant sau este de natură generală. Dacă aplicația de trimitere concluzionează că problema este tipică pentru sistemul în ansamblu, de exemplu, din cauza eșecului unuia dintre canalele de comunicare, atunci poate crește gradul de compresie a datelor în detrimentul reducerii calității sau refuza să transmite video complet - acest lucru permite transmiterea datelor prin conexiunea de capacitate redusă.
Identificarea expeditorului. Pachetele RTCP conțin o descriere text standard a expeditorului. Ele oferă mai multe informații despre expeditorul pachetelor de date decât un ID de sursă de sincronizare selectat aleatoriu. De asemenea, ajută utilizatorul să identifice firele care aparțin diferitelor sesiuni.
Estimarea și scalarea dimensiunii sesiunii. Pentru a asigura calitatea serviciilor și părereîn scopul controlului congestiei, precum și în scopul identificării expeditorului, toți participanții trimit periodic pachete RTCP. Frecvența de transmitere a acestor pachete scade pe măsură ce numărul participanților crește. Cu un număr mic de participanți, un pachet RTCP este trimis cel mult la fiecare 5 secunde. RFC-1889 descrie un algoritm prin care participanții limitează rata pachetelor RTCP pe baza numărului total de participanți. Scopul este de a menține traficul RTCP la cel mult 5% din traficul total al sesiunii.

RTP este un protocol orientat pe flux. Antetul pachetului RTP a fost creat ținând cont de nevoile transmisiei în timp real. Conține informații despre ordinea pachetelor, astfel încât fluxul de date să fie corect asamblat la capătul de recepție și un marcaj temporal pentru secvența corectă a cadrelor în timpul redării și pentru sincronizarea mai multor fluxuri de date, cum ar fi video și audio.

Fiecare pachet RTP are un antet principal și, eventual, câmpuri suplimentare specifice aplicației.

Utilizarea TCP ca protocol de transport pentru aceste aplicații nu este posibilă din mai multe motive:

Acest protocol permite doar stabilirea unei conexiuni între două puncte finale, prin urmare nu este potrivit pentru transmisia multicast.
TCP permite retransmiterea segmentelor pierdute care ajung atunci când aplicația în timp real nu le mai așteaptă.
TCP nu are un mecanism convenabil pentru asocierea informațiilor de sincronizare cu segmente - cerință suplimentară aplicații în timp real.

Un alt protocol de nivel de transport utilizat pe scară largă, LJDP nu are unele dintre limitările TCP, dar nu oferă informații critice de sincronizare.

Deși fiecare aplicație în timp real poate avea propriile mecanisme pentru a sprijini transmisia în timp real, acestea au multe caracteristici comune care fac definirea unui singur protocol extrem de dorită.

Această problemă este proiectat să rezolve noul protocol de transport în timp real - RTP (Real-time Transport Protocol), care garantează livrarea datelor către unul sau mai mulți destinatari cu o întârziere în limitele specificate, adică datele pot fi reproduse în în timp real.

În fig. 1 prezintă un antet RTP fix care conține un număr de câmpuri care identifică elemente precum formatul pachetului, numărul de secvență, sursele, limitele și tipul de încărcare utilă. Antetul fix poate fi urmat de alte câmpuri care conțin informații suplimentare despre date.

Orez. 1. Antet RTP fix.

V(2 biți). Câmpul Versiune. Versiunea actuală este a doua.
R(1 bit). Completați câmpul. Acest câmp semnalează prezența octeților de umplutură la sfârșitul sarcinii utile. Umplutura este utilizată atunci când aplicația necesită ca dimensiunea sarcinii utile să fie un multiplu de, de exemplu, 32 de biți. În acest caz, ultimul octet indică numărul de octeți de umplutură.
X(1 bit). Câmp de extensie antet. Când acest câmp este setat, antetul principal este urmat de un antet suplimentar utilizat în extensiile RTP experimentale.
SS(4 biți). Câmpul Număr de expeditori. Acest câmp conține numărul de ID-uri de expeditor ale căror date sunt în pachet, ID-urile în sine urmând antetul principal.
M(1 bit). Câmp de marcare. Semnificația bitului de marcare depinde de tipul de sarcină utilă. Bitul de marcare este de obicei folosit pentru a indica limitele unui flux de date. În cazul video, acesta specifică sfârșitul cadrului. În cazul vocii, se precizează începutul vorbirii după o perioadă de tăcere.
RT(7 biți). Câmpul tip sarcină utilă. Acest câmp identifică tipul de încărcare utilă și formatul datelor, inclusiv compresia și criptarea. Într-o stare de echilibru, expeditorul folosește un singur tip de sarcină utilă în timpul unei sesiuni, dar o poate modifica ca răspuns la condițiile în schimbare, dacă este semnalată de Protocolul de control al transportului în timp real.
Număr de secvență(16 biți). Câmp cu numărul de secvență. Fiecare sursă începe numerotarea pachetelor cu un număr arbitrar, care apoi crește cu unul cu fiecare pachet de date RTP trimis. Acest lucru vă permite să detectați pierderea de pachete și să determinați ordinea pachetelor cu același marcaj temporal. Mai multe pachete consecutive pot avea aceeași amprentă temporală dacă au provenit în mod logic în același timp, cum ar fi pachetele aparținând aceluiași cadru video.
Timestamp-ul(32 de biți). Câmp de marcare a timpului. Acest câmp conține momentul în care a fost creat primul octet de date de încărcare utilă. Unitățile în care timpul este raportat în acest câmp depind de tipul de sarcină utilă. Valoarea este determinată de ceasul local al expeditorului.
Sursa de sincronizare (SSRC) Identificator(32 de biți). Câmp Sincronizare ID sursă: un număr generat aleatoriu care identifică în mod unic sursa în timpul unei sesiuni, independent de adresa de rețea. Acest număr joacă un rol important atunci când procesează o bucată de date primită dintr-o singură sursă.
Identificatorul sursei contributive (CSRC).(32 de biți). O listă de câmpuri de identificare sursă „amestecate” în fluxul principal, de exemplu, folosind un mixer. Mixerul inserează o listă întreagă de identificatori de sursă SSRC care au participat la construirea acestui pachet RTP. Această listă se numește CSRC. Număr de elemente din listă: de la 0 la 15. Dacă numărul de participanți este mai mare de 15, primii 15 sunt selectați Un exemplu ar fi o conferință audio, ale cărei pachete RTP conțin discursurile tuturor participanților, fiecare cu. propriul lor SSRC - formează lista CSRC. În plus, întreaga conferință are un SSRC comun.

Protocolul RTCP, ca orice protocol de control, este mult mai complex atât ca structură, cât și prin funcțiile îndeplinite (comparați, de exemplu, protocoalele IP și TCP). Deși baza Protocolul RTCP compune RTP, conține multe câmpuri suplimentare cu care își implementează funcțiile.

Protocolul de rezervare a resurselor, RSVP, aflat în prezent în curs de revizuire de către Internet Engineering Task Force (IETF), este conceput pentru a rezolva problema prioritizării datelor sensibile la latență, spre deosebire de datele tradiționale, pentru care latența nu este atât de critică. RSVP permite sistemelor finale să rezerve resurse de rețea pentru a obține calitatea necesară a serviciului, în special resurse pentru programul în timp real prin protocolul RTP. RSVP se preocupă în primul rând de routere, deși aplicațiile de pe nodurile finale trebuie, de asemenea, să știe cum să folosească RSVP pentru a rezerva lățimea de bandă necesară pentru din această clasă servicii sau nivel de prioritate.

RTP, împreună cu alte standarde descrise, vă permite să transmiteți cu succes video și audio prin rețele IP obișnuite. RTP/RTCP/RSVP - o soluție standardizată pentru rețele cu transmisie de date în timp real. Singurul său dezavantaj este că este destinat doar rețelelor IP. Cu toate acestea, această limitare este temporară: rețelele se vor dezvolta în această direcție într-un fel sau altul. Această soluție promite să rezolve problema transmiterii datelor sensibile la întârziere prin Internet.

O descriere a protocolului RTP poate fi găsită în RFC-1889.

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 retele 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. Beneficiază utilizatorii finali, cărora li se oferă servicii 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 aditionale 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 originale de pachete, livrarea acestora cu întârziere minimă, redare în timp real în momente precise specificate, recunoaștere a 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 nivelul transportuluiș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ă cele mai multe echipamente de retea si deosebita 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.

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 secvența 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ă rețeaua de bază acceptă multicast. RTP este conceput pentru a furniza informațiile necesare aplicatii individuale, iar în cele mai multe cazuri este integrat în aplicație.

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 pentru asigurarea securității comunicațiilor, caracteristicile de utilizare a protocolului de bază etc. (de exemplu, secțiunea 11 ia în considerare 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 e disponibil nu e asigurat nu e prevazut.

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.

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 intră 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ă la conferință. acest momentși cât de bine primesc participanții la conferință datele 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.

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.

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.

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) . Marcaj 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 de trafic conținute î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.

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 să fie separate în funcție de tipul de trafic sau câmpurile SSRC. Intercalarea pachetelor care au Tipuri variate trafic, dar folosirea aceluiași SSRC ar cauza unele probleme:

Dacă unul dintre tipurile de trafic se modifică în timpul unei sesiuni, nu vor exista mijloace generale de a determina care dintre valorile vechi a fost înlocuită cu cea nouă.
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.
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.
Mixerul RTP nu este capabil să combine fluxuri intercalate ale diferitelor tipuri de trafic într-un singur flux.
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.

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 o nouă versiune RTP de făcut schimbare constantă antet fix.

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. Formatul acestor 16 biți trebuie să fie determinat de specificația profilului cu care funcționează aplicațiile.

1999
2000

RTSP(Protocol de streaming în timp real sau, în rusă, protocol de streaming în timp real) este un protocol de aplicație care descrie comenzi pentru controlul unui flux video. Folosind aceste comenzi, putem „ordona” camerei sau serverului, de exemplu, să înceapă difuzarea unui flux video. Un exemplu de solicitare de pornire a redării arată astfel: PLAY rtsp://192.168.0.200/h264 RTSP/1.0

Adică, RTSP este pur și simplu un set de comenzi pentru controlul unui flux video. Să facem un experiment. Pentru a face acest lucru, avem nevoie de o cameră IP care acceptă protocolul RTSP și adresa sa RTSP. Această adresă arată ceva de genul rtsp:///mpeg. Îl puteți găsi în manualul camerei sau în descrierea API. Pentru comoditate, vom enumera adresele RTSP pentru o serie de camere populare în tabel. După ce am aflat adresa RTSP a camerei, deschidem un player standard care acceptă RTSP. Acesta poate fi unul dintre următoarele programe: Windows Media Player, QuickTime, Media Player Classic, VLC media Player, RealPlayer, MPlayer. Am ales QuickTime. Deschideți meniul „Fișier > Deschidere URL” și introduceți adresa noastră RTSP. QuickTime se va conecta apoi la cameră și va reda videoclipuri live. Dispozitivele de înregistrare care funcționează în sistemele de supraveghere video IP primesc videoclipuri de la camere fie folosind protocolul HTTP - adică în același mod în care descarcăm imagini JPEG de pe site-uri web, fie ca flux prin RTSP - adică în același mod în care l-am primit folosind standardul jucător din ultimul exemplu. În setările camerelor IP, opțiunea de streaming pentru transmiterea datelor poate fi desemnată ca RTSP over, RTSP over sau pur și simplu. Deci, RTSP este un set de comenzi pentru controlul fluxului. Dar ce înseamnă celelalte abrevieri: TCP, RTP? TCP și RTP sunt mecanisme de transport (protocoale) care transmit de fapt video.

Protocolul TCP

Să presupunem că am ales metoda RSTP peste TCP și dorim să începem să transmitem un flux video. Ce se va întâmpla la nivelul mecanismelor de transport? Mai întâi, folosind mai multe comenzi, se va stabili o conexiune între expeditor și destinatar. După aceasta, va începe transferul de date video. În același timp, mecanismele TCP
se va asigura că toate datele ajung la destinatar fără modificări și în ordinea necesară. TCP va regla, de asemenea, rata de transmisie, astfel încât transmițătorul să nu trimită mai multe date decât poate procesa receptorul.

UDP este o alternativă la protocolul de transport TCP. Spre deosebire de TCP, UDP nu stabilește o conexiune preliminară, ci pur și simplu începe să transmită date. UDP nu se asigură că datele sunt primite și nu le dublează dacă piese lipsesc sau au sosit cu erori. UDP este mai puțin fiabil decât TCP. Dar, pe de altă parte, oferă o transmisie mai rapidă a fluxurilor din cauza absenței unui mecanism de retransmitere a pachetelor pierdute.

Puteți vedea diferența dintre protocoale făcând următorul experiment: încercați să setați camera la modul RTSP peste TCP și fluturând mâna în fața obiectivului - veți vedea o întârziere pe ecranul monitorului. Acum rulați același test în RTSP prin modul UDP. Întârzierea va fi mai mică. Latența este afectată de mai mulți factori: formatul de compresie, puterea computerului, protocolul de transmisie și caracteristicile software-ului implicat în decodarea video.

RTP (Protocol de transport în timp real), sau în rusă protocolul de transport în timp real. Acest protocol este creat special pentru transmiterea traficului în timp real. Vă permite să monitorizați sincronizarea datelor transmise, să ajustați secvența de livrare a pachetelor și, prin urmare, este mai potrivit decât altele pentru transmiterea de date video și audio. În general, este de preferat să utilizați fie RTP, fie UDP pentru a transmite un flux video. Lucrul prin TCP este justificat doar dacă trebuie să lucrăm cu rețele problematice, deoarece Protocolul TCP va putea corecta erorile și defecțiunile care apar în timpul transferului de date.

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.

Î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. Există un port bine-cunoscut doar pentru protocolul RTSP, dar fluxurile UDP pot trece prin porturi arbitrare (în plus, s-a dovedit că adesea încalcă cerința TREBUIE pentru porturile pare/impare, 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.

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

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

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 aceasta 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!

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. Ca urmare, a trebuit să adăugăm porturi la ID-ul camerei. Acest lucru a rezolvat complet problema unicității.

Întrebarea rămâne: 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.

Mai există un factor - paritatea portuară, dar, după cum a arătat practica, nu este întotdeauna respectată, așa că a trebuit abandonată.

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

Primim pachetul, îl analizăm în câmpuri;
dacă versiunea este 2 și tipul de încărcare utilă este în limitele specificate, atunci trimitem antetele 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.

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!

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.;
înregistrarea datelor 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.

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

Voi începe cu profesioniștii:

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 link-uri noi 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 întreruperii).

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;)

În final, am ajuns să avem 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!

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), incluzând rețelele de calculatoare locale, corporative, globale ș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 neîndoielnice care îi asigură dezvoltarea și extinderea rapidă a pieței de telefonie pe computer. Beneficiază utilizatorii finali, cărora li se oferă servicii 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. Un avantaj incontestabil al telefoniei IP față de un telefon obișnuit este capacitatea de a oferi servicii suplimentare prin utilizarea unui computer multimedia și a diferitelor 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.

Ce standarde și protocoale internaționale reglementează parametrii și algoritmii de bază pentru funcționarea comunicațiilor hardware și software 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.

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 la nivel de transport și este completat de protocolul de control al transferului 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 dedicate telefoniei IP notează că majoritatea echipamentelor de rețea și a software-ului special pentru această tehnologie sunt dezvoltate pe baza Recomandării Sectorului de Standardizare a Telecomunicațiilor (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.

Protocolul RTP acceptă atât comunicarea bidirecțională, cât și transferul de date către un grup de destinatari dacă rețeaua de bază acceptă multicast. RTP este conceput pentru a furniza informațiile solicitate de aplicațiile individuale și, în majoritatea cazurilor, este integrat în funcționarea aplicației.

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

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.

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.

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

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.

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 să fie separate în funcție de tipul de trafic sau câmpurile SSRC. Intercalarea pachetelor cu tipuri de trafic diferite, dar folosind același SSRC ar cauza unele probleme:

Dacă unul dintre tipurile de trafic se modifică în timpul unei sesiuni, nu vor exista mijloace generale de a determina care dintre valorile vechi a fost înlocuită cu cea nouă.
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.
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.
Mixerul RTP nu este capabil să combine fluxuri intercalate ale diferitelor tipuri de trafic într-un singur flux.
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.

Dacă se consideră că este nevoie de funcționalități suplimentare pentru toate profilurile, atunci trebuie definită o nouă versiune RTP pentru a face o modificare permanentă a antetului fix.

Identificatorul sursei de sincronizare (SSRC).

Identificatori de surse contributive (CSRC).

1999
2000