Dezvoltarea unei structuri de rețea cu comutare de pachete folosind exemplul rețelei telefonice de stat din Moscova OJSC. Curs de prelegeri despre tehnologiile de rețea

Această secțiune discută câteva aspecte ale transportului pachetelor RTP prin rețea și protocoale de transport. Dacă nu se specifică altfel în specificațiile altor protocoale, la transmiterea pachetelor se aplică următoarele reguli de bază.

RTP se bazează pe protocoalele de bază pentru a asigura separarea fluxurilor de date RTP de informațiile de control RTCP. Pentru protocoale UDP și similare Protocolul RTP folosește un număr de port par, iar fluxul RTCP corespunzător utilizează un număr de port cu unul mai mare.

Pachetele de informații RTP nu conțin niciun câmp de lungime, prin urmare RTP se bazează pe protocolul de bază pentru a furniza indicații 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 poate facilita sincronizarea între diferite fire.

9. Lista constantelor de protocol

Această secțiune conține o listă de constante definite în specificația protocolului RTP.

Constantele de tip trafic RTP (PT - tipul de sarcină utilă) sunt definite în profiluri. Totuși, octetul antet RTP care conține biții de marcare și câmpul tip de trafic nu trebuie să conțină valorile rezervate 200 și 201 (notație zecimală) pentru ca pachetele RTP să fie distinse de pachetele RTCP SR și RR. Pentru un format standard cu un bit de marcator și un câmp de tip de trafic pe șapte biți, această limitare înseamnă că tipurile de trafic 72 și 73 nu trebuie utilizate.

Valorile tipului de pachet RTCP (a se vedea tabelul 1) sunt selectate în intervalul de la 200 la 204 pentru un control mai bun al corectitudinii antetului pachetului RTCP în comparație cu pachetele RTP. Când câmpul de tip pachet RTCP este comparat cu octetul de antet RTP corespunzător, acest interval corespunde unui bit marcator de unu (ceea ce nu este cazul în mod obișnuit în pachetele de informații) și MSB al câmpului standard de tip de trafic al unuia (în timp ce este definit static. tipurile de trafic au de obicei valori PT cu zero în cifra cea mai semnificativă). Acest interval a fost, de asemenea, ales pentru a oferi o distanță mai mare de la valorile 0 și 255, deoarece câmpurile constând în întregime din zerouri sau unu sunt în primul rând caracteristice datelor.

Alte tipuri de pachete RTCP sunt definite de Comunitatea IANA. Dezvoltatorii au capacitatea de a înregistra valorile de care au nevoie pentru cercetarea experimentală și apoi de a anula înregistrarea, deoarece acele valori nu mai sunt necesare.

Tipurile de articole permise în pachetul SDES sunt prezentate în Tabel.

2. Alte tipuri de puncte SDES sunt desemnate de Comunitatea IANA. Dezvoltatorii au capacitatea de a înregistra valorile de care au nevoie atunci când efectuează studii experimentale și apoi de a anula înregistrarea atunci când acele valori nu mai sunt necesare.

10. Descrierea profilului de trafic și a formatului

După cum sa menționat mai sus (a se vedea secțiunea 2), pentru a descrie complet protocolul RTP pentru o anumită aplicație, sunt necesare două tipuri de documente suplimentare: o descriere a profilului și formatul de trafic. RTP poate fi utilizat pentru multe clase de aplicații cu cerințe semnificativ diferite. Flexibilitatea de adaptare la aceste cerințe este oferită de utilizarea diferitelor profile (vezi). De obicei, aplicația folosește un singur profil și nu există nicio indicație evidentă a profilului în care se aflăîn acest moment

în uz - nr. .

Al doilea tip de document suplimentar, specificația formatului de trafic, definește modul în care un anumit tip de trafic (de exemplu, video codificat conform H.261) ar trebui să fie transmis în conformitate cu RTP. Același format de trafic poate fi utilizat pentru mai multe profiluri și, prin urmare, poate fi definit independent de profil. Documentele de profil sunt responsabile doar pentru potrivirea acestui format și a valorii PT

Antetul pachetului de date RTP. Octetul din antetul pachetului de date RTP, care conține bitul de marcare și câmpul de tip de trafic, poate fi redefinit în funcție de profil pentru a îndeplini diferite cerințe, de exemplu, pentru a furniza mai mulți sau mai puțini biți de marcare (secțiunea 3.3).

