Rtp Si Internetul
Cuprins
Cuprins
Capitolul I
RTP și Internetul
1.1. O scurtă istorie a RTP
1.2. Stiva de protocoale Internet și Multimedia.
1.2.1. Nivelul Fizic
1.2.2. Nivelul Internet
1.2.3. Nivelul Transport
1.2.3.1. TCP
1.2.3.2. UDP
1.2.3.3. TLS
1.2.3.4. SCTP
1.2.4. Nivelul Aplicație
1.3. Aplicații
1.4. DNS și adresele IP
1.5. URL-uri si URI-uri
1.6. Multicast
Capitolul II
Protocoalele de transport pentru aplicații în timp real
2.1. Domenii de utilizare a RTP-ului
2.1.1. Conferințe audio tip multicast
2.1.2. Conferințe audio și video
2.1.3. Multiplexoare și Translatoare
2.1.4. Codări stratificate
2.2. Noțiuni generale / definiții
2.3. RTP – Protocolul de transfer de date
2.3.1. Dezvoltare
2.3.2. Cum funcționează RTP
2.3.3. Structura pachetului
2.4. RTCP – Protocolul de control în timp real
2.5. Caracteristicile RTP-ului
2.6. Resursele de implementare RTP
2.7. Modificări aduse antetului RTP
2.7.1. Extensia antetului RTP
Capitolul III
Profilul pentru conferințe audio și video cu control minim
3.1. Introducere
3.2. RTP și RTCP – Formatul pachetelor și comportamentul protocolului
3.3. Audio
3.3.1 Regulile codării independente
3.3.2. Recomandari pentru codările audio bazate pe eșantionare
3.3.3. Recomandări pentru codările audio bazate pe cadre
3.3.4. Codecuri audio
3.4. Video
3.5. Definițiile tipurilor de payload
Capitolul IV
Next Generation Network (NGN)
4.1. Structura NGN
4.2. Avantajele NGN
4.3. Tranziția spre NGN
4.4. Calitatea serviciului (QoS)
4.5. Securitatea în NGN
4.5.1 Arhitectura de securitate în NGN
Capitolul V
Aspecte practice ale unei transmisii streaming
5.1. Echipamente necesare
5.2. Servere de streaming
5.2.1. Soluții comerciale
5.2.2. Soluții Open Source
5.3. VLC
5.3.1 Generalități
5.3.2. Codec/container
5.3.3 Particularități MPEG
5.4. Streaming utilizând linia de comandă
5.5. Instalarea și configurarea serverului VLC
5.6. Analizoare de trafic de rețea
5.7. Wireshark
Concluzii
BIBLIOGRAFIE:
Introducere
Rețelele de calculatoare au fost proiectate să conecteze computere din diferite locații pentru a putea împărtăși datele și pentru a comunica. În urmă, majoritatea informațiilor transportate prin rețele au fost sub formã de text. Astăzi, cu evoluția tehnologiilor multimedia dar și celor de rețea, multimedia a ajuns o caracteristică indispensabilă a Internetului. Animația, vocea, clipurile video, toate acestea au devenit din ce în ce mai populare pe Internet. Produsele multimedia ca telefonia pe Internet, TV pe Internet, conferințele video, au apărut pe piață.
Rețelele multimedia vor impulsiona utilizarea calculatorului ca instrument de comunicare. Eu cred că într-o zi, rețelele mutimedia vor înlocui seviciul de telefonie, televiziunea și alte invenții care ne-au schimbat radical viața.
1. Provocarea “real-time”[4]
Ne puteam aștepta la cel puțin trei probleme, în primul rând comparând cu aplicațiile tradiționale sub formă de text, aplicațiile multimedia necesită lățime de bandă mult mai mare. De exemplu un segment dintr-un filmuleț, cu rezoluția de 320×240, de 25 secunde, poate solicita pâna la 2.3 MB, și este echivalentul la aproximativ 1000 de screens (ecrane) de date sub formă de text. Acest lucru era de neimaginat în trecut, când numai informațiile sub formă de text erau transmise pe rețea.
În al doilea rând, majoritatea aplicațiilor multimedia necesită traficul în timp real. Datele audio și video trebuie redate continuu, la rata la care sunt eșantionate. Dacă datele nu ajung la timp, procesul de redare va înceta, iar utilizatorul va sesiza acest lucru. În cazul telefoniei pe Internet, omul poate tolera o latență de aproximativ 250 milisecunde. Dacă întârzierea va depăși această limită, vocea va suna ciudat, iar utilizatorii se vor plânge legat de calitatea apelului. De asemenea congestiile din rețele, au un efect destul de grav asupra traficului în timp real. Dacă rețeaua este congestionată, singurul efect în rețelele fară trafic în timp real, este că durează mai mult timp până când se termină transferul de date, în schimb datele în timp real devin « învechite » și vor fi «aruncate » dacă nu ajung la timp. Dacă nu se ia nici o măsură adecvată, retransmiterea pachetelor pierdute ar agrava și mai mult situația și ar bloca rețeaua.
În al treilea rând, fluxurile de date mutimedia sunt de obicei transmise în rafale. Doar creșterea lățimii de bandă nu va rezolva această problemă. Pentru majoritatea aplicațiilor multimedia, receptorul are o memorie tampon limitată. Dacă nu se i-a nici o măsură pentru a regulariza fluxul de date, atunci memoria tampon, ar putea deveni sau neîncăpătoare, sau neocupată. Când informațiile ajung prea repede, memoria va fi neîncăpătoare, și unele pachete de date vor fi pierdute, rezultând o calitate slabă. Când informațiile ajung prea încet, memoria va fi prea neocupată, iar aplicația va fi lipsită de informații.
Spre deosebire de lățimea de bandă mare, trafic de date în timp real și în rafale, în viața reală, rețele sunt împărțite de mii și milioane de utilizatori, și au banda limitată și întârzieri imprevizibile. Cum să rezolve aceste conflicte este o provocare la care rețelele multimedia trebuie să facă față.
Posibilitatea de a răspunde la această provocare vine de la arhitectura software a rețelei existente, și de la hardware-ul în curs de dezvoltare. Bazele Interentului, TCP/IP și UDP/IP, oferă o gamă de servicii pe care aplicațiile multimedia le pot folosi. Rețele rapide, cum ar fi Gigabit Ethernet, FDDI (Fiber Distributed Data Interface), și ATM (Asynchronous Transfer Mode), furnizează lățime de bandă mare, solicitată de către mediile audio și video.
Deci, proiectarea protocolalelor în timp real pentru rețelele multimedia, devine necesară, înainte de sosirea erei multimedia.
2. Multimedia peste Internet [7]
Există și alte metode de a transmite datele multimedia, cum ar fi legături (links) dedicate, cabluri, și ATM-uri. Cu toate acestea, ideea de a rula multimedia peste Internet este extrem de atractivă.
Legăturile dedicate și cablurile nu sunt practice deoarece au nevoie de instalare și de software nou. Fără o tehnologie existentă cum ar fi LAN (Local Area Network), WAN (Wide Area Network), dezvoltarea software va fi foarte scumpă. ATM a fost declarat a fi o ultimă soluție pentru multimedia, deoarece suportă lățimi de bandă foarte mari, este orientat pe conexiune, și poate ajusta alt nivel de calitate al serviciului pentru diferitele tipuri de aplicații, dar în acest moment, foarte puțini utilizatori beneficiază de rețele ATM, și chiar mai puțini sunt cei care au conexiuni ATM la calculatoare.
Pe de altă parte, Internetul crește exponențial. Bine stabilitele tehnologii LAN și WAN, bazate pe protocolul IP, leagă rețele tot mai mari, de peste tot în lume la Internet. De fapt, Internetul a devenit platforma cu cele mai multe activități de rețea. Acesta este și motivul principal pentru a dezvolta multimedia peste Internet. Un alt avantaj este faptul că utilizatorii pot avea date integrate și servicii multimedia, într-o singură rețea, fără a fi nevoie de o altă rețea, infrastructură, sau interfață între cele două rețele.
La ora actuală, IP-ul și Ethernet-ul par a fi mai favorizate în birou și în LAN-uri, iar ATM-ul în WAN-uri.
Pentru a rula multimedia peste Internet, mai multe probleme trebuie să fie rezolvate. În primul rând, multimedia înseamnă date compacte și trafic încărcat, iar rețeaua trebuie să ofere suficientă lațime de bandă.
În al doilea rând, aplicațiile multimedia sunt de obicei legate de multicast – același flux de date, este transmis unui grup de utilizatori. De exemplu, într-o video conferință, datele video în timp real trebuie transmise către toți participanții în același timp. Protocoalele proiectate pentru aplicații multimedia, trebuie să folosească multicast-ul pentru a reduce traficul.
În al treilea rând, Internetul este o rețea de comutare de pachete, iar acestea sunt rutate independent prin rețelele partajate.Tehnologiile actuale nu pot garanta faptul că datele în timp real vor ajunge la destinație, fără a fi sacadate sau pierdute. Unele protocoale de transport trebuie să fie utilizate pentru a avea grijă de problemele de sincronizare, astfel încât datele audio și video să poată fi redate continuu, sincronizate și în timp util.
Răspunsurile la problemele de mai sus, sunt protocoalele care vor fi discutate în această lucrare.
Capitolul I
RTP și Internetul[10]
Protocolul de Transport în Timp Real (RTP) se bazează pe ideile propuse de Klark și Tenenhauzen, și are scopul de a transmite datele audio și video în timp real.
Acest capitol acoperă istoria protocoalelor de timp real, cât și despre arhitectura RTP-ului, care a fost proiectat să se potrivească cu alte protocoale cum ar fi: TCP (Transport Control Protocol), UDP (User Datagram Protocol), TLS (Transport Layer Protocol), IP (Internet Protocol), DNS (Domain Name System), și altele.
1.1. O scurtă istorie a RTP[10]
Încercări de a transmite voce pe o rețea au început în prima parte a anului 1970. Mai multe brevete despre conferință, timestamp (marcarea cu o ștampilă de timp), și sequence numbering (numerotarea secvențelor), au fost obținute în 1970 și 1980. În 1991, o serie de experimente de voce au fost finalizate la DARTnet. În August 1991, Network Reserch Group de la Laboratorul Național Lawrence Berkeley, au lansat un instrument de conferințe audio “vat”, pentru utilizarea DARTnet. Protocolul folosit a fost numit mai târziu Protocolul de Transport în Timp Real versiunea 0.
În Decembrie 1992 Henning Schulzrinne, a publicat Protocolul de Transport în Timp Real versiunea 1. A trecut prin mai multe faze, și în final a fost aprobat și propus standard la 22 Noiembrie 1995 de către IESG. Această versiune a fost numită Protocolul de Transport în Timp Real vesiunea 2, și a fost publicată ca:
RFC 1889, RTP – Un protocol de transport pentru Aplicații în timp real
RFC 1890, RTP – Profil pentru conferințe audio și video cu minimum de control
În 31 Ianuarie 1996, într-un comunicat de presă Netscape anunță "Netscape LiveMedia”, bazat pe RTP și alte standarde. Netscape LiveMedia framework va fi bazat pe Protocolul de transport în timp real (RTP), pe RFC 1889, și pe alte standarde audio-video cum ar fi MPEG, H.261 și GSM. Microsoft pretinde că software-ul lor, NetMeeting Conferencing suportă RTP.
În Internet, la fel ca și în alte rețele, este posibilă pierderea pachetelor, schimbarea ordinii în procesul de transmitere, de asemenea variază timpului de transmitere a pachetelor la distanțe mari. Aplicațiile multimedia pun condiții foarte dure asupra ambianței de transmitere. Pentru convenirea cu posibilitățile Internetului a fost creat protocolul RTP. Protocolul RTP are scopul de a transmite date în timp real (de exemplu semnalul audio sau video). Față de acesta se precizează tipul câmpului de date, se numerotează pachetele, se înregistrează reperul de timp și se monitorizează transmiterea datelor. Aplicațiile de obicei folosesc RTP implementat peste UDP, pentru ca să se poată folosi de posibilitatea sa de multiplexare și controlul checsum. Dar RTP se poate folosi de asemenea și deasupra oricărui protocol de nivel 4 OSI. RTP permite transmiterea concomitentă pe adrese diferite, dacă multicastul este susținut la nivel de rețea.
1.2. Stiva de protocoale Internet și Multimedia.[3]
În Figura 1.1. ne sunt prezentate cele patru nivele ale stivei de protocoale Internet și Multimedia. Nivelele și protocoalele din figură vor fi discutate în cele ce urmează.
1.2.1. Nivelul Fizic[3]
Nivelul cel mai de jos din stivă este nivelul fizic, care ar putea fi un nivel dintr-o rețea locala Ethernet, o linie telefonică (V.90 sau modem de 56k) care rulează protocolul punct-la-punct (PPP), o linie de telefon digitală (DSL) care rulează modul de transfer asincron (ATM), sau chiar o rețea wirelesport în Timp Real vesiunea 2, și a fost publicată ca:
RFC 1889, RTP – Un protocol de transport pentru Aplicații în timp real
RFC 1890, RTP – Profil pentru conferințe audio și video cu minimum de control
În 31 Ianuarie 1996, într-un comunicat de presă Netscape anunță "Netscape LiveMedia”, bazat pe RTP și alte standarde. Netscape LiveMedia framework va fi bazat pe Protocolul de transport în timp real (RTP), pe RFC 1889, și pe alte standarde audio-video cum ar fi MPEG, H.261 și GSM. Microsoft pretinde că software-ul lor, NetMeeting Conferencing suportă RTP.
În Internet, la fel ca și în alte rețele, este posibilă pierderea pachetelor, schimbarea ordinii în procesul de transmitere, de asemenea variază timpului de transmitere a pachetelor la distanțe mari. Aplicațiile multimedia pun condiții foarte dure asupra ambianței de transmitere. Pentru convenirea cu posibilitățile Internetului a fost creat protocolul RTP. Protocolul RTP are scopul de a transmite date în timp real (de exemplu semnalul audio sau video). Față de acesta se precizează tipul câmpului de date, se numerotează pachetele, se înregistrează reperul de timp și se monitorizează transmiterea datelor. Aplicațiile de obicei folosesc RTP implementat peste UDP, pentru ca să se poată folosi de posibilitatea sa de multiplexare și controlul checsum. Dar RTP se poate folosi de asemenea și deasupra oricărui protocol de nivel 4 OSI. RTP permite transmiterea concomitentă pe adrese diferite, dacă multicastul este susținut la nivel de rețea.
1.2. Stiva de protocoale Internet și Multimedia.[3]
În Figura 1.1. ne sunt prezentate cele patru nivele ale stivei de protocoale Internet și Multimedia. Nivelele și protocoalele din figură vor fi discutate în cele ce urmează.
1.2.1. Nivelul Fizic[3]
Nivelul cel mai de jos din stivă este nivelul fizic, care ar putea fi un nivel dintr-o rețea locala Ethernet, o linie telefonică (V.90 sau modem de 56k) care rulează protocolul punct-la-punct (PPP), o linie de telefon digitală (DSL) care rulează modul de transfer asincron (ATM), sau chiar o rețea wireless 802.11.
1.2.2. Nivelul Internet[3]
Urmatorul nivel din Figura 1.1. este nivelul Internet. Protocolul Internet (IP) este utilizat la acest nivel pentru a ruta pachetele de date prin rețea folosind adresa IP destinație. IP este un protocol bazat pe livrarea pachetelor “best-effort” (cel mai bun efort) și “connectionless” (nu este orientat pe conexiune). Pachetele pot fi pierdute, întarziate, sau primite într-o altă ordine decât cum au fost transmise. Fiecare pachet de date este rutat folosind antetul IP legat de pachetul fizic. Adresele IPv4 sunt lungi de 4 octeți, scrise în “dotted decimal” (exemplu, 128.122.3.1). Între fiecare punct este un număr zecimal de la 0 la 255. La nivelul stratului IP, pachetele nu sunt cu validare. Este un algoritm special pentru detecția erorilor în header-ul IP, care ar putea cauza rutarea incorecta a pachetelor. IP folosește un număr format dintr-un singur octet în header, pentru a identifica protocolul care ar trebui să primească pachetul.
Figura 1.1. Stiva de protocoale Internet și Multimedia[3]
ATM= Asynchronous Transfer Mode, V.90= recomandare pentru modem, 802.11= rețea wireless, AALx= ATM Adaptation Layer, PPP= Point-to-Point Protocol, IP= Internet Protocol, TCP=transport Control Protocol, UDP= User Datagram Protocol, SIP= Session Initiation Protocol, RTP= Realtime Transport Protocol, DNS= Domain Name System, DHCP= Dynamic Host Configuration Protocol, SDP= Session Description Protocol;
IP versiunea 6 (IPv6), a fost inițiat de către IETF (Internet Engineering Task Force), ca înlocuitor pentru IPv4. Momentan este suportat numai de câteva dintre sistemele de operare, dar încet încet va câștiga și interesul celorlalte aplicații. Cele mai multe rețele bazate pe IPv6 vor fi cel mai probabil rețelele telefonice wireless, care au nevoie de cel mai mare avantaj al IPv6, si anume spațiul de adresare mult mai mare. IPv6 crește spațiul de adresare de la 32 biți în IPv4 la 128 biți , asigurând peste 4 bilioane de adrese IPv6. Sunt multe alte îmbunătățiri la IPv6 peste IPv4, iar una dintre cele mai importante este securitatea. O adresa IPv6 este scrisă ca o secvență de 8 numere hexazecimale separate de două puncte. De exemplu, 0:0:0:0:aaaa:bbbb:cccc:dddd, este o adresă IPv6.
Adresele IP folosite în Internet sunt asignate de către IANA (Internet Assigned Number Association). Ca rezultat al acestei centralizări, adresele IP sunt unice la nivel global.
1.2.3. Nivelul Transport[3]
Următorul nivel prezentat în figură, este nivelul transport. Folosește un port format din 2 octeți de la nivelul aplicație, pentru a livra datagrama sau segmentul, de la protocolul care utilizează aplicația corectă, la adresa IP destinație. Există porturi dedicate anumitor protocoale, așa numitele porturi “well-known” (bine cunoscute). De exemplu, protocolul HTTP folosește portul “well-known” 80, SIP folosește portul 5060 și 5061, RTP folosește portul 5004, și RTCP portul 5005. Alte porturi pot fi folosite pentru orice protocol, și ele sunt asignate dinamic dintr-o plajă de porturi disponibile de la 49152 la 65535. Exista trei protocoale cele mai folosite ale nivelului transport, TCP (Transport Control Protocol), TLS (Transport Layer Security) și UDP (User Datagram Protocol).
1.2.3.1. TCP[3]
TCP asigură un transport sigur, orientat pe conexiune. TCP-ul folosește sequence numbers și acknowledgments(confirmări) pentru a se asigura că fiecare bloc al datelor, numit segment, a fost recepționat. Segmentele pierdute sunt retransmise până când acestea vor fi recepționate cu succes. Figura 1.2 ne arată schimbul de mesaje făcut pentru a stabili și a întrerupe o conexiune TCP. Serverul de TCP “ascultă” pe un port “well-known” o cerere de TCP. Clientul TCP trimite un mesaj SYN (sincronizare) pentru a iniția conexiunea. Mesajul SYN conține un număr de secvență inițial pe care clientul îl va folosi în timpul conexiunii. Serverul răspunde cu un mesaj SYN care conține propriul număr de secvență, și un acknowledgement, care indică primirea unui SYN de la client. Clientul încheie mecanismul denumit “three-way handshake” (comunicare cu confirmare în trei pași) cu un ACK (acknowlegement). Acum conexiunea e deschisă și se pot trimite pachete de date, numite segmente, atât server-ului, cât și clientului.
Figura 1.2. Deschiderea și închiderea unei conexiuni TCP[3].
De fiecare dată când se transmite un segment, se pornește un cronometru. Dacă segmentul este pierdut pe durata transmisiei, acest cronometru va expira. Dacă va exista vreun segment pierdut, se va retransmite acel segment până când cel care îl retransmite va primi confirmarea că a fost recepționat. Mesajul FIN închide conexiunea TCP. Secvența de patru mesaje din Figura 1.2 închid conexiunea. Astfel porturile folosite in timpul conexiunii vor fi eliberate pentru a putea fi folosite în stabilirea altor conexiuni. În TCP exista de asemenea mecanisme pentru controlul fluxului de date. În timpul procesării mesajului SYN, mărimea ferestrei reprezintă numărul maxim inițial de segmente neconfirmate trimise, care începe la 1 și crește exponențial până la o limită maximă. Când apare congestia în rețea și pierderea de pachete, fereastra se reseteaza înapoi la 1 și crește din nou până la limita maximă. Antetul unui segment TCP conține 24 de octeți. Segmentele eronate sunt detectate de un algoritm care acopera atât antetul unui segment TCP, cât și payload-ul.
1.2.3.2. UDP[3]
UDP asigură transportul nesigur al datelor prin Internet. Este un serviciu de tipul “best-effort”, atâta timp cât nu exista acknowledgment pentru datagrama transmisă. Majoritatea complexitații TCP-ului (numerotarea secvențelor-sequence numbers, confirmările-acknowlegements, și dimensiunea ferestrei) nu este prezentă și la UDP. Detectarea datagramelor eronate se face cu ajutorul unui algoritm, de verificare a sumei ciclice de control (checksum). Este la latitudinea protocolalelor de nivel superior, să detecteze datagramele pierdute și să inițieze retransmiteri.
1.2.3.3. TLS[3]
TLS se bazează pe protocolul SSL (Secure Sockets Layer), utilizat pentru prima dată în browsere-le de Web, și folosește TCP pentru transport. TLS este foarte utilizat în prezent în Internet, pentru site-urile securizate care folosesc HTTPS (Hypertext Transfer Protocol over Secure Socket Layer).
Protocolul TLS are două nivele:
– protocolul Transport TL
– protocolul Handshake TLS;
Protocolul de Transport TLS este utilizat pentru a asigura un mecanism de transport stabil și privat. Datele transmise cu ajutorul protocolului Transport TLS sunt criptate, pentru a nu putea fi interceptate.
Protocolul Handshake (comunicare cu confirmare) TLS este folosit pentru a stabili conexiunea, pentru a negocia cheia de criptare folosita de protocolul Transport TLS, și pentru a asigura autentificarea.
Mecanismul de negociere al cheii, selectează un algoritm de criptare și generează o cheie unică, secretă, cunoscută doar de cele două părți. În timpul înțelegerii în 3 pași, părțile schimbă certificatele, care pot fi folosite pentru autentificare.
Calculul cheii de criptare pentru o conexiune TLS este un mecanism laborios, iar deschiderea în mai multe rânduri a conexiunii (Figura 1.3.), poate adauga întârzieri. De asemenea, verificarea certificatului poate introduce întârzieri. Transportul prin TLS are mai multe avantaje de securitate decât UDP sau TCP. Multe sisteme de operare suportă deja TLS datorită utilizării mari in browsere-le Web securizate și servere.
1.2.3.4. SCTP[3]
SCTP (Stream Control Transport Protocol) este similar cu TCP-ul, deoarece asigură transport sigur pe baza de curent. De altfel, are ceva avantaje peste TCP. Are implementată partea de segmentare a mesajului, astfel că mesajele individuale sunt separate la nivelul transport.
Figura 1.3. Inițializarea unei conexiuni TLS[3].
Alt avantaj este acela că, SCTP evită problema “blocarea la cap de linie” (“head of line blocking”) a TCP-ului. Aceasta este o problemă comună la TCP, în care un segment care este transmis cu o fereastră mare, nu poate fi transmis spre legătura de ieșire dorită, deoarece aceasta este ocupată. În acest caz, segmentul va bloca toate celelate segmente din coadă, care asteaptă în urma sa, și cauzează așteptarea într-un buffer a întregului mesaj, până când segmentul în cauză este retransmis.
SCTP de asemenea, suporta multihoming-ul (router/dispozitiv care are mai mult de o interfață de rețea, folosit pentru creșterea siguranței în funcționare), astfel că dacă unul din perechea de servere de “load balacing” (echilibrare a încărcării) cade, celălalt poate începe imediat recepționarea mesajelor, făra a avea nevoie de DNS sau de alte căutari în baza de date.
SCTP este un protocol de transport de nivel 2, care are nevoie de un suport al sistemului de operare, fapt pentru care se vor produce întârzieri. De asemenea, este de reținut că avantajele SCTP-ului peste TCP, exista numai în cazul pierderilor de pachete. Într-o rețea făra pierderi, performanțele celor două protocoale sunt identice.
1.2.4. Nivelul Aplicație[5]
Nivelul cel mai de sus din Figura 1.1., este nivelul aplicație. Acesta include protocoale de transport media ca RTP (Real-time Transport Protocol), și protocoale de semnalizare ca SIP (Session Initiation Protocol). Figura 1.1 mai include H.323, care este un protocol alternativ de semnalizare către SIP, dezvoltat de către Uniunea Internațională de Telecomunicații (ITU). HTTP (Hypertext Transfer Protocol), SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol) și Telnet sunt toate exemple de protocoale ale nivelului aplicație.
1.3. Aplicații[5]
În Figura 1.1., sunt prezentate două aplicații care utilizează UDP-ul, și acestea sunt DNS-ul și DHCP-ul. Funcția principală a DNS-ului (port 53) este, să rezolve un nume simbolic (de exemplu : domeniu.ro, care este ușor de ținut minte), într-o adresa IP (necesară pentru rutarea pachetelor). De asemenea DHCP-ul permite unui dispozitiv IP să descarce informațiile de configurare la inițializare. Câmpurile cele mai comune includ o adresă IP alocată dinamic, adresa DNS, subnet masks (masca de subrețea), MTU (Maximum Transmission Unit) sau dimensiunea maximă a pachetului, și adresa serverului de mail.
Figura 1.4. ne arata implicarea celor patru nivele la procesarea unei cereri.
Figura 1.4. Procesarea unei cereri în Stiva deProtocoale
Internet și Multimedia[5]
URL-ul (Universal Resource Locator) este introdus de către utilizator în aplicația respectivă, și este prima etapă a procesului. URL-urile sunt nume folosite pentru a reprezenta unele resurse, PC-uri, sau fișiere de pe Internet. Aplicația pasează cererea generată (de exemplu o cerere GET a HTTP-ului, care cere descărcarea unei pagini Web), URL-ul, și numărul de port, către nivelul inferior și anume nivelul transport. Nivelul transport folosește un utilitar DNS, pentru a rezolva numele de domeniu extras din URL, într-o adresă IP. Adresa IP, datagrama (sau segmentul, depinde de protocolul de transport folosit), și numărul de port (care identifică protocolul de transport) sunt pasate către nivelul Internet. Nivelul Internet pasează pachetul cât și adresa MAC (Medium Access Control) către nivelul fizic. Apoi este dat un răspuns, prin inversarea pașilor de mai sus. Un răspuns primit la nivelul fizic, merge ulterior la nivelele superioare și în final la utilizator. Marea diferență între cerere și răspuns este aceea că în cazul procesării răspunsului, nu se folosește nici un utilitar, și deci întarzierile sunt mult mai mici.
1.4. DNS și adresele IP[4]
DNS-ul este utilizat în Internet pentru a asocia un nume simbolic (ca de exemplu www.domeniu.ro) cu o adresa IP (ca de exemplu: 192.168.2.1). De asemenea DNS-ul este folosit pentru a obține informații necesare pentru a ruta mesajele de e-mail, și pe viitor mesajele SIP. Utilizarea numelor în locul adreselor numerice este necesară, deoarece este mult mai ușor de ținut minte de către utilizatori. Numele de domenii sunt organizate ierarhic. Fiecare nivel din nume este separat cu un punct, în partea dreapta aflându-se nivelul superior (punctele din numele de domeniu nu corespund cu punctele din adresa IP). Nivelele superioare de domenii sunt prezentate in Tabelul 1.1. (http://www.iana.org ). Există și un set de domenii de țara ca: us (Statele Unite), ro (Romania), uk (Anglia), și ca (Canada). Fiecare din aceste nivele superioare de domenii au o autoritate care asigneaza acel domeniu la un utilizator sau un grup.
Tabel 1.1. Domenii din Internet[4]
Odata ce numele de domeniu a fost asignat, autoritatea plasează acea legătură (link) în serverul lor de DNS către serverul de DNS al utilizatorului sau grupului căruia i-a fost asignat domeniul. De exemplu, când « companie.com » este alocat unei companii, serverul de DNS principal pentru nivelul superior de domeniu com coține adresa IP a serverului de DNS a companiei. Un nume poate fi introdus apoi în tabelele serverului de DNS a companiei, care să ruteze către serverele individuale din rețea. De exemplu, tabelele serverului de DNS a companiei respective pot conține : www. companie.com, ftp .companie.com, și smtp. companie.com. Înregistrările din DNS utilizate pentru a rezolva un nume într-o adresa IP se numesc înregistrări de adrese (A records).
Când un utilizator caută o adresa Web, ca www .domeniu.ro, numele trebuie să fie rezolvat într-o adresa IP, înainte ca browser-ul să trimită cererea pentru pagina Web la serverul Web “domeniu”. Browser-ul lansează o interogare DNS (DNS query) către adresa IP pentru ai afla serverul de DNS, care a fost configurat manual sau setat folosind DHCP. Dacă se întâmpla ca serverul de DNS să aiba numele stocat local (cached), dintr-o interogare recentă, va returna adresa IP. Dacă nu, serverul DNS radăcină va fi interogat pentru a localiza serverul DNS principal pentru “domeniu”, care trebuia să conțina în înregistrări adresa pentru domeniu.ro. Cererea HTTP GET este trimisă către acea adresă IP, și începe sesiunea de navigare Web.
1.5. URL-uri si URI-uri[8]
URL-urile, sunt nume care reprezintă adrese sau locații din Internet. URL-urile sunt proiectate să cuprindă o gamă largă de protocoale si resurse din Internet. Forma de bază a unui URL este: specificatorul – de exemplu, http://www.domeniu.com/search/
search.html. HTTP-ul identifică protocolul care se folosește, în cazul acesta HTTP. Apoi urmeaza “:” și conține un nume de domeniu (www.domeniu. com), care poate fi rezolvat într-o adresa IP, și un nume de fișier ( /search/search.html). URL-urile pot conține parametrii adiționali, sau calificative legate de transport. De exemplu, telnet://host.companie.com:24, indică faptul că trebuie folosit protocolul Telnet pentru a accesa host.companie.com, folosind portul 24. Noi scheme de URL-uri au fost definite pentru protocoalele noi, ca de exemplu tel, https, și mailto. Majoritatea protocoalelor folosesc URL-urile, dar când vorbim despre SIP, atunci ne referim la URI-uri (Uniform Resource Identifier).
Aceasta se datorează aspectelor de mobilitate ale SIP, care înseamnă că o adresa URI, nu este neaparat legată de un singur dispozitiv, în schimb este o entitate logică care își poate schimba locația în Internet. În alte contexte termenele URL și URI sunt foarte des folosite alternativ.
1.6. Multicast[8]
Într-o rutare normala de pachete, sau o rutare unicast, un pachet este transmis către o singura destinatie. Într-o rutare multicast, un singur pachet este transmis către anumite destinații. LAN-urile care folosesc Ethernet-ul, au capacitatea să transmită pachetele în regim broadcast, ceea ce înseamnă că un pachet este transmis către fiecare nod al rețelei. Dacă facem analogia cu o rețea mult mai mare, cu mai multe rutere, atunci vom avea cu siguranță “rețeta dezastrului” – [Alan B. Johnston, Understanding the Session Initiation Protocol], deoarece traficul broadcast poate foarte rapid să cauzeze congestia. Adresele de multicast sunt rezervate de la 224.0.0.0 până la 239.255.255.255. Transportul multicast este tot timpul UDP, atâta timp cât nu sunt posibile “hand-shake-ul” și “acknoledgments” TCP-ului. Răspândirea unei sesiuni multicast poate fi limitată cu ajutorul câmpului TTL (time-to-live) din antetul IP. Câmpul TTL este decrementat de fiecare ruter care transmite mai departe pachetul, și limitează numărul de hopuri pe care le face pachetul.
Figura 1.5. Rutarea Unicast și Multicast[8]
Capitolul II
Protocoalele de transport pentru aplicații în timp real[13]
În acest capitol descriem RTP, protocolul de transport în timp real care asigură funcții de transport în rețele de tip end-to-end, potrivite pentru transmiterea datelor audio sau video în timp real, peste servicii de rețea multicast sau unicast. RTP nu garanteaza calitatea serviciului pentru transmisiile în timp real. Transportul de date este extins printr-un protocol de control, RTCP, care monitorizează livrarea datelor într-o manieră scalabilă pentru rețele multicast de mari dimensiuni cu un control minim. RTP si RTCP sunt proiectate să fie independente de protocolalele de transport și de nivelele de rețea.
2.1. Domenii de utilizare a RTP-ului[13]
Exemplele au fost alese pentru a ilustra funcționarea de bază a unor aplicații folosind RTP, și nu de a limita utilitatea RTP-ului. În aceste exemple, RTP-ul este transportat peste IP și UDP, și urmează convențiile stabilite de către profilul pentru audio și video (RTP/AVP), specificat în RFC 3551.
2.1.1. Conferințe audio tip multicast[13]
Un grup de specialiști din IETF se întâlnesc pentru a discuta ultimul document despre un protocol, utilizând serviciile IP multicast de Internet pentru comunicațiile de voce. Grupul obține un set de adrese muticast și o pereche de porturi. Un port este folosit pentru datele audio, și celălalt pentru controlul pachetelor (RTCP). Această informație despre adresă și port sunt distribuite tuturor participanților. Datele si controlul pachetelor se pot cripta, dar pentru aceasta va trebui generată și distribuită o cheie de criptare.
Aplicația despre conferința audio, folosită de fiecare dintre participanți, trimite segmente mici de date, de aproximativ 20 ms. Fiecare segment de dată audio este precedat de un antet RTP, iar la rândul lui, antetul de RTP este conținut într-un pachet UDP. Antetul RTP indica ce fel de codificare audio este folosită în fiecare pachet (PCM-Pulse Code Modulation, ADPCM-Adaptive Differential Pulse Code Modulation sau LPC-Linear Predictive Coding), iar utilizatorii pot schimba codificarea în timpul conferinței, dacă apar cogestii pe rețea, sau de exemplu pentru a primi un nou participant care este conectat folosind un link cu lățimea de bandă mai mică.
Internetul, ocazional pierde, reorganizează pachetele, și le întârzie o anumită perioadă de timp. De aceea antetul de RTP conține informații despre timpi și număr de secvențe, iar acestea ajuta receptorul să reconstruiasca procedurile de timing ale sursei. Reconstruirea procedurilor de timing din timpul conferinței, se face separat pentru fiecare sursă RTP. Numărul secvențelor, poate fi folosit de receptor pentru a estima câte pachete sunt pierdute.
În timpul unei conferințe, membrii grupului se alătură dar și părăsesc conferința, și din această cauză, este bine de știut cine participă în orice moment, dar și cât de bine recepționează datele audio. Pentru aceasta, fiecare instanță a aplicației audio trimite periodic în regim multicast un raport de recepție și numele utilizatorului, pe portul de control RTCP. Raportul de recepție indica cât de bine este recepționat semnalul audio, și poate fi folosit pentru a controla codările adaptive. Pe lângă numele utilizatorului, mai pot exista și alte informații, de exemplu limitele lățimii de bandă. Când cineva părăsește conferința, se transmite un pachet RTCP BYE.
2.1.2. Conferințe audio și video[15]
Dacă ambele medii audio și video sunt folosite în conferință, acestea sunt transmise ca sesiuni separate RTP. Adică pachetele RTP și RTCP sunt transmise separat, iar fiecare mediu folosește doua perechi de porturi UDP diferite sau/și adrese de multicast. Nu există o asociere directă la nivel de RTP între sesiunile audio și video, decât că utilizatorul participant la ambele sesiuni, trebuie sa folosească același nume (canonic), în ambele pachete RTCP, pentru ca să putem asocia sesiunile. O motivare a acestei separații, este de a permite unor participanți la conferință să folosească numai un mediu (audio sau video), dacă ei doresc.
2.1.3. Multiplexoare și Translatoare[2]
Până acum am presupus că toate site-urile vor să primească datele în același format, cu toate că acest lucru nu este întotdeauna indicat. Considerăm cazul în care participanții dintr-o anumită zonă, sunt conectați la conferință printr-o legatură cu viteză redusă, față de ceilalți participanți care se bucură de accesul la rețea, beneficiind de viteză mai mare. În loc să forțăm pe toata lumea să folosească viteză redusă, și calitatea codarii audio scăzută, un releu de nivel RTP numit multiplexor, poate fi plasat langă zona cu conectivitate redusă.
Figura 2.1. Multiplexor în transmisii de date[2]
Multiplexorul resincronizează pachetele audio care sosesc, pentru a reconstrui spațiul de 20 ms generat de transmițător, mixează aceste pachete audio într-unul singur, translatează codările audio la o lățime de bandă mai mică, și înaintează pachetul cu lățimea de bandă mai mică, către legătura cu viteză scăzută. Aceste pachete pot fi transmise unicast, către o singură destinație sau multicast, pe adrese diferite, spre diferite destinații.
Unii din participanții la conferința audio, pot fi conectați printr-o legătură de mare viteză, și totodată nu sunt neaparat direct accesibili via IP multicast. De exemplu, ei pot fi în spatele unei aplicații firewall, care nu va permite trecerea nici unui pachet IP. Pentru aceste site-uri multiplexarea nu va fi necesară, caz în care vom folosi alt tip de releu de nivel RTP, numit translator. Se instalează două translatoare, câte unul pe fiecare parte a firewall-ului, cu partea din exterior se filtrează toate pachetele multicast recepționate printr-o conexiune sigură către translatorul din interiorul firewal-ului. Translatorul din interiorul firewal-ului le retrimite ca pachete multicast către un grup multicast din rețeaua internă.
Figura 2.2. Translator în RTP[2]
Multiplexoarele și translatoarele pot fi proiectate pentru diferite scopuri. Un exemplu este multiplexorul video, care scalează imaginile unor persoane în fluxuri video separate, apoi le compune într-un flux video care simulează o scenă grupată. Alt exemplu este conexiunea unui grup de host-uri care cunosc (înteleg) numai IP/UDP, cu un grup de host-uri care cunosc numai ST-II, sau codarea pachet cu pachet a fluxului video de la o sursă individuală, fără resincronizare sau mixare.
2.1.4. Codări stratificate[1]
Aplicațiile multimedia ar trebui să poată ajusta rata transmisiei, pentru a se potrivi cu capacitatea receptorului, sau pentru a se adapta la congestiile din rețea. Majoritatea implementărilor plasează această responsabilitate a ratei transmisiei/adaptării, la sursă, iar acest lucru nu funcționează bine cu transmisiile multicast datorită conflictului dintre cerințele lățimii de bandă ale receptoarelor diverse. Responsabilitatea pentru rata transmisiei/adaptare, poate fi plasată la recepție combinând această codare stratificată cu un sistem de transmisie pe nivele.
2.2. Noțiuni generale / definiții[9]
Câmpul de date RTP: Informația, transmisă în pachetul RTP, de exemplu fragment de sunet sau informație video compresată.
Pachetul RTP: Pachet de informație, care conține un antent fix, o listă goală de surse de informații (CSRC), și câmpul de date. Un pachet de nivel inferior, de exemplu UDP, conține de obicei un pachet RTP, dar pot fi conținute mai multe pachete RTP, dacă permite metoda de încapsulare. .
Pachetul RTCP: Pachetul de coordonare sau control, care conține un antent fix asemănător cu antentul pachetului RTP, după care vin elementele structurate, care variază în funcție de tipul pachetului RTCP. De obicei câteva pachete RTCP se transmit ca un singur pachet încorporat într-un pachet de nivel mai jos cum este UDP.
Portul: Este “Abstracția care transportă protocoale, folosit pentru a distinge destinațiile multiple ale unui computer. Protocoalele TCP/IP identifică porturile folosind numere mici întregi pozitive.”- Comer D., Internetworking with TCP/IP. RTP depinde de protocoalele de nivel inferior, pentru a oferi unele mecanisme cum sunt porturile, pentru a multiplexa pachetele RTP și RTCP dintr-o sesiune.
Adresa de transportare: combinația de IP și numărul portului, care identifică punctul final al canalului (ex: adresa IP și portul UDP). Pachetele de date sunt transmise de la o adresă de transport sursă la o adresă de transport destinație.
Sesiunea multimedia: mai multe sesiuni RTP între un grup comun de participanți (ex: videoconferința este o sesiune multimedia deoarece poate conține o sesiune RTP audio și o sesiune RTP video ).
Sesiunea RTP: perioada de la momentul când se face grupa de membri între care se face schimbul de pachete RTP și până la dispariția ei. Pentru fiecare dintre participant sesiunea se precizează cu o pereche de adrese de transport destinație. Adresa de transmitere poate sa fie comuna pentru toți, în cazul IP multicast, sau să difere adresele, ca și în cazul rețelei unicast. În cazul rețelei unicast, participantul poate recepționa date de la toți paticipanții din aceea sesiune, folosind aceeași pereche de porturi, sau poate folosi o pereche distinctivă de porturi pntru fiecare. Caracterul distinctiv al sesiunii RTP, este acela că fiecare menține un spațiu separat de identificatori SSRC. Un grup de participanți care sunt într-o sesiune RTP se compune din aceeia care pot recepționa un identificator SSRC transmis de oricare din participanți. De exemplu să considerăm o conferință compusă din trei părți, folosind UDP unicast, cu fiecare participant recepționând de la ceilalți doi pe perechi de porturi separate. Dacă fiecare participant trimite un feedback RTCP despre informațiile recepționate de la un alt participant, către acel participant, atunci conferința este alcătuită din trei sesiuni punct-la-punct separate RTP. Dacă fiecare participant oferă feedback RTCP despre recepția de la un alt participant, către ceilalți doi membrii, atunci conferința e compusă din mai multe parți.
Sursa de sincronizare SSRC (syncronization source): Sursa fluxului pentru pachetul RTP, se determină de un identificator numeric de 32 biți și e independent de adresa de rețea. Toate pachetele de la sursa de sincronizare formează o parte identică in timp și numerotație. Aceste date se folosesc de către partea care primește și le reproduce. Sursele de sincronizare includ emițătorul unui flux de date derivate din sursele de semnal cum ar fi un microfon, o cameră video, sau un mixer RTP. Identificatorul SSRC reprezintă un număr aleator unic pentru această sesiune RTP. Membrul acestei sesiuni este obligat să folosească unul și același identificator SSRC pentru toate sesiunile RTP. Dacă un membru formează câteva fluxuri în limita unei sesiuni RTP, de exemplu de la o cameră video separată, fiecare participant trebuie să aibă un identificator SSRC unic.
Sursa informațională CSRC (contributing source): Sursa fluxului pachetului RTP, care contribuie la crearea fluxului comun, format de către mixerul RTP. Mixerul pune lista identificatorilor SSRC care identifică sursele parțiale, în antentul pachetelor RTP. Această listă se numește CSRC. Ca exemplu de aplicație poate fi audio conferința, unde mixerul îi înregistrează pe toți care vorbesc, iar glasul fiecărui membru devine ca sursă de transmitere a pachetelor. Aceasta permite receptorului să identifice membrul care vorbește, chiar dacă toate pachetele au unul și același identificator SSRC.
Sistemul final: Aplicația care generează sau percepe datele, transmise în pachete RTP. Sistemul final poate să acționeze în calitate de una sau mai multe surse de sincronizare pentru o sesiune concretă.
Multiplexorul: Sistem intermediar, care primește pachete RTP de la una sau mai multe surse, având posibilitatea de a schimba formatul, combină pachetele și apoi transmite un nou pachet RTP. Deoarece legătura de timp a pachetelor poate să difere, multiplexorul înfăptuiește sincronizarea lor și generează singur un flux de protocoale RTP. Cu toate acestea, toate pachetele RTP transmise au în calitate de sursă de sincronizare, multiplexorul.
Translator: Un sistem intermediar, care redirecționează pachetele RTP, fără a schimba identificatorii surselor de sincronizare. Astfel de sisteme se folosesc pentru reorganizarea sistemului de codificare, trecerea de la multicast la unicastul tradițional sau la lucrul cu firewall.
Monitor: Aplicația, care primește pachete RTCP, trimise de către membrii sesiunii RTP, în particular mesaje de diagnoză, estimează calitatea legăturii și păstrează statistica de termen lung.
2.3. RTP – Protocolul de transfer de date[6]
Protocolul în timp real RTP este un protocol bazat pe IP, și oferă suport pentru transportul informațiilor în timp real, cum ar fi fluxuri video și audio. Serviciile oferite de RTP include reconstrucția în timp, detecția pachetelor pierdute, securitate și identificarea conținutului. RTP este inițial proiectat pentru transmisia multicast a datelor în timp real, dar poate fi folosit de asemenea și în transmisii unicast. Poate fi folosit pentru transportul într-o singură direcție, cum ar fi video-on-demand (video la cerere), precum și ca serviciu interactiv așa cum este telefonia pe Internet. RTP este proiectat să lucreze în conjuncție cu protocolul auxiliar de control RTCP, pentru a primii feedback despre calitatea transmisiei și informații despre participanții din sesiunea în desfășurare.
2.3.1. Dezvoltare[11]
Încercări de a transmite voce pe o rețea au început în prima parte a anului 1970. Mai multe brevete despre conferință, timestamp (etichete de timp), și sequence numbering (numerotarea secvențelor), au fost obținute în 1970 și 1980. În 1991, o serie de experimente de voce au fost finalizate la DARTnet. În August 1991, Network Reserch Group de la Laboratorul Național Lawrence Berkeley, au lansat un instrument de conferințe audio, vat, pentru utilizarea DARTnet. Protocolul folosit a fost numit mai târziu RTP versiunea 0.
În Decembrie 1992 Henning Schulzrinne, a publicat Protocolul de Transport în Timp Real versiunea 1. A trecut prin mai multe faze, și în final a fost aprobat și propus standard la 22 Noiembrie 1995 de către IESG. Această versiune a fost numită Protocolul de Transport în Timp Real vesiunea 2, și a fost publicată ca:
– RFC 1889, RTP – Un protocol de transport pentru Aplicații in timp real
– RFC 1890, RTP – Profil pentru conferințe audio și video cu minimum de control
În 31 Ianuarie 1996, într-un comunicat de presă Netscape anunță "Netscape LiveMedia”, bazat pe RTP și alte standarde. Netscape LiveMedia framework va fi bazat pe Protocolul de transport în timp real (RTP), pe RFC 1889, și pe alte standarde audio-video cum ar fi MPEG, H.261 și GSM. Microsoft pretinde că software-ul lor, NetMeeting Conferencing suportă RTP.
2.3.2. Cum funcționează RTP[11]
Așa cum sa discutat în prima secțiune, Internet-ul este o rețea de datagrame partajată. Pachetele trimise pe Internet au întârzieri și bruiaje imprevizibile. Aplicațiile multimedia necesită sincronizare adecvată în transmiterea datelor și redarea lor. RTP prevede timestamping (marcarea cu o etichetă de timp), numerotarea secvențelor, precum și alte mecanisme referitoare la problemele de sincronizare. Prin aceste mecanisme, RTP oferă transport de tipul end-to-end pentru date în timp real.
Timestamping-ul este cea mai importantă informație pentru aplicațiile în timp real. Sursa setează o etichetă de timp în momentul eșantionării primului octet dintr-un pachet. Acest timp este apoi incrementat cu durata necesară transmiterii unui pachet. După ce sunt recepționate toate pachetele de date, receptorul folosește acest timestamp pentru a reconstrui fiecare pachet în ordinea corectă, astfel încât o eventuală vizualizare să se facă la o rată corectă. Acest procedeu este de asemenea folosit pentru sincronizarea diferitelor fluxuri ce au proprietăți dependente de timp, cum ar fi audio și video într-un fișier MPEG. RTP-ul nu este responsabil pentru sincronizare, acest lucru facându-se la nivel de aplicație.
UDP nu livrează pachetele în ordine, sau la timp, astfel numerotarea secvențelor se folosește pentru a plasa informațiile sosite în ordinea corectă. De asemenea se folosește și pentru detecția pachetelor pierdute. De remarcat faptul că în unele formate video, când un cadru este împărțit în mai multe pachete RTP, toate pot avea același timestamp. Deci doar timestampul nu este de ajuns pentru a reconstrui pachetele în ordine.
Identificatorul despre formatul informației utile (payload type) ne arată formatul, dar și schemele de codare/compresie. De la acest identificator, aplicația de la recepție știe cum să interpreteze informația utilă. Tipurile de informații utile standard sunt definite în RFC 3551. Exemple: PCM, MPEG1/MPEG2 (Moving Picture Experts Group)-codări audio/video, JPEG (Joint Photographic Experts Group)-codare video, Sun CellB-codare video, H.261-fluxuri video etc. Putem adăuga mai multe tipuri de payload, dacă avem specificațiile despre un profil și formatul payload-ului. În orice moment al transmisiei, sursa RTP poate transmite doar un tip de payload, cu toate că tipul de informație poate să difere în timpul unei transmisii, de exemplu, la adaptarea într-o rețea cogestionată.
Altă funcție este identificarea sursei. Permite aplicației de la recepție să știe de unde vin informațiile. De exemplu, într-o conferință audio, de la indentificatorul sursă un utilizator ar putea spune cine vorbește. Mecanismele de deasupra sunt implementate în antetul RTP. Figura de mai jos ne arată un pachet RTP încapsulat într-un pachet UDP/IP.
Figura 2.3. Informația RTP într-un pachet IP[11]
De obicei RTP rulează peste UDP, pentru a se folosi de funcțiile acestuia de multiplexare și verificare a sumei ciclice de control.
TCP și UDP sunt două dintre cele mai utilizate protocoale de transport în Internet. TCP-ul asigură un flux sigur și orientat pe conexiune, între doua calculatoare, iar UDP-ul asigură servicii nesigure, și care nu sunt orientate pe conexiune.
UDP-ul a fost ales ca protocol de transport pentru RTP din două motive. RTP-ul este în primul rând proiectat pentru transmisii multicast, iar TCP-ul orientat pe conexiune nu este adecvat. Al doilea motiv, pentru informațiile în timp real, fiabilitatea nu este așa de importantă în comparație cu livrarea la timp a datelor. Chiar mai mult, transmisia fiabilă oferită prin retransmiterea datelor, ca în cazul TCP-ului, nu este de dorit. De exemplu, într-o rețea cogestionată, unele pachete se pot pierde, iar aplicația va avea ca rezultat o calitate mai slabă, dar totuși acceptabilă. Dacă se optează pentru o transmisiune fiabilă, pachetele retransmise ar putea crește întârzierile, ar putea bloca rețeaua, și în final nu ar mai ajunge informațiile la aplicația de la recepție.
Pachetele RTP și RTCP sunt transmise de obicei folosind serviciul UDP/IP, dar s-au făcut eforturi pentru a le face independente de protocolul de transport folosit, pentru ca acestea să poată funcționa și cu CLNP (Connectionless Network Protocol), IPX (Internetwork Packet eXchange), AAL5/ATM și cu alte protocoale.
În practică, RTP-ul este implementat în cadrul aplicației. Multe probleme, cum ar fi recuperarea pachetelor pierdute, controlul congestiei, trebuiesc implementate la nivel de aplicație. Pentru a pune bazele unei sesiuni RTP, aplicația definește o pereche de adrese de transport destinație (o adresă de rețea plus o pereche de porturi pentru RTP și RTCP). Într-o sesiune multimedia, fiecare mediu este transportat în sesiuni RTP separate, fiecare având pachete RTCP proprii, pentru raportul privind calitatea recepției din acea sesiune. De exemplu, transmisia audio și video se face folosind sesiuni RTP separate, dând posibilitatea receptorului să aleagă dacă vrea sau nu să recepționeze un mediu particular.
Un scenariu despre o conferință audio, prezentată în RFC 3550, ilustrează utilitatea RTP-ului. Să presupunem că fiecare participant trimite date audio în segmente de 20 ms. Fiecare segment audio este precedat de un antet RTP, iar mesajul RTP rezultat este plasat într-un pachet UDP. Antetul RTP indică tipul de codare audio care este folosită, ex., PCM. Utilizatorii pot schimba tipul de codare, în timpul conferinței, în cazul în care apar cogestii pe rețea sau de exemplu, pentru a primi un nou participant la coferință, dar care beneficează de un link cu lățimea de bandă mai mică.
Informațiile despre timpi și numerotare a secvențelor din antetul RTP, sunt folosite de receptoare, pentru a reconstrui procedurile de timing ale sursei, iar pentru acest exemplu, segmentele audio sunt redate continuu de receptor la fiecare 20 ms.
2.3.3. Structura pachetului[14]
Pachetul de date RTP are urmatorul format:
Figura 2.4. Structura pachetului RTP[14]
Primii 12 octeți sunt prezenți în toate pachetele RTP, iar identificatorii CSRC sunt prezenți doar introduși de un multiplexor.
Ver. (2 biți) indică versiunea protocolului RTP utilizată. Versiunea actuală este 2. Valoarea 1 este folosită de prima versiune a RTP.
P – padding (1 bit), este folosit pentru a indica dacă există informație suplimentară la finalul pachetului RTP. Dacă bitul este setat, pachetul conține informație suplimentară la finalul pachetului, care nu face parte din informația utilă. Este nevoie de padding la anumiți algoritmi de criptare structură fixă, sau pentru transportul pachetelor RTP într-un nivel inferior a PDU .
X – extensie (1 bit), indică dacă sunt utilizate extensii ale protocolului în pachet. Dacă bitul este setat, antetul fix trebuie urmat de exact o extensie de antet, cu un anumit format.
CC – CSRC count (4 biți), conține numărul identificatorului CSRC care îi urmează antetului fix.
M – marker (1 bit), este folosit la nivelul aplicație și este definit în cadrul profilelor. Dacă este setat, dovedește că datele curente au o semnificație specială pentru nivelul aplicație. Un profil poate defini biți adiționali pentru marker, sau poate specifica faptul că nu este nici un bit pentru marker, prin schimbarea numărului de biți din câmpul informație utilă .
PT – payload type (7 biți) indică formatul payload-ului (informația utilă) și determină interpretarea de către aplicație. SSRC indică sursa de sincronizare.Un receptor trebuie să ignore pachetele cu format pe care acesta nu îl întelege.
Numărul secvenței: (16 biți) indică numărul de pachete transmise pe canal. Numărul secvenței se incrementează cu 1 pentru fiecare pachet trimis, și poate fi folosit de către receptor pentru determinarea de pachete pierdute, dar si pentru reconstrucția sevenței. Valoarea inițială a numărului secvenței ar trebui să fie aleatoare, pentru ca criptarea datelor să fie mai sigură.
Timestamp – timpul la transmitere (32 biți): este cea mai importantă informație pentru aplicațiile în timp real. Sursa setează un timestamp în momentul eșantionării primului octet dintr-un pachet. Acest timp este apoi incrementat cu durata necesară transmiterii unui pachet. După ce sunt recepționate toate pachetele de date, receptorul folosește acest timestamp pentru a reconstrui fiecare pachet în ordinea corectă, astfel încât o eventuală vizualizare să se facă la o rată corectă. Acest procedeu este de asemenea folosit pentru sincronizarea diferitelor fluxuri ce au proprietăți dependente de timp, cum ar fi audio și video într-un fișier MPEG.
Identificatorul SSRC (32 biți): un număr ales aleator, pentru a deosebi sursele de sincronizare din aceeași sesiune RTP. Indică unde s-au combinat datele, sau sursa datelor, în cazul în care există numai o sursă
Identificatorii CSRC sau lista CSRC (între 0 și 15 obiecte, cu 32 biți fiecare): indică sursele informaționale pentru informația utilă conținută în acest pachet. Numărul identificatorilor este dat de câmpul CC.
2.4. RTCP – Protocolul de control în timp real[17]
RTCP este un protocol de control proiectat să lucreze în conjuncție cu RTP-ul. Este standardizat în RFC 3550. RTP-ul livrează datele actuale, în timp ce RTCP este folosit pentru a trimite pachete de control participanților la un apel. Funcția primară este furnizarea de rapoarte cu privire la calitatea serviciilor furnizate de RTP. Într-o sesiune RTP, participanții trimit periodic pachete RTCP, pentru a furniza rapoarte despre calitatea livrării datelor, și informații despre membrii. RFC 3550 definește cinci tipuri de pachete RTCP pentru informațiile de control. Aceste pachete sunt:
► RR (receiver report): rapoartele receptorului sunt generate de participanții care nu sunt surse active. Ele conțin feedback-ul receptorului despre livrarea datelor, incluzând numărul cel mai mare de pachete recepționate, numărul pachetelor pierdute, bruiajul de tip inter-arrival, și timestamps care calculează întârzierile dus-întors dintre sursă și destinație.
► SR (sender report): rapoartele sursei sunt generate de susele active. Pe lângă feedback-ul despre calitatea transmisiei, ele conțin o secțiune cu informații despre sursă, oferind sincronizari inter-media, numărarea pachetelor cumulative, și numărul byților transmiși.
► SDES (source description items): conțin informații care descriu sursele.
► BYE indică sfârșitul participării (transmisiei).
► APP indică funcțiile specifice aplicației.
Figura 2.5. Pachete RTCP compuse[17]
RTCP-ul îndeplinește următoarele funcții:
► Calitatea serviciului care monitorizează controlul congestiei.
Aceasta este funcția principală a RTCP. RTCP-ul furnizează feedback unei aplicații, despre calitatea distribuirii datelor. Informațiile de control sunt utile sursei, receptorului, dar și administratorilor de rețea. Sursa iși poate modifica transmisia, în funcție de raportul receptorului. Receptorul poate determina dacă o cogestie este locală, regională, sau globală. Administratorii de rețea pot evalua performanțele rețelei pentru transmisii multicast.
► Identificarea sursei.
În pachetele de date RTP, sursele sunt identificate de identificatori de 32-biți generați in mod aleator. Acești identificatori nu sunt convenabili pentru utilizatori. Pachetele RTCP SDES (descrierea sursei) conțin informații textuale numite nume canonice (CNAME). Acestea pot include numele de utilizator, numărul de telefon, adresa de email și alte informații.
► Sincronizare inter-media.
Rapoartele RTCP ale sursei conțin o indicație de timp real și timestamp-ul RTP corespunzător. Acestea pot fi utilizate în sincronizarea inter-media.
► Scalarea informațiilor de control.
Pachetele RTCP sunt transmise periodic printre participanți. Când numărul participanților crește, este necesar să existe un echilibru între actualizarea informațiilor de control și limitarea traficului de control. Pentru a scala la grupuri multicast mai mari, RTCP-ul trebuie sa prevină traficul de control, pentru a nu aglomera resursele rețelei. Limitele RTP de control a traficului sunt de cel mult 5% din totalul traficului sesiunii.
2.5. Caracteristicile RTP-ului[12]
● RTP oferă servicii de livrare de tipul end-to-end, pentru informații cu caracteristici în timp real, cum ar fi audio și video interactiv, dar nu furnizează nici un mecanism care să asigure livrarea la timp a datelor. Are nevoie de suportul nivelelor inferioare, care chiar au control asupra resurselor din switch-uri și routere. RTP depinde de RSVP (Resource Reservation Protocol), pentru rezervarea resurselor și pentru furnizarea calității serviciilor cerute.
● RTP-ul nu presupune nimic despre rețea, cu excepția faptului că furnizează framing (cadre). De obicei RTP rulează peste UDP, pentru a se folosi de serviciile de multiplexare si checksum ale acestuia, dar au fost facute eforturi pentru al face compatibil si cu alte protocoale de transport, cum ar fi ATM, AAL5 și IPv6.
● Spre deosebire de transmisia datelor, RTP-ul nu oferă nici o formă de fiabilitate, control al debitului, sau al congestiei. Furnizează timestamps, numerotarea secvențelor, folosite pentru adăugarea fiabilității și controlul debitului/congestiei, dar modalitățile de implementare, sunt lăsate la latitudinea aplicației.
● RTP este un protocol bazat pe cadre, care nu este încă complet. Este deschis la noi formate a payload-ului, dar și pentru noi soft-uri multimedia. Prin aplicarea de noi profile, și formate ale payload-ului, putem adapta RTP-ul la noi formate de date și la noi aplicații.
● RTP/RTCP furnizează funcționalitate și mecanisme de control necesare pentru transportul în timp real al conținutului. Dar RTP/RTCP nu sunt responsabile pentru sarcinile nivelelor superioare, cum ar fi asamblarea și sincronizarea. Acestea trebuie făcute la nivelul aplicație.
● Informațiile despre controlul debitului și al congestiilor sunt furnizate de către expeditorul (sursa) RTCP și rapoartele receptorului.
2.6. Resursele de implementare RTP[16]
RTP este un protocol deschis care nu oferă un sistem de telefonie preimplementat. Implementarea este strâns legată de aplicație. Programatorii trebuie să adauge toate funționalitățile la nivel de aplicație. De altfel, este mult mai eficient să folosești o aplicație gata facută, decât să o faci de la zero. RFC 3550 conține numeroase segmente de coduri, care pot fi folosite direct de către aplicații. Există pe Web și câteva implementări ale unor coduri sursă, care pot fi folosite în scopuri educative. Multe din acele module ale codurilor sursă, pot fi folosite dacă facem mici modificări.
2.7. Modificări aduse antetului RTP[16]
Formatul antetului RTP este considerat a fi complet pentru setul de funcții necesare pentru toate tipurile de aplicații suportate de RTP. Dar dacă unele aplicații speciale au nevoie de funcții adiționale, independente de formatul payload-ului, profilul sub care acele aplicații operează trebuie să definească câmpuri suplimentare care să urmeze dupa câmpul SSRC al antetului existent. Acele aplicații vor putea să acceseze direct și rapid câmpurile adiționale, și în același timp se pot procesa și pachetele RTP, interpretând numai primii 12 octeți.
2.7.1. Extensia antetului RTP[16]
Mecanismul de extensie există, pentru a permite implementărilor individuale să experimenteze noile funcții independente ale payload-ului, care necesită informații adiționale pentru a fi transmise în antetul pachetului de date RTP. Acest mecanism este proiectat în așa fel încât extensia antetului să fie ignorată de celelalte implementări care nu au fost extinse. Această extindere a antetului este destinată pentru utilizare limitată. Informațiile adiționale necesare pentru un format specific al payload-ului, nu ar trebui să folosească această extensie a antetului, dar ar trebui transportată în secțiunea payload-ului din pachet.
Figura 2.6. Extensia antetului RTP[16]
Dacă bitul X din antetul RTP este “1”, o extensie a antetului de lungime variabilă trebuie să fie anexată antetului RTP, urmând apoi lista CSRC, dacă există. Extensia antetului conține un câmp cu lungimea de 16 biți, care numără cuvinte de 32 de biți, exceptând extensia antetului de 4 octeți (zero, prin urmare, este o lungime valabilă).
Doar o singură extensie poate fi adăugată antetului de date RTP. Pentru a permite implementări multiple fiecărui experiment, independent și cu extensia antetului diferită, sau pentru a pemite implementări cu mai multe tipuri de extensii de antet, primii 16 biți ai extensiei antetului sunt lasați deschiși pentru a distinge identificatorii sau parametrii. Formatul acestor 16 biți sunt definiți de către specificațiile profilului. Specificațiile RTP-ului nu definesc nici o extensie a antetului.
Capitolul III
Profilul pentru conferințe audio și video cu control minim[7]
Vom descrie un profil numit „RTP/AVP”, folosit pentru utilizarea protocolului de transport în timp real RTP, versiunea 2, dar și pentru protocolul de control asociat, RTCP, în conferințele audio și video cu control minim. Furnizează interpretări ale câmpurilor generice din specificațiile RTP potrivite pentru conferințele audio și video. De asemenea vom descrie cum datele audio și video sunt transportate prin RTP, și vom trece în revistă un set de codări standard folosite în colaborare cu RTP.
3.1. Introducere[7]
Acest profil este destinat utilizării în cadrul conferințelor audio și video cu control minim. Profilul este de așteptat să fie folositor în sesiuni unde nu se utilizează controlul negocierii sau al membrilor, de asemenea mai poate fi folositor și în conjuncție cu protocoale de control de nivele superioare.
3.2. RTP și RTCP – Formatul pachetelor și comportamentul protocolului[7]
În general, acest profil adoptă aspectele de bază și/sau cele recomandate de specificațiile RTP.
Antetul de date RTP: este folosit formatul standard al antetului de date fix RTP (bitul marker pe „1”).
Tipul payload-ului (informația utilă): este folosit tipul static de payload.
Adăugiri ale antetului de date RTP: nu sunt adăugate câmpuri suplimentare antetului RTP.
Extensii ale antetului de date RTP: nu sunt definite extensii ale antetului, dar aplicațiile care operează în conformitate cu acest profil pot utiliza aceste extensii. În acest fel, aplicațiile nu ar trebui să presupună că bitul X al antetului RTP este tot timpul „0”, și ar trebui să fie pregătite să ignore extensia antetului.
Tipuri de pachete RTCP: nu sunt definite tipuri de pachete adiționale de către specificațiile acestui profil.
Intervalul raportului RTCP: constantele sugerate sunt folosite pentru calculul intervalelor rapoartelor RTCP. Lățimea de bandă a traficului RTCP poate fi divizată în două sesiuni separate, pentru acei participanți care sunt transmițători de date activi, și pentru cei care nu sunt. Recomandarea din specificațiile RTP sunt ca ¼ din lațimea de bandă să fie dedicată celor care transmit date, iar valorile recomandate pentru cele două sesiuni separate sunt 1,25% și respectiv 3,75% . Lățimea de bandă pentru transmițătorii de date ar trebui să fie nenula, pentru ca rapoartele transmițătorului să poată fi trimise pentru sincronizarea inter-media, și pentru a putea identifica sursa după numele canonic CNAME (Canonical NAME).
Extensiile SR/RR: nu este definită nici o extensie pentru pachetele RTCP SR sau RR.
Utilizarea SDES: aplicațiile pot folosi oricare dintre elementele descrise în specificațiile RTP. Dacă informațiile CNAME trebuie trimise la fiecare interval de raportare, alte elemente trebuie transmise numai la al treilea interval de raportare, numele (NAME) este transmis de șapte ori din cele opt, în acel slot, iar elementele SDES care au mai rămas, ocupă ciclic slotul opt. Cu alte cuvinte, „NAME” este transmis în pachetele RTCP 1, 4, 7, 10, 13, 16, 19, iar „EMAIL-ul” este utilizat în pachetul RTCP 22.
Securitate: serviciile de securitate ale protocolului RTP, sunt folosite și de către profilul RTP/AVP.
Maparea string-to key: nu este specificată nici o mapare de către acest profil.
Congestia: RTP, și acest profil poate fi folosit în contextul serviciilor îmbunătățite de rețea, de exemplu, prin Serviciile Integrate (RFC 1633), Serviciile Diferențiale (RFC 2475), sau pot fi folosite cu serviciile de tipul best effort (cel mai bun efort).
Dacă sunt folosite serviciile îmbunătățite, receptoarele RTP, ar trebui să monitorizeze pierderea de pachete, pentru a asigura faptul că serviciul solicitat este chiar emis. Dacă nu, atunci acestea ar trebui să presupună recepționarea serviciilor de tipul best effort, și să se comporte în consecință.
Dacă sunt folsite serviciile de tipul best effort, receptoarele RTP, ar trebui să monitorizeze pierderea de pachete, pentru a asigura faptul că rata pierderilor se află în parametrii acceptabili. Pierdera pachetelor se consideră acceptabilă, dacă un flux TCP peste aceeași cale de rețea și care întâmpină aceleași condiții de rețea, ar realiza o medie throughput(tranzitată), masurată pe un interval rezonabil de timp, care nu este mai mică decât ceea ce realizează fluxul RTP. Această condiție poate fi satisfăcută prin implementarea mecanismelor de control a congestiei, care să adapteze rata transmisiei (sau un număr de nivele subscris pentru o sesiune multicast stratificată), sau prin planificarea ca un receptor să părăsească sesiunea , dacă rata pierderilor este inacceptabil de mare.
Scara de timp pe care se măsoară tranzitul TCP, este timpul dus-întors al conexiunii RTT (Round Trip Time). În esență, această cerință afirmă că nu este acceptabil pentru a implementa o aplicație (folosind RTP sau orice alt protocol de transport), care consumă lățime de bandă în mod arbitrar, și nu concurează drept cu TCP-ul într-un ordin de mărime.
Profilul specifică utilizarea RTP-ului peste transmisii UDP unicast și multicast precum și peste TCP.
Încapsularea: profilul lasă la latitudinea aplicațiilor, specificațiile despre încapsularea RTP în protocoale, altele decât UDP.
3.3. Audio[7]
3.3.1 Regulile codării independente[7]
Deoarece capacitatea de a suprima tăcerea (intervalele de timp neutilizate) este una din principalele motivații pentru uilizarea pachetelor pentru a transimite voce, antetul RTP are inclus numărul secvenței dar și timestamp (timpul de transmisie), pentru a permite receptorului să facă disticția dintre pierderea de pachete și perioada de timp în care nu au fost transmise date.
Transmisia discontinuă (suprimarea tăcerii) poate fi folosită cu orice format audio. Receptoarele trebuie să presupună că emițătorii pot suprima tăcerea, cu excepția cazului în care acest lucru este restricționat de o semnalizare specificată în altă parte. Chiar dacă transmițătorul nu transmite dicontinuu, receptorul trebuie să fie pregătit să se ocupe de perioadele în care nu există informații, deoarece pachetele pot fi pierdute. Unele formate ale payload-ului definesc cadre ca: “silence insertion descriptor” sau ”confort noise”, pentru a specifica parametrii pentru zgomotul artificial, care poate fi generat în timpul unei perioade de liniște ca să aproximeze zgomotul de fond de la sursă.
Pentru aplicații care, în timpul perioadei de liniște, nu transmit nici un pachet, sau transmit ocazional pachete “confort noise”, primul pachet după această perioadă (în timpul careia pachetele nu au fost transmise continuu), trebuie deosebit de celelalte prin setarea bitului marker din antetul RTP la “1”. Bitul marker din toate celelalte pachete este “0”. Aplicațiile care nu au capacitatea de a suprima tăcerea, trebuie să seteze bitul marker la zero.
Dacă se folosesc canale audio multiple, atunci ele trebuiesc numerotate de la stânga la dreapta, începând cu unu. În pachetele audio RTP, informația provenită de la canalele cu număr mai mic, o precede pe cea provenită de la canalele cu număr mai mare. Pentru un număr mai mare de două canale, convenția stabilită de AIFF-C (Audio Interchange File Format), pentru formatul audio interschimbabil, trebuie urmată folosind următoarele notații, cu excepția cazului în care o altă convenție este stabilită, pentru un anumit tip de codare, sau format al sarcinii utile:
l – stânga
r – dreapta
c – centru
s – surround
f – față
r – spate
Tabelul 3.1.: Convenția AIFF-C, priviind sunetele pe mai multe canale
De reținut că în RFC 1890 erau definite două convenții pentru repartizarea pe patru canale audio. Având în vedere că repartizarea este indicată de numărul de canale, repartizarea tip “quadrophonic”, a fost eliminată în RFC 3551, fiind considerată ambiguă.
3.3.2. Recomandari pentru codările audio bazate pe eșantionare[14]
În codarile bazate pe eșantionare, fiecare eșantion audio este reprezentat de un număr fix de biți. Un pachet audio RTP poate conține orice număr de eșantioane audio, sub rezerva constrângerii că numărul de biți per eșantion se înmulțește cu numărului de eșantioane per pachete. Codările fracționare produc mai puțin de un octet per eșantion.
Perioada unui pachet audio este determinată de numărul de eșantioane din pachet. Eșantioanele din canalele diferite, eșantionat e cu același pas de eșantionare, ar trebui împachetate în octeți consecutivi. De exemplu, pentru o codare pe două canale, secvența de octeți este: (canalul din stânga, primul eșantion), (canalul din dreapta, primul eșantion), (canalul din stânga, al doilea eșantion), (canalul din dreapta, al doilea eșantion), …. Pentru codari multi-octeți, aceștia ar trebui să fie transmiși în rețea în ordine (primul să fie cel mai semnificativ octet).
Timestamp-ul (timpul de transmitere) RTP reflectă momentul în care primul eșantion din pachet a fost eșantionat, iar acesta este cea mai veche informație din pachet.
3.3.3. Recomandări pentru codările audio bazate pe cadre[14]
Codările bazate pe cadre, execută o codare a unui bloc audio de lungime fixă, într-un alt bloc de date comprimat, de obicei și acesta de lungime fixă. Pentru acest tip de codare, transmițătorul poate alege să combine mai multe cadre într-un singur pachet RTP. Receptorul poate știi numărul de cadre cuprinse într-un pachet RTP, dacă toate cadrele au aceeași lungime, prin divizarea lungimii payload-ului RTP cu mărimea cadrului audio, care este definit ca parte a codării. Acest lucru nu funcționează dacă există cadre de diferite dimensiuni, cu excepția cazului în care dimensiunile cadrelor sunt relativ prime. Astfel cadrele trebuie să-și indice dimensiunea.
Pentru codecuri bazate pe cadre, ordinea canalului este definită pentru întreg blocul. Astfel, pentru codări audio pe două canale, eșantioanele din dreapta și stânga, trebuie codate independent, cu cadrul pentru canalul din stânga precedând pe cel din canalul din dreapta.
Toate codecurile orientate pe cadre, trebuie să fie capabile să codeze și să decodeze mai multe cadre consecutive dintr-un singur pachet. Pachetele RTP trebuie să conțină un număr întreg de cadre, acestea fiind inserate în funcție de vechime în pachet, astfel ca cel mai vechi cadru (să fie rulat primul) să apară imediat după antetul pachetului RTP.
Timestamp-ul RTP reflectă momentul în care primul eșantion din primul cadru a fost eșantionat, iar acesta este cea mai veche informație din pachet.
3.3.4. Codecuri audio[10]
Caracteristicile codărilor audio sunt descrise in Tabelul 3.2, și sunt enumerate în ordinea tipului de payload din Tabelul 3.3. În timp ce majoritatea codecurilor audio sunt specificate pentru o rată fixă de prelevare a eșantioanelor, câțiva algoritmi (indicați de “var.” din coloana “rata de eșantionare” a Tabelului 3.2), pot fi folosiți cu diferite rate de eșantionare, rezultând rate de bit codate diferit.
Tabel 3.2. : Proprietățile codărilor audio (N/A : nu se aplică ; var. :variabil)
3.4. Video[7]
Toate aceste codări video folosesc o frecvență a timestampului de 90,000 Hz, la fel ca frecvența timestampului unei prezentări MPEG. În timp ce frecvența recomandată pentru viitoarele codări video utilizate de către acest profil este de 90 kHz, pot fi folosite și alte frecvențe. Cu toate acestea, nu este suficient să utilizăm rata cadrelor video (tipic între 15 și 30 Hz), deoarece nu livrează o rezoluție adecvată pentru cerințele de sincronizare, când se calculează timestamp-ul RTP, corespunzător timestamp-ului NTP dintr-un pachet RTCP de tipul SR. De asemenea, rezoluția timestamp-ului trebuie să fie suficientă pentru a estima bruiajul conținut în rapoartele receptorului.
Pentru majoritatea codărilor video, timestampul RTP codează eșantioanele prelevate, ale imaginii video conținute într-un pachet de date RTP. Dacă o imagine video ocupă mai mult de un pachet, atunci timestampul este la fel în toate acele pachete. Pachetele din imaginile video diferite, se disting prin timestamp-uri diferite.
Majoritatea codărilor video specifică de asemenea faptul că bitul marker, din antetul RTP, trebuie setat la “1” în ultimul pachet al cadrului video, și altfel setat la “0”.
Astfel, nu este necesar să așteptăm următorul pachet cu timestamp-ul diferit, ca să constatăm faptul că un nou cadru ar trebui sa fie afișat. Codările video dar și payload-ul acestora sunt enumerate în Tabelul 3.4.
3.5. Definițiile tipurilor de payload[7]
Tabelele 3.3, și 3.4, definesc valorile statice de payload ale acestui profil, pentru câmpul PT al antetulu RTP. În plus, tipurile de payload-uri din intervalul 96-127, pot fi definite dinamic printr-un protocol de control de conferință. De exemplu, pentru o sesiune dată, PT 96, indică o codare PCMU, cu o rată de eșantionare de 8,000 Hz, pe două canale.
Intrările din Tabelele 3.3 și 3.4, cu tipul de payload “dyn”, nu au asignate payload-uri statice, și sunt folosite numai cu payload dinamic. PT 2 a fost alocat codării G726-32, dar utilizarea sa este depășită, și acel tip de payload static este rezervat, ca urmare a conflictului dintre formatele G726-32 și AAL2-G726-32. PT 13 indică formatul de payload “Confort Noise”(zgomot de confort), CN. PT 19, este marcat ca ”rezervat”, pentru că unele versiuni au alocat acest număr într-o versiune anterioară, zgomotului de confort, CN. Intervalul de PT 72-76 este marcat ca “rezervat”, pentru ca pachetele RTP și RTCP, să poată fi distinse.
Tipurile de payload definite de acest profil, sunt atribuite unei categorii din trei, sau unui tip media: doar audio, doar video, precum și cele care combină mediul audio și video. Tipurile de media sunt marcate în Tabelele 3.3 și 3.4 cu “A”, ”V”, și respectiv cu ”AV”. Tipurile de payload de la medii diferite, nu vor putea fi multiplexate într-o singură sesiune RTP, dar mai multe sesiuni pot fi folosite în paralel, pentru a trimite mai multe tipuri media. O sursă RTP poate schimba tipul de payload din cadrul aceluiași tip de media în timpul unei sesiuni.
Tabelul 3.3. : Tipuri de payload PT (Payload Type), pentru codările audio
Tabelul 3.4. : Tipuri de payload PT (Payload Type), pentru codările video și cele combinate
Participanții la sesiune decid, prin anumite mecanisme, setul de payload-uri permise într-o sesiune dată. Acest set de payload-uri, poate fi definit de capabilitățile aplicațiilor folosite, negociat de un protocol de control pentru conferință, sau stabilit de comun acord de către participanți.
Aplicațiile audio care operează în conformitate cu acest profil ar trebui, cel puțin, să fie capabile să trimită și/sau să receptioneze PT 0 (PCMU) și PT 5 (DVI4). Acest lucru permite interoperabilitatea, fără negocierea formatului, și asigură negocieri de succes, cu un protocol de control pentru conferință.
Capitolul IV
Next Generation Network (NGN)[12]
Soluția care asigură convergența rețelelor de date cu cele de voce, oferind servicii multimedia este NGN – Next Generation Network.
4.1. Structura NGN[12]
NGN este un “schelet” pentru o infrastructură informatică globală prin care se asigură utilizatorilor servicii multimedia. Utilizatorii au acces la aceste servicii multimedia asigurate de NGN, oricând, de oriunde, și de la orice terminal (în limita capabilităților terminalului).
Arhitectura NGN este structurată pe nivele independente, care folosesc modul de transport pachet atât pentru voce cât și pentru date și care sunt reprezentate în Figura 4.1.
Figura 4.1. Structura NGN[12]
Nivelul terminalelor include toate tipurile de terminale: terminalul telefonic clasic (analogic), terminalul ISDN, terminalul ADSL, terminale de date (PC – personal computer) și terminalele mobile GSM (2G – 2,5G) și UMTS (3G). Nivelul terminalelor și nivelul acces cuprind și elemente specifice comunicațiilor mobile GSM și UMTS, deoarece tendința NGN este de a integra toate tipurile de comunicații într-o singură rețea. Terminalele pot opera în două domenii:
● CS (Circuit Switching)
● PS (Packet Switching)
Terminalele din domeniul CS rămân limitate la comutația de circuite de 64 kbps și nu asigură servicii multimedia. Domeniul CS este controlat de CSCS (Circuit Switched Call Server) din planul de control. Transformarea semnalului de voce în pachete IP se face fie în terminal fie în Media Gateway (MG).
Terminalele din domeniul PS asigură servicii multimedia (voce, video, date etc.). Controlul acestui domeniu este realizat de MMCS (MultiMedia Call Server), iar transformarea semnalelor în pachete IP este realizată exclusiv în terminal.
La nivelul terminalului se poate pune problema recunoașterii (autentificării) utilizatorului. În acest scop se poate folosi mecanismul bazat pe utilizator (nume utilizator) – parolă, sau autentificarea cu USIM (Universal Subscriber Identification Module), ca în comunicațiile mobile 3G.
NGN trebuie să asigure mobilitatea utilizatorului, sub următoarele aspecte:
▪ Mobilitate personală – posibilitatea de a folosi diferite terminale, cu pastrarea identității utilizatorului;
▪ Mobilitatea serviciului – posibilitatea de a avea acces la un serviciu anume, indiferent de terminal și de locul de acces;
▪ Mobilitatea terminalului – posibilitatea schimbării locației terminalului, cu păstrarea comunicației. Sub acest aspect se face distincție între mobilitatea discretă a terminalului (roaming) – fără ca terminalul să facă tranfer de informație pe timpul deplasării, și mobilitatea continuă (hand-over) – când transferul de informație nu se întrerupe pe durata deplasării. Managementul mobilității terminalului este singurul aspect al NGN specific mobilelor, toate celelalte funcții fiind comune pentru mobil și fix.
Nivelul acces și transport. Nivelul acces are rolul de a “ascunde” tipul de acces al utilizatorului față de sistem, astfel încât toți utilizatorii să fie tratați uniform de nivelele superioare; pentru utilizatorii mobili nivelul acces este responsabil cu managementul mobilității, care nu este vizibil pentru nivelele superioare, iar transportul cuprinde rețelele interne ale NGN (backbone), și tehnicile folosite pentru transportu (IP, ATM). Nivelul acces combină toate tehnicile de acces utilizate în prezent: telefonia clasică POTS, telefonia ISDN, ADSL, telefonia mobilă GSM – BSS/UMTS – RAN, HFC (Hibrid Fiber-Coax), LMDS (Local Multipoin Distribution System).
Nivelul media cuprinde echipamente de tip Media Gateway (MGW), cu rol de adaptare a datelor provenite de la diferite tipuri de terminale de acces la modul specific folosit în rețeauade transport (backbone): IP sau ATM. Se pot întâlni patru tipuri de MGW organizate în două categorii:
● MGW de acces, care cuprinde:
– Acces Gateway (AGW), localizat în centrală (între centrală și abonat)
– Residential Gateway (RGW), localizat la abonat
– Integrated Acces Devices (IAD), localizat la abonat, dar cu posibilități mai extinse decât RGW.
● MGW de trunchiuri (conexiuni între centrale), respectiv Trunking Gateway (TGW), localizat între centrale.
Protocoalele folosite la nivel de media sunt protocoalele pentru transmisia informației : RTP, împreună cu RTCP.
Nivelul control cuprinde echipamente care prelucrează informația de semnalizare (Signaling Gateway – SGW) și controlează apelul (Media Gateway Controller – MGC). MGC mai este denumit Call Server, Call Agent sau Softswitch deoarece îndeplinește o funcție similară centrului de comutație din rețeaua telefonică clasică.
SGW are rolul de a realiza conversia între sistemul de semnalizare ITU-T nr. 7 folosit în rețeaua telefonică clasică și semnalizarea bazată pe IP (SIGTRAN, definit de IETF).
MGW îndeplinește rolul de control al apelurilor (Softswitch) și de control al echpamentelor de tip Media Gateway, astfel încât acestea să rezerve resurse pentru conversia și transmisia semnalului asociat apelului.
Pentru stabilirea apelurilor, MGC pot folosi și alte protocoale:
● protocolul SIP, bazat pe clienți SIP și servere SIP, care schimbă mesaje simple și răspunsuri la mesaje;
● protocolul H323, bazat pe zone controlate de un Gatekeeper (GC), care asigură translatarea adreselor, controlul admisiei și managementul terminalelor din zona respectivă;
Există trei tipuri de MGC, denumite în continuare Call Server (CS):
● Multimedia CS (MMCS), care stabilesc conexiuni de tip multimedia;
● Circuit Switching CS (CSCS), care controlează comutația de circuite (pentru apeluri telefonice):
– Mobile CSCS pentru apeluri de la / spre mobil
– Fixed CSCS pentru apeluri de la / spre telefonia fixă.
Nivelul servicii înglobează elementele care asigură la nivel centralizat logica de tratare a serviciilor (Application Server – AS) precum și bazele de date asociate cu aceste servicii (Media Server – MS). Nivelul servicii este similar cu SCP (Service Control Point) din rețeaua inteligentă IN.
Nivelul management acoperă toate nivelele prezentate (mai puțin terminalele) asigurând managementul NGN sub toate aspectele : configurări, alarme și înlăturarea defecțiunilor, statistici de trafic, securitate, taxare.
4.2. Avantajele NGN[12]
Pentru producătorii de echipamente: o nouă piață de desfacere;
Pentru operator: posibilitatea de a oferi servicii de date și telefonie într-o singură rețea flexibilă (datorită modului de comutare de pachete și transportului IP);
Pentru utilizator: posibilitatea de a alege între mai mulți furnizori de acces, mai mulți furnizori de servicii și mai mulți operatori de transport, deoarece NGN permite coexistarea acestora pe baza unor interfețe deschise între nivelele funcționale, înlocuind modelul economic convențional operator-abonat;
Organizarea pe nivele independente interconectate prin interfețe deschise permite înlocuirea (upgrade hardware sau software) la un anumit nivel fără a fi necesară intervenția la celelalte nivele;
Centralizarea funcțiilor de control într-un număr redus de MGC reduce costurile de întreținere;
4.3. Tranziția spre NGN[12]
Se va face treptat, în primul rând din motive de cost. Deși echipamentele NGN sunt mai ieftine decât echipamentele unei rețele clasice (centrale telefonice și echipamente de transmisiuni), înlocuirea totală a rețelei existentă cu NGN nu este economică, mai ales în cazul în care rețeaua existentă a fost modernizată recent prin introducerea centralelor digitale de mare capacitate.
Prima etapă a tranziției va fi înlocuirea centralelor din clasa 4 (de tranzit) și a sitemelor de transmisiuni aferente cu elementele NGN și păstrarea centralelor locale (clasa 5), care se vor conecta la NGN prin Media Gateway pentru planul de comutație și prin Signalling Gateway pentru planul de semnalizare.
În următoarea etapă se vor înlocui centralele de tip 5 (locale) cu Media Gateway controlate de MGC.
Rețelele mobile, au trecut printr-o tranziție majoră în ultimii 20 ani. Prima generație, 1G, oferea servicii de bază, legate despre discurs. A doua generație, 2G, a adăugat câteva servicii suplimenare și servicii de date. A treia generație, 3G, permite viteze mai ridicate, dar și diverse servicii multimedia. Dispozitivele multimedia sunt mai tot timpul pornite și conectate la rețea. Acest lucru redfinește aplicațiile care nu mai lucrează izolat, ci sunt entități de tipul peer-to-peer (vârf la vârf), care facilitează partajarea: între browsere, între două sesiuni radio, etc. Apelarea și comunicarea vor deveni o parte îngustă a rețelisticii, iar abilitatea de a stabili o conexiune peer-to-peer între dispozitivele noului protocol Internet (IP), este condiția necesară.
Avem nevoie de de un sistem la nivel global, și anume IP Multimedia Subsystem (IMS) care permite aplicațiilor să stabilească conexiuni peer-to-peer sau peer-to-content, ușor și sigur. IMS este un sistem global, bazat pe conectivitate IP standard.
GSM (Global System for Mobile Communications) a fost definit de ETSI (European Telecommunications Standards Institute) între anii 1980 și 1990. ETSI de asemenea a mai definit și arhitectura rețelei GPRS (General Packet Radio Service). Ultimul standard GSM a fost produs în 1998, și în același an a fost fondată și 3GPP (Third Generation Partnership Project) de către organizațiile de de standardizare din Europa, USA, China, Japan și Korea de Sud. După Release (lansarea) 1999, Release 2000 a început să includă toate protocolalele Internet care au fost numite mai târziu IMS. Dezvoltarea IMS nu a fost terminată la sfârșitul anului 2000, și de aceea Release 2000 a fost împărțită în Release 4 și Release 5.
În final, 3GPP Release 5 a introdus IMS, o arhitectură bazată pe IP, independentă, care conlucrează cu rețelele existente de voce și date, pentru utilizatorii mobili și fixi.
4.4. Calitatea serviciului (QoS)[13]
QoS în NGN este în stânsă legătură cu QoS în rețeaua Internet având în vedere că NGN se bazează pe o rețea backbone IP.
Specificațiile originale IP nu garantează QoS (best effort – cel mai bun efort). Se pot folosi următoarele mecanisme pentru asigurarea calității :
● IntServ
● DiffServ
● MPLS
IntServ (Integrated Services) folosește protocolul RSVP (Resource Reservation Protocol) pentru a asigura un nivel QoS cerut pentru o conexiune cap la cap, prin rezervarea de bandă și prioritate de livrare.
Sunt posibile trei clase QoS :
▪ Best Effort (BE), care corespunde specificației originale Internet și nu garantează nimic în privința QoS (nu folosește RSVP) ;
▪ Controlled Local (CL), folosește RSVP pentru a garanta un QoS similar cu cel asigurat de o rețea slab încărcată ;
▪ Guaranteed Service (GS), care asigură un QoS garantat (limita superioară pentru întârziere și pierderi de pachete).
DiffServ (Differentiated Services): oferă utilizatorilor nivele diferite de QoS, simplu de implementat cu ajutorul unor câmpuri din antetul IP: ToS (Type of Service), prin care se stabilește o prioritate relativă a pachetelor care corespund cu diferite servicii.
MPLS – Multi Protocol Label Switching, folosește pentru controlul fluxului de date o etichetă prin care se asigură un nivel QoS impus.
4.5. Securitatea în NGN[11]
În NGN pot fi identificate patru aspecte privind cerințele de securitate:
▪ Securitatea calității serviciului (QoS), în scopul prevenirii folosirii neautorizate a resurselor rețelei și degradării calității serviciului din cauza traficului neautorizat;
▪ Securitatea infrastructurii rețelei, atât din punct de vedere funcțional al rețelei de telecomunicații propriu-zise, cât și din punct de vedete al securității controlului și managementului rețelei.
▪ Securitatea end-to-end, care asigură confidențialitatea și integritatea comunicației end-to-end;
▪ Securitatea punctului de acces, cu scopul prevenirii accesului neautorizat la terminalul utilizatorului și la datele memorate în acesta, precum și cu scopul de a preveni utilizarea neautorizată a terminalului utilizatorului, în scopul folosirii rețelei și serviciilor în contul acestui utilizator. Securitatea punctului de acces presupune folosirea unor proceduri de autentificare și autorizare;
4.5.1 Arhitectura de securitate în NGN[11]
Are în vedere:
▪ Proceduri securizate de acces, care sunt obligatorii având în vedere mobilitatea personală a utilizatorului, care se poate conecta oriunde la rețea, folosind orice terminal, păstrându-și identitatea ca utilizator. În acest sens NGN trebuie să suporte:
► Autentificarea cu parolă (PAP – Password Authentication Protocol)
► Autentificarea CHAP (Challenge Handshake Authentication Protocol)
► Autentificarea RADIUS (Remote Authentication Dial In Service)
▪ Securitatea în rețeaua de acces.
▪ Securitatea în rețeaua backbone a NGN (IPSEC – IP Security), cu unele aspecte specifice:
► Protocoale de securitate: autentificarea antetului (AH – Authentication Header), criptarea informației utile (ESP – Encapsulation Security Payload);
► Managementul cheilor de criptare: IKE – Internet Key Exchange;
► Algoritmi de criptare și autentificare: deși mecanismele IPSEC sunt concepute pentru a fi independente de algoritm (care poate fi ales de operator), este specificat un set de algoritmi standard pentru a asigura interoperabilitatea la nivel global;
► Utilizarea unui firewall și a unor filtre pentru limitarea accesului.
Capitolul V
Aspecte practice ale unei transmisii streaming
5.1. Echipamente necesare[16]
Pentru a transmite materiale prin video streaming trebuie să avem acces la o serie de produse:
■ Camera video
■ Microfon
■ Lumini
■ Computer
■ Soft pentru codare
■ Server pentru streaming
Camera video
Camerele digitale (digital video-DV) sunt de obicei mai scumpe decât cele analogice, dar au o calitate a imaginii mult mai bună. Dacă imaginile sunt salvate direct în format digital pierderile sunt mici în timpul capturii de pe camera DV pe calculator. Dacă camera este prevazută și cu un conector de tip FireWire captura poate să se realizeze în condiții optime.
FireWire este o interfața standard pentru calculatoare (PC-uri) și Macintosh-uri care permite transmisia directă a formatului audio/video digital între camera DV și calculator.
Formatele digitale utilizate sunt :
■ MiniDV – una dintre camerele performante pe care consumatorul o poate avea;
■ Digital 8 – aproape la fel de performantă ca și camera MiniDV, de dimensiuni mai mari și preț mai scăzut. Filmează în același format ca și camerele analog HI-8, oferind conexiune FireWire;
■ MicroMV – format digital introdus de Sony cu rezultate comparabile cu MiniDV, dar în casete cu 70% mai mici;
■ Camera Web – conectată direct la un calculator prin USB poate fi folosită pentru a transmite evenimente în direct. Soft-ul de care dispune, permite înregistrarea evenimentelor. Performanțele uneori lasă de dorit, dar alegerea acestei camere se datorează prețului scăzut.
Microfonul
Marea majoritate a camerelor sunt prevăzute cu microfon, iar cele mai performante sunt capabile să elimine zgomotul de fond. Dacă avem nevoie de mai multe microfoane, ar fi indicată folosirea unui mixer pentru a combina două sau mai multe canale de intrare într-unul singur.
Luminile
Luminile folosite depind de ceea ce dorim să filmăm. Când le utilizăm trebuie să fim atenți, deoarece pot apărea diferențe între ceea ce vedem, LCD-ul camerei și monitorul calculatorului.
5.2. Servere de streaming[14]
Avantajul serverelor de streaming fața de serverele uzuale îl reprezintă abilitatea de a proteja proprietatea intelectuală (fișierul nu este descărcat) și faptul că utilizatorii pot ‘interacționa’ cu fișierul (pot derula înainte și înapoi în timp real). De asemenea în cazul streamingului se asigură un control bun asupra accesului utilizatorilor la fișiere.
Pentru o configurație de server streaming se recomandă un minim necesar :
▪ procesor > 1 GHz. Un sistem multi procesor îmbunătățește performanțele și crește abilitațile de multi-tasking ale sistemului;
▪ 1 GB RAM memorie minim. De regulă aceste servere oferă și servicii de FTP și Web. Dimensiunea mică a memoriei va determina scăderea dramatică a eficenței server-ului;
▪ capacitați de stocare mari. Mai multe opțiuni sunt disponibile în materie de capacitate de stocare; se recomandă folosirea sistemelor RAID, deoarece permit ca HDD-urile să fie legate împreună ca un singur disc, back-up-ul realizându-se de asemenea mai ușor. Sistemele RAID au timpi de acces foarte mici și sunt foarte rapide, oferind un avantaj serverelor care realizează mai multe operații;
▪ raport viteză/rată de transmisie optim. Nu are sens un server puternic, rapid, dacă conexiunea nu suportă ratele respective ;
▪ pentru transmisii live este necesară prezența plăcii de captură în cazul utilizării unei surse analogice și/sau a porturilor fireware pentru sursele digtale.Este indicată utilizarea unor plăci de captura dedicate/specializate cu capacitați de compresie pe placă pentru a nu folosi resursele de procesare ale serverului.
În unele sisteme, captura și partea de server se fac în același loc. Se recomandă două ‘dispozitive’ diferite, astfel încât dacă o parte ‘cade’, se defectează, se înlocuiește partea respectivă și un intreg sistemul. În orice situație se poate utiliza un sistem de back-up.
Toate formatele majore de streaming oferă soft pe partea de server care controlează accesul și distribuția. Acest soft trebuie să ruleze pe un calculator cu un sistem de operare corespunzător : Linux, MS Server, OS.
Alegerea serverului cu care se va face streaming-ul este importantă deoarece :
▪ sunt influențați direct parametrii transmisiei, formatele de fișiere care vor fi oferite, precum și numarul de utilizatori care pot accesa simultan transmisia;
▪ costurile sunt diferite, putându-se ajunge la peste 10.000 $;
▪ diferă posibilitatea de configurare a parametrilor de funcționare, de realizare a securitații datelor.
5.2.1. Soluții comerciale[14]
RealNetworks Server
Este destul de stabil, rapid, utilizează o interfață agreabilă, este securizat și are capabilitați de control de la distanța (remote). Este suportat de Microsoft Windows, Linux, FreeBSD și Solaris, cu abilitați de transmitere pe toate dispozitivele media. Ușor de configurat, permite lucrul cu alte servicii și cu alte programe de streaming. Dezavantajul serviciului este costul ridicat.
Helix Universal Server, care tinde să înlocuiască RealSystem Server, afirmă că reduce costul supotând formatele de streaming: Windows Media, QuickTime, RealVideo, precum și MPEG (MPEG-1, MPEG-2, MPEG-3 și MPEG-4). O versiune gratuită a acestui program există, cu mențiunea că numărul persoanelor care pot accesa conținutul simultan este limitat la 10, iar licența este valabilă un an.
Serverul permite selectarea automată a codării potrivită fiecărui utilizator atunci când acesta se conectează. Dacă banda disponibilă utilizatorului scade, serverul va trece la o codare inferioară, astfel încât transmisia nu se întrerupe, iar când banda revine la valori mai mari, se va trece din nou la rate de codare mai mari.
Microsoft Windows Media Server
Spre deosebire de RealNetworks, Media Server rulează doar pe un server Windows. Un avantaj al acestei soluții îl reprezintă abilitatea de a transmite la peste 3000 de utilizatori fară să implice cheltuieli de licența suplimentare. Nu este la fel de sigur ca RealNetworks; aceasta nu însemnă că serverul și fișierele pot fi atacate/modificate, dar au fost create programe care permit utilizatorilor să înregistreze secvențele video transmise prin streaming.
Clienții pot fi dispozitive ce utiltizează un player precum Windows Media Player sau alte calculatoare pe care rulează Windows Media Services, depozitând sau redistribuind informațiile.
Apple QuickTime Streaming Server
Este destinat exclusiv calculatoarelor Macintosh și suportă formate ca : MOV, MP3, MPEG-4, Shockware Flash și peste 4000 de utilizatori.
Avantajul îl constituie calitatea secvențelor video, codate după algoritmi specifici. Este un factor decisiv pentru multe companii cinematografice în acțiunea lor de lansare a filmelor de prezentare (trailere-lor) pe web (http://www.apple.com/trailers/). Dezavantajul apare la viteze de transmisie mici; calitatea este inferioară celorlalte soluții oferite datorită arhitecturii codecurilor folosite precum și grupului țintă ales.
Flash Media Server
Serviciile de streaming pentru ‘flash’ au fost introduse o dată cu apariția pe piață a produselor Flash MX, Flash Player 6 și Flash Communication Server MX.
Dintre caracteristici amintesc :
▪ determinarea lărgimii de bandă a clientului și furnizarea unui streaming cu o rată de bit adecvată;
▪ măsurarea și urmărirea calității streaming-ului, comutarea la o rată de bit mai mică, dacă rețeaua este congestionată;
▪ generarea automată de thumbnail-uri sau rularea de mici preview-uri ale clipului fară crearea unei imagini separate sau a unui alt clip video;
▪ webcastingul live.
Prețul acestui pachet software este însa unul ridicat : ~ 4500$ .
5.2.2. Soluții Open Source[14]
Soluțiile Open Source oferă posibilitatea utilizării gratuite a alicațiilor și continuă dezvoltarea în funcție de nevoile utilizatorilor. Existența unei comunități largi de utilizatori și dezvoltatori duce în mod automat la o evoluție rapidă a soluțiilor oferite, cel puțin teoretic.
VLC Streaming Server
VLC este una dintre aplicațiile cu cea mai spectaculoasă evoluție într-un timp relativ scurt de la lansarea proiectului.
Darwin Streaming Server
Darwin Streaming Server este versiunea Open Source a Apple QuickTime Streaming, versiune bazată e PERL și pusă la dispoziția dezvoltătorilor cu apariția QuickTime 5.
Sistemele de operare compatibile sunt : Mac OS X, Windows XP și Windows NT Server/Windows Server, RedHat 7.1, Solaris, FreeBSD. Fiind realizat din scripturi PERL, această versiune este dificil de configurat pentru necunoscătorii limbajului, dar oferă o mare diversitate de formate suportate pentru streaming, standarde media MPEG-4 și 3GPP, configurări remote prin intermediul unei interfețe web, precum și peste 2000 de utilizatori suportați de server simultan. Protocoalele utilizate sunt RTP/RTSP în modul unicast sau multicast.
5.3. VLC[19]
5.3.1 Generalități[19]
VLC (VideoLAN Client) face parte din proiectul VideoLAN ce se dorește a fi o soluție completă pentru streaming si playback. A fost dezvoltat de către studenții de la Ecole Centrale Paris și alți dezvoltatori din întreaga lume sub licența GNU (General Public License).
Se caracterizează prin posibilitatea utilizării pe diferite platforme : Windows, Mac OS X, BeOS, Debian GNU/Linux, Ubuntu Linux, Mandriva Linux, Fedora Core, Familiar Linux, SUSE Linux, Red Hat Linux, Slakware Linux, ALT Linux, YOPY/Linupy, Zaurus, WinCE / PocketPC, Arch Linux, NetBSD, OpenBSD, FreeBSD, Solaris, QNX, Gentoo Linux, Crux Linux.
Poate citi :
▪ MPEG-1, MPEG-2 și MPEG-4 / DivX de pe hard disc sau CD-ROM
▪ DVD și VCD
▪ de la carduri de satelit (DVB-S)
▪ de la camere video (DV)
▪ streamuri din rețeaua locală sau Internet.
VLC este utilizat ca și server de streaming pentru a genera fluxuri de date :
▪ MPEG-1, MPEG-2 și MPEG-4 / DivX ;
▪ DVD ;
▪ captate de la diverse plăci de achiziții MPEG ;
▪ de la camere video la : – un dispozitiv printr-o adresa IP – unicast.
– un grup dinamic de dispozitive unde clienții se pot loga sau pot părăsi transmisia- multicast.
Figura 5.1. Input/Output VLC[19]
5.3.2. Codec/container[20]
Un codec este un algoritm de compresie utilizat pentru a reduce dimensiunea unui stream, codarea propriu-zisă presupunând o compresie dintr-un format într-altul ce ocupă mai puțin spațiu decât precedentul. Avem de a face cu codec-uri audio/video MP3, MPEG1, MPEG2, MPEG4, Ogg-vorbis, DivX etc.
Un ‘container’ conține mai multe stream-uri codate/compresate de diverse codec-uri. AVI, MOV, Ogg, ASF, MP4 sunt containere. Conținutul unui stream poate fi codat utilizând diverse codec-uri, într-o lume perfectă putem pune orice codec în orice container. Se găsește o listă completă la adresa : http://www.videolan.org/streaming/ features.html. Stream-urile codate se multiplexează, aceasta însemnând că părți separate ale materialului de transmis se combină într-un singur container.
Vizualizarea video: pentru a decoda un stream, VLC-ul îl demultiplexează mai întâi, citește conținutul container-ului și separă audio de video, eventual de subtitrare dacă există. Demultiplexarea nu presupune pierdera calității, înseamnă doar separarea în stream-uri individuale. Ulterior, pentru fiecare stream urmează procesul de decodare, procesul matematic propriu-zis de decompresie.
5.3.3 Particularități MPEG[18]
MPEG este un codec, și există mai multe versiuni, MPEG1, MPEG2, MPEG4… .
MPEG este de asemenea și un container cunoscut ca și MPEG System. Distingem MPEG, ES, PS, TS.
Vom lua ca exemplu vizualizarea unui MPEG de pe DVD, unde stream-ul principal MPEG este compus din mai multe Elementary Streams (ES): există câte un stream pentru video, pentru audio și pentru subtitrare, dacă este cazul. Aceste stream-uri elementare sunt combinate într-un singur Program Stream (PS). Prin urmare fișierele cu extensia VOB, ce se găsesc pe DVD sunt fișiere MPEG PS. Acest format nu este întotdeauna adaptat pentru transmiterea de conținut audio-video print-o rețea de date sau prin satelit (streaming), de aceea a fost proiectat un alt format, Transport Stream (TS), pentru astfel de situații.
5.4. Streaming utilizând linia de comandă[18]
Modulele disponibile sunt:
● standard – permite transmiterea stream-ului prin UDP, HTTP, fișier etc.
● transcode – permite codarea și decodarea (utilizând codec-uri/bitrate-uri diferite) părții audio și video a fluxului de intrare.
● duplicate – permite crearea unui lanț secundar pentru streaming, unde stream-ul poate fi tratat într-un mod independent.
● display – permite vizualizarea stream-ului de intrare. În combinație cu duplicate se monitorizează fluxul de date în timpul procesării.
● rtp – permite folosirea RTP/RTSP.
● es – permite creearea de stream-uri elementare separate.
5.5. Instalarea și configurarea serverului VLC[19]
Se instalează VLC, iar figura de mai jos ne arată interfața cu utilizatorul.
Pentru încărcarea unui fișier audio/video, se parcurg următorii pași : ‘Media > Streaming’, pentru a deschide fereastra ‘Open’, apoi se selectează fișierul dorit, și se apasă butonul ‘Stream’.
Figura 5.2. Programul VLC[19]
Figura 5.3. Uploadarea unui fișier[19]
Se bifează căsuța ‘Play locally’ de sub meniul ‘Outputs’. Când se face streaming către un alt calculator, nu este neapărat sa rulăm fișierul respectiv și pe server, dar noi vom folosi această opțiune pentru a confirma faptul că filmul nostru merge normal, înainte de a accesa stream-ul de pe alt calculator.
Se bifează căsuța cu protocolul pe care dorim sa-l utilizăm, în cazul nostru RTP, se introduce adresa IP a calculatorului pe care dorim să stream-uim fișierul, și numărul de port (în cazul unui fișier audio-video, transmisia se face pe două canale, și deci trebuie folosit un port pentru audio, și unul pentru video).
Apoi se alege metoda de încapsulare, se bifează căsuța ‘Keep stream output open’, și se apasă butonul ‘Stream’.
Figura 5.4. Configurarea VLC-ului[19]
Play locally : permite vizualizarea stream-ului pe calculatorul propriu, oferindu-se posibilitatea monitorizării locale a efectelor de codare, rescalare etc.
File: permite salvarea stream-ului într-un fișier.
HTTP: permite stream-ul pentru Microsoft Windows Media Player. Se specifică adresa IP și portul TCP, unde stream-ul va putea fi vizualizat. Funcționează doar cu metoda de “încapsulare” ASF.
UDP: permite streamingul în unicast cu adrese între 0.0.0.0 – 223.255.255.255 și multicast.
RTP: utilizează protocolul Real Time Transfer Protocol. Ca și la UDP, se poate face streaming unicast și multicast.
Metode de încapsulare: presupun alegerea unui container MPEG TS, MPEG PS, MPEG1, OGG, Raw, ASF, AVI, MP4 și MOV care să se potrivească codec-urilor audio și video. Aceste codecuri sunt selectate dintr-o listă pusă la dispoziție de VLC în interfața grafică aferentă (mărimi ca rata de bit pentru codecul video sau audio, numărul de canale audio, pot lua diferite valori).
Figura 5.5. Ajustarea ratei de bit[19]
Fișierul audio sau video, ar trebui să înceapă să ruleze pe server. Ultimul lucru înainte de a trece la celălalt calculator, este de a activa interfața Web a VLC-ului, prin parcurgerea următorilor pași: ‘Tools > Add Interface > Web Interface’.
Se deschide VLC-ul pe calculatorul client, se face click pe ‘Media > Open Network’, pentru a deschide fereastra ‘Open’, se selectează protocolul dorit, RTP, apoi se apasă butonul ‘Play’, iar VLC-ul va începe redarea stream-ului.
Figura 5.6. Deschiderea stream-ului de pe un calculator client[19]
Acum, dacă stream-ul este redat cu succes, se poate deschide un browser Web, pentru a controla VLC-ul de la distanță. Tipăriți în bara de adrese: http://<IP-ul serverului>:8080/ . Browser-ul de web va furniza toate controalele de care avem nevoie pentru a gestiona fișierul la distanță.
Figura 5.7. Streamul audio/video care rulează de pe calculatorul client[19]
5.6. Analizoare de trafic de rețea[16]
Analizoarele de trafic de rețea sunt în general instrumente software care sunt capabile să capteze și să analizeze traficul transmis sau recepționat de către un calculator care este conectat într-o rețea. Aceste instrumente pot fi utilizate atât în scop de studiu al funcționării protocoalelor de rețea (mecanisme, structura cadrelor etc), cât și pentru îmbunătățirea funcționalității și a securității rețelei.
Cele mai multe dintre aceste instrumente se descarcă gratuit de pe Internet, unele dintre ele fiind chiar părți integrante ale unor sisteme de operare. Câteva analizoare de rețea (packet sniffer) des folosite sunt: Ethereal, Wireshark (versiunea nouă a lui Ethereal), Microsoft Network Monitor (pachet suplimentar al sistemelor de operare Windows), ettercap (program ce poate fi folosit pentru capturarea parolelor transmise într-o rețea de către unele protocoale de nivel aplicație), ufasoft_sniffer (care poate fi folosit pentru interpretarea pachetelor de pe diferite interfețe), trafmeter (este folosit pentru evidențierea grafică a ratei de transfer).
5.7. Wireshark[8]
Prin folosirea acestui program se poate urmări traficul care se realizează între client și serverul de video streaming. Pentru aceasta se realizează următori pași:
Din meniul programului “Wireshark” se alege interfața care se dorește a fi spionată. Pentru aceasta se alege: Capture > Interfaces.
Pe ecran vor apărea diverse pachete, care reprezintă comunicarea între stațiile din rețea (în cazul nostru , majoritatea pachetelor sunt RTP și reprezintă comunicarea clientului cu serverul de video streaming).
Figura 5.8. Pachetele RTP care apar în timpul conexiunii[8]
Din fereastra inițială a programului se alege Statistics > IO Graphs și se pornește captura. În figura de mai jos se poate observa cantitatea de informații care este transmisă de pe calculatorul client, pe server
Figura 5.9. Pachetele capturate într-un interval de timp[8]
Concluzii
În Internet, la fel ca și în alte rețele, este posibilă pierderea pachetelor, schimbarea ordinii în procesul de transmitere, de asemenea variază timpului de transmitere a pachetelor la distanțe mari. Aplicațiile multimedia pun condiții foarte dure asupra ambianței de transmitere. Pentru convenirea cu posibilitățile Internetului a fost creat protocolul RTP. Protocolul RTP este bazat pe cadre, și are scopul de a transmite date audio și video în timp real. RTP furnizează transport în timp real, numerotarea secvențelor, identificarea informației utile, sincronizarea Intra și Intermedia, criptare, multicast, nu oferă calitatea serviciului, și nu necesită rezervarea de resurse.
RTCP-ul este folosit pentru raportul QoS, și anume raportul emițătorului (pachete transmise), și raportul receptorului (pierderi, întârzieri, bruiaj). Se mai folosește pentru sincronizare Media (corelarea etichetei de timp a RTP-ului). Aplicațiile de obicei folosesc RTP implementat peste UDP, pentru ca să se poată folosi de posibilitatea sa de multiplexare dar și de verificarea unei sume ciclice. RTP se poate folosi de asemenea și deasupra oricărui protocol de nivel 4 OSI (Open Systems Interconnect).
Întârzierea și jitterul întârzierii, sunt principalele aspecte ale transmisiunilor în timp real, iar traficul în timp real necesită mult mai multă lățime de bandă, decât traficul de tipul best effort. Din cauza întârzierilor care apar pe rețea, eșantioanele de sunet nu vin la timp, și atunci vocea va părea ciudată, iar acest lucru va fi sesizat de către utilizator, la fel se întâmplă și în cazul eșantioanelor video. În transportul în timp real, cel mai important lucru care se dorește, este ca lățimea de bandă să fie împărțită în mod egal în rândul utilizatorilor.
Streaming-ul a cauzat o profundă schimbare în educație, mass-media, divertisment, afaceri, combinând promptitudinea televiziunii cu interactivitatea Internetului, continuând să revoluționeze peisajul media actual, adăugând noi elemente.
Rețelele multimedia vor impulsiona utilizarea calculatorului ca instrument de comunicare. Eu cred că într-o zi, rețelele mutimedia vor înlocui serviciul de telefonie, televiziunea și alte invenții care ne-au schimbat radical viața.
Deci, proiectarea protocolalelor în timp real pentru rețelele multimedia, devine necesară, înainte de sosirea erei multimedia
BIBLIOGRAFIE:
[1] Mircea Vladuțiu, Marius Marcu, A genetic algorithm for Thermal Image Deconvultion, Iranial Journal of Electrical and Computer Engineering, vol 3, No2, Summer-Fall 2004
[2] Horia Ciocârlie , Rodica Ciocârlie, Utilizarea si programarea calculatoarelor , Orizonturi Universitare 2004
[3] Silea Ioan, Administrarea rețelelor de calculatoare, Centrul de multiplicare al Universității Politechnica din Timișoara ,2001
[4] Titu I Bajenescu, Retele inteligente , Editura Teora, 2008
[5] Arhitectura retelelor de telecomunicatii , Editura Politehnica 2004
[6] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RFC 3550: "RTP: A Transport Protocol for Real-Time Applications", 2003. http://tools.ietf.org/html/rfc3550
[7] H. Schulzrinne, S. Casner , RFC 3551: "RTP Profile for Audio and Video Conferences with Minimal Control"; 2003. http://tools.ietf.org/html/rfc3551
[8] Alan B. Johnston, Understanding the Session Initiation Protocol, 2012
[9] Henning Schulzrinne, RTP, http://www.cs.columbia.edu/~hgs/rtp/.
[10] Chunlei Liu, Multimedia Over IP: RSVP, RTP, RTCP, RTSP
[11] Ian Wakeman, Jon Crowcroft, "Tunnelling RTSP and RTP through HTTP". A standard solution to help RTSP work through firewalls and web proxies, Computer Science Department, University College London, 2013
[12] Rafael Osso, Handbook of Emerging Communications Technologies: The Next Decade, 2011
[13] Real-time Transport Protocol (RTP), defined in RFC 3550, Hasselt University, 2013
[14] Javvin Technologies, "RTP". Network Protocols Handbook. 2012
[15] RTP. Broadband Networks. Ministry of Human resources, India. 2008.
[16] Addison-Wesley, RTP : Audio and video for the Internet / Colin Perkins, Boston, 2013
[17] Simon MORLAT, http://www.linphone.org/eng/documentation/dev/ortp.html
[18] http://en.wikipedia.org/wiki/Streaming_media
[19] http://www.videolan.org/vlc/
[20] http://en.wikipedia.org/wiki/Audio_Interchange_File_Format
Cuprins
Cuprins
Capitolul I
RTP și Internetul
1.1. O scurtă istorie a RTP
1.2. Stiva de protocoale Internet și Multimedia.
1.2.1. Nivelul Fizic
1.2.2. Nivelul Internet
1.2.3. Nivelul Transport
1.2.3.1. TCP
1.2.3.2. UDP
1.2.3.3. TLS
1.2.3.4. SCTP
1.2.4. Nivelul Aplicație
1.3. Aplicații
1.4. DNS și adresele IP
1.5. URL-uri si URI-uri
1.6. Multicast
Capitolul II
Protocoalele de transport pentru aplicații în timp real
2.1. Domenii de utilizare a RTP-ului
2.1.1. Conferințe audio tip multicast
2.1.2. Conferințe audio și video
2.1.3. Multiplexoare și Translatoare
2.1.4. Codări stratificate
2.2. Noțiuni generale / definiții
2.3. RTP – Protocolul de transfer de date
2.3.1. Dezvoltare
2.3.2. Cum funcționează RTP
2.3.3. Structura pachetului
2.4. RTCP – Protocolul de control în timp real
2.5. Caracteristicile RTP-ului
2.6. Resursele de implementare RTP
2.7. Modificări aduse antetului RTP
2.7.1. Extensia antetului RTP
Capitolul III
Profilul pentru conferințe audio și video cu control minim
3.1. Introducere
3.2. RTP și RTCP – Formatul pachetelor și comportamentul protocolului
3.3. Audio
3.3.1 Regulile codării independente
3.3.2. Recomandari pentru codările audio bazate pe eșantionare
3.3.3. Recomandări pentru codările audio bazate pe cadre
3.3.4. Codecuri audio
3.4. Video
3.5. Definițiile tipurilor de payload
Capitolul IV
Next Generation Network (NGN)
4.1. Structura NGN
4.2. Avantajele NGN
4.3. Tranziția spre NGN
4.4. Calitatea serviciului (QoS)
4.5. Securitatea în NGN
4.5.1 Arhitectura de securitate în NGN
Capitolul V
Aspecte practice ale unei transmisii streaming
5.1. Echipamente necesare
5.2. Servere de streaming
5.2.1. Soluții comerciale
5.2.2. Soluții Open Source
5.3. VLC
5.3.1 Generalități
5.3.2. Codec/container
5.3.3 Particularități MPEG
5.4. Streaming utilizând linia de comandă
5.5. Instalarea și configurarea serverului VLC
5.6. Analizoare de trafic de rețea
5.7. Wireshark
Concluzii
BIBLIOGRAFIE:
Introducere
Rețelele de calculatoare au fost proiectate să conecteze computere din diferite locații pentru a putea împărtăși datele și pentru a comunica. În urmă, majoritatea informațiilor transportate prin rețele au fost sub formã de text. Astăzi, cu evoluția tehnologiilor multimedia dar și celor de rețea, multimedia a ajuns o caracteristică indispensabilă a Internetului. Animația, vocea, clipurile video, toate acestea au devenit din ce în ce mai populare pe Internet. Produsele multimedia ca telefonia pe Internet, TV pe Internet, conferințele video, au apărut pe piață.
Rețelele multimedia vor impulsiona utilizarea calculatorului ca instrument de comunicare. Eu cred că într-o zi, rețelele mutimedia vor înlocui seviciul de telefonie, televiziunea și alte invenții care ne-au schimbat radical viața.
1. Provocarea “real-time”[4]
Ne puteam aștepta la cel puțin trei probleme, în primul rând comparând cu aplicațiile tradiționale sub formă de text, aplicațiile multimedia necesită lățime de bandă mult mai mare. De exemplu un segment dintr-un filmuleț, cu rezoluția de 320×240, de 25 secunde, poate solicita pâna la 2.3 MB, și este echivalentul la aproximativ 1000 de screens (ecrane) de date sub formă de text. Acest lucru era de neimaginat în trecut, când numai informațiile sub formă de text erau transmise pe rețea.
În al doilea rând, majoritatea aplicațiilor multimedia necesită traficul în timp real. Datele audio și video trebuie redate continuu, la rata la care sunt eșantionate. Dacă datele nu ajung la timp, procesul de redare va înceta, iar utilizatorul va sesiza acest lucru. În cazul telefoniei pe Internet, omul poate tolera o latență de aproximativ 250 milisecunde. Dacă întârzierea va depăși această limită, vocea va suna ciudat, iar utilizatorii se vor plânge legat de calitatea apelului. De asemenea congestiile din rețele, au un efect destul de grav asupra traficului în timp real. Dacă rețeaua este congestionată, singurul efect în rețelele fară trafic în timp real, este că durează mai mult timp până când se termină transferul de date, în schimb datele în timp real devin « învechite » și vor fi «aruncate » dacă nu ajung la timp. Dacă nu se ia nici o măsură adecvată, retransmiterea pachetelor pierdute ar agrava și mai mult situația și ar bloca rețeaua.
În al treilea rând, fluxurile de date mutimedia sunt de obicei transmise în rafale. Doar creșterea lățimii de bandă nu va rezolva această problemă. Pentru majoritatea aplicațiilor multimedia, receptorul are o memorie tampon limitată. Dacă nu se i-a nici o măsură pentru a regulariza fluxul de date, atunci memoria tampon, ar putea deveni sau neîncăpătoare, sau neocupată. Când informațiile ajung prea repede, memoria va fi neîncăpătoare, și unele pachete de date vor fi pierdute, rezultând o calitate slabă. Când informațiile ajung prea încet, memoria va fi prea neocupată, iar aplicația va fi lipsită de informații.
Spre deosebire de lățimea de bandă mare, trafic de date în timp real și în rafale, în viața reală, rețele sunt împărțite de mii și milioane de utilizatori, și au banda limitată și întârzieri imprevizibile. Cum să rezolve aceste conflicte este o provocare la care rețelele multimedia trebuie să facă față.
Posibilitatea de a răspunde la această provocare vine de la arhitectura software a rețelei existente, și de la hardware-ul în curs de dezvoltare. Bazele Interentului, TCP/IP și UDP/IP, oferă o gamă de servicii pe care aplicațiile multimedia le pot folosi. Rețele rapide, cum ar fi Gigabit Ethernet, FDDI (Fiber Distributed Data Interface), și ATM (Asynchronous Transfer Mode), furnizează lățime de bandă mare, solicitată de către mediile audio și video.
Deci, proiectarea protocolalelor în timp real pentru rețelele multimedia, devine necesară, înainte de sosirea erei multimedia.
2. Multimedia peste Internet [7]
Există și alte metode de a transmite datele multimedia, cum ar fi legături (links) dedicate, cabluri, și ATM-uri. Cu toate acestea, ideea de a rula multimedia peste Internet este extrem de atractivă.
Legăturile dedicate și cablurile nu sunt practice deoarece au nevoie de instalare și de software nou. Fără o tehnologie existentă cum ar fi LAN (Local Area Network), WAN (Wide Area Network), dezvoltarea software va fi foarte scumpă. ATM a fost declarat a fi o ultimă soluție pentru multimedia, deoarece suportă lățimi de bandă foarte mari, este orientat pe conexiune, și poate ajusta alt nivel de calitate al serviciului pentru diferitele tipuri de aplicații, dar în acest moment, foarte puțini utilizatori beneficiază de rețele ATM, și chiar mai puțini sunt cei care au conexiuni ATM la calculatoare.
Pe de altă parte, Internetul crește exponențial. Bine stabilitele tehnologii LAN și WAN, bazate pe protocolul IP, leagă rețele tot mai mari, de peste tot în lume la Internet. De fapt, Internetul a devenit platforma cu cele mai multe activități de rețea. Acesta este și motivul principal pentru a dezvolta multimedia peste Internet. Un alt avantaj este faptul că utilizatorii pot avea date integrate și servicii multimedia, într-o singură rețea, fără a fi nevoie de o altă rețea, infrastructură, sau interfață între cele două rețele.
La ora actuală, IP-ul și Ethernet-ul par a fi mai favorizate în birou și în LAN-uri, iar ATM-ul în WAN-uri.
Pentru a rula multimedia peste Internet, mai multe probleme trebuie să fie rezolvate. În primul rând, multimedia înseamnă date compacte și trafic încărcat, iar rețeaua trebuie să ofere suficientă lațime de bandă.
În al doilea rând, aplicațiile multimedia sunt de obicei legate de multicast – același flux de date, este transmis unui grup de utilizatori. De exemplu, într-o video conferință, datele video în timp real trebuie transmise către toți participanții în același timp. Protocoalele proiectate pentru aplicații multimedia, trebuie să folosească multicast-ul pentru a reduce traficul.
În al treilea rând, Internetul este o rețea de comutare de pachete, iar acestea sunt rutate independent prin rețelele partajate.Tehnologiile actuale nu pot garanta faptul că datele în timp real vor ajunge la destinație, fără a fi sacadate sau pierdute. Unele protocoale de transport trebuie să fie utilizate pentru a avea grijă de problemele de sincronizare, astfel încât datele audio și video să poată fi redate continuu, sincronizate și în timp util.
Răspunsurile la problemele de mai sus, sunt protocoalele care vor fi discutate în această lucrare.
Capitolul I
RTP și Internetul[10]
Protocolul de Transport în Timp Real (RTP) se bazează pe ideile propuse de Klark și Tenenhauzen, și are scopul de a transmite datele audio și video în timp real.
Acest capitol acoperă istoria protocoalelor de timp real, cât și despre arhitectura RTP-ului, care a fost proiectat să se potrivească cu alte protocoale cum ar fi: TCP (Transport Control Protocol), UDP (User Datagram Protocol), TLS (Transport Layer Protocol), IP (Internet Protocol), DNS (Domain Name System), și altele.
1.1. O scurtă istorie a RTP[10]
Încercări de a transmite voce pe o rețea au început în prima parte a anului 1970. Mai multe brevete despre conferință, timestamp (marcarea cu o ștampilă de timp), și sequence numbering (numerotarea secvențelor), au fost obținute în 1970 și 1980. În 1991, o serie de experimente de voce au fost finalizate la DARTnet. În August 1991, Network Reserch Group de la Laboratorul Național Lawrence Berkeley, au lansat un instrument de conferințe audio “vat”, pentru utilizarea DARTnet. Protocolul folosit a fost numit mai târziu Protocolul de Transport în Timp Real versiunea 0.
În Decembrie 1992 Henning Schulzrinne, a publicat Protocolul de Transport în Timp Real versiunea 1. A trecut prin mai multe faze, și în final a fost aprobat și propus standard la 22 Noiembrie 1995 de către IESG. Această versiune a fost numită Protocolul de Transport în Timp Real vesiunea 2, și a fost publicată ca:
RFC 1889, RTP – Un protocol de transport pentru Aplicații în timp real
RFC 1890, RTP – Profil pentru conferințe audio și video cu minimum de control
În 31 Ianuarie 1996, într-un comunicat de presă Netscape anunță "Netscape LiveMedia”, bazat pe RTP și alte standarde. Netscape LiveMedia framework va fi bazat pe Protocolul de transport în timp real (RTP), pe RFC 1889, și pe alte standarde audio-video cum ar fi MPEG, H.261 și GSM. Microsoft pretinde că software-ul lor, NetMeeting Conferencing suportă RTP.
În Internet, la fel ca și în alte rețele, este posibilă pierderea pachetelor, schimbarea ordinii în procesul de transmitere, de asemenea variază timpului de transmitere a pachetelor la distanțe mari. Aplicațiile multimedia pun condiții foarte dure asupra ambianței de transmitere. Pentru convenirea cu posibilitățile Internetului a fost creat protocolul RTP. Protocolul RTP are scopul de a transmite date în timp real (de exemplu semnalul audio sau video). Față de acesta se precizează tipul câmpului de date, se numerotează pachetele, se înregistrează reperul de timp și se monitorizează transmiterea datelor. Aplicațiile de obicei folosesc RTP implementat peste UDP, pentru ca să se poată folosi de posibilitatea sa de multiplexare și controlul checsum. Dar RTP se poate folosi de asemenea și deasupra oricărui protocol de nivel 4 OSI. RTP permite transmiterea concomitentă pe adrese diferite, dacă multicastul este susținut la nivel de rețea.
1.2. Stiva de protocoale Internet și Multimedia.[3]
În Figura 1.1. ne sunt prezentate cele patru nivele ale stivei de protocoale Internet și Multimedia. Nivelele și protocoalele din figură vor fi discutate în cele ce urmează.
1.2.1. Nivelul Fizic[3]
Nivelul cel mai de jos din stivă este nivelul fizic, care ar putea fi un nivel dintr-o rețea locala Ethernet, o linie telefonică (V.90 sau modem de 56k) care rulează protocolul punct-la-punct (PPP), o linie de telefon digitală (DSL) care rulează modul de transfer asincron (ATM), sau chiar o rețea wireless 802.11.
1.2.2. Nivelul Internet[3]
Urmatorul nivel din Figura 1.1. este nivelul Internet. Protocolul Internet (IP) este utilizat la acest nivel pentru a ruta pachetele de date prin rețea folosind adresa IP destinație. IP este un protocol bazat pe livrarea pachetelor “best-effort” (cel mai bun efort) și “connectionless” (nu este orientat pe conexiune). Pachetele pot fi pierdute, întarziate, sau primite într-o altă ordine decât cum au fost transmise. Fiecare pachet de date este rutat folosind antetul IP legat de pachetul fizic. Adresele IPv4 sunt lungi de 4 octeți, scrise în “dotted decimal” (exemplu, 128.122.3.1). Între fiecare punct este un număr zecimal de la 0 la 255. La nivelul stratului IP, pachetele nu sunt cu validare. Este un algoritm special pentru detecția erorilor în header-ul IP, care ar putea cauza rutarea incorecta a pachetelor. IP folosește un număr format dintr-un singur octet în header, pentru a identifica protocolul care ar trebui să primească pachetul.
Figura 1.1. Stiva de protocoale Internet și Multimedia[3]
ATM= Asynchronous Transfer Mode, V.90= recomandare pentru modem, 802.11= rețea wireless, AALx= ATM Adaptation Layer, PPP= Point-to-Point Protocol, IP= Internet Protocol, TCP=transport Control Protocol, UDP= User Datagram Protocol, SIP= Session Initiation Protocol, RTP= Realtime Transport Protocol, DNS= Domain Name System, DHCP= Dynamic Host Configuration Protocol, SDP= Session Description Protocol;
IP versiunea 6 (IPv6), a fost inițiat de către IETF (Internet Engineering Task Force), ca înlocuitor pentru IPv4. Momentan este suportat numai de câteva dintre sistemele de operare, dar încet încet va câștiga și interesul celorlalte aplicații. Cele mai multe rețele bazate pe IPv6 vor fi cel mai probabil rețelele telefonice wireless, care au nevoie de cel mai mare avantaj al IPv6, si anume spațiul de adresare mult mai mare. IPv6 crește spațiul de adresare de la 32 biți în IPv4 la 128 biți , asigurând peste 4 bilioane de adrese IPv6. Sunt multe alte îmbunătățiri la IPv6 peste IPv4, iar una dintre cele mai importante este securitatea. O adresa IPv6 este scrisă ca o secvență de 8 numere hexazecimale separate de două puncte. De exemplu, 0:0:0:0:aaaa:bbbb:cccc:dddd, este o adresă IPv6.
Adresele IP folosite în Internet sunt asignate de către IANA (Internet Assigned Number Association). Ca rezultat al acestei centralizări, adresele IP sunt unice la nivel global.
1.2.3. Nivelul Transport[3]
Următorul nivel prezentat în figură, este nivelul transport. Folosește un port format din 2 octeți de la nivelul aplicație, pentru a livra datagrama sau segmentul, de la protocolul care utilizează aplicația corectă, la adresa IP destinație. Există porturi dedicate anumitor protocoale, așa numitele porturi “well-known” (bine cunoscute). De exemplu, protocolul HTTP folosește portul “well-known” 80, SIP folosește portul 5060 și 5061, RTP folosește portul 5004, și RTCP portul 5005. Alte porturi pot fi folosite pentru orice protocol, și ele sunt asignate dinamic dintr-o plajă de porturi disponibile de la 49152 la 65535. Exista trei protocoale cele mai folosite ale nivelului transport, TCP (Transport Control Protocol), TLS (Transport Layer Security) și UDP (User Datagram Protocol).
1.2.3.1. TCP[3]
TCP asigură un transport sigur, orientat pe conexiune. TCP-ul folosește sequence numbers și acknowledgments(confirmări) pentru a se asigura că fiecare bloc al datelor, numit segment, a fost recepționat. Segmentele pierdute sunt retransmise până când acestea vor fi recepționate cu succes. Figura 1.2 ne arată schimbul de mesaje făcut pentru a stabili și a întrerupe o conexiune TCP. Serverul de TCP “ascultă” pe un port “well-known” o cerere de TCP. Clientul TCP trimite un mesaj SYN (sincronizare) pentru a iniția conexiunea. Mesajul SYN conține un număr de secvență inițial pe care clientul îl va folosi în timpul conexiunii. Serverul răspunde cu un mesaj SYN care conține propriul număr de secvență, și un acknowledgement, care indică primirea unui SYN de la client. Clientul încheie mecanismul denumit “three-way handshake” (comunicare cu confirmare în trei pași) cu un ACK (acknowlegement). Acum conexiunea e deschisă și se pot trimite pachete de date, numite segmente, atât server-ului, cât și clientului.
Figura 1.2. Deschiderea și închiderea unei conexiuni TCP[3].
De fiecare dată când se transmite un segment, se pornește un cronometru. Dacă segmentul este pierdut pe durata transmisiei, acest cronometru va expira. Dacă va exista vreun segment pierdut, se va retransmite acel segment până când cel care îl retransmite va primi confirmarea că a fost recepționat. Mesajul FIN închide conexiunea TCP. Secvența de patru mesaje din Figura 1.2 închid conexiunea. Astfel porturile folosite in timpul conexiunii vor fi eliberate pentru a putea fi folosite în stabilirea altor conexiuni. În TCP exista de asemenea mecanisme pentru controlul fluxului de date. În timpul procesării mesajului SYN, mărimea ferestrei reprezintă numărul maxim inițial de segmente neconfirmate trimise, care începe la 1 și crește exponențial până la o limită maximă. Când apare congestia în rețea și pierderea de pachete, fereastra se reseteaza înapoi la 1 și crește din nou până la limita maximă. Antetul unui segment TCP conține 24 de octeți. Segmentele eronate sunt detectate de un algoritm care acopera atât antetul unui segment TCP, cât și payload-ul.
1.2.3.2. UDP[3]
UDP asigură transportul nesigur al datelor prin Internet. Este un serviciu de tipul “best-effort”, atâta timp cât nu exista acknowledgment pentru datagrama transmisă. Majoritatea complexitații TCP-ului (numerotarea secvențelor-sequence numbers, confirmările-acknowlegements, și dimensiunea ferestrei) nu este prezentă și la UDP. Detectarea datagramelor eronate se face cu ajutorul unui algoritm, de verificare a sumei ciclice de control (checksum). Este la latitudinea protocolalelor de nivel superior, să detecteze datagramele pierdute și să inițieze retransmiteri.
1.2.3.3. TLS[3]
TLS se bazează pe protocolul SSL (Secure Sockets Layer), utilizat pentru prima dată în browsere-le de Web, și folosește TCP pentru transport. TLS este foarte utilizat în prezent în Internet, pentru site-urile securizate care folosesc HTTPS (Hypertext Transfer Protocol over Secure Socket Layer).
Protocolul TLS are două nivele:
– protocolul Transport TL
– protocolul Handshake TLS;
Protocolul de Transport TLS este utilizat pentru a asigura un mecanism de transport stabil și privat. Datele transmise cu ajutorul protocolului Transport TLS sunt criptate, pentru a nu putea fi interceptate.
Protocolul Handshake (comunicare cu confirmare) TLS este folosit pentru a stabili conexiunea, pentru a negocia cheia de criptare folosita de protocolul Transport TLS, și pentru a asigura autentificarea.
Mecanismul de negociere al cheii, selectează un algoritm de criptare și generează o cheie unică, secretă, cunoscută doar de cele două părți. În timpul înțelegerii în 3 pași, părțile schimbă certificatele, care pot fi folosite pentru autentificare.
Calculul cheii de criptare pentru o conexiune TLS este un mecanism laborios, iar deschiderea în mai multe rânduri a conexiunii (Figura 1.3.), poate adauga întârzieri. De asemenea, verificarea certificatului poate introduce întârzieri. Transportul prin TLS are mai multe avantaje de securitate decât UDP sau TCP. Multe sisteme de operare suportă deja TLS datorită utilizării mari in browsere-le Web securizate și servere.
1.2.3.4. SCTP[3]
SCTP (Stream Control Transport Protocol) este similar cu TCP-ul, deoarece asigură transport sigur pe baza de curent. De altfel, are ceva avantaje peste TCP. Are implementată partea de segmentare a mesajului, astfel că mesajele individuale sunt separate la nivelul transport.
Figura 1.3. Inițializarea unei conexiuni TLS[3].
Alt avantaj este acela că, SCTP evită problema “blocarea la cap de linie” (“head of line blocking”) a TCP-ului. Aceasta este o problemă comună la TCP, în care un segment care este transmis cu o fereastră mare, nu poate fi transmis spre legătura de ieșire dorită, deoarece aceasta este ocupată. În acest caz, segmentul va bloca toate celelate segmente din coadă, care asteaptă în urma sa, și cauzează așteptarea într-un buffer a întregului mesaj, până când segmentul în cauză este retransmis.
SCTP de asemenea, suporta multihoming-ul (router/dispozitiv care are mai mult de o interfață de rețea, folosit pentru creșterea siguranței în funcționare), astfel că dacă unul din perechea de servere de “load balacing” (echilibrare a încărcării) cade, celălalt poate începe imediat recepționarea mesajelor, făra a avea nevoie de DNS sau de alte căutari în baza de date.
SCTP este un protocol de transport de nivel 2, care are nevoie de un suport al sistemului de operare, fapt pentru care se vor produce întârzieri. De asemenea, este de reținut că avantajele SCTP-ului peste TCP, exista numai în cazul pierderilor de pachete. Într-o rețea făra pierderi, performanțele celor două protocoale sunt identice.
1.2.4. Nivelul Aplicație[5]
Nivelul cel mai de sus din Figura 1.1., este nivelul aplicație. Acesta include protocoale de transport media ca RTP (Real-time Transport Protocol), și protocoale de semnalizare ca SIP (Session Initiation Protocol). Figura 1.1 mai include H.323, care este un protocol alternativ de semnalizare către SIP, dezvoltat de către Uniunea Internațională de Telecomunicații (ITU). HTTP (Hypertext Transfer Protocol), SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol) și Telnet sunt toate exemple de protocoale ale nivelului aplicație.
1.3. Aplicații[5]
În Figura 1.1., sunt prezentate două aplicații care utilizează UDP-ul, și acestea sunt DNS-ul și DHCP-ul. Funcția principală a DNS-ului (port 53) este, să rezolve un nume simbolic (de exemplu : domeniu.ro, care este ușor de ținut minte), într-o adresa IP (necesară pentru rutarea pachetelor). De asemenea DHCP-ul permite unui dispozitiv IP să descarce informațiile de configurare la inițializare. Câmpurile cele mai comune includ o adresă IP alocată dinamic, adresa DNS, subnet masks (masca de subrețea), MTU (Maximum Transmission Unit) sau dimensiunea maximă a pachetului, și adresa serverului de mail.
Figura 1.4. ne arata implicarea celor patru nivele la procesarea unei cereri.
Figura 1.4. Procesarea unei cereri în Stiva deProtocoale
Internet și Multimedia[5]
URL-ul (Universal Resource Locator) este introdus de către utilizator în aplicația respectivă, și este prima etapă a procesului. URL-urile sunt nume folosite pentru a reprezenta unele resurse, PC-uri, sau fișiere de pe Internet. Aplicația pasează cererea generată (de exemplu o cerere GET a HTTP-ului, care cere descărcarea unei pagini Web), URL-ul, și numărul de port, către nivelul inferior și anume nivelul transport. Nivelul transport folosește un utilitar DNS, pentru a rezolva numele de domeniu extras din URL, într-o adresă IP. Adresa IP, datagrama (sau segmentul, depinde de protocolul de transport folosit), și numărul de port (care identifică protocolul de transport) sunt pasate către nivelul Internet. Nivelul Internet pasează pachetul cât și adresa MAC (Medium Access Control) către nivelul fizic. Apoi este dat un răspuns, prin inversarea pașilor de mai sus. Un răspuns primit la nivelul fizic, merge ulterior la nivelele superioare și în final la utilizator. Marea diferență între cerere și răspuns este aceea că în cazul procesării răspunsului, nu se folosește nici un utilitar, și deci întarzierile sunt mult mai mici.
1.4. DNS și adresele IP[4]
DNS-ul este utilizat în Internet pentru a asocia un nume simbolic (ca de exemplu www.domeniu.ro) cu o adresa IP (ca de exemplu: 192.168.2.1). De asemenea DNS-ul este folosit pentru a obține informații necesare pentru a ruta mesajele de e-mail, și pe viitor mesajele SIP. Utilizarea numelor în locul adreselor numerice este necesară, deoarece este mult mai ușor de ținut minte de către utilizatori. Numele de domenii sunt organizate ierarhic. Fiecare nivel din nume este separat cu un punct, în partea dreapta aflându-se nivelul superior (punctele din numele de domeniu nu corespund cu punctele din adresa IP). Nivelele superioare de domenii sunt prezentate in Tabelul 1.1. (http://www.iana.org ). Există și un set de domenii de țara ca: us (Statele Unite), ro (Romania), uk (Anglia), și ca (Canada). Fiecare din aceste nivele superioare de domenii au o autoritate care asigneaza acel domeniu la un utilizator sau un grup.
Tabel 1.1. Domenii din Internet[4]
Odata ce numele de domeniu a fost asignat, autoritatea plasează acea legătură (link) în serverul lor de DNS către serverul de DNS al utilizatorului sau grupului căruia i-a fost asignat domeniul. De exemplu, când « companie.com » este alocat unei companii, serverul de DNS principal pentru nivelul superior de domeniu com coține adresa IP a serverului de DNS a companiei. Un nume poate fi introdus apoi în tabelele serverului de DNS a companiei, care să ruteze către serverele individuale din rețea. De exemplu, tabelele serverului de DNS a companiei respective pot conține : www. companie.com, ftp .companie.com, și smtp. companie.com. Înregistrările din DNS utilizate pentru a rezolva un nume într-o adresa IP se numesc înregistrări de adrese (A records).
Când un utilizator caută o adresa Web, ca www .domeniu.ro, numele trebuie să fie rezolvat într-o adresa IP, înainte ca browser-ul să trimită cererea pentru pagina Web la serverul Web “domeniu”. Browser-ul lansează o interogare DNS (DNS query) către adresa IP pentru ai afla serverul de DNS, care a fost configurat manual sau setat folosind DHCP. Dacă se întâmpla ca serverul de DNS să aiba numele stocat local (cached), dintr-o interogare recentă, va returna adresa IP. Dacă nu, serverul DNS radăcină va fi interogat pentru a localiza serverul DNS principal pentru “domeniu”, care trebuia să conțina în înregistrări adresa pentru domeniu.ro. Cererea HTTP GET este trimisă către acea adresă IP, și începe sesiunea de navigare Web.
1.5. URL-uri si URI-uri[8]
URL-urile, sunt nume care reprezintă adrese sau locații din Internet. URL-urile sunt proiectate să cuprindă o gamă largă de protocoale si resurse din Internet. Forma de bază a unui URL este: specificatorul – de exemplu, http://www.domeniu.com/search/
search.html. HTTP-ul identifică protocolul care se folosește, în cazul acesta HTTP. Apoi urmeaza “:” și conține un nume de domeniu (www.domeniu. com), care poate fi rezolvat într-o adresa IP, și un nume de fișier ( /search/search.html). URL-urile pot conține parametrii adiționali, sau calificative legate de transport. De exemplu, telnet://host.companie.com:24, indică faptul că trebuie folosit protocolul Telnet pentru a accesa host.companie.com, folosind portul 24. Noi scheme de URL-uri au fost definite pentru protocoalele noi, ca de exemplu tel, https, și mailto. Majoritatea protocoalelor folosesc URL-urile, dar când vorbim despre SIP, atunci ne referim la URI-uri (Uniform Resource Identifier).
Aceasta se datorează aspectelor de mobilitate ale SIP, care înseamnă că o adresa URI, nu este neaparat legată de un singur dispozitiv, în schimb este o entitate logică care își poate schimba locația în Internet. În alte contexte termenele URL și URI sunt foarte des folosite alternativ.
1.6. Multicast[8]
Într-o rutare normala de pachete, sau o rutare unicast, un pachet este transmis către o singura destinatie. Într-o rutare multicast, un singur pachet este transmis către anumite destinații. LAN-urile care folosesc Ethernet-ul, au capacitatea să transmită pachetele în regim broadcast, ceea ce înseamnă că un pachet este transmis către fiecare nod al rețelei. Dacă facem analogia cu o rețea mult mai mare, cu mai multe rutere, atunci vom avea cu siguranță “rețeta dezastrului” – [Alan B. Johnston, Understanding the Session Initiation Protocol], deoarece traficul broadcast poate foarte rapid să cauzeze congestia. Adresele de multicast sunt rezervate de la 224.0.0.0 până la 239.255.255.255. Transportul multicast este tot timpul UDP, atâta timp cât nu sunt posibile “hand-shake-ul” și “acknoledgments” TCP-ului. Răspândirea unei sesiuni multicast poate fi limitată cu ajutorul câmpului TTL (time-to-live) din antetul IP. Câmpul TTL este decrementat de fiecare ruter care transmite mai departe pachetul, și limitează numărul de hopuri pe care le face pachetul.
Figura 1.5. Rutarea Unicast și Multicast[8]
Capitolul II
Protocoalele de transport pentru aplicații în timp real[13]
În acest capitol descriem RTP, protocolul de transport în timp real care asigură funcții de transport în rețele de tip end-to-end, potrivite pentru transmiterea datelor audio sau video în timp real, peste servicii de rețea multicast sau unicast. RTP nu garanteaza calitatea serviciului pentru transmisiile în timp real. Transportul de date este extins printr-un protocol de control, RTCP, care monitorizează livrarea datelor într-o manieră scalabilă pentru rețele multicast de mari dimensiuni cu un control minim. RTP si RTCP sunt proiectate să fie independente de protocolalele de transport și de nivelele de rețea.
2.1. Domenii de utilizare a RTP-ului[13]
Exemplele au fost alese pentru a ilustra funcționarea de bază a unor aplicații folosind RTP, și nu de a limita utilitatea RTP-ului. În aceste exemple, RTP-ul este transportat peste IP și UDP, și urmează convențiile stabilite de către profilul pentru audio și video (RTP/AVP), specificat în RFC 3551.
2.1.1. Conferințe audio tip multicast[13]
Un grup de specialiști din IETF se întâlnesc pentru a discuta ultimul document despre un protocol, utilizând serviciile IP multicast de Internet pentru comunicațiile de voce. Grupul obține un set de adrese muticast și o pereche de porturi. Un port este folosit pentru datele audio, și celălalt pentru controlul pachetelor (RTCP). Această informație despre adresă și port sunt distribuite tuturor participanților. Datele si controlul pachetelor se pot cripta, dar pentru aceasta va trebui generată și distribuită o cheie de criptare.
Aplicația despre conferința audio, folosită de fiecare dintre participanți, trimite segmente mici de date, de aproximativ 20 ms. Fiecare segment de dată audio este precedat de un antet RTP, iar la rândul lui, antetul de RTP este conținut într-un pachet UDP. Antetul RTP indica ce fel de codificare audio este folosită în fiecare pachet (PCM-Pulse Code Modulation, ADPCM-Adaptive Differential Pulse Code Modulation sau LPC-Linear Predictive Coding), iar utilizatorii pot schimba codificarea în timpul conferinței, dacă apar cogestii pe rețea, sau de exemplu pentru a primi un nou participant care este conectat folosind un link cu lățimea de bandă mai mică.
Internetul, ocazional pierde, reorganizează pachetele, și le întârzie o anumită perioadă de timp. De aceea antetul de RTP conține informații despre timpi și număr de secvențe, iar acestea ajuta receptorul să reconstruiasca procedurile de timing ale sursei. Reconstruirea procedurilor de timing din timpul conferinței, se face separat pentru fiecare sursă RTP. Numărul secvențelor, poate fi folosit de receptor pentru a estima câte pachete sunt pierdute.
În timpul unei conferințe, membrii grupului se alătură dar și părăsesc conferința, și din această cauză, este bine de știut cine participă în orice moment, dar și cât de bine recepționează datele audio. Pentru aceasta, fiecare instanță a aplicației audio trimite periodic în regim multicast un raport de recepție și numele utilizatorului, pe portul de control RTCP. Raportul de recepție indica cât de bine este recepționat semnalul audio, și poate fi folosit pentru a controla codările adaptive. Pe lângă numele utilizatorului, mai pot exista și alte informații, de exemplu limitele lățimii de bandă. Când cineva părăsește conferința, se transmite un pachet RTCP BYE.
2.1.2. Conferințe audio și video[15]
Dacă ambele medii audio și video sunt folosite în conferință, acestea sunt transmise ca sesiuni separate RTP. Adică pachetele RTP și RTCP sunt transmise separat, iar fiecare mediu folosește doua perechi de porturi UDP diferite sau/și adrese de multicast. Nu există o asociere directă la nivel de RTP între sesiunile audio și video, decât că utilizatorul participant la ambele sesiuni, trebuie sa folosească același nume (canonic), în ambele pachete RTCP, pentru ca să putem asocia sesiunile. O motivare a acestei separații, este de a permite unor participanți la conferință să folosească numai un mediu (audio sau video), dacă ei doresc.
2.1.3. Multiplexoare și Translatoare[2]
Până acum am presupus că toate site-urile vor să primească datele în același format, cu toate că acest lucru nu este întotdeauna indicat. Considerăm cazul în care participanții dintr-o anumită zonă, sunt conectați la conferință printr-o legatură cu viteză redusă, față de ceilalți participanți care se bucură de accesul la rețea, beneficiind de viteză mai mare. În loc să forțăm pe toata lumea să folosească viteză redusă, și calitatea codarii audio scăzută, un releu de nivel RTP numit multiplexor, poate fi plasat langă zona cu conectivitate redusă.
Figura 2.1. Multiplexor în transmisii de date[2]
Multiplexorul resincronizează pachetele audio care sosesc, pentru a reconstrui spațiul de 20 ms generat de transmițător, mixează aceste pachete audio într-unul singur, translatează codările audio la o lățime de bandă mai mică, și înaintează pachetul cu lățimea de bandă mai mică, către legătura cu viteză scăzută. Aceste pachete pot fi transmise unicast, către o singură destinație sau multicast, pe adrese diferite, spre diferite destinații.
Unii din participanții la conferința audio, pot fi conectați printr-o legătură de mare viteză, și totodată nu sunt neaparat direct accesibili via IP multicast. De exemplu, ei pot fi în spatele unei aplicații firewall, care nu va permite trecerea nici unui pachet IP. Pentru aceste site-uri multiplexarea nu va fi necesară, caz în care vom folosi alt tip de releu de nivel RTP, numit translator. Se instalează două translatoare, câte unul pe fiecare parte a firewall-ului, cu partea din exterior se filtrează toate pachetele multicast recepționate printr-o conexiune sigură către translatorul din interiorul firewal-ului. Translatorul din interiorul firewal-ului le retrimite ca pachete multicast către un grup multicast din rețeaua internă.
Figura 2.2. Translator în RTP[2]
Multiplexoarele și translatoarele pot fi proiectate pentru diferite scopuri. Un exemplu este multiplexorul video, care scalează imaginile unor persoane în fluxuri video separate, apoi le compune într-un flux video care simulează o scenă grupată. Alt exemplu este conexiunea unui grup de host-uri care cunosc (înteleg) numai IP/UDP, cu un grup de host-uri care cunosc numai ST-II, sau codarea pachet cu pachet a fluxului video de la o sursă individuală, fără resincronizare sau mixare.
2.1.4. Codări stratificate[1]
Aplicațiile multimedia ar trebui să poată ajusta rata transmisiei, pentru a se potrivi cu capacitatea receptorului, sau pentru a se adapta la congestiile din rețea. Majoritatea implementărilor plasează această responsabilitate a ratei transmisiei/adaptării, la sursă, iar acest lucru nu funcționează bine cu transmisiile multicast datorită conflictului dintre cerințele lățimii de bandă ale receptoarelor diverse. Responsabilitatea pentru rata transmisiei/adaptare, poate fi plasată la recepție combinând această codare stratificată cu un sistem de transmisie pe nivele.
2.2. Noțiuni generale / definiții[9]
Câmpul de date RTP: Informația, transmisă în pachetul RTP, de exemplu fragment de sunet sau informație video compresată.
Pachetul RTP: Pachet de informație, care conține un antent fix, o listă goală de surse de informații (CSRC), și câmpul de date. Un pachet de nivel inferior, de exemplu UDP, conține de obicei un pachet RTP, dar pot fi conținute mai multe pachete RTP, dacă permite metoda de încapsulare. .
Pachetul RTCP: Pachetul de coordonare sau control, care conține un antent fix asemănător cu antentul pachetului RTP, după care vin elementele structurate, care variază în funcție de tipul pachetului RTCP. De obicei câteva pachete RTCP se transmit ca un singur pachet încorporat într-un pachet de nivel mai jos cum este UDP.
Portul: Este “Abstracția care transportă protocoale, folosit pentru a distinge destinațiile multiple ale unui computer. Protocoalele TCP/IP identifică porturile folosind numere mici întregi pozitive.”- Comer D., Internetworking with TCP/IP. RTP depinde de protocoalele de nivel inferior, pentru a oferi unele mecanisme cum sunt porturile, pentru a multiplexa pachetele RTP și RTCP dintr-o sesiune.
Adresa de transportare: combinația de IP și numărul portului, care identifică punctul final al canalului (ex: adresa IP și portul UDP). Pachetele de date sunt transmise de la o adresă de transport sursă la o adresă de transport destinație.
Sesiunea multimedia: mai multe sesiuni RTP între un grup comun de participanți (ex: videoconferința este o sesiune multimedia deoarece poate conține o sesiune RTP audio și o sesiune RTP video ).
Sesiunea RTP: perioada de la momentul când se face grupa de membri între care se face schimbul de pachete RTP și până la dispariția ei. Pentru fiecare dintre participant sesiunea se precizează cu o pereche de adrese de transport destinație. Adresa de transmitere poate sa fie comuna pentru toți, în cazul IP multicast, sau să difere adresele, ca și în cazul rețelei unicast. În cazul rețelei unicast, participantul poate recepționa date de la toți paticipanții din aceea sesiune, folosind aceeași pereche de porturi, sau poate folosi o pereche distinctivă de porturi pntru fiecare. Caracterul distinctiv al sesiunii RTP, este acela că fiecare menține un spațiu separat de identificatori SSRC. Un grup de participanți care sunt într-o sesiune RTP se compune din aceeia care pot recepționa un identificator SSRC transmis de oricare din participanți. De exemplu să considerăm o conferință compusă din trei părți, folosind UDP unicast, cu fiecare participant recepționând de la ceilalți doi pe perechi de porturi separate. Dacă fiecare participant trimite un feedback RTCP despre informațiile recepționate de la un alt participant, către acel participant, atunci conferința este alcătuită din trei sesiuni punct-la-punct separate RTP. Dacă fiecare participant oferă feedback RTCP despre recepția de la un alt participant, către ceilalți doi membrii, atunci conferința e compusă din mai multe parți.
Sursa de sincronizare SSRC (syncronization source): Sursa fluxului pentru pachetul RTP, se determină de un identificator numeric de 32 biți și e independent de adresa de rețea. Toate pachetele de la sursa de sincronizare formează o parte identică in timp și numerotație. Aceste date se folosesc de către partea care primește și le reproduce. Sursele de sincronizare includ emițătorul unui flux de date derivate din sursele de semnal cum ar fi un microfon, o cameră video, sau un mixer RTP. Identificatorul SSRC reprezintă un număr aleator unic pentru această sesiune RTP. Membrul acestei sesiuni este obligat să folosească unul și același identificator SSRC pentru toate sesiunile RTP. Dacă un membru formează câteva fluxuri în limita unei sesiuni RTP, de exemplu de la o cameră video separată, fiecare participant trebuie să aibă un identificator SSRC unic.
Sursa informațională CSRC (contributing source): Sursa fluxului pachetului RTP, care contribuie la crearea fluxului comun, format de către mixerul RTP. Mixerul pune lista identificatorilor SSRC care identifică sursele parțiale, în antentul pachetelor RTP. Această listă se numește CSRC. Ca exemplu de aplicație poate fi audio conferința, unde mixerul îi înregistrează pe toți care vorbesc, iar glasul fiecărui membru devine ca sursă de transmitere a pachetelor. Aceasta permite receptorului să identifice membrul care vorbește, chiar dacă toate pachetele au unul și același identificator SSRC.
Sistemul final: Aplicația care generează sau percepe datele, transmise în pachete RTP. Sistemul final poate să acționeze în calitate de una sau mai multe surse de sincronizare pentru o sesiune concretă.
Multiplexorul: Sistem intermediar, care primește pachete RTP de la una sau mai multe surse, având posibilitatea de a schimba formatul, combină pachetele și apoi transmite un nou pachet RTP. Deoarece legătura de timp a pachetelor poate să difere, multiplexorul înfăptuiește sincronizarea lor și generează singur un flux de protocoale RTP. Cu toate acestea, toate pachetele RTP transmise au în calitate de sursă de sincronizare, multiplexorul.
Translator: Un sistem intermediar, care redirecționează pachetele RTP, fără a schimba identificatorii surselor de sincronizare. Astfel de sisteme se folosesc pentru reorganizarea sistemului de codificare, trecerea de la multicast la unicastul tradițional sau la lucrul cu firewall.
Monitor: Aplicația, care primește pachete RTCP, trimise de către membrii sesiunii RTP, în particular mesaje de diagnoză, estimează calitatea legăturii și păstrează statistica de termen lung.
2.3. RTP – Protocolul de transfer de date[6]
Protocolul în timp real RTP este un protocol bazat pe IP, și oferă suport pentru transportul informațiilor în timp real, cum ar fi fluxuri video și audio. Serviciile oferite de RTP include reconstrucția în timp, detecția pachetelor pierdute, securitate și identificarea conținutului. RTP este inițial proiectat pentru transmisia multicast a datelor în timp real, dar poate fi folosit de asemenea și în transmisii unicast. Poate fi folosit pentru transportul într-o singură direcție, cum ar fi video-on-demand (video la cerere), precum și ca serviciu interactiv așa cum este telefonia pe Internet. RTP este proiectat să lucreze în conjuncție cu protocolul auxiliar de control RTCP, pentru a primii feedback despre calitatea transmisiei și informații despre participanții din sesiunea în desfășurare.
2.3.1. Dezvoltare[11]
Încercări de a transmite voce pe o rețea au început în prima parte a anului 1970. Mai multe brevete despre conferință, timestamp (etichete de timp), și sequence numbering (numerotarea secvențelor), au fost obținute în 1970 și 1980. În 1991, o serie de experimente de voce au fost finalizate la DARTnet. În August 1991, Network Reserch Group de la Laboratorul Național Lawrence Berkeley, au lansat un instrument de conferințe audio, vat, pentru utilizarea DARTnet. Protocolul folosit a fost numit mai târziu RTP versiunea 0.
În Decembrie 1992 Henning Schulzrinne, a publicat Protocolul de Transport în Timp Real versiunea 1. A trecut prin mai multe faze, și în final a fost aprobat și propus standard la 22 Noiembrie 1995 de către IESG. Această versiune a fost numită Protocolul de Transport în Timp Real vesiunea 2, și a fost publicată ca:
– RFC 1889, RTP – Un protocol de transport pentru Aplicații in timp real
– RFC 1890, RTP – Profil pentru conferințe audio și video cu minimum de control
În 31 Ianuarie 1996, într-un comunicat de presă Netscape anunță "Netscape LiveMedia”, bazat pe RTP și alte standarde. Netscape LiveMedia framework va fi bazat pe Protocolul de transport în timp real (RTP), pe RFC 1889, și pe alte standarde audio-video cum ar fi MPEG, H.261 și GSM. Microsoft pretinde că software-ul lor, NetMeeting Conferencing suportă RTP.
2.3.2. Cum funcționează RTP[11]
Așa cum sa discutat în prima secțiune, Internet-ul este o rețea de datagrame partajată. Pachetele trimise pe Internet au întârzieri și bruiaje imprevizibile. Aplicațiile multimedia necesită sincronizare adecvată în transmiterea datelor și redarea lor. RTP prevede timestamping (marcarea cu o etichetă de timp), numerotarea secvențelor, precum și alte mecanisme referitoare la problemele de sincronizare. Prin aceste mecanisme, RTP oferă transport de tipul end-to-end pentru date în timp real.
Timestamping-ul este cea mai importantă informație pentru aplicațiile în timp real. Sursa setează o etichetă de timp în momentul eșantionării primului octet dintr-un pachet. Acest timp este apoi incrementat cu durata necesară transmiterii unui pachet. După ce sunt recepționate toate pachetele de date, receptorul folosește acest timestamp pentru a reconstrui fiecare pachet în ordinea corectă, astfel încât o eventuală vizualizare să se facă la o rată corectă. Acest procedeu este de asemenea folosit pentru sincronizarea diferitelor fluxuri ce au proprietăți dependente de timp, cum ar fi audio și video într-un fișier MPEG. RTP-ul nu este responsabil pentru sincronizare, acest lucru facându-se la nivel de aplicație.
UDP nu livrează pachetele în ordine, sau la timp, astfel numerotarea secvențelor se folosește pentru a plasa informațiile sosite în ordinea corectă. De asemenea se folosește și pentru detecția pachetelor pierdute. De remarcat faptul că în unele formate video, când un cadru este împărțit în mai multe pachete RTP, toate pot avea același timestamp. Deci doar timestampul nu este de ajuns pentru a reconstrui pachetele în ordine.
Identificatorul despre formatul informației utile (payload type) ne arată formatul, dar și schemele de codare/compresie. De la acest identificator, aplicația de la recepție știe cum să interpreteze informația utilă. Tipurile de informații utile standard sunt definite în RFC 3551. Exemple: PCM, MPEG1/MPEG2 (Moving Picture Experts Group)-codări audio/video, JPEG (Joint Photographic Experts Group)-codare video, Sun CellB-codare video, H.261-fluxuri video etc. Putem adăuga mai multe tipuri de payload, dacă avem specificațiile despre un profil și formatul payload-ului. În orice moment al transmisiei, sursa RTP poate transmite doar un tip de payload, cu toate că tipul de informație poate să difere în timpul unei transmisii, de exemplu, la adaptarea într-o rețea cogestionată.
Altă funcție este identificarea sursei. Permite aplicației de la recepție să știe de unde vin informațiile. De exemplu, într-o conferință audio, de la indentificatorul sursă un utilizator ar putea spune cine vorbește. Mecanismele de deasupra sunt implementate în antetul RTP. Figura de mai jos ne arată un pachet RTP încapsulat într-un pachet UDP/IP.
Figura 2.3. Informația RTP într-un pachet IP[11]
De obicei RTP rulează peste UDP, pentru a se folosi de funcțiile acestuia de multiplexare și verificare a sumei ciclice de control.
TCP și UDP sunt două dintre cele mai utilizate protocoale de transport în Internet. TCP-ul asigură un flux sigur și orientat pe conexiune, între doua calculatoare, iar UDP-ul asigură servicii nesigure, și care nu sunt orientate pe conexiune.
UDP-ul a fost ales ca protocol de transport pentru RTP din două motive. RTP-ul este în primul rând proiectat pentru transmisii multicast, iar TCP-ul orientat pe conexiune nu este adecvat. Al doilea motiv, pentru informațiile în timp real, fiabilitatea nu este așa de importantă în comparație cu livrarea la timp a datelor. Chiar mai mult, transmisia fiabilă oferită prin retransmiterea datelor, ca în cazul TCP-ului, nu este de dorit. De exemplu, într-o rețea cogestionată, unele pachete se pot pierde, iar aplicația va avea ca rezultat o calitate mai slabă, dar totuși acceptabilă. Dacă se optează pentru o transmisiune fiabilă, pachetele retransmise ar putea crește întârzierile, ar putea bloca rețeaua, și în final nu ar mai ajunge informațiile la aplicația de la recepție.
Pachetele RTP și RTCP sunt transmise de obicei folosind serviciul UDP/IP, dar s-au făcut eforturi pentru a le face independente de protocolul de transport folosit, pentru ca acestea să poată funcționa și cu CLNP (Connectionless Network Protocol), IPX (Internetwork Packet eXchange), AAL5/ATM și cu alte protocoale.
În practică, RTP-ul este implementat în cadrul aplicației. Multe probleme, cum ar fi recuperarea pachetelor pierdute, controlul congestiei, trebuiesc implementate la nivel de aplicație. Pentru a pune bazele unei sesiuni RTP, aplicația definește o pereche de adrese de transport destinație (o adresă de rețea plus o pereche de porturi pentru RTP și RTCP). Într-o sesiune multimedia, fiecare mediu este transportat în sesiuni RTP separate, fiecare având pachete RTCP proprii, pentru raportul privind calitatea recepției din acea sesiune. De exemplu, transmisia audio și video se face folosind sesiuni RTP separate, dând posibilitatea receptorului să aleagă dacă vrea sau nu să recepționeze un mediu particular.
Un scenariu despre o conferință audio, prezentată în RFC 3550, ilustrează utilitatea RTP-ului. Să presupunem că fiecare participant trimite date audio în segmente de 20 ms. Fiecare segment audio este precedat de un antet RTP, iar mesajul RTP rezultat este plasat într-un pachet UDP. Antetul RTP indică tipul de codare audio care este folosită, ex., PCM. Utilizatorii pot schimba tipul de codare, în timpul conferinței, în cazul în care apar cogestii pe rețea sau de exemplu, pentru a primi un nou participant la coferință, dar care beneficează de un link cu lățimea de bandă mai mică.
Informațiile despre timpi și numerotare a secvențelor din antetul RTP, sunt folosite de receptoare, pentru a reconstrui procedurile de timing ale sursei, iar pentru acest exemplu, segmentele audio sunt redate continuu de receptor la fiecare 20 ms.
2.3.3. Structura pachetului[14]
Pachetul de date RTP are urmatorul format:
Figura 2.4. Structura pachetului RTP[14]
Primii 12 octeți sunt prezenți în toate pachetele RTP, iar identificatorii CSRC sunt prezenți doar introduși de un multiplexor.
Ver. (2 biți) indică versiunea protocolului RTP utilizată. Versiunea actuală este 2. Valoarea 1 este folosită de prima versiune a RTP.
P – padding (1 bit), este folosit pentru a indica dacă există informație suplimentară la finalul pachetului RTP. Dacă bitul este setat, pachetul conține informație suplimentară la finalul pachetului, care nu face parte din informația utilă. Este nevoie de padding la anumiți algoritmi de criptare structură fixă, sau pentru transportul pachetelor RTP într-un nivel inferior a PDU .
X – extensie (1 bit), indică dacă sunt utilizate extensii ale protocolului în pachet. Dacă bitul este setat, antetul fix trebuie urmat de exact o extensie de antet, cu un anumit format.
CC – CSRC count (4 biți), conține numărul identificatorului CSRC care îi urmează antetului fix.
M – marker (1 bit), este folosit la nivelul aplicație și este definit în cadrul profilelor. Dacă este setat, dovedește că datele curente au o semnificație specială pentru nivelul aplicație. Un profil poate defini biți adiționali pentru marker, sau poate specifica faptul că nu este nici un bit pentru marker, prin schimbarea numărului de biți din câmpul informație utilă .
PT – payload type (7 biți) indică formatul payload-ului (informația utilă) și determină interpretarea de către aplicație. SSRC indică sursa de sincronizare.Un receptor trebuie să ignore pachetele cu format pe care acesta nu îl întelege.
Numărul secvenței: (16 biți) indică numărul de pachete transmise pe canal. Numărul secvenței se incrementează cu 1 pentru fiecare pachet trimis, și poate fi folosit de către receptor pentru determinarea de pachete pierdute, dar si pentru reconstrucția sevenței. Valoarea inițială a numărului secvenței ar trebui să fie aleatoare, pentru ca criptarea datelor să fie mai sigură.
Timestamp – timpul la transmitere (32 biți): este cea mai importantă informație pentru aplicațiile în timp real. Sursa setează un timestamp în momentul eșantionării primului octet dintr-un pachet. Acest timp este apoi incrementat cu durata necesară transmiterii unui pachet. După ce sunt recepționate toate pachetele de date, receptorul folosește acest timestamp pentru a reconstrui fiecare pachet în ordinea corectă, astfel încât o eventuală vizualizare să se facă la o rată corectă. Acest procedeu este de asemenea folosit pentru sincronizarea diferitelor fluxuri ce au proprietăți dependente de timp, cum ar fi audio și video într-un fișier MPEG.
Identificatorul SSRC (32 biți): un număr ales aleator, pentru a deosebi sursele de sincronizare din aceeași sesiune RTP. Indică unde s-au combinat datele, sau sursa datelor, în cazul în care există numai o sursă
Identificatorii CSRC sau lista CSRC (între 0 și 15 obiecte, cu 32 biți fiecare): indică sursele informaționale pentru informația utilă conținută în acest pachet. Numărul identificatorilor este dat de câmpul CC.
2.4. RTCP – Protocolul de control în timp real[17]
RTCP este un protocol de control proiectat să lucreze în conjuncție cu RTP-ul. Este standardizat în RFC 3550. RTP-ul livrează datele actuale, în timp ce RTCP este folosit pentru a trimite pachete de control participanților la un apel. Funcția primară este furnizarea de rapoarte cu privire la calitatea serviciilor furnizate de RTP. Într-o sesiune RTP, participanții trimit periodic pachete RTCP, pentru a furniza rapoarte despre calitatea livrării datelor, și informații despre membrii. RFC 3550 definește cinci tipuri de pachete RTCP pentru informațiile de control. Aceste pachete sunt:
► RR (receiver report): rapoartele receptorului sunt generate de participanții care nu sunt surse active. Ele conțin feedback-ul receptorului despre livrarea datelor, incluzând numărul cel mai mare de pachete recepționate, numărul pachetelor pierdute, bruiajul de tip inter-arrival, și timestamps care calculează întârzierile dus-întors dintre sursă și destinație.
► SR (sender report): rapoartele sursei sunt generate de susele active. Pe lângă feedback-ul despre calitatea transmisiei, ele conțin o secțiune cu informații despre sursă, oferind sincronizari inter-media, numărarea pachetelor cumulative, și numărul byților transmiși.
► SDES (source description items): conțin informații care descriu sursele.
► BYE indică sfârșitul participării (transmisiei).
► APP indică funcțiile specifice aplicației.
Figura 2.5. Pachete RTCP compuse[17]
RTCP-ul îndeplinește următoarele funcții:
► Calitatea serviciului care monitorizează controlul congestiei.
Aceasta este funcția principală a RTCP. RTCP-ul furnizează feedback unei aplicații, despre calitatea distribuirii datelor. Informațiile de control sunt utile sursei, receptorului, dar și administratorilor de rețea. Sursa iși poate modifica transmisia, în funcție de raportul receptorului. Receptorul poate determina dacă o cogestie este locală, regională, sau globală. Administratorii de rețea pot evalua performanțele rețelei pentru transmisii multicast.
► Identificarea sursei.
În pachetele de date RTP, sursele sunt identificate de identificatori de 32-biți generați in mod aleator. Acești identificatori nu sunt convenabili pentru utilizatori. Pachetele RTCP SDES (descrierea sursei) conțin informații textuale numite nume canonice (CNAME). Acestea pot include numele de utilizator, numărul de telefon, adresa de email și alte informații.
► Sincronizare inter-media.
Rapoartele RTCP ale sursei conțin o indicație de timp real și timestamp-ul RTP corespunzător. Acestea pot fi utilizate în sincronizarea inter-media.
► Scalarea informațiilor de control.
Pachetele RTCP sunt transmise periodic printre participanți. Când numărul participanților crește, este necesar să existe un echilibru între actualizarea informațiilor de control și limitarea traficului de control. Pentru a scala la grupuri multicast mai mari, RTCP-ul trebuie sa prevină traficul de control, pentru a nu aglomera resursele rețelei. Limitele RTP de control a traficului sunt de cel mult 5% din totalul traficului sesiunii.
2.5. Caracteristicile RTP-ului[12]
● RTP oferă servicii de livrare de tipul end-to-end, pentru informații cu caracteristici în timp real, cum ar fi audio și video interactiv, dar nu furnizează nici un mecanism care să asigure livrarea la timp a datelor. Are nevoie de suportul nivelelor inferioare, care chiar au control asupra resurselor din switch-uri și routere. RTP depinde de RSVP (Resource Reservation Protocol), pentru rezervarea resurselor și pentru furnizarea calității serviciilor cerute.
● RTP-ul nu presupune nimic despre rețea, cu excepția faptului că furnizează framing (cadre). De obicei RTP rulează peste UDP, pentru a se folosi de serviciile de multiplexare si checksum ale acestuia, dar au fost facute eforturi pentru al face compatibil si cu alte protocoale de transport, cum ar fi ATM, AAL5 și IPv6.
● Spre deosebire de transmisia datelor, RTP-ul nu oferă nici o formă de fiabilitate, control al debitului, sau al congestiei. Furnizează timestamps, numerotarea secvențelor, folosite pentru adăugarea fiabilității și controlul debitului/congestiei, dar modalitățile de implementare, sunt lăsate la latitudinea aplicației.
● RTP este un protocol bazat pe cadre, care nu este încă complet. Este deschis la noi formate a payload-ului, dar și pentru noi soft-uri multimedia. Prin aplicarea de noi profile, și formate ale payload-ului, putem adapta RTP-ul la noi formate de date și la noi aplicații.
● RTP/RTCP furnizează funcționalitate și mecanisme de control necesare pentru transportul în timp real al conținutului. Dar RTP/RTCP nu sunt responsabile pentru sarcinile nivelelor superioare, cum ar fi asamblarea și sincronizarea. Acestea trebuie făcute la nivelul aplicație.
● Informațiile despre controlul debitului și al congestiilor sunt furnizate de către expeditorul (sursa) RTCP și rapoartele receptorului.
2.6. Resursele de implementare RTP[16]
RTP este un protocol deschis care nu oferă un sistem de telefonie preimplementat. Implementarea este strâns legată de aplicație. Programatorii trebuie să adauge toate funționalitățile la nivel de aplicație. De altfel, este mult mai eficient să folosești o aplicație gata facută, decât să o faci de la zero. RFC 3550 conține numeroase segmente de coduri, care pot fi folosite direct de către aplicații. Există pe Web și câteva implementări ale unor coduri sursă, care pot fi folosite în scopuri educative. Multe din acele module ale codurilor sursă, pot fi folosite dacă facem mici modificări.
2.7. Modificări aduse antetului RTP[16]
Formatul antetului RTP este considerat a fi complet pentru setul de funcții necesare pentru toate tipurile de aplicații suportate de RTP. Dar dacă unele aplicații speciale au nevoie de funcții adiționale, independente de formatul payload-ului, profilul sub care acele aplicații operează trebuie să definească câmpuri suplimentare care să urmeze dupa câmpul SSRC al antetului existent. Acele aplicații vor putea să acceseze direct și rapid câmpurile adiționale, și în același timp se pot procesa și pachetele RTP, interpretând numai primii 12 octeți.
2.7.1. Extensia antetului RTP[16]
Mecanismul de extensie există, pentru a permite implementărilor individuale să experimenteze noile funcții independente ale payload-ului, care necesită informații adiționale pentru a fi transmise în antetul pachetului de date RTP. Acest mecanism este proiectat în așa fel încât extensia antetului să fie ignorată de celelalte implementări care nu au fost extinse. Această extindere a antetului este destinată pentru utilizare limitată. Informațiile adiționale necesare pentru un format specific al payload-ului, nu ar trebui să folosească această extensie a antetului, dar ar trebui transportată în secțiunea payload-ului din pachet.
Figura 2.6. Extensia antetului RTP[16]
Dacă bitul X din antetul RTP este “1”, o extensie a antetului de lungime variabilă trebuie să fie anexată antetului RTP, urmând apoi lista CSRC, dacă există. Extensia antetului conține un câmp cu lungimea de 16 biți, care numără cuvinte de 32 de biți, exceptând extensia antetului de 4 octeți (zero, prin urmare, este o lungime valabilă).
Doar o singură extensie poate fi adăugată antetului de date RTP. Pentru a permite implementări multiple fiecărui experiment, independent și cu extensia antetului diferită, sau pentru a pemite implementări cu mai multe tipuri de extensii de antet, primii 16 biți ai extensiei antetului sunt lasați deschiși pentru a distinge identificatorii sau parametrii. Formatul acestor 16 biți sunt definiți de către specificațiile profilului. Specificațiile RTP-ului nu definesc nici o extensie a antetului.
Capitolul III
Profilul pentru conferințe audio și video cu control minim[7]
Vom descrie un profil numit „RTP/AVP”, folosit pentru utilizarea protocolului de transport în timp real RTP, versiunea 2, dar și pentru protocolul de control asociat, RTCP, în conferințele audio și video cu control minim. Furnizează interpretări ale câmpurilor generice din specificațiile RTP potrivite pentru conferințele audio și video. De asemenea vom descrie cum datele audio și video sunt transportate prin RTP, și vom trece în revistă un set de codări standard folosite în colaborare cu RTP.
3.1. Introducere[7]
Acest profil este destinat utilizării în cadrul conferințelor audio și video cu control minim. Profilul este de așteptat să fie folositor în sesiuni unde nu se utilizează controlul negocierii sau al membrilor, de asemenea mai poate fi folositor și în conjuncție cu protocoale de control de nivele superioare.
3.2. RTP și RTCP – Formatul pachetelor și comportamentul protocolului[7]
În general, acest profil adoptă aspectele de bază și/sau cele recomandate de specificațiile RTP.
Antetul de date RTP: este folosit formatul standard al antetului de date fix RTP (bitul marker pe „1”).
Tipul payload-ului (informația utilă): este folosit tipul static de payload.
Adăugiri ale antetului de date RTP: nu sunt adăugate câmpuri suplimentare antetului RTP.
Extensii ale antetului de date RTP: nu sunt definite extensii ale antetului, dar aplicațiile care operează în conformitate cu acest profil pot utiliza aceste extensii. În acest fel, aplicațiile nu ar trebui să presupună că bitul X al antetului RTP este tot timpul „0”, și ar trebui să fie pregătite să ignore extensia antetului.
Tipuri de pachete RTCP: nu sunt definite tipuri de pachete adiționale de către specificațiile acestui profil.
Intervalul raportului RTCP: constantele sugerate sunt folosite pentru calculul intervalelor rapoartelor RTCP. Lățimea de bandă a traficului RTCP poate fi divizată în două sesiuni separate, pentru acei participanți care sunt transmițători de date activi, și pentru cei care nu sunt. Recomandarea din specificațiile RTP sunt ca ¼ din lațimea de bandă să fie dedicată celor care transmit date, iar valorile recomandate pentru cele două sesiuni separate sunt 1,25% și respectiv 3,75% . Lățimea de bandă pentru transmițătorii de date ar trebui să fie nenula, pentru ca rapoartele transmițătorului să poată fi trimise pentru sincronizarea inter-media, și pentru a putea identifica sursa după numele canonic CNAME (Canonical NAME).
Extensiile SR/RR: nu este definită nici o extensie pentru pachetele RTCP SR sau RR.
Utilizarea SDES: aplicațiile pot folosi oricare dintre elementele descrise în specificațiile RTP. Dacă informațiile CNAME trebuie trimise la fiecare interval de raportare, alte elemente trebuie transmise numai la al treilea interval de raportare, numele (NAME) este transmis de șapte ori din cele opt, în acel slot, iar elementele SDES care au mai rămas, ocupă ciclic slotul opt. Cu alte cuvinte, „NAME” este transmis în pachetele RTCP 1, 4, 7, 10, 13, 16, 19, iar „EMAIL-ul” este utilizat în pachetul RTCP 22.
Securitate: serviciile de securitate ale protocolului RTP, sunt folosite și de către profilul RTP/AVP.
Maparea string-to key: nu este specificată nici o mapare de către acest profil.
Congestia: RTP, și acest profil poate fi folosit în contextul serviciilor îmbunătățite de rețea, de exemplu, prin Serviciile Integrate (RFC 1633), Serviciile Diferențiale (RFC 2475), sau pot fi folosite cu serviciile de tipul best effort (cel mai bun efort).
Dacă sunt folosite serviciile îmbunătățite, receptoarele RTP, ar trebui să monitorizeze pierderea de pachete, pentru a asigura faptul că serviciul solicitat este chiar emis. Dacă nu, atunci acestea ar trebui să presupună recepționarea serviciilor de tipul best effort, și să se comporte în consecință.
Dacă sunt folsite serviciile de tipul best effort, receptoarele RTP, ar trebui să monitorizeze pierderea de pachete, pentru a asigura faptul că rata pierderilor se află în parametrii acceptabili. Pierdera pachetelor se consideră acceptabilă, dacă un flux TCP peste aceeași cale de rețea și care întâmpină aceleași condiții de rețea, ar realiza o medie throughput(tranzitată), masurată pe un interval rezonabil de timp, care nu este mai mică decât ceea ce realizează fluxul RTP. Această condiție poate fi satisfăcută prin implementarea mecanismelor de control a congestiei, care să adapteze rata transmisiei (sau un număr de nivele subscris pentru o sesiune multicast stratificată), sau prin planificarea ca un receptor să părăsească sesiunea , dacă rata pierderilor este inacceptabil de mare.
Scara de timp pe care se măsoară tranzitul TCP, este timpul dus-întors al conexiunii RTT (Round Trip Time). În esență, această cerință afirmă că nu este acceptabil pentru a implementa o aplicație (folosind RTP sau orice alt protocol de transport), care consumă lățime de bandă în mod arbitrar, și nu concurează drept cu TCP-ul într-un ordin de mărime.
Profilul specifică utilizarea RTP-ului peste transmisii UDP unicast și multicast precum și peste TCP.
Încapsularea: profilul lasă la latitudinea aplicațiilor, specificațiile despre încapsularea RTP în protocoale, altele decât UDP.
3.3. Audio[7]
3.3.1 Regulile codării independente[7]
Deoarece capacitatea de a suprima tăcerea (intervalele de timp neutilizate) este una din principalele motivații pentru uilizarea pachetelor pentru a transimite voce, antetul RTP are inclus numărul secvenței dar și timestamp (timpul de transmisie), pentru a permite receptorului să facă disticția dintre pierderea de pachete și perioada de timp în care nu au fost transmise date.
Transmisia discontinuă (suprimarea tăcerii) poate fi folosită cu orice format audio. Receptoarele trebuie să presupună că emițătorii pot suprima tăcerea, cu excepția cazului în care acest lucru este restricționat de o semnalizare specificată în altă parte. Chiar dacă transmițătorul nu transmite dicontinuu, receptorul trebuie să fie pregătit să se ocupe de perioadele în care nu există informații, deoarece pachetele pot fi pierdute. Unele formate ale payload-ului definesc cadre ca: “silence insertion descriptor” sau ”confort noise”, pentru a specifica parametrii pentru zgomotul artificial, care poate fi generat în timpul unei perioade de liniște ca să aproximeze zgomotul de fond de la sursă.
Pentru aplicații care, în timpul perioadei de liniște, nu transmit nici un pachet, sau transmit ocazional pachete “confort noise”, primul pachet după această perioadă (în timpul careia pachetele nu au fost transmise continuu), trebuie deosebit de celelalte prin setarea bitului marker din antetul RTP la “1”. Bitul marker din toate celelalte pachete este “0”. Aplicațiile care nu au capacitatea de a suprima tăcerea, trebuie să seteze bitul marker la zero.
Dacă se folosesc canale audio multiple, atunci ele trebuiesc numerotate de la stânga la dreapta, începând cu unu. În pachetele audio RTP, informația provenită de la canalele cu număr mai mic, o precede pe cea provenită de la canalele cu număr mai mare. Pentru un număr mai mare de două canale, convenția stabilită de AIFF-C (Audio Interchange File Format), pentru formatul audio interschimbabil, trebuie urmată folosind următoarele notații, cu excepția cazului în care o altă convenție este stabilită, pentru un anumit tip de codare, sau format al sarcinii utile:
l – stânga
r – dreapta
c – centru
s – surround
f – față
r – spate
Tabelul 3.1.: Convenția AIFF-C, priviind sunetele pe mai multe canale
De reținut că în RFC 1890 erau definite două convenții pentru repartizarea pe patru canale audio. Având în vedere că repartizarea este indicată de numărul de canale, repartizarea tip “quadrophonic”, a fost eliminată în RFC 3551, fiind considerată ambiguă.
3.3.2. Recomandari pentru codările audio bazate pe eșantionare[14]
În codarile bazate pe eșantionare, fiecare eșantion audio este reprezentat de un număr fix de biți. Un pachet audio RTP poate conține orice număr de eșantioane audio, sub rezerva constrângerii că numărul de biți per eșantion se înmulțește cu numărului de eșantioane per pachete. Codările fracționare produc mai puțin de un octet per eșantion.
Perioada unui pachet audio este determinată de numărul de eșantioane din pachet. Eșantioanele din canalele diferite, eșantionat e cu același pas de eșantionare, ar trebui împachetate în octeți consecutivi. De exemplu, pentru o codare pe două canale, secvența de octeți este: (canalul din stânga, primul eșantion), (canalul din dreapta, primul eșantion), (canalul din stânga, al doilea eșantion), (canalul din dreapta, al doilea eșantion), …. Pentru codari multi-octeți, aceștia ar trebui să fie transmiși în rețea în ordine (primul să fie cel mai semnificativ octet).
Timestamp-ul (timpul de transmitere) RTP reflectă momentul în care primul eșantion din pachet a fost eșantionat, iar acesta este cea mai veche informație din pachet.
3.3.3. Recomandări pentru codările audio bazate pe cadre[14]
Codările bazate pe cadre, execută o codare a unui bloc audio de lungime fixă, într-un alt bloc de date comprimat, de obicei și acesta de lungime fixă. Pentru acest tip de codare, transmițătorul poate alege să combine mai multe cadre într-un singur pachet RTP. Receptorul poate știi numărul de cadre cuprinse într-un pachet RTP, dacă toate cadrele au aceeași lungime, prin divizarea lungimii payload-ului RTP cu mărimea cadrului audio, care este definit ca parte a codării. Acest lucru nu funcționează dacă există cadre de diferite dimensiuni, cu excepția cazului în care dimensiunile cadrelor sunt relativ prime. Astfel cadrele trebuie să-și indice dimensiunea.
Pentru codecuri bazate pe cadre, ordinea canalului este definită pentru întreg blocul. Astfel, pentru codări audio pe două canale, eșantioanele din dreapta și stânga, trebuie codate independent, cu cadrul pentru canalul din stânga precedând pe cel din canalul din dreapta.
Toate codecurile orientate pe cadre, trebuie să fie capabile să codeze și să decodeze mai multe cadre consecutive dintr-un singur pachet. Pachetele RTP trebuie să conțină un număr întreg de cadre, acestea fiind inserate în funcție de vechime în pachet, astfel ca cel mai vechi cadru (să fie rulat primul) să apară imediat după antetul pachetului RTP.
Timestamp-ul RTP reflectă momentul în care primul eșantion din primul cadru a fost eșantionat, iar acesta este cea mai veche informație din pachet.
3.3.4. Codecuri audio[10]
Caracteristicile codărilor audio sunt descrise in Tabelul 3.2, și sunt enumerate în ordinea tipului de payload din Tabelul 3.3. În timp ce majoritatea codecurilor audio sunt specificate pentru o rată fixă de prelevare a eșantioanelor, câțiva algoritmi (indicați de “var.” din coloana “rata de eșantionare” a Tabelului 3.2), pot fi folosiți cu diferite rate de eșantionare, rezultând rate de bit codate diferit.
Tabel 3.2. : Proprietățile codărilor audio (N/A : nu se aplică ; var. :variabil)
3.4. Video[7]
Toate aceste codări video folosesc o frecvență a timestampului de 90,000 Hz, la fel ca frecvența timestampului unei prezentări MPEG. În timp ce frecvența recomandată pentru viitoarele codări video utilizate de către acest profil este de 90 kHz, pot fi folosite și alte frecvențe. Cu toate acestea, nu este suficient să utilizăm rata cadrelor video (tipic între 15 și 30 Hz), deoarece nu livrează o rezoluție adecvată pentru cerințele de sincronizare, când se calculează timestamp-ul RTP, corespunzător timestamp-ului NTP dintr-un pachet RTCP de tipul SR. De asemenea, rezoluția timestamp-ului trebuie să fie suficientă pentru a estima bruiajul conținut în rapoartele receptorului.
Pentru majoritatea codărilor video, timestampul RTP codează eșantioanele prelevate, ale imaginii video conținute într-un pachet de date RTP. Dacă o imagine video ocupă mai mult de un pachet, atunci timestampul este la fel în toate acele pachete. Pachetele din imaginile video diferite, se disting prin timestamp-uri diferite.
Majoritatea codărilor video specifică de asemenea faptul că bitul marker, din antetul RTP, trebuie setat la “1” în ultimul pachet al cadrului video, și altfel setat la “0”.
Astfel, nu este necesar să așteptăm următorul pachet cu timestamp-ul diferit, ca să constatăm faptul că un nou cadru ar trebui sa fie afișat. Codările video dar și payload-ul acestora sunt enumerate în Tabelul 3.4.
3.5. Definițiile tipurilor de payload[7]
Tabelele 3.3, și 3.4, definesc valorile statice de payload ale acestui profil, pentru câmpul PT al antetulu RTP. În plus, tipurile de payload-uri din intervalul 96-127, pot fi definite dinamic printr-un protocol de control de conferință. De exemplu, pentru o sesiune dată, PT 96, indică o codare PCMU, cu o rată de eșantionare de 8,000 Hz, pe două canale.
Intrările din Tabelele 3.3 și 3.4, cu tipul de payload “dyn”, nu au asignate payload-uri statice, și sunt folosite numai cu payload dinamic. PT 2 a fost alocat codării G726-32, dar utilizarea sa este depășită, și acel tip de payload static este rezervat, ca urmare a conflictului dintre formatele G726-32 și AAL2-G726-32. PT 13 indică formatul de payload “Confort Noise”(zgomot de confort), CN. PT 19, este marcat ca ”rezervat”, pentru că unele versiuni au alocat acest număr într-o versiune anterioară, zgomotului de confort, CN. Intervalul de PT 72-76 este marcat ca “rezervat”, pentru ca pachetele RTP și RTCP, să poată fi distinse.
Tipurile de payload definite de acest profil, sunt atribuite unei categorii din trei, sau unui tip media: doar audio, doar video, precum și cele care combină mediul audio și video. Tipurile de media sunt marcate în Tabelele 3.3 și 3.4 cu “A”, ”V”, și respectiv cu ”AV”. Tipurile de payload de la medii diferite, nu vor putea fi multiplexate într-o singură sesiune RTP, dar mai multe sesiuni pot fi folosite în paralel, pentru a trimite mai multe tipuri media. O sursă RTP poate schimba tipul de payload din cadrul aceluiași tip de media în timpul unei sesiuni.
Tabelul 3.3. : Tipuri de payload PT (Payload Type), pentru codările audio
Tabelul 3.4. : Tipuri de payload PT (Payload Type), pentru codările video și cele combinate
Participanții la sesiune decid, prin anumite mecanisme, setul de payload-uri permise într-o sesiune dată. Acest set de payload-uri, poate fi definit de capabilitățile aplicațiilor folosite, negociat de un protocol de control pentru conferință, sau stabilit de comun acord de către participanți.
Aplicațiile audio care operează în conformitate cu acest profil ar trebui, cel puțin, să fie capabile să trimită și/sau să receptioneze PT 0 (PCMU) și PT 5 (DVI4). Acest lucru permite interoperabilitatea, fără negocierea formatului, și asigură negocieri de succes, cu un protocol de control pentru conferință.
Capitolul IV
Next Generation Network (NGN)[12]
Soluția care asigură convergența rețelelor de date cu cele de voce, oferind servicii multimedia este NGN – Next Generation Network.
4.1. Structura NGN[12]
NGN este un “schelet” pentru o infrastructură informatică globală prin care se asigură utilizatorilor servicii multimedia. Utilizatorii au acces la aceste servicii multimedia asigurate de NGN, oricând, de oriunde, și de la orice terminal (în limita capabilităților terminalului).
Arhitectura NGN este structurată pe nivele independente, care folosesc modul de transport pachet atât pentru voce cât și pentru date și care sunt reprezentate în Figura 4.1.
Figura 4.1. Structura NGN[12]
Nivelul terminalelor include toate tipurile de terminale: terminalul telefonic clasic (analogic), terminalul ISDN, terminalul ADSL, terminale de date (PC – personal computer) și terminalele mobile GSM (2G – 2,5G) și UMTS (3G). Nivelul terminalelor și nivelul acces cuprind și elemente specifice comunicațiilor mobile GSM și UMTS, deoarece tendința NGN este de a integra toate tipurile de comunicații într-o singură rețea. Terminalele pot opera în două domenii:
● CS (Circuit Switching)
● PS (Packet Switching)
Terminalele din domeniul CS rămân limitate la comutația de circuite de 64 kbps și nu asigură servicii multimedia. Domeniul CS este controlat de CSCS (Circuit Switched Call Server) din planul de control. Transformarea semnalului de voce în pachete IP se face fie în terminal fie în Media Gateway (MG).
Terminalele din domeniul PS asigură servicii multimedia (voce, video, date etc.). Controlul acestui domeniu este realizat de MMCS (MultiMedia Call Server), iar transformarea semnalelor în pachete IP este realizată exclusiv în terminal.
La nivelul terminalului se poate pune problema recunoașterii (autentificării) utilizatorului. În acest scop se poate folosi mecanismul bazat pe utilizator (nume utilizator) – parolă, sau autentificarea cu USIM (Universal Subscriber Identification Module), ca în comunicațiile mobile 3G.
NGN trebuie să asigure mobilitatea utilizatorului, sub următoarele aspecte:
▪ Mobilitate personală – posibilitatea de a folosi diferite terminale, cu pastrarea identității utilizatorului;
▪ Mobilitatea serviciului – posibilitatea de a avea acces la un serviciu anume, indiferent de terminal și de locul de acces;
▪ Mobilitatea terminalului – posibilitatea schimbării locației terminalului, cu păstrarea comunicației. Sub acest aspect se face distincție între mobilitatea discretă a terminalului (roaming) – fără ca terminalul să facă tranfer de informație pe timpul deplasării, și mobilitatea continuă (hand-over) – când transferul de informație nu se întrerupe pe durata deplasării. Managementul mobilității terminalului este singurul aspect al NGN specific mobilelor, toate celelalte funcții fiind comune pentru mobil și fix.
Nivelul acces și transport. Nivelul acces are rolul de a “ascunde” tipul de acces al utilizatorului față de sistem, astfel încât toți utilizatorii să fie tratați uniform de nivelele superioare; pentru utilizatorii mobili nivelul acces este responsabil cu managementul mobilității, care nu este vizibil pentru nivelele superioare, iar transportul cuprinde rețelele interne ale NGN (backbone), și tehnicile folosite pentru transportu (IP, ATM). Nivelul acces combină toate tehnicile de acces utilizate în prezent: telefonia clasică POTS, telefonia ISDN, ADSL, telefonia mobilă GSM – BSS/UMTS – RAN, HFC (Hibrid Fiber-Coax), LMDS (Local Multipoin Distribution System).
Nivelul media cuprinde echipamente de tip Media Gateway (MGW), cu rol de adaptare a datelor provenite de la diferite tipuri de terminale de acces la modul specific folosit în rețeauade transport (backbone): IP sau ATM. Se pot întâlni patru tipuri de MGW organizate în două categorii:
● MGW de acces, care cuprinde:
– Acces Gateway (AGW), localizat în centrală (între centrală și abonat)
– Residential Gateway (RGW), localizat la abonat
– Integrated Acces Devices (IAD), localizat la abonat, dar cu posibilități mai extinse decât RGW.
● MGW de trunchiuri (conexiuni între centrale), respectiv Trunking Gateway (TGW), localizat între centrale.
Protocoalele folosite la nivel de media sunt protocoalele pentru transmisia informației : RTP, împreună cu RTCP.
Nivelul control cuprinde echipamente care prelucrează informația de semnalizare (Signaling Gateway – SGW) și controlează apelul (Media Gateway Controller – MGC). MGC mai este denumit Call Server, Call Agent sau Softswitch deoarece îndeplinește o funcție similară centrului de comutație din rețeaua telefonică clasică.
SGW are rolul de a realiza conversia între sistemul de semnalizare ITU-T nr. 7 folosit în rețeaua telefonică clasică și semnalizarea bazată pe IP (SIGTRAN, definit de IETF).
MGW îndeplinește rolul de control al apelurilor (Softswitch) și de control al echpamentelor de tip Media Gateway, astfel încât acestea să rezerve resurse pentru conversia și transmisia semnalului asociat apelului.
Pentru stabilirea apelurilor, MGC pot folosi și alte protocoale:
● protocolul SIP, bazat pe clienți SIP și servere SIP, care schimbă mesaje simple și răspunsuri la mesaje;
● protocolul H323, bazat pe zone controlate de un Gatekeeper (GC), care asigură translatarea adreselor, controlul admisiei și managementul terminalelor din zona respectivă;
Există trei tipuri de MGC, denumite în continuare Call Server (CS):
● Multimedia CS (MMCS), care stabilesc conexiuni de tip multimedia;
● Circuit Switching CS (CSCS), care controlează comutația de circuite (pentru apeluri telefonice):
– Mobile CSCS pentru apeluri de la / spre mobil
– Fixed CSCS pentru apeluri de la / spre telefonia fixă.
Nivelul servicii înglobează elementele care asigură la nivel centralizat logica de tratare a serviciilor (Application Server – AS) precum și bazele de date asociate cu aceste servicii (Media Server – MS). Nivelul servicii este similar cu SCP (Service Control Point) din rețeaua inteligentă IN.
Nivelul management acoperă toate nivelele prezentate (mai puțin terminalele) asigurând managementul NGN sub toate aspectele : configurări, alarme și înlăturarea defecțiunilor, statistici de trafic, securitate, taxare.
4.2. Avantajele NGN[12]
Pentru producătorii de echipamente: o nouă piață de desfacere;
Pentru operator: posibilitatea de a oferi servicii de date și telefonie într-o singură rețea flexibilă (datorită modului de comutare de pachete și transportului IP);
Pentru utilizator: posibilitatea de a alege între mai mulți furnizori de acces, mai mulți furnizori de servicii și mai mulți operatori de transport, deoarece NGN permite coexistarea acestora pe baza unor interfețe deschise între nivelele funcționale, înlocuind modelul economic convențional operator-abonat;
Organizarea pe nivele independente interconectate prin interfețe deschise permite înlocuirea (upgrade hardware sau software) la un anumit nivel fără a fi necesară intervenția la celelalte nivele;
Centralizarea funcțiilor de control într-un număr redus de MGC reduce costurile de întreținere;
4.3. Tranziția spre NGN[12]
Se va face treptat, în primul rând din motive de cost. Deși echipamentele NGN sunt mai ieftine decât echipamentele unei rețele clasice (centrale telefonice și echipamente de transmisiuni), înlocuirea totală a rețelei existentă cu NGN nu este economică, mai ales în cazul în care rețeaua existentă a fost modernizată recent prin introducerea centralelor digitale de mare capacitate.
Prima etapă a tranziției va fi înlocuirea centralelor din clasa 4 (de tranzit) și a sitemelor de transmisiuni aferente cu elementele NGN și păstrarea centralelor locale (clasa 5), care se vor conecta la NGN prin Media Gateway pentru planul de comutație și prin Signalling Gateway pentru planul de semnalizare.
În următoarea etapă se vor înlocui centralele de tip 5 (locale) cu Media Gateway controlate de MGC.
Rețelele mobile, au trecut printr-o tranziție majoră în ultimii 20 ani. Prima generație, 1G, oferea servicii de bază, legate despre discurs. A doua generație, 2G, a adăugat câteva servicii suplimenare și servicii de date. A treia generație, 3G, permite viteze mai ridicate, dar și diverse servicii multimedia. Dispozitivele multimedia sunt mai tot timpul pornite și conectate la rețea. Acest lucru redfinește aplicațiile care nu mai lucrează izolat, ci sunt entități de tipul peer-to-peer (vârf la vârf), care facilitează partajarea: între browsere, între două sesiuni radio, etc. Apelarea și comunicarea vor deveni o parte îngustă a rețelisticii, iar abilitatea de a stabili o conexiune peer-to-peer între dispozitivele noului protocol Internet (IP), este condiția necesară.
Avem nevoie de de un sistem la nivel global, și anume IP Multimedia Subsystem (IMS) care permite aplicațiilor să stabilească conexiuni peer-to-peer sau peer-to-content, ușor și sigur. IMS este un sistem global, bazat pe conectivitate IP standard.
GSM (Global System for Mobile Communications) a fost definit de ETSI (European Telecommunications Standards Institute) între anii 1980 și 1990. ETSI de asemenea a mai definit și arhitectura rețelei GPRS (General Packet Radio Service). Ultimul standard GSM a fost produs în 1998, și în același an a fost fondată și 3GPP (Third Generation Partnership Project) de către organizațiile de de standardizare din Europa, USA, China, Japan și Korea de Sud. După Release (lansarea) 1999, Release 2000 a început să includă toate protocolalele Internet care au fost numite mai târziu IMS. Dezvoltarea IMS nu a fost terminată la sfârșitul anului 2000, și de aceea Release 2000 a fost împărțită în Release 4 și Release 5.
În final, 3GPP Release 5 a introdus IMS, o arhitectură bazată pe IP, independentă, care conlucrează cu rețelele existente de voce și date, pentru utilizatorii mobili și fixi.
4.4. Calitatea serviciului (QoS)[13]
QoS în NGN este în stânsă legătură cu QoS în rețeaua Internet având în vedere că NGN se bazează pe o rețea backbone IP.
Specificațiile originale IP nu garantează QoS (best effort – cel mai bun efort). Se pot folosi următoarele mecanisme pentru asigurarea calității :
● IntServ
● DiffServ
● MPLS
IntServ (Integrated Services) folosește protocolul RSVP (Resource Reservation Protocol) pentru a asigura un nivel QoS cerut pentru o conexiune cap la cap, prin rezervarea de bandă și prioritate de livrare.
Sunt posibile trei clase QoS :
▪ Best Effort (BE), care corespunde specificației originale Internet și nu garantează nimic în privința QoS (nu folosește RSVP) ;
▪ Controlled Local (CL), folosește RSVP pentru a garanta un QoS similar cu cel asigurat de o rețea slab încărcată ;
▪ Guaranteed Service (GS), care asigură un QoS garantat (limita superioară pentru întârziere și pierderi de pachete).
DiffServ (Differentiated Services): oferă utilizatorilor nivele diferite de QoS, simplu de implementat cu ajutorul unor câmpuri din antetul IP: ToS (Type of Service), prin care se stabilește o prioritate relativă a pachetelor care corespund cu diferite servicii.
MPLS – Multi Protocol Label Switching, folosește pentru controlul fluxului de date o etichetă prin care se asigură un nivel QoS impus.
4.5. Securitatea în NGN[11]
În NGN pot fi identificate patru aspecte privind cerințele de securitate:
▪ Securitatea calității serviciului (QoS), în scopul prevenirii folosirii neautorizate a resurselor rețelei și degradării calității serviciului din cauza traficului neautorizat;
▪ Securitatea infrastructurii rețelei, atât din punct de vedere funcțional al rețelei de telecomunicații propriu-zise, cât și din punct de vedete al securității controlului și managementului rețelei.
▪ Securitatea end-to-end, care asigură confidențialitatea și integritatea comunicației end-to-end;
▪ Securitatea punctului de acces, cu scopul prevenirii accesului neautorizat la terminalul utilizatorului și la datele memorate în acesta, precum și cu scopul de a preveni utilizarea neautorizată a terminalului utilizatorului, în scopul folosirii rețelei și serviciilor în contul acestui utilizator. Securitatea punctului de acces presupune folosirea unor proceduri de autentificare și autorizare;
4.5.1 Arhitectura de securitate în NGN[11]
Are în vedere:
▪ Proceduri securizate de acces, care sunt obligatorii având în vedere mobilitatea personală a utilizatorului, care se poate conecta oriunde la rețea, folosind orice terminal, păstrându-și identitatea ca utilizator. În acest sens NGN trebuie să suporte:
► Autentificarea cu parolă (PAP – Password Authentication Protocol)
► Autentificarea CHAP (Challenge Handshake Authentication Protocol)
► Autentificarea RADIUS (Remote Authentication Dial In Service)
▪ Securitatea în rețeaua de acces.
▪ Securitatea în rețeaua backbone a NGN (IPSEC – IP Security), cu unele aspecte specifice:
► Protocoale de securitate: autentificarea antetului (AH – Authentication Header), criptarea informației utile (ESP – Encapsulation Security Payload);
► Managementul cheilor de criptare: IKE – Internet Key Exchange;
► Algoritmi de criptare și autentificare: deși mecanismele IPSEC sunt concepute pentru a fi independente de algoritm (care poate fi ales de operator), este specificat un set de algoritmi standard pentru a asigura interoperabilitatea la nivel global;
► Utilizarea unui firewall și a unor filtre pentru limitarea accesului.
Capitolul V
Aspecte practice ale unei transmisii streaming
5.1. Echipamente necesare[16]
Pentru a transmite materiale prin video streaming trebuie să avem acces la o serie de produse:
■ Camera video
■ Microfon
■ Lumini
■ Computer
■ Soft pentru codare
■ Server pentru streaming
Camera video
Camerele digitale (digital video-DV) sunt de obicei mai scumpe decât cele analogice, dar au o calitate a imaginii mult mai bună. Dacă imaginile sunt salvate direct în format digital pierderile sunt mici în timpul capturii de pe camera DV pe calculator. Dacă camera este prevazută și cu un conector de tip FireWire captura poate să se realizeze în condiții optime.
FireWire este o interfața standard pentru calculatoare (PC-uri) și Macintosh-uri care permite transmisia directă a formatului audio/video digital între camera DV și calculator.
Formatele digitale utilizate sunt :
■ MiniDV – una dintre camerele performante pe care consumatorul o poate avea;
■ Digital 8 – aproape la fel de performantă ca și camera MiniDV, de dimensiuni mai mari și preț mai scăzut. Filmează în același format ca și camerele analog HI-8, oferind conexiune FireWire;
■ MicroMV – format digital introdus de Sony cu rezultate comparabile cu MiniDV, dar în casete cu 70% mai mici;
■ Camera Web – conectată direct la un calculator prin USB poate fi folosită pentru a transmite evenimente în direct. Soft-ul de care dispune, permite înregistrarea evenimentelor. Performanțele uneori lasă de dorit, dar alegerea acestei camere se datorează prețului scăzut.
Microfonul
Marea majoritate a camerelor sunt prevăzute cu microfon, iar cele mai performante sunt capabile să elimine zgomotul de fond. Dacă avem nevoie de mai multe microfoane, ar fi indicată folosirea unui mixer pentru a combina două sau mai multe canale de intrare într-unul singur.
Luminile
Luminile folosite depind de ceea ce dorim să filmăm. Când le utilizăm trebuie să fim atenți, deoarece pot apărea diferențe între ceea ce vedem, LCD-ul camerei și monitorul calculatorului.
5.2. Servere de streaming[14]
Avantajul serverelor de streaming fața de serverele uzuale îl reprezintă abilitatea de a proteja proprietatea intelectuală (fișierul nu este descărcat) și faptul că utilizatorii pot ‘interacționa’ cu fișierul (pot derula înainte și înapoi în timp real). De asemenea în cazul streamingului se asigură un control bun asupra accesului utilizatorilor la fișiere.
Pentru o configurație de server streaming se recomandă un minim necesar :
▪ procesor > 1 GHz. Un sistem multi procesor îmbunătățește performanțele și crește abilitațile de multi-tasking ale sistemului;
▪ 1 GB RAM memorie minim. De regulă aceste servere oferă și servicii de FTP și Web. Dimensiunea mică a memoriei va determina scăderea dramatică a eficenței server-ului;
▪ capacitați de stocare mari. Mai multe opțiuni sunt disponibile în materie de capacitate de stocare; se recomandă folosirea sistemelor RAID, deoarece permit ca HDD-urile să fie legate împreună ca un singur disc, back-up-ul realizându-se de asemenea mai ușor. Sistemele RAID au timpi de acces foarte mici și sunt foarte rapide, oferind un avantaj serverelor care realizează mai multe operații;
▪ raport viteză/rată de transmisie optim. Nu are sens un server puternic, rapid, dacă conexiunea nu suportă ratele respective ;
▪ pentru transmisii live este necesară prezența plăcii de captură în cazul utilizării unei surse analogice și/sau a porturilor fireware pentru sursele digtale.Este indicată utilizarea unor plăci de captura dedicate/specializate cu capacitați de compresie pe placă pentru a nu folosi resursele de procesare ale serverului.
În unele sisteme, captura și partea de server se fac în același loc. Se recomandă două ‘dispozitive’ diferite, astfel încât dacă o parte ‘cade’, se defectează, se înlocuiește partea respectivă și un intreg sistemul. În orice situație se poate utiliza un sistem de back-up.
Toate formatele majore de streaming oferă soft pe partea de server care controlează accesul și distribuția. Acest soft trebuie să ruleze pe un calculator cu un sistem de operare corespunzător : Linux, MS Server, OS.
Alegerea serverului cu care se va face streaming-ul este importantă deoarece :
▪ sunt influențați direct parametrii transmisiei, formatele de fișiere care vor fi oferite, precum și numarul de utilizatori care pot accesa simultan transmisia;
▪ costurile sunt diferite, putându-se ajunge la peste 10.000 $;
▪ diferă posibilitatea de configurare a parametrilor de funcționare, de realizare a securitații datelor.
5.2.1. Soluții comerciale[14]
RealNetworks Server
Este destul de stabil, rapid, utilizează o interfață agreabilă, este securizat și are capabilitați de control de la distanța (remote). Este suportat de Microsoft Windows, Linux, FreeBSD și Solaris, cu abilitați de transmitere pe toate dispozitivele media. Ușor de configurat, permite lucrul cu alte servicii și cu alte programe de streaming. Dezavantajul serviciului este costul ridicat.
Helix Universal Server, care tinde să înlocuiască RealSystem Server, afirmă că reduce costul supotând formatele de streaming: Windows Media, QuickTime, RealVideo, precum și MPEG (MPEG-1, MPEG-2, MPEG-3 și MPEG-4). O versiune gratuită a acestui program există, cu mențiunea că numărul persoanelor care pot accesa conținutul simultan este limitat la 10, iar licența este valabilă un an.
Serverul permite selectarea automată a codării potrivită fiecărui utilizator atunci când acesta se conectează. Dacă banda disponibilă utilizatorului scade, serverul va trece la o codare inferioară, astfel încât transmisia nu se întrerupe, iar când banda revine la valori mai mari, se va trece din nou la rate de codare mai mari.
Microsoft Windows Media Server
Spre deosebire de RealNetworks, Media Server rulează doar pe un server Windows. Un avantaj al acestei soluții îl reprezintă abilitatea de a transmite la peste 3000 de utilizatori fară să implice cheltuieli de licența suplimentare. Nu este la fel de sigur ca RealNetworks; aceasta nu însemnă că serverul și fișierele pot fi atacate/modificate, dar au fost create programe care permit utilizatorilor să înregistreze secvențele video transmise prin streaming.
Clienții pot fi dispozitive ce utiltizează un player precum Windows Media Player sau alte calculatoare pe care rulează Windows Media Services, depozitând sau redistribuind informațiile.
Apple QuickTime Streaming Server
Este destinat exclusiv calculatoarelor Macintosh și suportă formate ca : MOV, MP3, MPEG-4, Shockware Flash și peste 4000 de utilizatori.
Avantajul îl constituie calitatea secvențelor video, codate după algoritmi specifici. Este un factor decisiv pentru multe companii cinematografice în acțiunea lor de lansare a filmelor de prezentare (trailere-lor) pe web (http://www.apple.com/trailers/). Dezavantajul apare la viteze de transmisie mici; calitatea este inferioară celorlalte soluții oferite datorită arhitecturii codecurilor folosite precum și grupului țintă ales.
Flash Media Server
Serviciile de streaming pentru ‘flash’ au fost introduse o dată cu apariția pe piață a produselor Flash MX, Flash Player 6 și Flash Communication Server MX.
Dintre caracteristici amintesc :
▪ determinarea lărgimii de bandă a clientului și furnizarea unui streaming cu o rată de bit adecvată;
▪ măsurarea și urmărirea calității streaming-ului, comutarea la o rată de bit mai mică, dacă rețeaua este congestionată;
▪ generarea automată de thumbnail-uri sau rularea de mici preview-uri ale clipului fară crearea unei imagini separate sau a unui alt clip video;
▪ webcastingul live.
Prețul acestui pachet software este însa unul ridicat : ~ 4500$ .
5.2.2. Soluții Open Source[14]
Soluțiile Open Source oferă posibilitatea utilizării gratuite a alicațiilor și continuă dezvoltarea în funcție de nevoile utilizatorilor. Existența unei comunități largi de utilizatori și dezvoltatori duce în mod automat la o evoluție rapidă a soluțiilor oferite, cel puțin teoretic.
VLC Streaming Server
VLC este una dintre aplicațiile cu cea mai spectaculoasă evoluție într-un timp relativ scurt de la lansarea proiectului.
Darwin Streaming Server
Darwin Streaming Server este versiunea Open Source a Apple QuickTime Streaming, versiune bazată e PERL și pusă la dispoziția dezvoltătorilor cu apariția QuickTime 5.
Sistemele de operare compatibile sunt : Mac OS X, Windows XP și Windows NT Server/Windows Server, RedHat 7.1, Solaris, FreeBSD. Fiind realizat din scripturi PERL, această versiune este dificil de configurat pentru necunoscătorii limbajului, dar oferă o mare diversitate de formate suportate pentru streaming, standarde media MPEG-4 și 3GPP, configurări remote prin intermediul unei interfețe web, precum și peste 2000 de utilizatori suportați de server simultan. Protocoalele utilizate sunt RTP/RTSP în modul unicast sau multicast.
5.3. VLC[19]
5.3.1 Generalități[19]
VLC (VideoLAN Client) face parte din proiectul VideoLAN ce se dorește a fi o soluție completă pentru streaming si playback. A fost dezvoltat de către studenții de la Ecole Centrale Paris și alți dezvoltatori din întreaga lume sub licența GNU (General Public License).
Se caracterizează prin posibilitatea utilizării pe diferite platforme : Windows, Mac OS X, BeOS, Debian GNU/Linux, Ubuntu Linux, Mandriva Linux, Fedora Core, Familiar Linux, SUSE Linux, Red Hat Linux, Slakware Linux, ALT Linux, YOPY/Linupy, Zaurus, WinCE / PocketPC, Arch Linux, NetBSD, OpenBSD, FreeBSD, Solaris, QNX, Gentoo Linux, Crux Linux.
Poate citi :
▪ MPEG-1, MPEG-2 și MPEG-4 / DivX de pe hard disc sau CD-ROM
▪ DVD și VCD
▪ de la carduri de satelit (DVB-S)
▪ de la camere video (DV)
▪ streamuri din rețeaua locală sau Internet.
VLC este utilizat ca și server de streaming pentru a genera fluxuri de date :
▪ MPEG-1, MPEG-2 și MPEG-4 / DivX ;
▪ DVD ;
▪ captate de la diverse plăci de achiziții MPEG ;
▪ de la camere video la : – un dispozitiv printr-o adresa IP – unicast.
– un grup dinamic de dispozitive unde clienții se pot loga sau pot părăsi transmisia- multicast.
Figura 5.1. Input/Output VLC[19]
5.3.2. Codec/container[20]
Un codec este un algoritm de compresie utilizat pentru a reduce dimensiunea unui stream, codarea propriu-zisă presupunând o compresie dintr-un format într-altul ce ocupă mai puțin spațiu decât precedentul. Avem de a face cu codec-uri audio/video MP3, MPEG1, MPEG2, MPEG4, Ogg-vorbis, DivX etc.
Un ‘container’ conține mai multe stream-uri codate/compresate de diverse codec-uri. AVI, MOV, Ogg, ASF, MP4 sunt containere. Conținutul unui stream poate fi codat utilizând diverse codec-uri, într-o lume perfectă putem pune orice codec în orice container. Se găsește o listă completă la adresa : http://www.videolan.org/streaming/ features.html. Stream-urile codate se multiplexează, aceasta însemnând că părți separate ale materialului de transmis se combină într-un singur container.
Vizualizarea video: pentru a decoda un stream, VLC-ul îl demultiplexează mai întâi, citește conținutul container-ului și separă audio de video, eventual de subtitrare dacă există. Demultiplexarea nu presupune pierdera calității, înseamnă doar separarea în stream-uri individuale. Ulterior, pentru fiecare stream urmează procesul de decodare, procesul matematic propriu-zis de decompresie.
5.3.3 Particularități MPEG[18]
MPEG este un codec, și există mai multe versiuni, MPEG1, MPEG2, MPEG4… .
MPEG este de asemenea și un container cunoscut ca și MPEG System. Distingem MPEG, ES, PS, TS.
Vom lua ca exemplu vizualizarea unui MPEG de pe DVD, unde stream-ul principal MPEG este compus din mai multe Elementary Streams (ES): există câte un stream pentru video, pentru audio și pentru subtitrare, dacă este cazul. Aceste stream-uri elementare sunt combinate într-un singur Program Stream (PS). Prin urmare fișierele cu extensia VOB, ce se găsesc pe DVD sunt fișiere MPEG PS. Acest format nu este întotdeauna adaptat pentru transmiterea de conținut audio-video print-o rețea de date sau prin satelit (streaming), de aceea a fost proiectat un alt format, Transport Stream (TS), pentru astfel de situații.
5.4. Streaming utilizând linia de comandă[18]
Modulele disponibile sunt:
● standard – permite transmiterea stream-ului prin UDP, HTTP, fișier etc.
● transcode – permite codarea și decodarea (utilizând codec-uri/bitrate-uri diferite) părții audio și video a fluxului de intrare.
● duplicate – permite crearea unui lanț secundar pentru streaming, unde stream-ul poate fi tratat într-un mod independent.
● display – permite vizualizarea stream-ului de intrare. În combinație cu duplicate se monitorizează fluxul de date în timpul procesării.
● rtp – permite folosirea RTP/RTSP.
● es – permite creearea de stream-uri elementare separate.
5.5. Instalarea și configurarea serverului VLC[19]
Se instalează VLC, iar figura de mai jos ne arată interfața cu utilizatorul.
Pentru încărcarea unui fișier audio/video, se parcurg următorii pași : ‘Media > Streaming’, pentru a deschide fereastra ‘Open’, apoi se selectează fișierul dorit, și se apasă butonul ‘Stream’.
Figura 5.2. Programul VLC[19]
Figura 5.3. Uploadarea unui fișier[19]
Se bifează căsuța ‘Play locally’ de sub meniul ‘Outputs’. Când se face streaming către un alt calculator, nu este neapărat sa rulăm fișierul respectiv și pe server, dar noi vom folosi această opțiune pentru a confirma faptul că filmul nostru merge normal, înainte de a accesa stream-ul de pe alt calculator.
Se bifează căsuța cu protocolul pe care dorim sa-l utilizăm, în cazul nostru RTP, se introduce adresa IP a calculatorului pe care dorim să stream-uim fișierul, și numărul de port (în cazul unui fișier audio-video, transmisia se face pe două canale, și deci trebuie folosit un port pentru audio, și unul pentru video).
Apoi se alege metoda de încapsulare, se bifează căsuța ‘Keep stream output open’, și se apasă butonul ‘Stream’.
Figura 5.4. Configurarea VLC-ului[19]
Play locally : permite vizualizarea stream-ului pe calculatorul propriu, oferindu-se posibilitatea monitorizării locale a efectelor de codare, rescalare etc.
File: permite salvarea stream-ului într-un fișier.
HTTP: permite stream-ul pentru Microsoft Windows Media Player. Se specifică adresa IP și portul TCP, unde stream-ul va putea fi vizualizat. Funcționează doar cu metoda de “încapsulare” ASF.
UDP: permite streamingul în unicast cu adrese între 0.0.0.0 – 223.255.255.255 și multicast.
RTP: utilizează protocolul Real Time Transfer Protocol. Ca și la UDP, se poate face streaming unicast și multicast.
Metode de încapsulare: presupun alegerea unui container MPEG TS, MPEG PS, MPEG1, OGG, Raw, ASF, AVI, MP4 și MOV care să se potrivească codec-urilor audio și video. Aceste codecuri sunt selectate dintr-o listă pusă la dispoziție de VLC în interfața grafică aferentă (mărimi ca rata de bit pentru codecul video sau audio, numărul de canale audio, pot lua diferite valori).
Figura 5.5. Ajustarea ratei de bit[19]
Fișierul audio sau video, ar trebui să înceapă să ruleze pe server. Ultimul lucru înainte de a trece la celălalt calculator, este de a activa interfața Web a VLC-ului, prin parcurgerea următorilor pași: ‘Tools > Add Interface > Web Interface’.
Se deschide VLC-ul pe calculatorul client, se face click pe ‘Media > Open Network’, pentru a deschide fereastra ‘Open’, se selectează protocolul dorit, RTP, apoi se apasă butonul ‘Play’, iar VLC-ul va începe redarea stream-ului.
Figura 5.6. Deschiderea stream-ului de pe un calculator client[19]
Acum, dacă stream-ul este redat cu succes, se poate deschide un browser Web, pentru a controla VLC-ul de la distanță. Tipăriți în bara de adrese: http://<IP-ul serverului>:8080/ . Browser-ul de web va furniza toate controalele de care avem nevoie pentru a gestiona fișierul la distanță.
Figura 5.7. Streamul audio/video care rulează de pe calculatorul client[19]
5.6. Analizoare de trafic de rețea[16]
Analizoarele de trafic de rețea sunt în general instrumente software care sunt capabile să capteze și să analizeze traficul transmis sau recepționat de către un calculator care este conectat într-o rețea. Aceste instrumente pot fi utilizate atât în scop de studiu al funcționării protocoalelor de rețea (mecanisme, structura cadrelor etc), cât și pentru îmbunătățirea funcționalității și a securității rețelei.
Cele mai multe dintre aceste instrumente se descarcă gratuit de pe Internet, unele dintre ele fiind chiar părți integrante ale unor sisteme de operare. Câteva analizoare de rețea (packet sniffer) des folosite sunt: Ethereal, Wireshark (versiunea nouă a lui Ethereal), Microsoft Network Monitor (pachet suplimentar al sistemelor de operare Windows), ettercap (program ce poate fi folosit pentru capturarea parolelor transmise într-o rețea de către unele protocoale de nivel aplicație), ufasoft_sniffer (care poate fi folosit pentru interpretarea pachetelor de pe diferite interfețe), trafmeter (este folosit pentru evidențierea grafică a ratei de transfer).
5.7. Wireshark[8]
Prin folosirea acestui program se poate urmări traficul care se realizează între client și serverul de video streaming. Pentru aceasta se realizează următori pași:
Din meniul programului “Wireshark” se alege interfața care se dorește a fi spionată. Pentru aceasta se alege: Capture > Interfaces.
Pe ecran vor apărea diverse pachete, care reprezintă comunicarea între stațiile din rețea (în cazul nostru , majoritatea pachetelor sunt RTP și reprezintă comunicarea clientului cu serverul de video streaming).
Figura 5.8. Pachetele RTP care apar în timpul conexiunii[8]
Din fereastra inițială a programului se alege Statistics > IO Graphs și se pornește captura. În figura de mai jos se poate observa cantitatea de informații care este transmisă de pe calculatorul client, pe server
Figura 5.9. Pachetele capturate într-un interval de timp[8]
Concluzii
În Internet, la fel ca și în alte rețele, este posibilă pierderea pachetelor, schimbarea ordinii în procesul de transmitere, de asemenea variază timpului de transmitere a pachetelor la distanțe mari. Aplicațiile multimedia pun condiții foarte dure asupra ambianței de transmitere. Pentru convenirea cu posibilitățile Internetului a fost creat protocolul RTP. Protocolul RTP este bazat pe cadre, și are scopul de a transmite date audio și video în timp real. RTP furnizează transport în timp real, numerotarea secvențelor, identificarea informației utile, sincronizarea Intra și Intermedia, criptare, multicast, nu oferă calitatea serviciului, și nu necesită rezervarea de resurse.
RTCP-ul este folosit pentru raportul QoS, și anume raportul emițătorului (pachete transmise), și raportul receptorului (pierderi, întârzieri, bruiaj). Se mai folosește pentru sincronizare Media (corelarea etichetei de timp a RTP-ului). Aplicațiile de obicei folosesc RTP implementat peste UDP, pentru ca să se poată folosi de posibilitatea sa de multiplexare dar și de verificarea unei sume ciclice. RTP se poate folosi de asemenea și deasupra oricărui protocol de nivel 4 OSI (Open Systems Interconnect).
Întârzierea și jitterul întârzierii, sunt principalele aspecte ale transmisiunilor în timp real, iar traficul în timp real necesită mult mai multă lățime de bandă, decât traficul de tipul best effort. Din cauza întârzierilor care apar pe rețea, eșantioanele de sunet nu vin la timp, și atunci vocea va părea ciudată, iar acest lucru va fi sesizat de către utilizator, la fel se întâmplă și în cazul eșantioanelor video. În transportul în timp real, cel mai important lucru care se dorește, este ca lățimea de bandă să fie împărțită în mod egal în rândul utilizatorilor.
Streaming-ul a cauzat o profundă schimbare în educație, mass-media, divertisment, afaceri, combinând promptitudinea televiziunii cu interactivitatea Internetului, continuând să revoluționeze peisajul media actual, adăugând noi elemente.
Rețelele multimedia vor impulsiona utilizarea calculatorului ca instrument de comunicare. Eu cred că într-o zi, rețelele mutimedia vor înlocui serviciul de telefonie, televiziunea și alte invenții care ne-au schimbat radical viața.
Deci, proiectarea protocolalelor în timp real pentru rețelele multimedia, devine necesară, înainte de sosirea erei multimedia
BIBLIOGRAFIE:
[1] Mircea Vladuțiu, Marius Marcu, A genetic algorithm for Thermal Image Deconvultion, Iranial Journal of Electrical and Computer Engineering, vol 3, No2, Summer-Fall 2004
[2] Horia Ciocârlie , Rodica Ciocârlie, Utilizarea si programarea calculatoarelor , Orizonturi Universitare 2004
[3] Silea Ioan, Administrarea rețelelor de calculatoare, Centrul de multiplicare al Universității Politechnica din Timișoara ,2001
[4] Titu I Bajenescu, Retele inteligente , Editura Teora, 2008
[5] Arhitectura retelelor de telecomunicatii , Editura Politehnica 2004
[6] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RFC 3550: "RTP: A Transport Protocol for Real-Time Applications", 2003. http://tools.ietf.org/html/rfc3550
[7] H. Schulzrinne, S. Casner , RFC 3551: "RTP Profile for Audio and Video Conferences with Minimal Control"; 2003. http://tools.ietf.org/html/rfc3551
[8] Alan B. Johnston, Understanding the Session Initiation Protocol, 2012
[9] Henning Schulzrinne, RTP, http://www.cs.columbia.edu/~hgs/rtp/.
[10] Chunlei Liu, Multimedia Over IP: RSVP, RTP, RTCP, RTSP
[11] Ian Wakeman, Jon Crowcroft, "Tunnelling RTSP and RTP through HTTP". A standard solution to help RTSP work through firewalls and web proxies, Computer Science Department, University College London, 2013
[12] Rafael Osso, Handbook of Emerging Communications Technologies: The Next Decade, 2011
[13] Real-time Transport Protocol (RTP), defined in RFC 3550, Hasselt University, 2013
[14] Javvin Technologies, "RTP". Network Protocols Handbook. 2012
[15] RTP. Broadband Networks. Ministry of Human resources, India. 2008.
[16] Addison-Wesley, RTP : Audio and video for the Internet / Colin Perkins, Boston, 2013
[17] Simon MORLAT, http://www.linphone.org/eng/documentation/dev/ortp.html
[18] http://en.wikipedia.org/wiki/Streaming_media
[19] http://www.videolan.org/vlc/
[20] http://en.wikipedia.org/wiki/Audio_Interchange_File_Format
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Rtp Si Internetul (ID: 150394)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.