Telefonie Prin Internet

Telefonie prin Internet

Voice over IP

Cuprins

Introducere…………………………………………………………………………………………………….. 3

Generalitati……………………………………………………………………………………………………. 3

1. Transportul de voce in retele IP ………………………………………………………………….4

1.1. Arhitectura voip………………………………………………………………………………………….

1.2. Modelul TCP/IP………………………………………………………………………………………….

1.3. Voip si TCP/IP……………………………………………………………………………………………

1.4. Protocoale reale time pentru aplicatii voip…………………………………………………….

1.4.1. RTP (RFC 1889)………………………………………………………………………………………

1.4.2. RTCP (RFC 1889)…………………………………………………………………………………….

1.4.3. RTSP (RFC 2326)…………………………………………………………………………………….

2. Protocoale Voip……………………………………………………………………………………………

2.1. H 323…………………………………………………………………………………………………………

2.2. SIP……………………………………………………………………………………………………………..

2.3. Compartie H323 si SIP…………………………………………………………………………………

3. Calitate Servici Voip……………………………………………………………………………………..

4. Aplicatie……………………………………………………………………………………………………….

Concluzii………………………………………………………………………………………………………….

Bibliografie……………………………………………………………………………………………………….

Introducere

Generalitati

Voice over IP (VoIP) sau telefonia prin Internet este fără îndoială, un instrument de comunicare puternic și inovator bazat pe tehnologia care-i permite trasmiterea de voce si de date printr-o singura retea folosind un standard universal, Internet Protocol (IP) .

Astfel se nasc combinatii intre retelele de telefonie clasice (PSTN) si VoIP existand posibilitatea ca utilizatorii de servicii voip sa comunice nu doar intre ei dar cat si cu utilizatori din retele clasice, fixe si mobile.

Prelucrarea semnalului vocal, digitalizarea vocii este procesul prin care semnalul vocal analogic este transformat într-o serie de numere care pot fi trimise pe o linie de comunicație și care pot fi folosite pentru a reconstrui semnalul vocal analogic la destinație.

Digitalizarea vocii rezolvă prima problemă a telefoniei analogice deoarece se poate transmite foarte usor o valoare numerică oricât de lungă ar fi calea, fără a fi degradată și fără să aibă zgomot. Multiplexarea în timp (TDM) rezolvă de asemenea și a doua problemă a telefoniei analogice. TDM permite rețelelor de voce să transporte multiple convorbiri în același timp pe un singur cablu cu patru fire. Deoarece convorbirile au fost digitalizate, valorile numerice sunt trimise în canale de timp. Deși tehnologia digitală rezolvă problema degradării semnalului și mutiplexării mai multor convorbiri pe aceeași linie, aceasta aduce o noua problemă: semnalizarea. În circuitele analogice, semnalele de supervizare erau transmise prin conectarea celor două fire ale cablului telefonic. Compania de telefonie generează semnale de adresare și informaționale prin intermediul unor frecvențe specifice. Rezolvând cele două probleme ale telefoniei analogice, tehnologia digitală a eliminat și posibilitatea de semnalizare semnalizare era transmisă utilizând aceeași bandă ca și vocea, prin "furarea" unor biți necesari comunicației vocale.

Transportul de voce in retele IP

1.1. Modelul TCP/IP

Multe personae sunt incantate de idea ca modalitatea clasica de a efectua apeluri telefonice poate fi inlocuita de o tehologie care in esenta functioneaza pe o retea de calculatoare. De aseemnea, sunt intrigati de multitudinea de optiuni interesante ce vin impreuna cu VOIP. In orice caz oamenii inca isi pun intrebari referitor la modalitatea in care VOIP functioneaza si sunt oarecum suspiciosi in privinta capabilitatii VOIP de a face fata tuturor cererilor.

Raspnsul poate fi gasit in acealasi model care sta la baza retelelor simple de date de la inceputul internetului de acum mai bine de 25 de ani: modelul TCP/IP.