Tipuri de trafic. Un profil definește de obicei o varietate de formate de trafic (de exemplu, algoritmi de codare media) și o mapare statică implicită între aceste formate și valorile PT. Unele dintre formatele de trafic pot fi specificate prin referire la descrierile individuale ale formatelor de trafic.

Pentru fiecare tip de trafic definit, profilul trebuie să specifice frecvența de timp RTP necesară pentru a fi utilizată (Secțiunea 3.1). Umpluturi pentru antetul pachetelor de date RTP. Dacă unele suplimentare funcţionalitate .

în cadrul clasei de aplicații de profil care nu depind de tipul de trafic, atunci câmpuri suplimentare pot fi atașate la antetul fix al pachetului de date RTP .

Extensii de antet pentru pachete de date RTP. Conținutul primilor 16 biți ai structurii RTP Data Packet Header Extension va fi specificat dacă utilizarea acestui mecanism este permisă de profil.

Tipuri de pachete RTCP. Pot fi definite noi tipuri de pachete RTCP specifice clasei de aplicație (și înregistrate de IANA).

Interval de raportare RTCP. Profilul trebuie să definească valorile utilizate la calcularea intervalului de raportare RTCP: porțiunea de lățime de bandă a sesiunii RTCP, intervalul minim de raportare și partajarea lățimii de bandă între expeditori și destinatari. Extinderea pachetului SR/RR. Dacă este disponibil Informații suplimentare despre expeditor sau destinatar, care trebuie transmis în mod regulat, apoi pentru pachetele SR și RR Protocolul RTCP

poate fi definită o secțiune de extensie.

Folosind SDES. Profilul poate defini prioritățile relative pentru clauzele RTCP SDES care urmează să fie transmise sau abandonate (a se vedea secțiunea 4.2.2); sintaxă sau semantică alternativă pentru clauza CNAME (secțiunea 4.4.1);

formatul clauzei LOC (secțiunea 4.4.5); semantica și utilizarea clauzei NOTE (Secțiunea 4.4.7) și a noilor clauze SDES care trebuie înregistrate la IANA.

Protocol de nivel inferior. Transportul pachetelor RTP poate necesita utilizarea unei rețele de bază specifice sau a unui protocol de nivel de transport.

Conformitatea transportului. Pot fi specificate mapări RTP și RTCP, altele decât cele specificate în Secțiunea 8, la adresele nivelului de transport, cum ar fi porturile UDP.

Încapsulare. Formarea pachetelor RTP poate fi definită pentru a permite transmiterea mai multor pachete de informații RTP într-un singur bloc de date de protocol de nivel inferior (clauza 8).

Fiecare aplicație pe care o dezvoltați nu ar trebui să necesite un profil nou.

Este mai logic să extindeți un profil existent într-o singură clasă de aplicații, mai degrabă decât să creați unul nou. Acest lucru va facilita comunicarea aplicațiilor, deoarece fiecare rulează de obicei sub un singur profil. Extensiile simple, cum ar fi definițiile valorilor RT suplimentare sau ale tipurilor de pachete RTCP, pot fi realizate prin înregistrarea lor la IANA și publicarea descrierilor lor într-o specificație de profil sau specificație de format de trafic.

11. Profil RTP pentru conferințe audio și video cu control minim

RFC 1890 descrie un profil pentru utilizarea protocolului de transport în timp real RTP versiunea 2 și a protocolului de control RTCP asociat într-o conferință audio sau video de grup, numit Profil RTP pentru conferințe audio și video cu control minim. Acest profil definește aspecte ale RTP nespecificate în specificația RTP Versiunea 2 (RFC 1889). Gestionarea minimă înseamnă că nu este nevoie de suport pentru negocierea parametrilor sau gestionarea apartenenței (de exemplu, când se utilizează mapări statice ale tipului de trafic și indicații de apartenență furnizate de RTCP). Să luăm în considerare principalele prevederi ale acestui profil.

11.1. Formate de pachete RTP și RTCP și parametri de protocol

Această secțiune conține o descriere a unui număr de elemente care pot fi definite sau modificate în profil.

Antetul pachetului de informații RTP. Este utilizat formatul standard de antet fix al pachetelor de informații RTP (un bit token).

Tipuri de trafic. Valorile tipului de trafic static sunt definite în secțiunile 11.3 și 11.4.

Extensii de antet de pachete de informații RTP. Nu sunt definite extensii de antet de pachete de informații RTP, dar aplicațiile care utilizează acest profil pot folosi astfel de extensii. Adică, aplicațiile nu ar trebui să presupună că bitul X al antetului RTP este întotdeauna setat la zero.

