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

Î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 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. 2. Concepte de bază Protocolul de transport în timp real RTP asigură transmiterea î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 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.

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ă ​​(asemănătoare 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 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 temporală 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 compoziția pachetului 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 octetilor, 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 aplicația îl interpretează. 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

1. 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:
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 poartă 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 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.

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

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.

Principii de construire a protocolului RTP

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.

Nota

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.

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.

Î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, reținute pentru un 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ă presupunem că un nou sistem dorește să participe la o 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 le transmite pe cele din urmă către noul sistem. membru de sesiune. 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 nu necesită o rată de transfer de date atât de mare.

Metode de control al muncii

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:

1. 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ă.
2. 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.
3. Estimarea și scalarea dimensiunii sesiunii. Pentru a asigura calitatea serviciului și feedback-ul în scopul gestionării congestionării, 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 de pachete 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.

Format antet protocol RTP

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:

1. Acest protocol permite doar stabilirea unei conexiuni între două puncte finale, prin urmare nu este potrivit pentru transmisia multicast.
2. TCP permite retransmiterea segmentelor pierdute care ajung atunci când aplicația în timp real nu le mai așteaptă.
3. TCP nu are un mecanism convenabil pentru asocierea informațiilor de sincronizare cu segmente, o cerință suplimentară pentru aplicațiile î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ărul 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.
Marca temporală(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 protocolul RTCP se bazează pe RTP, acesta conține multe câmpuri suplimentare cu care își implementează funcțiile.

Protocol de rezervare a resurselor - RSVP

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 la nodurile finale trebuie să știe și cum să folosească RSVP pentru a rezerva lățimea de bandă necesară pentru o anumită clasă de serviciu 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.

Literatură

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

2. În relativism, „lumina” este un fenomen mitic în sine, și nu o undă fizică, care este perturbarea unui anumit mediu fizic. „Lumina” relativistă este emoția nimicului în nimic. Nu are un mediu purtător pentru vibrații.

3. În relativism, manipulările cu timpul (încetinirea) sunt posibile, de aceea sunt încălcate principiile cauzalității și principiul logicii stricte, fundamental pentru orice știință. În relativism, la viteza luminii, timpul se oprește (prin urmare, este absurd să vorbim despre frecvența fotonului). În relativism, o astfel de violență împotriva minții este posibilă, cum ar fi afirmația despre excesul reciproc al vârstei gemenilor care se mișcă cu viteza subluminii și alte batjocuri de logica inerente oricărei religii.

Protocoale RTP și RTCP în VoIP

RTP este principalul protocol de transport în rețelele de telefonie IP. RTP (Real Time Protocol) este un protocol în timp real care a fost creat pentru transmiterea de informații multimedia (audio, video), codificate și împachetate prin rețele IP în limite de timp stricte. Transmiterea segmentelor RTP are loc prin protocoalele UDP și, respectiv, IP, la diferite niveluri ale modelului OSI. Utilizarea UDP, care nu garantează livrarea, se datorează timpului strict al transmisiei media în timp real, precum și incapacității TCP de a funcționa în timp real. Prin urmare, în ciuda pierderii unor date, livrarea la timp este mai importantă în acest caz.
În general, distribuția protocolului de-a lungul straturilor modelului OSI este următoarea:
Stratul de transport: RTP peste UDP
Rețea: IP
Canal: Ethernet
Fizic: Ethernet
Când transmiteți informații multimedia utilizând protocolul RTP, este utilizată următoarea încapsulare:

Dimensiunea minimă a unui segment RTP este de 12 octeți. Primii doi biți determină versiunea protocolului. Astăzi este folosit RTPv.2. Următorul câmp P are, de asemenea, 2 biți și indică prezența caracterelor de umplutură în câmpul de date atunci când se utilizează segmente de aceeași lungime. Câmpul X determină dacă este utilizat un antet extins. Câmpul CC pe 4 biți definește apoi numărul de câmpuri CSRC la sfârșitul antetului RTP, adică numărul de surse care formează fluxul. Urmează câmpul M, un bit marcator folosit pentru a evidenția datele importante. Următorul câmp PT are o dimensiune de 7 biți. Proiectat pentru a determina tipul de sarcină utilă - datele necesare pentru aplicație. Folosind codul specificat, aplicația determină tipul de informații multimedia și metoda de decodare.
Restul antetului constă dintr-un câmp SequenceNumber - numărul secvenţial al segmentului, care urmăreşte ordinea pachetelor şi pierderea acestora; Câmpuri Time Stamp - un cod de sincronizare care indică ora primului eșantion codificat din sarcina utilă, această ștampilă este utilizată de bufferele de recuperare de sincronizare pentru a elimina pierderile de calitate cauzate de variația întârzierii; câmpuri sursă de sincronizare SSRC - un număr arbitrar care distinge o sesiune RTP de alta, pentru a crea capabilități de multiplexare. După porțiunea constantă fixă ​​a antetului RTP, pot fi adăugate până la 15 câmpuri CSRC de treizeci și doi de biți care identifică sursele de date.
Să descriem procedura pentru stabilirea unei sesiuni RTP. Protocolul stabilește că traficul de diferite tipuri este transmis în sesiuni de comunicare separate. Pentru a stabili o sesiune, este necesar să se determine o pereche de adrese de transport destinație, de ex. o adresă de rețea și două porturi pentru RTP și RTCP. Deci, pentru o conferință video, este necesar să transmiteți audio și video în sesiuni diferite cu porturi de destinație diferite în mod corespunzător. Transportul diferitelor tipuri de trafic folosind intercalarea în aceeași sesiune poate cauza următoarele probleme:
- la schimbarea unuia dintre tipurile de trafic, este imposibil să se determine ce parametru din sesiune trebuie înlocuit cu o nouă valoare;
- pentru stabilirea unei sesiuni se folosește un singur interval de timp, iar la transmiterea traficului eterogen fiecare tip va avea un interval propriu, iar acestea vor diferi;
- mixerul RTP nu poate combina fluxuri intercalate de diferite tipuri de trafic într-un singur flux;
- transmiterea mai multor tipuri de trafic într-o sesiune RTP este imposibilă din următoarele motive: utilizarea diferitelor căi de rețea sau distribuirea resurselor rețelei; 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.

Cu toate acestea, RTP (Real-time Transport Protocol) și UDP (User Datagram Protocol) nu garantează calitatea, adică nu funcționează cu QoS (Quality of Service). Prin urmare, protocolul RTP este suportat de Real-Time Transport Control Protocol (RTCP), care oferă informații suplimentare despre starea sesiunii de comunicare RTP.
Protocolul RTCP îndeplinește patru funcții principale:
I. Sarcina principală a protocolului RTCP este de a oferi feedback pentru a garanta calitatea transmisiei datelor. Feedback-ul poate fi direct util atunci când este aplicat transmisiei de codare adaptivă. De asemenea, atunci când se utilizează IP multicasting, este extrem de important ca destinatarii să diagnosticheze erorile la transmiterea mesajelor (pachetelor). Trimiterea mesajelor cu rapoarte de recepție permite părții expeditoare să determine motivul transmiterii nereușite a mesajelor, dacă acest lucru se întâmplă.
II. RTCP conține un identificator de nivel de transport imuabil pentru sursa RTP, care se numește „nume canonic” sau „nume C”. Deoarece identificatorul SSRC se poate schimba dacă sunt găsite coliziuni, receptorul are nevoie de o valoare Cname pentru a ține evidența fiecărui participant. Destinatarii folosesc, de asemenea, Cname pentru a mapa mai multe fluxuri de date de la un singur participant atunci când stabilesc mai multe sesiuni simultan, de exemplu, pentru a sincroniza canalele audio și video atunci când transmit video cu audio.
III. Cele două funcții de mai sus presupun că toți participanții la sesiuni au trimis pachete RTCP, astfel încât rata de transmisie trebuie controlată astfel încât RTP să poată stabili sesiuni cu un număr mare de utilizatori. Când fiecare participant își transmite pachetele de control tuturor celorlalți, orice partener poate determina în mod independent numărul total de participanți la sesiune. Acest lucru este necesar pentru calculele ratelor de transmisie a mesajelor RTCP.
IV. Această funcție este utilizată pentru a transmite informațiile de control minime necesare, cum ar fi ID-ul participantului, care este utilizat de GUI. Această caracteristică este utilizată pentru sesiuni controlate în mod liber în care utilizatorii se conectează și se deconectează fără negocierea corespunzătoare a parametrilor și caracteristicilor. RTCP servește ca un canal convenabil pentru a contacta toți participanții, dar nu acceptă neapărat toate cerințele de comunicare ale aplicației.
În rețelele IP care utilizează multicasting, funcțiile unu, doi și trei sunt obligatorii atunci când se utilizează sesiuni RTP. Utilizarea lor este recomandată și pentru transmiterea în alte rețele și medii. Astăzi, se recomandă dezvoltatorilor de aplicații RTP să folosească instrumente care le permit să lucreze în modul multicast, și nu doar în modul unicast.
Să luăm în considerare formatul pachetelor RTCP.
Standardul de protocol definește mai multe tipuri de pachete RTCP. RTCP este conceput pentru a transmite informații de serviciu:
sr: Raportul expeditorului. Necesar pentru statisticile de primire și transmitere a participanților la sesiune care sunt expeditori activi direct;
rr: Raportul destinatarului. Necesar pentru statisticile de la participanții care nu sunt destinatari;
sdes: Descrie sursa, include Cname;
bye: Servește pentru a indica sfârșitul (ieșirea) sesiunii;
aplicație: funcții specifice aplicației;
Fiecare pachet RTCP constă dintr-o parte constantă, ca și în cazul protocolului RTP, care este utilizat de pachetele RTP, urmată de câmpuri care pot varia în lungime în funcție de tipul de pachet, dar sunt multiplu de 32 de biți. Cerințele de aliniere și câmpul de lungime din partea fixă ​​a antetului sunt introduse pentru a face pachetele RTCP unibile. Mai multe pachete RTCP pot fi concatenate împreună fără a introduce niciun separator pentru a produce un pachet RTCP compus care este trimis printr-un protocol de transport de nivel scăzut, cum ar fi UDP. Nu există un contor special pentru pachetele RTCP individuale, deoarece protocolul de nivel scăzut va specifica lungimea totală și va determina sfârșitul pachetului compus.


Formatul pachetului de mesaj al expeditorului RTCP este următorul, așa cum se arată în figura de mai sus.

Pachetele RTCP sunt supuse următoarelor verificări de sănătate.
- Câmpul pentru versiunea RTP trebuie să fie egal cu 2.
- Câmpul de tip de date al primului pachet RTCP dintr-un pachet compus trebuie să fie SR sau RR.
- Bitul de umplutură (P) trebuie să fie zero pentru primul pachet al unui pachet RTCP compus, deoarece padding-ul poate fi prezent doar în ultimul.
- Lungimea câmpurilor pachetelor individuale RTCP trebuie să se adună la lungimea totală a pachetului compus.

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

Î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 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. 2. Concepte de bază Protocolul de transport în timp real RTP asigură transmiterea î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 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.

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ă ​​(asemănătoare 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 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 temporală 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 compoziția pachetului 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 octetilor, 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 aplicația îl interpretează. 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

1. 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:
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 poartă 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 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.

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