Modelul functioneaza pe baza a 5 nivele (layers), TCP/IP este adaptat sa activeze si sa sutina VOIP, TCP/IP s-a dovedit a fi efficient cu “impachetarea” telefoniei asa cum a fost atatia ani cu impachetarea datelor informatice.

Pentru a intelege pe deplin Voip, este important sa intelegem bazele tehnice care il fac sa functioneaze intr-o retea. Mai departe voi descrie nivelele (layers) modelului TCP/IP in relatie cu retelele de calculatoare. TCP/IP este primul si cel mai important grup de protocoale de retea. Protocoalele sunt regulile care guverneaza modalitatea prin care traficul dintr-o retea este impachetat pentru a fi transmis catre o alta. Unele protocoale TCP/IP sunt utilizate strict pentru date, altele exclusive pentru telefonia VOIP, iar altele sunt folosite in ambele scopuri.

TCP asigura livrarea in siguranta fara erori a pachetelor de date. Cand sunt transmise pachete de date multiple se asigura ca toate ajung la destinatie si sunt presentate in ordinea corecta catre aplicatie. UDP este un protocol mai simplu care vizeza in principiu trnazactiile singular, unde un pachet este trimis iar alt raspuns este primit. Nu include secvente si functiuni de retransmisie. Deasupra TCP si UDP gasim diferite aplicatii si servicii, aplicatia sau serviciu in sine determina daca va fi utilizat TCP sau UDP. Avand in vedere aceste aspect figura 2-4 evidentiaza cum apare un pachet IP cand este transmis dintr-un nod de retea in alta. Datele aplicatiei sunt transferate ma jos catre nivelul de transport

Stuctura Pachet Figura 1

Fiecare protocol corespunde unuia dintre cele 5 nivele (layers) care alcatuiesc modelul TCP/IP:

Application: exista protocoale speciale la acest nivel care asigura calitatea si livrarea pachetelor VOIP

Transport: User Datagram Protocol (UDP) la acest nivel se asigura transportul pachetelor Voip de la initiere pana la terminare, adica de la apelant pana la aplelat si invers

Internetwork: la acest nivel adresa IP este adugata pachetului. Fiecare telefon Voip sau calculator actioneaza ca un telefon Voip v-a primi o adresa IP unica care ruteaza pachetele voip intre apelant si apelat si vice versa.

Network interface: La acest nivel adresa MAC este adaugata pachetului. Adresa MAC este oferita de NIC cerut de toate componentele retelei.

Physical: La acest nivel toate pachetele sunt convertite in semnale electro sau electo-optice pentru a fi transmise prin reteaua locala sau externa.

Fiecare nivel (layer) este asociat cu unul sau mai multe protocoale. Un pachet trebuie sa traverseze toate cele 5 nivele, de fiecare data cand un pachet este trimis si din nou cand un pachet este primit. In principiu pachetele Voip pleaca impreuna cu apelul initiat. Pachetul traverseaza in jos cele 5 nivele din reteaua apelantului si sunt impachetate cu protocoalele corecte, aferente fiecaru nivel. Cand pachetul a ajuns la ultimul nivel, nevelul fizic, este trimis prin retea catre destinatie. Cand pachetul ajunge la destinatie urca pe acelaesi nivele in reteaua celui care receptioneaza mesajul, fiind de data aceasat despachetat la fiecare nivel. Cand ajunge la nivelul aplicatiei, pachetul este tradus intr-un semnal vocal pe care destinatarul il aude.

1.2. VoIP si TCP/IP

Diferenta intre implementarea VoIP si TCP IP este la nivel de straturi. In timpul unui apel de tip voip cerea de la nivel de aplicatie utilizeaza urmatoarele trei tipuri de protocoale

NTP: Network Time Protocol Acest protocol permite sincronizarea si asigura faptul ca semnalele sunt trimise si primite intr-un interval de timp pentru a asigura calitatea.

RTP: Real Time Protocol. Acest protocol oferea functii end-to-end de transport in retea pentru semanle vocale digitale incapsulate in pachetul VOIP

RTCP: Real-time transport control protocol. Acest protocol monitorizeaza livrarea mesajului vocal si ofera un minim control al functiilor necesare pentru livrarea pachetelor.