Aplicațiile ar trebui să fie pregătite să ignore extensia antetului. Dacă în viitor este specificată o extensie de antet, trebuie specificat conținutul primilor 16 biți, astfel încât să poată fi identificate multe extensii diferite.

Tipuri de pachete RTCP. Nu sunt definite tipuri suplimentare de pachete RTCP în această specificație de profil.

Interval de raportare RTCP. La calcularea intervalului de raportare RTCP, trebuie utilizate constantele propuse în RFC 1889.

Extensii de pachete SR/RR. Extensiile pentru pachetele RTCP SR și RR nu sunt definite.

Folosind SDES. Aplicațiile pot folosi oricare dintre clauzele SDES descrise. În timp ce informațiile cu numele canonic (CNAME) sunt trimise la fiecare interval de raportare, alte elemente ar trebui trimise numai la fiecare al cincilea interval de raportare.

Siguranţă. Serviciile de securitate RTP implicite sunt, de asemenea, definite implicit de acest profil.

Potrivire parolă-cheie. Parola introdusă de utilizator este convertită folosind algoritmul MD5 într-un rezumat de 16 octeți. Cheia de N biți este obținută din digest folosind primii N biți. Se așteaptă ca parolele să includă numai litere, cifre, cratime și spații ASCII, pentru a reduce probabilitatea de apariție a unor confuze la transmiterea parolelor prin telefon, fax, telex sau e-mail. Parola poate fi precedată de o specificare a algoritmului de criptare. Orice caractere până la prima bară oblică (cod ASCII 0x2f) sunt interpretate ca numele algoritmului de criptare. Dacă nu există bară oblică, algoritmul de criptare implicit este DES-CBC.

Mai jos este protocolul. Profilul definește utilizarea RTP peste UDP în modul bidirecțional și multicast.

Conformitatea transportului. Este utilizată corespondența standard între adresele nivelului de transport RTP și RTCP.

Încapsulare. Încapsularea pachetelor RTP nu este definită.

11.2. Înregistrarea tipurilor de trafic

Acest profil definește tipurile de codificare standard utilizate cu RTP.

• Alte tipuri de codificare trebuie înregistrate la IANA înainte de utilizare. La înregistrarea unui nou tip de codificare, trebuie furnizate următoarele informații: denumirea convențională a tipului de codificare și
• frecvența ceasului
• Marca temporală RTP (etichetele trebuie să aibă trei sau patru caractere pentru a oferi o prezentare compactă, dacă se dorește);
• o indicație despre cine are dreptul de a schimba tipul de codificare (de exemplu, ISO, CCITT/ITU, alte organizații internaționale de standardizare, un consorțiu, o anumită companie sau grup de companii);
• orice parametri de funcționare;
• link-uri către descrierile disponibile ale algoritmului de codificare, cum ar fi (în ordinea preferințelor) un RFC, un articol publicat, un depunere de brevet, un raport tehnic, un cod sursă de codec sau o referință;
• pentru tipurile de codificare privată, informații de contact (adresă poștală și adresă de e-mail);
• o valoare care să indice tipul de trafic al acestui profil, dacă este necesar (vezi mai jos).
• Rețineți că nu toate tipurile de codificare care trebuie utilizate cu RTP trebuie să fie atribuite static. „Uneltele non-RTP” care nu sunt acoperite în acest articol pot fi utilizate pentru a stabili o mapare dinamică între o valoare a tipului de trafic (PT) în intervalul 96 la 127 și un tip de codificare.
• Spațiul disponibil pentru valoarea tipului de trafic este destul de mic. Noile tipuri de trafic sunt atribuite static (permanent) numai dacă sunt îndeplinite următoarele condiții:
• codificarea este de mare interes pentru comunitatea internetului;

oferă beneficii comparabile cu codificările existente și/sau este necesar pentru a interopera cu sistemele de conferințe sau multimedia existente, utilizate pe scară largă;

descrierea este suficientă pentru a crea un decodor.

Ceasul RTP utilizat pentru a genera marcajul de timp RTP este independent de numărul de canale și tipul de codificare; este egal cu numărul de perioade de prelevare pe secundă. Pentru codificarea N-canal (stereo, quad etc.), fiecare perioadă de eșantionare (să zicem 1/8000 dintr-o secundă) generează N eșantioane. Numărul total de mostre generate pe secundă este egal cu produsul dintre rata de eșantionare și numărul de canale.

