Utilizarea protocoalelor Internet în telefonia IP. Protocoale RTP și RTCP în VoIP

Identificatorul sursei de sincronizare (SSRC).

Identificatori de surse contributive (CSRC).

17.09.2020

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. De codul specificat aplicația determină tipul de informații media ș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 acel trafic tipuri diferite transmise în sesiuni separate de comunicare. 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 propriul interval, 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 furniza părere pentru a garanta calitatea în timpul transmiterii 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 strat 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, este necesară o valoare Cname pentru destinatar 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 interfata grafica utilizator. Această caracteristică este utilizată pentru sesiuni controlate în mod liber în care utilizatorii se conectează și se deconectează fără negocierea adecvată 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 recepție ș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.

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.

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.

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.

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.

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:

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

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:

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.
P (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.
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.
Identificator sursă de sincronizare (SSRC) (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.

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

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.

Când se utilizează protocolul RTP, două porturi sunt deschise pentru comunicare. Unul pentru transmiterea fluxului de date media (chiar numărul de port) și unul pentru transmiterea datelor de semnalizare (feedback pentru QoS și controlul fluxului media) - RTCP. Valorile numerelor de port nu sunt strict legate în general, ele depind puternic de aplicația utilizată;

RTP - Protocolul de transport în timp real RTCP - Protocolul de control în timp real Include suplimentar informații despre: Pierderea pachetelor Întârzieri în tamponare Intensitatea semnalului Măsurarea calității semnalului (Metrici calitatea apelului) Pierderea returnării ecoului etc. RTCP XR - Rapoarte extinse Protocol de control în timp real Toate câmpurile descrise pentru protocolul RTCP, plus: R Factor - Parametru de calitate semnal MOS - Parametru de calitate semnal și altele
Pachetele care conțin vocea transmisă sunt transmise folosind protocolul RTP/RTCP, care este utilizat pentru apelurile VOIP. Protocolul RTP poate transmite date media identificate prin parametri care sunt înregistrați de organizație: „Internet assigned numbers authority” - IANA. Ele sunt, de asemenea, folosite pentru câmpurile din protocolul care este utilizat în mesaje.

Câteva valori ale câmpului de sarcină utilă:

P.T.	nume de codec	audio/video (A/V)	frecvența ceasului (Hz)	numărul de canale	Document	0	PCMU	A	8000	1	RFC3551	3	GSM	A	8000	1	RFC3551	4	G723	A	8000	1	Kumar	5	DVI4	A	8000	1	RFC3551	6	DVI4	A	16000	1	RFC3551	7	LPC	A	8000	1	RFC3551	8	PCMA	A	8000	1	RFC3551	9	G722	A	8000	1	RFC3551	10	L16	A	44100	2	RFC3551	11	L16	A	44100	1	RFC3551	12	QCELP	A	8000	1	-	13	CN	A	8000	1	RFC3389	14	MPA	A	90000		RFC3551,RFC2250	15	G728	A	8000	1	RFC3551	16	DVI4	A	11025	1	DiPol	17	DVI4	A	22050	1	DiPol	18	G729	A	8000	1		19	rezervat	A				20	nealocat	A				21	nealocat	A				22	nealocat	A				23	nealocat	A				24	nealocat	V				25	CelB	V	90000		RFC2029	26	JPEG	V	90000		RFC2435	27	nealocat	V				28	nv	V	90000		RFC3551	29	nealocat	V				30	nealocat	V				31	H261	V	90000		RFC2032	32	MPV	V	90000		RFC2250	33	MP2T	AV	90000		RFC2250	34	H263	V	90000		Zhu	35--71	nealocat				72--76	rezervat pentru RTCP pentru a evita conflictele				RFC3550	77--95	nealocat				77--95	dinamic			RFC3551

IANA: Parametrii protocolului RTP înregistrați: http://www.iana.org/assignments/rtp-parameters

Protocolul RTP și traducerea adresei IP (NAT) Când se desfășoară o sesiune de comunicare VOIP, se formează două fluxuri RTP, câte unul în fiecare direcție. Dacă unul dintre participanții care participă la această sesiune folosește o adresă IP din rețeaua privată, atunci fluxul de la abonatul aflat în rețeaua publică către serverul NAT nu va putea ajunge la abonatul aflat în rețeaua internă. Pentru a rezolva această problemă, (RTP simetric) este adesea folosit. Pentru Informații suplimentare despre utilizarea VOIP în rețele cu NAT, consultați: articolele NAT și VOIP RTCP XR măsoară performanța VoIP Network World 17/11/03 Documente RFC: IETF RFC 3550 RTP: Protocol de transport pentru aplicații în timp real. IETF RFC 3611 RTP Control Protocol Extended Reports (RTCP XR) IETF RFC 1890 Profil RTP pentru conferințe audio și video cu control minim. IETF RFC 2508 Comprimarea antetelor de pachete IP/UDP/RTP pentru linii de comunicație de viteză redusă. IETF RFC 3545 Compresie RTP avansată (CRTP) pentru legături cu latență mare, pierderi mari de pachete și retrimiteri frecvente de date.

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 vă permite să organizați comunicațiile telefonice între abonații rețelei de Internet, între abonați retelele telefonice rețeaua publică (PSTN) prin Internet, 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.

2. Concepte de bază

Protocolul de transport în timp real RTP oferă transmisie în timp real de la capăt la capăt a datelor multimedia, cum ar fi audio și video interactiv. Acest protocol implementează recunoașterea tipului de trafic, numerotarea secvenței pachetelor, managementul marcajului 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.

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

2.2. Videoconferinta

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.

2.3. Conceptul de mixere și traducători

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. Protocolul de transfer de date RTP 3.1. Câmpuri de antet fixe RTP

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

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

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

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

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

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

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

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

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

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

Lista CSRC: de la 0 la 15 articole, 32 de biți fiecare. Lista CSRC (sursa contributivă) identifică sursele incluse 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.

3.2. Sesiuni de comunicare RTP

După cum am menționat mai sus, conform protocolului RTP, diferite tipuri de trafic trebuie transmise separat, în diferite sesiuni de comunicare RTP. O sesiune este definită de o pereche specifică de adrese de transport destinație (o adresă de rețea plus o pereche de porturi pentru RTP și RTCP). De exemplu, într-o teleconferință compusă din audio și video codificate separat, fiecare tip de trafic trebuie trimis într-o sesiune RTP separată cu propria sa adresă de transport destinație. Nu se intenționează ca audio și video să fie transmise în aceeași sesiune RTP și 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.

3.3. Se modifică antetul RTP definit de profil

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

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

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

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

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

3.4. Extensie antet RTP

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

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

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

1999
2000

Cea mai presantă problemă este din ce în ce mai mult lipsa spațiului de adrese, care necesită schimbarea formatului adresei.

O altă problemă este lipsa de scalabilitate a procedurii de rutare - baza rețelelor IP. Creșterea rapidă a rețelei supraîncărcă routerele, care sunt deja forțate să mențină tabele de rutare cu zeci și sute de mii de intrări, precum și să se ocupe de problemele de fragmentare a pachetelor. Puteți face munca ruterelor mai ușoară, în special prin actualizarea protocolului IP.

Pe lângă introducerea de noi funcții direct în protocolul IP, este recomandabil să se asigure o interacțiune mai strânsă cu noile protocoale prin introducerea de noi câmpuri în antetul pachetului.

Ca urmare, s-a decis modernizarea protocolului IP, urmărind următoarele obiective principale:

crearea unei noi scheme extinse de adresare;
îmbunătățirea scalabilității rețelei prin reducerea funcțiilor routerelor backbone;
asigurarea protectiei datelor.

Extinderea spațiului de adrese. Protocolul IP rezolvă potențiala problemă a lipsei de adrese prin extinderea lungimii adresei la 128. Cu toate acestea, această creștere semnificativă a lungimii adresei a fost făcută în mare parte nu pentru a atenua problema lipsei de adrese, ci pentru a îmbunătăți eficiența rețelelor bazate pe acest protocol. Scopul principal a fost schimbarea structurală a sistemului de adresare și extinderea funcționalității acestuia.

În locul celor două niveluri existente de ierarhie a adreselor (numărul rețelei și numărul nodului), IPv6 propune utilizarea a patru niveluri, ceea ce implică o identificare pe trei niveluri a rețelelor și un nivel pentru identificarea nodurilor.

Adresa este acum scrisă în hexazecimal, cu fiecare patru cifre separate prin două puncte, de exemplu:

FEDC:0A96:0:0:0:0:7733:567A.

Pentru rețelele care acceptă ambele versiuni ale protocoalelor IPv4 și IPv6, este posibil să utilizați notația zecimală tradițională pentru cei 4 octeți mai mici și notația hexazecimală pentru octeții mai mari:

0:0:0:0:FFFF 194.135.75.104.

În cadrul sistemului de adresare IPv6 există și un spațiu de adrese dedicat pentru uz local, adică pentru rețele care nu sunt de pe Internet. Există două soiuri adrese locale: pentru rețelele „plate” care nu sunt împărțite în subrețele (Link-Local) și pentru rețelele împărțite în subrețele (Site-Local), care diferă prin valoarea prefixului.

Modificarea formatului antetelor pachetelor. Acest lucru poate fi implementat folosind o nouă schemă de organizare a „antetelor imbricate”, care asigură că antetul este împărțit într-unul principal, care conține informațiile minime necesare, și altele suplimentare, care pot lipsi. Această abordare deschide posibilități bogate de extindere a protocolului prin definirea de noi anteturi opționale, făcând protocolul deschis.

Antetul principal al unei datagrame IPv6, lung de 40 de octeți, are următorul format (Fig. 2.4).

Câmpul Clasă de trafic este echivalent ca scop cu câmpul Tip de serviciu, iar câmpul Limită hop este echivalent cu câmpul Time To Live al protocolului IPv4.

Câmpul Flow Label vă permite să evidențiați și să tratați fluxurile de date individuale într-un mod special, fără a fi nevoie să analizați conținutul pachetelor. Acest lucru este foarte important din punctul de vedere al reducerii sarcinii pe routere.

Câmpul Next Header este analog cu câmpul IPv4 Protocol și determină tipul de antet care urmează celui principal. Fiecare antet suplimentar ulterior conține, de asemenea, un câmp Antet următor.

2.3.3. Protocolul TCP

Protocolul de control al transmisiei (TCP) a fost dezvoltat pentru a sprijini comunicarea interactivă între computere. Protocolul TCP asigură fiabilitatea și fiabilitatea schimbului de date între procesele de pe computere care fac parte dintr-o rețea comună.

Din păcate, protocolul TCP nu este potrivit pentru transmiterea de informații multimedia. Motivul principal este disponibilitatea controlului livrării. Monitorizarea necesită prea mult timp pentru a transmite mai multe informații sensibile la latență. În plus, TCP oferă mecanisme de control al ratei pentru a evita congestionarea rețelei. Cu toate acestea, datele audio și video necesită rate de transmisie strict definite, care nu pot fi modificate în mod arbitrar.

Pe de o parte, protocolul TCP interacționează cu protocolul aplicației utilizator și, pe de altă parte, cu un protocol care furnizează funcțiile de rutare „la nivel scăzut” și adresarea pachetelor pe care IP le realizează de obicei.

Structura logică a software-ului de rețea care implementează protocoalele familiei TCP/IP în fiecare nod de Internet este prezentată în Fig. 2.5.

Dreptunghiurile reprezintă module care procesează date, iar liniile care leagă dreptunghiurile reprezintă căi de transfer de date. Linia orizontală din partea de jos a figurii reprezintă rețeaua Ethernet, care este folosită ca exemplu de mediu fizic.

Orez. 2.5.

Pentru a stabili o legătură între două procese pe diferite calculatoare rețeaua, trebuie să cunoașteți nu numai adresele de internet ale computerelor, ci și numerele acelor porturi TCP (socket-uri) pe care procesele le utilizează pe aceste computere. Orice conexiune TCP de pe Internet este identificată în mod unic prin două adrese IP și două numere de port TCP.

Protocolul TCP poate gestiona pachete deteriorate, pierdute, duplicate sau necomandate. Acest lucru se realizează printr-un mecanism de atribuire a unui număr de secvență fiecărui pachet transmis și un mecanism de verificare a primirii pachetelor.

Când TCP transmite un segment de date, o copie a acestor date este plasată într-o coadă de retransmisie și este pornit un temporizator de confirmare.

2.3.4. Protocolul UDP

Protocolul de datagramă utilizator (UDP) este destinat schimbului de datagrame între procesele calculatoarelor situate într-un sistem integrat de rețele de calculatoare.

Protocolul UDP se bazează pe protocolul IP și oferă servicii de transport proceselor de aplicație care nu diferă mult de cele ale protocolului IP. Protocolul UDP asigură livrarea negarantată a datelor, adică nu necesită confirmarea primirii acestora; În plus, acest protocol nu necesită stabilirea unei conexiuni între sursa și receptorul de informații, adică între modulele UDP.

2.3.5. Concepte de bază ale protocoalelor RTP și RTCP

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 destinatarului să reconstruiască secvența pachetelor expeditorului.

Protocolul RTP acceptă atât comunicația bidirecțională, cât și transferul de date către un grup de destinații, 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.

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ții de serviciu necesare pentru funcționarea fiabilă a unei teleconferințe 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 având lungime variabilă.

Pentru ca protocolul RTP să fie mai flexibil și să poată fi folosit pentru aplicatii diverse, unii dintre parametrii săi sunt în mod deliberat vagi, 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, completarea antetului și extensiile antetului, tipurile de pachete, serviciile și algoritmii de securitate a comunicațiilor, utilizarea protocolului de bază etc. Fiecare aplicație funcționează de obicei cu un singur profil, iar Tipul de profil este specificat prin selectarea aplicației corespunzătoare. Nu există nicio indicație explicită a tipului de profil prin numărul de port, identificatorul de protocol etc.

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ă se cere secretul, atunci pachetele de informații și de control pot fi criptate, caz în care trebuie generată și distribuită și o cheie de criptare.

Deoarece participanții la o teleconferință se pot alătura și părăsi în timp ce conferința 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 către portul de control (portul RTCP) pentru aplicațiile tuturor celorlalți participanți despre recepția pachetelor 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.

Videoconferinta

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 comunicație 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). 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 asociate.

Conceptul de mixere și traducători

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ă lățime de bandă mai mică și codare audio de calitate inferioară, o facilitate 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 conferințe de grup folosind protocolul IP (IPM - IP multicast). 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.

Protocolul de control RTCP

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.

Protocolul de control RTCP (RTCP - Real-Time Control Protocol) se bazează pe transmisia periodică de pachete management tuturor participanților la o sesiune de comunicare folosind același mecanism de distribuție ca protocolul RTP. Protocolul de bază trebuie să ofere multiplexarea informațiilor și pachetele de control, de exemplu, folosind numere diferite porturi UDP. Protocolul RTCP îndeplinește patru funcții principale.

Funcția principală este de a oferi feedback pentru a evalua calitatea distribuției datelor. Aceasta este o funcție integrală a RTCP ca protocol de transport și este legată de funcțiile de control al fluxului și de congestie ale altor protocoale de transport. Feedback-ul poate fi direct util pentru controlul codificării adaptive, dar experimentele cu IP multicasting au arătat că feedback-ul către destinatari este important și pentru diagnosticarea defectelor în diseminarea informațiilor. Trimiterea rapoartelor de feedback privind recepția datelor către toți participanții vă permite să evaluați dacă problemele sunt locale sau globale atunci când observați probleme. Cu mecanismul de distribuție IPM, entitățile precum furnizorii de servicii de rețea pot primi, de asemenea, informații de feedback și pot acționa ca un monitor terț atunci când diagnostichează problemele de rețea. Această funcție de feedback este furnizată de rapoartele expeditorului și receptorului RTCP.

RTCP menține un identificator de sursă de date RTP al stratului de transport persistent numit nume canonic (CNAME). Deoarece ID-ul SSRC se poate schimba dacă este detectat un conflict sau programul este repornit, destinatarii au nevoie de un CNAME canonic pentru a ține evidența fiecărui participant. Destinatarii necesită, de asemenea, un CNAME pentru a mapa mai multe fluxuri de informații de la un anumit participant la mai multe sesiuni RTP asociate, cum ar fi sincronizarea audio și video.

Primele două funcții necesită ca toți participanții să trimită pachete RTCP, prin urmare, pentru a permite scalarea numărului de participanți, RTP trebuie să regleze frecvența de transmitere a acestor pachete. Când fiecare participant la o teleconferință trimite pachete de control tuturor celorlalți participanți, fiecare poate estima independent numărul total de participanți.

O a patra funcție opțională RTCP trebuie să furnizeze informații de control al sesiunii (de exemplu, identificarea participantului) care se vor reflecta în interfața cu utilizatorul. Acest lucru este cel mai probabil să fie util în sesiunile „administrate în mod liber”, în care participanții se alătură și părăsesc un grup fără a controla apartenența sau a conveni asupra parametrilor.

Funcțiile de la unu la trei sunt necesare atunci când RTP este utilizat în multicasting IP și recomandat în toate celelalte cazuri. Dezvoltatorii de aplicații RTP sunt încurajați să evite mecanismele care funcționează doar în două sensuri și nu sunt scalabile pentru a crește numărul de utilizatori.

Rata de transmisie a pachetelor RTCP

Protocolul RTP permite aplicației să scaleze automat reprezentativitatea unei sesiuni de comunicare, variind de la câțiva participanți la câteva mii. De exemplu, într-o conferință audio, traficul de date este, în esență, autolimitat, deoarece doar una sau două persoane pot vorbi simultan, iar cu distribuția în grup, rata de date pe orice legătură rămâne relativ constantă, indiferent de numărul de participanți. Cu toate acestea, traficul de control nu este autolimitat. Dacă rapoartele primite de la fiecare participant sunt trimise la o rată constantă, atunci traficul de control va crește liniar pe măsură ce crește numărul de participanți. Prin urmare, trebuie prevăzut un mecanism special pentru a reduce frecvența de transmisie a pachetelor de control.

Pentru fiecare sesiune, se presupune că traficul de date îndeplinește o limită agregată numită lățime de bandă a sesiunii, care este partajată de toți participanții. Această lățime de bandă poate fi rezervată, iar limita sa este stabilită de rețea. Lățimea de bandă a sesiunii este independentă de tipul de codare media, dar alegerea tipului de codificare poate fi limitată de lățimea de bandă a sesiunii. Se așteaptă ca setarea lățimii de bandă a sesiunii să fie furnizată de aplicația de gestionare a sesiunii atunci când apelează aplicația media, dar aplicațiile media pot seta și o valoare implicită pe baza lățimii de bandă a datelor cu un singur expeditor pentru tipul de codificare selectat pentru o anumită sesiune.

Calculele lățimii de bandă pentru control și trafic de date sunt efectuate ținând cont de protocoalele de transport și de nivel de rețea subiacente (de exemplu, UDP și IP). Anteturile de nivel de legătură de date (DLC) nu sunt luate în considerare în calcule deoarece un pachet poate fi încapsulat cu diferite antete de strat DLC pe măsură ce este transmis.

Traficul de control ar trebui limitat la o parte mică și cunoscută a lățimii de bandă a sesiunii: suficient de mică încât funcția principală a protocolului de transport - transmisia de date - să nu fie afectată; cunoscut astfel încât traficul de control să poată fi inclus în specificația de lățime de bandă dată protocolului de rezervare a resurselor și astfel încât fiecare participant să își poată calcula în mod independent cota. Se presupune că porțiunea de lățime de bandă a sesiunii alocată RTCP ar trebui să fie setată la 5%. Toți participanții la sesiune trebuie să utilizeze aceeași cantitate de lățime de bandă RTCP, astfel încât valorile calculate ale intervalului de transmisie a pachetelor de control să fie aceleași. Prin urmare, aceste constante trebuie setate pentru fiecare profil.

Algoritmul pentru calcularea intervalului dintre trimiterea pachetelor RTCP compuse pentru a împărți lățimea de bandă alocată pentru traficul de control între participanți are următoarele caracteristici principale:

expeditorii folosesc în mod colectiv cel puțin 1/4 din lățimea de bandă a traficului de control ca în sesiunile cu mulți receptori, dar puțini expeditori; După ce abia au stabilit o conexiune, participanții primesc CNAME-ul site-urilor de trimitere într-o perioadă scurtă de timp;
Este necesar ca intervalul calculat între pachetele RTCP să fie de cel puțin 5 secunde pentru a evita exploziile de pachete RTCP care depășesc lățimea de bandă admisă atunci când numărul de participanți este mic și traficul nu este netezit conform legii numerelor mari;
Intervalul dintre pachetele RTCP este variat aleatoriu în intervalul de jumătate până la unu și jumătate din intervalele calculate pentru a evita sincronizarea neintenționată a tuturor participanților. Primul pachet RTCP trimis după intrarea în sesiune este, de asemenea, întârziat aleatoriu (până la jumătate din intervalul minim RTCP) dacă aplicația este pornită pe mai multe site-uri simultan, cum ar fi atunci când se anunță începutul unei sesiuni;
pentru a se adapta automat la modificările cantității de informații de control transmise, se calculează o estimare dinamică a dimensiunii medii a unui pachet RTCP compus folosind toate pachetele primite și trimise;
acest algoritm poate fi utilizat pentru sesiuni în care transmisia de pachete este acceptabilă pentru toți participanții. În acest caz, parametrul lățimii de bandă a sesiunii este lățimea de bandă a expeditorului individual înmulțită cu numărul de participanți, iar lățimea de bandă RTP se bazează pe protocolul de bază pentru a oferi o indicație de lungime. Lungimea maximă a pachetelor RTP este limitată doar de protocoalele subiacente.
Mai multe pachete de protocol RTP pot fi transportate într-un singur bloc de date de protocol de nivel inferior, cum ar fi un pachet UDP. Acest lucru reduce redundanța antetului și simplifică sincronizarea între diferite fire.