Figura 2

TCP are o viteza mai mica decat UDP, dar ofera o garantie a livrarii pachetelor. Viteza este masurat ain nanosecunde. Desi timpul de livrare a pachetelor catre destinatie este mai mare, si TCP asigura livrarea.

Pentru ca vocea este o aplicatie real-time, este mult mai important ca pachetele de voce sa ajunga la destinatie cat se poate de repede. De aceea UDP este de departe favorit pentru a asigura nivelul de transport pentru retelele Voip.

1.4. Protocoale reale time pentru aplicatii voip

Retelele de calculatoare furnizeaza diferite servicii de retea si aplicatii diverse.

Pe langa trasferul de date, un rol aparte in retele il au aplicatiile in timp real, cu transmisii vocale, audio sau video, pe baza protocolelor in real time.

1.4.1. RTP (Real Time Protocol)

Scopul acestui protocol este de a oferi servicii cerute de conferințele multimedia interactive, ca sincronizare a redării informațiilor primite, de multiplexare, identificarea tipului de mediu folosit pentru transmisie și identificarea participanților activi. Totuși, nu numai aplicațiile pentru conferințe multimedia pot beneficia de RTP, ci și stocarea de date continue, distribuția interactivă de date cu formate multimedia, simulări realizate în paralel pe mai multe terminale și aplicațiile de măsură și control pot profita de avantajele aduse de RTP. Scopul proiectării RTP a fost obținerea unui protocol cu următoarele caracteristici:

Flexibil. RTP nu trebuie să fie limitat numai pentru conferințe audio și video;

Extensibil. RTP trebuie să permită implementarea de noi servicii;

Independent față de protocoalele inferioare. RTP ar trebui să lucreze cu UDP, TCP, ATM și altele;

Capabil să combine mai multe fluxuri media într-unul singur și să-l transmită cu alt tip de codare;

Eficient din punct de vedere al benzii. Dimensiunea antetului în cazul pachetelor mici de voce poate fi chiar cât dimensiunea informațiilor propriu-zise. De exemplu pentru pachetele ce conțin 65ms de voce codată de o procedură ce oferă 4800bit/s dimensiunea informației transportate este 39 de octeți. Ipv4 introduce 20 de octeți în antet, UDP[3] încă 8 octeți și nivelul de transport alți cel puțin 8 octeți. Cu antetul RTP de 4 – 8 octeți dimensiunea antetului totală poate ajunge la 40 – 44 de octeți. Acest fapt poate sta în calea folosirii RTP pe conexiuni de mică viteză.

Internațional. Protocolul trebuie să includă codări de tipul legea A, legea μ dar și seturi de caractere non ASCII.

Eficient din punct de vedere al procesării. Și cele mai mari intervale de timp conținute în pachete creează o rată de 40 de pachete pe secundă pentru un singur canal de voce. La acesta valoare procesarea pachetelor poate deveni o problemă.

Implementabil imediat. Protocolul poate să nu aibă o viață îndelungată și de aceea trebuie să fie posibil să fie implementat având la dispoziție software-ul și hardware-ul curent.

Protocolul pentru transportul în timp real (RTP) a fost proiectat pentru a permite receptoarelor compensarea problemelor cauzate de jitter și sosirea într-o altă ordine a pachetelor decât cea în care au fost transmise. RTP poate fi folosit pentru orice flux de date în timp real, de exemplu pentru voce și pentru video. RTP include o modalitate de a identifica pachetele IP ce transportă informații izocrone prin următoarele informați incluse în antet:

Informații referitoare la tipul datelor transportate;

Informații referitoare la tipul la care au fost emise (timestamps);

Numere de secvență.

Pachetul RTP conține întotdeauna toate câmpurile până la lista CSRC. Această listă există numai după ce pachetul trece de un mixer. Câmpurile sunt:

2 biți sunt rezervați pentru versiunea folosită de RTP.

Un bit ce indică adăugarea de biți în plus din considerente de aliniere. Dacă pachetul a fost modificat (P=1), atunci ultimul octet al câmpului de indică tipul datelor transportate indică mai precis câți octeți au fost adăugați.