Când utilizați mai multe canale audio sunt numerotate de la stânga la dreapta, începând cu primul. În pachetele audio RTP, datele de la canalele cu numere mai mici preced datele de la canalele cu numere mai mari. Pentru mai mult de două canale se utilizează următoarea notație:

• l - stânga;
• r - dreapta;
• c - central;
• S - periferic;
• F - frontal;
• R - spate.

Numărul de canale	Numele sistemului	Numerele canalelor
		1	2	3	4	5	6
2	stereo	l	r
3		l	r	c
4	quad	Fl	pr	Rl	Rr
4		l	c	r	S
5		Fl	pr	Fc	Sl	Sr
6		l	lc	c	r	rc	S

Eșantioanele tuturor canalelor aparținând aceluiași moment de eșantionare trebuie să fie în același pachet. Intercalarea mostrelor de la diferite canale depinde de tipul de codificare.

Frecvența de eșantionare trebuie selectată dintr-o varietate de: 8000, 11025, 16000, 22050, 24000, 32000, 44100 și 48000 Hz (calculatoarele Apple Macintosh au propriile rate de eșantionare de 22254,54 și 22254,54 și 271212, care pot fi convertite la 271,212. este o calitate acceptabilă prin sărirea a patru sau două mostre într-un cadru de 20 ms). Cu toate acestea, majoritatea algoritmilor de codare audio sunt definiți pentru un set mai limitat de rate de eșantionare. Destinatarii trebuie să fie pregătiți să primească audio multicanal, dar pot alege audio mono.

Pentru pachetarea audio, intervalul implicit de pachetare trebuie să fie de 20 ms, dacă nu se specifică altfel în descrierea de codificare. Intervalul de pachetare definește întârzierea minimă de la capăt la capăt. Pachetele mai lungi au relativ mai puțini octeți în antet, dar produc mai multă latență și fac pierderea pachetelor mai semnificativă. Pentru aplicații non-interactive, cum ar fi prelegeri sau canale cu limitări semnificative ale lățimii de bandă, o latență mai mare a pachetelor poate fi acceptabilă. Destinatarul trebuie să primească pachete audio cu o întârziere de la 0 la 200 ms. Această limită asigură o dimensiune rezonabilă a tamponului pentru destinatar.

În codificările bazate pe eșantion, fiecare probă de semnal este reprezentată de un număr fix de biți. În cadrul datelor audio comprimate, codurile de eșantionare individuale pot depăși granițele octeților. Durata semnalului transmis într-un pachet audio este determinată de numărul de mostre din pachet.

Pentru tipurile de codificare bazate pe eșantion care produc unul sau mai mulți octeți pentru fiecare eșantion, mostrele de la diferite canale eșantionate simultan sunt împachetate în octeți adiacenți. De exemplu, pentru a codifica audio stereo, secvența de octeți este: canalul din stânga, primul eșantion; canalul drept, primul numărare; canalul stâng, al doilea număr; canalul drept, al doilea număr, etc. În codificarea multi-octetă, cel mai semnificativ octet este transmis primul. Ambalarea codificărilor bazate pe eșantion, producând mai puțin de un octet pentru fiecare probă, este determinată de algoritmul de codificare.

Un algoritm de codare bazat pe cadru convertește un bloc de semnal audio cu lungime fixă ​​într-un alt bloc de date comprimate, de obicei și cu lungime fixă. Pentru codificări bazate pe cadre, expeditorul poate combina mai multe astfel de cadre într-un singur mesaj.

Pentru codecurile bazate pe cadre, ordinea canalului este specifică întregului bloc. Adică, pentru audio stereo, mostrele pentru canalele stânga și dreapta sunt codificate independent; în care cadrul de codificare pentru canalul stâng precede cadrul pentru canalul drept.

Toate codecurile audio orientate pe cadru trebuie să poată codifica și decoda mai multe cadre consecutive transmise într-un singur pachet. Deoarece dimensiunea cadrului pentru codec-urile orientate pe cadru este fixă, nu este nevoie să folosiți o notație separată pentru aceeași codificare, dar cu un număr diferit de cadre pe pachet.

În tabel Figura 3 prezintă valorile tipurilor de trafic (PT) definite de acest profil pentru semnalele audio, ale acestora simboluriși de bază specificatii tehnice algoritmi de codare.

11.4. Codificare video

În tabel 4 prezintă valorile tipurilor de codare (PT), simbolurile algoritmilor de codare și caracteristicile tehnice ale algoritmilor de codare a semnalului video definiți de acest profil, precum și valorile PT nealocate, rezervate și specificate dinamic.

Valorile tipului de trafic în intervalul 96 până la 127 pot fi determinate dinamic prin protocolul de control al conferinței, care nu este acoperit în acest articol. .

De exemplu, directorul de sesiune poate determina că, pentru o sesiune de comunicaţie dată, tipul de trafic 96 denotă codificare PCMU, canal dublu, rata de eşantionare de 8000 Hz. Intervalul de valori ale tipului de trafic marcat ca „rezervat” nu este utilizat, astfel încât pachetele de protocol RTCP și RTP să poată fi distinse în mod fiabil

O sursă RTP produce un singur tip de trafic la un moment dat;

Nu este permisă intercalarea diferitelor tipuri de trafic în aceeași sesiune de comunicare RTP. Mai multe sesiuni RTP pot fi utilizate în paralel pentru a transmite diferite tipuri de trafic. Tipurile de trafic definite în acest profil sunt fie audio, fie video, dar nu ambele. Cu toate acestea, este posibil să se definească tipuri de trafic combinate care combină, de exemplu, audio și video, cu o separare corespunzătoare în formatul de trafic.

Aplicațiile audio care utilizează acest profil trebuie să poată, cel puțin, să trimită și să primească tipurile de trafic 0 (PCMU) și 5 (DVI4). Acest lucru permite interacțiunea fără a fi de acord asupra unui format.

11.5. Alocarea portului

După cum este definit în descrierea protocolului RTP, datele RTP trebuie trimise pe un port UDP cu număr par, iar pachetele RTCP corespunzătoare trebuie trimise pe un port cu un număr mai mare (număr impar).

Aplicațiile care rulează cu acest profil pot folosi orice astfel de pereche de porturi UDP. De exemplu, o pereche de porturi poate fi alocată aleatoriu de către programul de gestionare a sesiunii. O singură pereche fixă ​​de numere de port nu poate fi specificată, deoarece în unele cazuri mai multe aplicații care utilizează acest profil trebuie să ruleze corect pe aceeași gazdă, iar unele sisteme de operare nu permit proceselor multiple să utilizeze același port UDP cu adrese diferite de grup.