Câmpul de 4 biți CC indică numărul de CSRC-uri ce urmează după antetul fix.

Bit de marcaj (M). Interpretarea acestui bit este definită de un alt document ce vine odată cu aplicația folosită și numit profil RTP. A fost pus cu intenția pentru a permite semnalizarea unor evenimente importante cum ar fi marginile unui cadru în fluxul de pachete. Acel document ar putea defini și alți biți de marcaj sau specifica că nu există bit de marcaj prin modificarea numărului de biți din câmpul tipul informației transportate (sarcini).

Tipul informației transportate(PT). Are 7 biți și identifică forma informației transportate și determină interpretarea acesteia de către aplicație. Documentul amintit mai sus specifică o corespondență statică între coduri de identificare a tipului informației și diferite formate de date. În plus se pot defini alte corespondențe dinamice prin mijloace non-RTP. Un emitor RTP trimite un singur identificator de sarcină la un moment dat; acest câmp nu este destinat pentru multiplexarea a unor fluxuri media diferite. Figura I.3 prezintă o parte din identificatori statici.

Identificatori statici Fig

Numărul de secvență (16 biți). Numărul de secvență este incrementat pentru fiecare pachet RTP trimis și poate fi folosit de receptor pentru a detecta pierderea pachetelor și a reface ordinea pachetelor. Valoarea inițială a numărului este aleatorie pentru a face atacurile asupra fluxurilor codate mai dificile

Figura I.4 Pachetul RTP

1.4.2. RTCP (Real time control protocol)

Protocolul pentru controlul RTP-ului este bazat pe transmisia periodică a pachetelor de control către toți participanții unei sesiuni particulare. Pachetele de control sunt distribuite în același mod ca și pachetele de date. Fiecare pachet RTCP include un raport al transmițătorului și/sau un raport al receptorului care prezintă statistici cum ar fi numărul de pachete trimise, numărul de pachete pierdute, jitterul, întârzierea fată de ultimul raport, timpul de emisie al ultimului raport, etc, utile pentru aplicațiilor. RTCP are patru funcții separate:

Funcția principală este de a furniza feedback cu privire la calitatea distribuției de date. Informațiile primite prin această cale putând fi folosite la controlul unei codări adaptive (codec adaptiv). Experimentele folosind multiplexarea IP au arătat că feedback-ul este critic pentru diagnosticul greșelilor în distribuție. Această funcție este realizată prin folosirea a două rapoarte: raportul transmițătorului și raportul receptorului.

RTCP identifică toți participanți unei sesiuni. Acest protocol face acest lucru prin transportul unui identificator de nivel transport al fiecărei surse numit nume canonic (CNAME) („canonical name”) și al unui identificator de sursă de sincronizare (SSRC). SSRC-ul se poate schimba într-o sesiune. Identificatorul CNAME este de asemenea folosit pentru sincronizarea fluxurilor multimedia multiple. Când un participant părăsește conferința este trimis un pachet RTCP BYE.

Pachetele protocolului sunt trimise pentru a îndeplini primele două funcții, de aceea rata cu care sunt trimise pachetele este de asemenea controlată. Acest control al ratei este realizat de RTCP. Numărul de participanți observat este folosit pentru determinarea valorii acestei rate. Cu cât numărul participanților este mai mare cu atât rata cu care se trimite pachete de către fiecare participant este mai mică.

A patra funcție (opțională) este de a transporta minimum de informație de control a sesiunii, pentru, ca exemplu, să se poată face identificarea participanților în interfața grafică.

Toți participanții trebuie să trimită pachete RTCP, fapt ce poate crea probleme pentru conferințele pe bază de multicast de mari dimensiuni deoarece traficul RTCP va crește liniar cu creșterea numărului de participanți. Această problemă nu există cu fluxurile RTP în conferințele audio ce folosesc suprimarea pauzelor, deoarece oameni nu vorbesc de regulă în același timp.