• Cu toate acestea, numerele de porturi implicite pot fi 5004 și 5005. Aplicațiile care utilizează mai multe profiluri pot alege această pereche de porturi ca indicator al profilului respectiv. Dar aplicațiile pot necesita, de asemenea, ca perechea de porturi să fie specificată în mod explicit. sisteme de calcul
• CBC (cipher block chaining) - un lanț de blocuri criptate, modul standardului de criptare a datelor DES
• CELP (predicție liniară excitată de cod) - un tip de codificare a semnalului audio care utilizează predicția liniară excitată de cod
• CNAME (nume canonic) - nume canonic
• CSRC (sursa contributiva) - sursa inclusa. Sursa fluxului de pachete RTP care a contribuit la fluxul combinat produs de mixerul RTP. Mixerul inserează în antetul pachetului de protocol RTP o listă de identificatori SSRC ai acelor surse care au participat la formarea acestui pachet. Această listă se numește lista CSRC. Exemplu: Mixerul transmite ID-urile participanților la teleconferință care vorbesc în prezent ale căror sunete vocale au fost amestecate și utilizate pentru a crea un pachet de ieșire, indicând destinatarul către sursa curentă de mesaje, chiar dacă toate pachetele audio conțin același ID SSRC (la fel ca și mixer)
• DES (Data Encryption Standard) - standard de criptare a datelor
• IANA (Internet Assigned Numbers Authority) - Comunitatea Internet Assigned Numbers
• IMA (Interactive Multimedia Association) - Asociația Interactive Multimedia
• IP (Internet Protocol) - protocol de interconectare, protocol de nivel de rețea, protocol de datagramă. Permite pachetelor să traverseze mai multe rețele în drum spre destinație
• IPM (IP Multicast) – multicast folosind protocolul IP
• LD-CELP (predicție liniară excitată de cod cu întârziere redusă) - algoritm de codare a vorbirii care utilizează predicția liniară cu excitație de cod și latență scăzută
• LPC (linear predictive encoding) - codificare de predicție liniară
• NTP (Network Time Protocol) este un protocol de timp de rețea care măsoară timpul î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. În unele cazuri, este utilizată o reprezentare mai compactă, în care doar cei 32 de biți din mijloc sunt preluați din formatul complet: cei 16 biți inferiori ai părții întregi și cei mai semnificativi 16 biți ai părții fracționale.
• RPE/LTP ​​(excitația pulsului rezidual/predicția pe termen lung) - algoritm de codare a semnalului vocal cu excitație diferențială a pulsului și predicție pe termen lung
• RTCP (Real-Time Control Protocol) - protocol de control al transmisiei de date în timp real
• RTP (Real-Time Transport Protocol) - protocol de transport în timp real
• SSRC (sursa de sincronizare) - sursa de sincronizare. Sursa unui flux de pachete RTP, identificată printr-un identificator SSRC numeric de 32 de biți transportat în antetul RTP, indiferent de adresa rețelei. Toate pachetele cu aceeași sursă de ceas utilizează același interval de temporizare și spațiu de număr de secvență, astfel încât receptorul grupează pachetele pentru redare folosind sursa de ceas. Exemplu de sursă de ceas: expeditorul unui flux de pachete primit de la o sursă de semnal, cum ar fi un microfon, o cameră video sau un mixer RTP. Sursa ceasului poate schimba formatul datelor în timp, cum ar fi codificarea audio. ID-ul SSRC este o valoare selectată aleatoriu care este considerată unică la nivel global într-o anumită sesiune RTP. Un participant la teleconferință nu trebuie să folosească același ID SSRC pentru toate sesiunile RTP dintr-o sesiune multimedia; Agregarea identificatorilor SSRC este furnizată prin protocolul RTCP. Dacă un participant generează mai multe fluxuri într-o singură sesiune RTP, de exemplu de la mai multe camere video, atunci fiecare flux trebuie să fie identificat printr-un SSRC separat
• TCP (Transmission Control Protocol) este un protocol de nivel de transport utilizat împreună cu protocolul IP
• UDP (User Datagram Protocol) este un protocol de nivel de transport fără a stabili o conexiune logică. UDP asigură doar că un pachet este trimis către una sau mai multe stații din rețea. Verificarea corectitudinii și asigurarea integrității (livrarea garantată) a transmisiei datelor se realizează pe mai mult de nivel înalt
• ADPCM - modulare adaptivă a codului de impulsuri diferenţiale
• jitter - jitter, abaterea fazei sau a frecvenței unui semnal; în legătură cu telefonia IP - întârziere neuniformă a datagramelor în rețea
• DPD - legătură de transmisie a datelor (nivelul doi al Modelului de Interacțiune de Referință sisteme deschise)
• IVS - informatii- rețele de calculatoare
• mixer - Un sistem intermediar care primește pachete RTP de la una sau mai multe surse, eventual modifică formatul de date, combină pachetele într-un nou pachet RTP și apoi îl transmite. Deoarece sursele multiple de semnal nu sunt în general sincronizate, mixerul ajustează sincronizarea fluxurilor componente și generează propriul ceas pentru fluxul combinat. Astfel, toate pachetele de date generate de mixer sunt identificate ca având mixerul ca sursă de ceas
• monitor - O aplicație care primește pachete RTCP trimise de participanții la sesiunea RTP, în special rapoarte de recepție, și evaluează calitatea curentă a serviciului pentru controlul distribuției, detectarea erorilor și statistici pe termen lung. De obicei, funcțiile unui monitor aparțin aplicațiilor utilizate în sesiunea de comunicare, dar monitorul poate fi o aplicație separată care nu este utilizată altfel sau care trimite sau primește pachete de informații RTP. Astfel de aplicații sunt numite monitoare terțe
• ITU-T - Sectorul de standardizare a telecomunicațiilor al Uniunii Internaționale a Telecomunicațiilor
• sistem final - o aplicație care generează conținut trimis în pachete RTP și/sau care consumă conținutul pachetelor RTP primite. Sistemul final poate acționa ca una sau mai multe (dar de obicei doar una) surse de ceas în fiecare sesiune RTP
• Pachet RTCP - un pachet de control constând dintr-o parte antet fixă, similară antetelor pachetelor de informații despre protocolul RTP, urmată de elemente structurale, modificându-se în funcție de tipul de pachet RTCP. De obicei, mai multe pachete RTCP sunt trimise împreună ca un pachet RTCP compus într-un singur pachet de protocol subiacent; acest lucru este asigurat de un câmp de lungime în antetul fix al fiecărui pachet RTCP
• Pachet RTP - un bloc de date de protocol constând dintr-un antet RTP fix, o listă opțională goală de surse incluse, extensii și trafic.
• De obicei, un pachet de protocol de nivel inferior conține un pachet RTP, dar pot exista mai multe port este o abstractizare utilizată de protocoalele stratului de transport pentru a distinge mai multe destinații dintr-un singur computer gazdă. Un port este identificat prin numărul său. Astfel, numărul portului este un număr care identifică aplicația specifică către care sunt trimise datele. Acest număr, împreună cu informații despre ce protocol (de exemplu, TCP sau UDP) este utilizat la nivelul superior, este conținut printre alte informații de serviciu în datagramele trimise pe Internet. Selectoare de transport (TSEL - transport selector) utilizate de transport Nivelul OSI
• profil (profil) - un set de parametri ai protocoalelor RTP și RTCP pentru o clasă de aplicații, definind caracteristicile funcționării acestora. Profilul definește utilizarea câmpurilor de bit marcator și tip de trafic în antetul pachetului de date RTP, tipurile de trafic, extensiile antet pachetului de date RTP, primii 16 biți ai extensiei antet pachetului de date RTP, tipurile de pachete RTCP, intervalul de raportare RTCP, SR/ Extensia pachetelor RR, utilizarea pachetelor SDES, servicii și algoritmi pentru asigurarea securității comunicațiilor și caracteristicile utilizării protocolului de nivel inferior
• Sesiune RTP - comunicare între mai mulți participanți care interacționează prin protocolul RTP. Pentru fiecare participant, 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). Perechea de adrese de transport destinație poate fi comună tuturor participanților (ca în cazul IPM) sau poate fi diferită pentru fiecare (o adresă de rețea individuală și o pereche comună de porturi, ca în comunicarea bidirecțională). Într-o sesiune multimedia, fiecare tip de trafic este trimis într-o sesiune RTP separată cu propriile pachete RTCP. Sesiunile RTP de grup variază numere diferite perechi de porturi și/sau adrese de grup diferite
• Mijloacele non-RTP sunt protocoale și mecanisme care pot fi necesare în plus față de RTP pentru a furniza servicii acceptabile. În special pentru conferințele multimedia, aplicația de gestionare a conferințelor poate aloca adrese multicast și chei de criptare, poate negocia algoritmul de criptare de utilizat și poate defini mapări dinamice între valorile tipului de trafic RTP și formatele de trafic pe care le reprezintă (formate care nu au o valoare predefinită). ). tipul de trafic). Pentru aplicații simple poate fi de asemenea folosit e-mail sau baze de date pentru conferințe
• translator - un sistem intermediar care transmite pachete RTP fără a schimba identificatorul sursei de sincronizare. Exemple de traducători: dispozitive care efectuează transcodare fără amestecare, replicatoare multidirecționale sau bidirecționale, aplicații la nivel de aplicație în firewall-uri
• adresa de transport - o combinație de adresă de rețea și număr de port care identifică un punct final al stratului de transport, cum ar fi o adresă IP și un număr de port UDP. Pachetele sunt transmise de la adresa de transport sursă la adresa de transport destinație
• Trafic RTP - date multimedia transmise într-un pachet de protocol RTP, de exemplu, mostre audio sau date video comprimate
• PSTN - rețele publice de telefonie

Când noi, vorbind pe un telefon IP, auzim vocea interlocutorului pe receptor sau, folosind un sistem de videoconferință, comunicăm cu colegii și rudele noștri, schimbăm un flux continuu de date. Când transmiteți date în flux, cum ar fi voce și video, printr-o rețea de pachete, este foarte important să utilizați mecanisme care rezolvă următoarele probleme:

• Eliminarea efectului pierderii pachetelor
• Restabilirea ordinii și controlul sosirii pachetelor
• Efect de întârziere de netezire (jitter)

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

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

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

Pe partea de expediere, fiecare pachet este marcat cu un marcaj temporal, partea de recepție îl primește și determină întârzierea totală, după care se calculează diferența dintre întârzierile totale și se determină jitterul. Astfel, devine posibil să se stabilească o întârziere constantă pentru emiterea pachetelor și astfel să se reducă impactul fluctuației.

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

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

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

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

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

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

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

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. Avantajul indubitabil al telefoniei IP față de un telefon obișnuit este, de asemenea, capacitatea de a oferi servicii suplimentare prin utilizarea unui computer multimedia și a diverselor aplicații de Internet. Astfel, cu telefonia IP, companiile și persoanele fizice își pot extinde capacitățile de comunicații pentru a include videoconferințe avansate, partajarea aplicațiilor, instrumente de tip tablă și altele asemenea.

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

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