Deoarece numărul de participanți este cunoscut tuturor ce ascultă rapoartele RTCP, fiecare din aceștia își poate controla rata cu care trimite aceste rapoarte. Acest fapt este folosit pentru a limita banda folosite de RTCP la o valoare rezonabilă, de obicei nu mai mult de 5% din banda alocată sesiunii. Această bandă trebuie împărțită de toți participanții. În „standarde” se stipulează că transmițătorilor activi le revine un sfert din această bandă deoarece informațiile conținute în rapoartele transmițătorilor sunt foarte importante pentru receptori. Cea ce rămâne se împarte între receptori.

Chiar și pentru cele mai mici sesiuni, cea mai mare rată cu care se poate transmite, de către un participant, un raport RTCP este unul la fiecare 5 secunde. Rata cu care se transmite este aleatorizată cu un factor de 0,5 până la 1,5 pentru a nu se crea sincronizări nedorite între rapoarte. Valoarea medie a ratei este derivată, de fiecare participant, din mărimea pachetului pe care vrea să-l trimită și din numărul de transmițători și receptori din pachetele pe care le primește.

Sunt mai multe tipuri de pachete RTCP, unul pentru fiecare tip de informație:

SR: reprezintă raportul transmițătorului și conține informațiile de transmisie și recepție despre transmițătorii activi;

RR: reprezintă raportul receptorului și conține informațiile despre ascultătorii ce nu sunt și transmițători activi;

SDES: reprezintă descrierea sursei și conține numeroși parametrii referitori la sursă, incluzând și CNAME;

BYE: reprezintă raportul trimis atunci când un participant părăsește conferință;

APP: prezintă funcțiile specifice unei aplicații.

Câteva pachete RTCP pot fi incluse într-un singur pachet al protocolului de transport. Fiecare mesaj RTCP conține destule informații pentru a fi decodat fără probleme dacă mai multe asemenea mesaje sunt încapsulate în același pachet UDP. Acest mod de folosire este folositor pentru a transmite eficient informația, ținând cont de dimensiunile antetului protocolului de transport.

Fiecare SR („sender report”) conține trei secțiuni obligatori.

Prima secțiune conține:

5 biți pentru numărul de rapoarte conținute în acest raport;

tipul pachetului, care în cazul SR-ului este 200;

lungimea acestui raport pe 16 biți și numărul de biți introduși ca umplutură pe 32 de biți;

SSRC-ul transmițătorului acestui raport. Acest identificator se va regăsi și în pachetele RTP ce pleacă de la acesta.

A doua secțiune conține informațiile despre fluxul RTP ce este trimis de acest transmițător:

informația de timp ce conține data la care a fost trimis acest raport. Aceasta poate să fie absolută sau relativă fată de momentul începerii sesiunii.

informația de timp RTP ce reprezintă același lucru ca mai sus dar folosind regulile de la pachetele RTP;

numărul de pachete trimise de acest transmițător de la începutul sesiunii pe 16 biți. Este resetat dacă SSRC-ul este schimbat;

numărul de octeți de date ce au fost trimise de la începutul sesiunii. Acesta este deasemenea resetat când se schimbă SSRC-ul.

Cea de-a treia secțiune conține un set de fragmente ale raportului de recepție, unul pentru fiecare sursă de care a auzit de când a trimis ultimul SR sau RR. Fiecare are același format. Acestea conțin:

SSRC (identificatorul sursei): 32 de biți – identificatorul sursei despre care se face raportul;

rata pierderilor: 8 biți – valoarea rotunjită a raportului (pachete primite/pachete pierdute*256);

numărul total al pachetelor pierdute (24 biți) de la începutul recepției. Pachetele întârziate nu sunt numărate ca pierdute iar pachetele duplicate sunt numărate ca primite;

cel mai mare număr de secvență primit, variantă extinsă: (32 biți). Cei mai importanți 16 biți conțin numărul de cicluri ale numărului de secvență iar ultimi 16 biți conțin cel mai mare număr de secvență primit într-un pachet RTP de la sursa indicată în primul câmp;