Pentru aplicațiile de conferințe audio și video, întârzierile de pachete au un impact mult mai mare asupra calității semnalului decât corupțiile individuale ale datelor. Diferențele de întârziere pot duce la pauze. Astfel de aplicații necesită un alt protocol de nivel de transport care asigură restabilirea secvenței inițiale de pachete, livrarea lor cu întârziere minimă, redare în timp real la momente precis specificate, recunoașterea tipului de trafic, comunicare de grup sau bidirecțională. Acest protocol este protocolul de transport în timp real RTP (Real-Time Transport Protocol). Acest protocol reglementează transferul de date multimedia în pachete prin IVS către strat de transportși este completat de protocolul de control al 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 despre telefonia IP notează că cele mai multe echipamente de rețea 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 și lucrul cu

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 destinatarului 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 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 vizați la teleconferință. Dacă este necesară confidențialitatea, informațiile și pachetele de control pot fi criptate așa cum este definit în Secțiunea 7.1, caz în care trebuie generată și distribuită și o cheie de criptare.

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

Pe Internet, ca și în alte rețele de date cu comutare de pachete, pachetele sunt uneori pierdute și reordonate și sunt întârziate pentru perioade diferite de timp. Pentru a contracara aceste evenimente, antetul RTP conține un marcaj de timp și un număr de secvență care le permite destinatarilor să resetați sincronizarea, astfel încât, de exemplu, porțiuni din semnalul audio să fie redate continuu de difuzor la fiecare 20 ms. Această reconstrucție 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 octeților, alinierea și formatul marcajului de timp

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

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

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

3. Protocol de transfer de date RTP

3.1. Câmpuri de antet fixe RTP

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

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

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

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

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

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

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

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

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

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

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

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 diverse tipuri

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

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

3.3. Se modifică antetul RTP definit de profil

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

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

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

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

Dacă se consideră că este nevoie de funcționalitate suplimentară în general pentru toate profilurile, atunci a noua versiune RTP de făcut schimbare constantă antet fix.

3.4. Extensie antet RTP

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

Dacă bitul X din antetul RTP este setat la unu, atunci o extensie de antet cu lungime variabilă este atașată antetului RTP fix (urmând lista CSRC, dacă există). Rețineți că această extensie de antet este doar pentru utilizare limitată. Extensia 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.

1999

2000

Formatul acestor 16 biți trebuie să fie determinat de specificația profilului cu care funcționează aplicațiile.

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

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

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

Schema de adrese IP

Schema de adresare a internetworking utilizată în protocolul IP este descrisă în RFC 990 și RFC 997. Se bazează pe separarea rețelelor de adresare de dispozitivele de adresare din aceste rețele. Această schemă face rutarea mai ușoară. În acest caz, adresele trebuie alocate într-o manieră ordonată (secvențial) pentru a face rutarea mai eficientă. Când se utilizează stiva de protocoale TCP/IP într-o rețea, dispozitivele finale primesc adrese unice. Astfel de dispozitive pot fi, servere de comunicații, routere etc. Cu toate acestea, unele dispozitive care au mai multe porturi fizice, cum ar fi routerele, trebuie să aibă o adresă unică pe fiecare port. Pe baza schemei de adresare și a faptului că unele dispozitive din rețea pot avea mai multe adrese, putem concluziona că această schemă de adresare nu descrie dispozitivul în sine în rețea, ci o conexiune specifică a acestui dispozitiv la rețea. Această schemă duce la o serie de inconveniente. Una dintre ele este necesitatea de a schimba adresa dispozitivului atunci când îl mutați într-o altă rețea. Un alt dezavantaj este că pentru a lucra cu un dispozitiv care are mai multe conexiuni într-o rețea distribuită, trebuie să cunoști toate adresele sale care identifică aceste conexiuni.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tabelul 6.9. Clasele de rețea

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

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

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

Tabelul 6.10. Intervalele de valori ale adresei

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

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

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

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

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

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

Tabelul 6.12. Destinatari ai datagramelor difuzate

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

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

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

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

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

Tabelul 6.13. Clasa D Alocarea adresei

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

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

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

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

Tabelul 6.14. Adrese rezervate clasa D

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

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

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

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

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

Protocolul TCP

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

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

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

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