jitterul: 32 de biți. O estimare a variației a timpului scurs între sosirile pachetelor RTP, măsurată în unități în care se măsoară și informația de timp și exprimată ca un număr întreg fără semn. Jitterul J este definit ca deviația medie a diferenței între distanțele în timp de la receptor față de cele la transmițător pentru o pachete consecutive. Așa cum este arătat în relația de mai jos, definiția este echivalentă cu diferența timpului de propagare relativ pentru cele două pachete; timpul de propagare relativ este diferența între informația de timp înscrisă în pachetul RTP și timpul indicat de ceasul receptorului atunci la momentul sosirii pachetului, măsurate în același unități. Dacă Si reprezintă informația de timp purtată de pachetul i și Ri este timpul de sosire al acestuia, atunci pentru cele două pachete i și j, D poate fi exprimată ca: D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si). Jitterul este calculat în mod continuu la fiecare sosire a unui pachet i de la sursa SSRC_n, folosind această diferență D pentru acest pachet și pentru pachetul i-1 în ordinea sosirii (nu neapărat în secvență), conform formulei: J=J+(|D(i-1,i)|-J)/16. Când se emite un raport, valoarea curentă a lui J este preluată.

informația de timp conținută de ultimul raport al sursei (LSR): 32 de biți. Se folosesc cei 32 de biți din mijlocul informației de timp conținută de ultimul raport primit din partea unei surse (această formă se numește forma compactă).

întârzierea față de momentul când s-a primit ultimul raport SR (DLSR): 32 de biți. Exprimat în forma compactă (mai simplu în multipli de 1/65536s). Împreună cu LSR transmițătorul acestui ultim SR poate folosi această informație pentru a calcula timpul dus-întors.

Raportul receptorului arată ca raportul transmițătorului, cu diferențele că valoarea câmpului ce indică tipul informației transportate (PT) este egală cu 201 și secțiunea a doua lipsește. Acest raport poate fi folosit de receptorii pasivi care nu generează fluxuri de RTP.

Figura I.5 Raportul transmițătorului

1.4.3. RTSP (Real Time Streaming Protocol – RFC 2326).

Protocolul pentru fluxurile în timp real sau RTSP este un protocol de nivel aplicație pentru controlul livrării datelor cu proprietăți de timp real. RTSP furnizează o bază extensibilă pentru a permite transportul controlat, la cerere, al datelor de timp real, cum ar fi cele audio și video. Sursele de date pot fi atât aparatele ce captează în momentul transmisiei că și date stocate. Acest protocol este proiectat pentru a controla multiple sesiuni de transfer de date, pentru a furniza mijloacele prin care se alege canalele de transport, cum ar fi UDP, multicast UDP sau TCP și pentru a furniza mijloacele pentru alegerea mecanismelor de transport bazate pe RTP.

RTSP stabilește și controlează unul sau mai multe fluxuri sincronizate de date continue cum ar fi audio sau video. În mod normal nu transportă el însuși aceste fluxuri, cu toate că interpunerea fluxurilor media cu fluxul de control este posibilă. Cu alte cuvinte, RTSP propune un control la distanță prin rețea al serverelor multimedia.

Fluxurile controlate de RTSP pot folosi RTP, dar modul de funcționare al protocolului prezentat nu depinde de mecanismul de transport folosit pentru a duce datele în timp real. Protocolul este intenționat asemănător în sintaxă și mod de operare cu HTTP versiunea 1.1. HTTP adică Hypertext Transfer Protocol este un protocol de nivel aplicație pentru sistemele aflate la distanță și care comunică între ele. Este un protocol generic, fără stări. Acesta a fost folosit de către inițiativa globală informatică „World Wide Web” încă din 1990. Prima versiune HTTP/0.9 a fost un simplu protocol pentru transferul datelor neprelucrate prin Internet. Versiunea 1.0, cum a fost definită în RFC-ul 1495, a îmbunătățit protocolul prin faptul că a permis mesajelor să aibă un format asemănător cu formatul MIME (Multipurpose Internet Mail Extensions), mesaje ce conțineau informații despre datele transportate și modificatori ai semanticii mesajelor de cerere și răspuns.

Versiunea 1.1 include cerințe mai dure decât versiunea anterioară cu scopul de a furniza implementări sigure a caracteristicilor acestui protocol. HTTP asigură un set de metode și antete ce indică scopul unei cereri. Acesta este construit pe disciplina referințelor furnizate de „Uniform Resource Identifier”(URI), ca locație URL sau ca nume URN, pentru a indica resursa pentru care se va aplica metoda. Mesajele sunt trimise într-un format similar cu cel folosit în sistemele de poștă electronică din Internet definit în documentul „Multipurpose Internet Mail Extensions” (MIME). HTTP este de altfel folosit și ca protocol de comunicație între agentul utilizatorului (aplicația care rulează la cererea utilizatorului), gateway-uri sau proxy-uri și alte sisteme din Internet, incluzând și pe acelea ce suportă protocoalele FTP și SMTP. În acest mod HTTP

Protocolul RTSP se diferențiază de HTTP/1.1 prin următoarele aspecte:

introduce un număr de noi metode și are un identificator de protocol diferit;

un server RTSP trebuie să mențină o stare în toate cazurile, spre deosebire de natura fără stări a HTTP-ului.

și clientul și serverul pot emite cereri.

datele sunt transportate de către un alt protocol.

setul de caractere folosite în compunerea mesajelor este altul.

identificatorul resursei URI este în cadrul unei cereri întotdeauna absolut.

Aceste modificări duc la implementarea mai ușoară a unor situații în care există mai multe ierarhii de directoare pe o singură gazdă cu o singură adresă IP.

Protocolul permite următoarele operații:

– obținerea de informații de la un server. Clientul poate cere o descriere a prezentărilor prin HTTP sau altă metodă. Dacă prezentarea este trimisă în mod multicast atunci descrierea conține adresa de multicast și porturile utilizate pentru fluxurile media. Dacă doar acest client este vizat de prezentare, adică numai el va primi fluxurile media prin unicast atunci clientul va oferi destinația din motive de securitate.

– invitarea unui server media la o conferință. Un server media poate fi invitat la o conferință, fie pentru a reda fișiere multimedia, fie pentru a înregistra toată sau o parte din conferință. Această operație este foarte utilă pentru aplicațiile de învățământ la distanță.

– informarea utilizatorilor despre tipurile de date în timp real disponibile pentru o prezentare existentă deja. În special pentru prezentările în timp real, este util să se informeze pe cei care participă de către server ce tipuri de date în timp real au devenit disponibile.

Sunt necesare câteva precizări:

Prezentarea. Reprezintă unul sau mai multe fluxuri prezentate de către server clienților ca o transmisiune multimedia completă, folosind descrierea prezentării care este definită mai jos. În cele mai multe cazuri în contextul RTSP, aceasta implică controlul asupra acelor fluxuri, dar nu întotdeauna este așa.

Descrierea prezentării. O descriere a unei prezentări conține informații asupra unuia sau mai multe fluxuri media din cadrul prezentării, cum ar fi setul de codecuri folosit, adresele folosite și informații despre conținut. În alte protocoale propuse de IETF ca SDP (Session Description Protocol) folosesc termenul de sesiune pentru o prezentare în timp real. Descrierea prezentării poate avea mai multe formate, incluzând dar nu numai formatul SDP.

Flux media. Reprezintă un singur flux de date ce pot fi audio, video sau datele provenite de la un „whiteboard”. Când se folosește RTP, un flux conține toate pachetele RTP și RTCP create de o sursă într-o sesiune RTP.

Mesaj. Este unitatea de bază în comunicația RTSP.

Entitate. Reprezintă informația transferată în cadrul unui răspuns sau cereri.

Sesiunea RTSP. Reprezintă o tranzacție completă RTSP, cum ar fi vizionarea unui film. O sesiune constă de obicei în crearea de către client a unui mecanism de transport pentru fluxul media, pornirea redării și închiderea fluxului.

Protocolul RTSP are următoarele proprietăți:

Extensibil. Metode și parametri noi pot fi foarte ușor adăugați la acest protocol;

Ușor de analizat. RTSP poate analizat de către analizoarele standard HTTP sau MIME;

Sigur. RTSP reutilizează mecanismele rețelei de securitate. Toate mecanismele de autentificare folosite în HTTP sunt direct aplicabile. Se pot folosi și mecanismele de securitate ale nivelurilor transport și rețea;

Independent de modul de transport. RTSP poate folosi protocolul cu datagrame nesigur UDP sau protocolul sigur pe bază de fluxuri ca RTP.

Capabil de lucrul cu mai multe servere. Fiecare flux media dintr-o prezentare poate fi stocat pe diferite servere. Clientul în mod automat stabilește mai multe sesiuni de control concurente cu severele ce conțin fișierele media. Sincronizarea se face la nivelul transport;

Controlează aparatele ce fac înregistrarea. Protocolul poate controla atât aparatele ce fac înregistrarea sau redarea fișierelor media cât și a aparatelor ce fac aceste funcți în mod alternativ;

Separă controlul fluxului de inițializarea conferinței. Controlul fluxului este separat de invitarea la conferință a server-elor. Singura cerință în acest caz este ca protocolul ce inițiază conferință să furnizeze sau utilizat pentru a crea un identificator pentru conferință. În particular SIP sau H.323 pot fi utilizați pentru invitarea unui server la o conferință. Prin server se înțelege orice sistem ce dorește sau este solicitat să trimită date în timp real.

Potrivit pentru aplicațiile profesionale. RTSP furnizează o acuratețe mare, la nivelul cadrelor ce permite editarea la distanță;

Neutru din punct de vedere al descrierii prezentării. Protocolul nu impune un format de descriere și poate comunica tipul descrierii ce va fi folosit. Totuși, descrierea trebuie să aibă cel puțin un identificator al resursei adică un URI;

Permite folosirea sistemelor firewall și proxy. Protocolul poate fi manevrat cu ușurință atât de sistemele firewall la nivel aplicație cât și de cele la nivel transport. Un astfel de sistem trebuie să înțeleagă metoda SETUP pentru a deschide un canal de comunicație pentru fluxul media de pe UDP;

Folosește HTTP. Acolo unde este nevoie, RTSP reutilizează conceptele HTTP pentru ca infrastructura existentă să nu fie modificată;

Permite controlul rezonabil al server-ului. Dacă un client poate să pornească un flux de date, atunci el trebuie să aibă capacitatea și să oprească fluxul. Server-ele nu trebuie să pornească trimiterea unui flux într-un asemenea mod încât clientul să nu poată să oprească acel flux;

Permite negocierea metodei de transport. Clientul poate negocia metoda de transport înainte de a fi nevoit să proceseze un flux de date în timp real;

Permite negocierea capacităților. Dacă caracteristicile de bază nu sunt disponibile, trebuie să existe un mecanism pentru ca clientul să determine ce metode nu vor fi implementate. Aceasta permite clienților să afișeze interfața grafică corespunzătoare. De exemplu, dacă sărirea unor porțiuni din film nu este permisă, atunci interfața grafică trebuie să fie în stare să împiedice mișcarea indicatorului de poziție în timp al filmului.

Fiecare prezentare și flux media poate fi identificată de un URL. Prezentarea în sine și proprietățile fluxurilor din care aceasta este formată sunt definite de un document ce conține descrierea prezentării. Acest document poate fi obținut de către client folosind HTTP sau alte mijloace cum ar fi poșta electronică și nu este obligatorul să fie stocat pe serverul media. În general acest document trebuie să conțină descrierea mediilor ce formează prezentarea, incluzând și codecurile folosite, limbajul și alți parametri care permit clientului să aleagă cea mai potrivită combinație. În această descriere a prezentării fiecare flux media controlat de RTSP este identificat printr-un URL al protocolului RTSP, care indică spre server-ul ce prelucrează acel flux și poartă numele ori a fluxului ori a server-ului. Mai multe fluxuri media pot fi localizate pe servere diferite; de exemplu, fluxurile audio și video pot fi împărțite pe mai multe server-e pentru ca încărcarea acestora să fie echitabilă. Descrierea enumeră și ce metode de transport poate folosi un server.