Real-time Transport Protocol

Acest articol sau această secţiune trebuie pus(ă) în formatul standard. Ştergeţi eticheta la încheierea standardizării. Acest articol a fost etichetat în martie 2007

Real-time Transport Protocol (abreviat deseori ca RTP) este un protocol prin intermediul căruia se pot transmite informaţii de tip media (sunete, imagini) printr-o reţea de telecomunicaţii.

În Internet, de asemenea 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 se bazează pe ideile propuse de Klark şi Tenenhauzen, şi 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, şi 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.

Trebuie de luat în consideraţie căci RTP nu garantează transmiterea la timp a pachetelor şi nu oferă garanţia integrităţii transmiterii datelor. Corectitudinea transmiterii informaţiei poate fi asigurată de către partea care recepţionează pachetele cu ajutorul numerelor de ordine a pachetelor. Această posibilitate este foarte utilizată tot timpul, dar în special atunci când se transmit imagini prin intermediul protocolului RTP. În practică, protocolul RTP nu este divizat de protocolul RTCP (RTP control protocol). Ultimul îndeplineşte funcţia ca monitorizare şi pentru transmiterea informaţiei despre utilizatorii care schimbă informaţii. Protocolul RTP nu este un protocol strict, care poate să transmită informaţie unei aplicaţii, modulele funcţionale ale lui nu formează un strat aparte, dar mai des se integrează în programă. Protocolul RTP nu este un protocol strict reglamentat. Pentru organizarea la o audio-conferinţă fiecare membru trebuie sa aibă o adresă şi două porturi, unul pentru semnalele audio altul pentru schimbul de pachete RTCP. Aceşti parametri trebuie să fie cunoscuţi tuturor membrilor conferinţei. În dependenţă de cerinţe pachetele de coordonare pot fi codate. În timpul conferinţei fiecare membru trimite pachete audio mici codate, timpul de transmitere 20ms. Fiecare din acest pachet este înglobat în câmpul de date RTP care la rândul său se integrează în UDP. Antentul pachetului RTP determină ce fel de codare audio este folosită (PCM, ADPCM sau LPC), ce permite transmiţătorului în timpul transmiterii să schimbe algoritmul de codare, dacă la conferinţă s-a conectat un utilizator nou, cu anumite restricţii, sau daca trebuie micşorată viteza de transmitere a informaţiei prin reţea. În timpul transmiterii sunetului, o parte importantă e interacţiunea între fragmentele codate în timp. Pentru hotărârea acestei probleme antetul protocolului RTP conţine informaţia de timp şi numărul de ordine. Numărul de ordine ajută nu numai la regenera ordinii fragmentelor, dar şi pentru a afla numărul de fragmentelor pierdute în timpul de transmitere. Deoarece în timpul conferinţei pot să apară noi utilizatori, sau alţii să se retragă la după propria dorinţă, trebuie cunoscut, cine din ei sunt în reţea la momentul dat şi dacă informaţia transmisă către ei ajunge. Pentru acest scop periodic fiecare membru al conferinţei transmite prin portul RTCP un mesaj multicast, care conţine numele utilizatorului şi careva date de diagnostic. Aplicaţia client trimite pachetul BUY (RTCP), dacă utilizatorul părăseşte sesiunea. Dacă în timpul conferinţei se transmite nu numai semnal audio dar şi video, ele se transmit independent unul faţă de altul pe fluxuri diferite incorporate în protocolul UDP. RTCP pachetele se transmit indiferent pentru fiecare sesiune în parte. La nivel de RTP nu este nici o legătură între semnalele audio şi video. Numai RTCP pachetele transmit una şi aceeaşi adică numele membrului.

În unele cazuri putem sa ne întâlnim cu situaţia când unul din membrii conferinţei este conectat la un canal de viteză mica. Nu va fi chiar bine daca de la aceşti utilizatori va trebui să cerem transferul pe criptare. Pentru ca să scăpăm de aceasta se poate de instalat un reformator aşa numitul amestecător, în imediata apropiere de canalele de viteză mică. Amestecătorul transforma fluxul audio pachete in conformitate cu canalul de viteză mică. Aceste pachete pot fi uni-cast (adică adresate unui singur utilizator ) cât şi multicast. Antetul RTP include în sine mijloace care permit multiplexoarelor de a recunoaşte sursele externe. Aşa că primitorul poate identifica corect sursa de semnal. Unii utilizatori ai conferinţei, folosesc canale de viteză mare, care nu sunt susţin IP-multicast (de exemplu se află după Firewall). Pentru aşa noduri de reţea amestecătorul nu este nevoie, aici se foloseşte alt nivel de transmitere a protocolului RTP, aşa numitul translator. Se instalează două translatoare câte unul de fiecare parte a Firewall. Translatorul extern transmite pachete multicast pe o linie securizată translatorului intern. Translatorul intern deja transmite abonaţilor reţelei locale în mod obişnuit. Amestecătorul şi translatorul pot îndeplini şi alte funcţii de exemplu transformare pachetelor din IP/UDP în pachete ST-II in cazul la video conferinţă.

Structura pachetului

Ver. (2 biţi) indică versiunea protocolului RTP utilizată. Versiunea actuală este 2. P (un bit) este folosit pentru a indica dacă există informaţie suplimantară la finalul pachetului RTP. X (un bit) indică dacă sunt utilizate extensii ale protocolului în pachet. CC (patru biţi) conţine numărul identificatorului CSRC care îi urmează antetului fix. M (un bit) este folosit la nivelul aplicaţie şi este definit în cadrul profilelor. Dacă este setat, semnifică că datele curente au o semificaţie specială pentru nivelul aplicaţie. PT (7 biţi) indică formatul payloadlui şi determină interpretarea de către aplicaţie. SSRC indică sursa de sincronizare.

Atribute

• Câmpul de date RTP: Informaţia, transmisă în pachetul RTP, ca exemplu fragment de sunet sau informaţie video compresată.
• Pachetul RTP: Pachet de informaţie, care conţine un antent fixat. Un pachet de nivel inferior de exemplu UDP conţine un pachet RTP, dar aceasta nu e numaidecât. Câmpul pachetului poate sa fie gol.
• Pachetul RTCP: Pachetul de coordonare, care conţine un antent fixat asemănător cu antentul pachetului RTP, după care vin elementele structurate, în dependenţă de tipul pachetului RTCP. De obicei câteva pachete RTCP se transmit ca un singur pachet incorporat într-un pachet de nivel mai jos cum este UDP.
• Adresa de transportare: combinaţia de IP şi numărul portului, care identifică punctul final al canalului (ex: adresa IP şi portul UDP).
• Sesiunea RTP: perioada de la momentul când se face grupa de membri între care se face schimbul de RTP pachete şi până la dispariţia ei. Pentru fiecare dintre participant sesiunea se precizează cu o pereche de adrese de transport. Adresa de transmitere poate sa fie comuna pentru toţi.
• Sursa de sincronizare(SSRC): 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 pot fi ca surse de semnal începător (microfon sau cameră video). SSRC identificatorul reprezintă un număr aliator unical pentru această RTP sesiune. Membrul acestei sesiuni este obligat să folosească unul şi acelaşi SSRC identificator pentru toate sesiunile RTP. Dacă membrul formează câteva fluxuri in limita unei sesiuni RTP , fiecare membru trebuie să aibă un SSRC identificator unical.
• Sursa informaţională CSRC(contributing source): Sursa fluxului pachetului RTP, care contribuie la crearea fluxului comun, format de către amestecătorul RTP. Amestecătorul 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 amestecătorul înregistrează pe toţi care vorbesc, care glasul fiecărui membru devine ca sursă de transmitere a pachetelor. Aceasta permite parţii primitoare să identifice membrul care vorbeşte, măcar că toate pachetele au unul şi acelaşi SSRC identificator.
• Sistemul final: Aplicaţia care generează sau percepe datele, transmise in RTP pachete. Sistema finală poate să iasă în calitate de o sursă sau ca mai multe surse de sincronizare pentru o sesiune concretă.
• Amestecătorul: Sistemă intermediară, care primeşte pachete RTP de la unul sau mai multe surse, după necesitate schimbă formatul, le leagă şi le transmite abonaţilor. Deoarece legătura de timp a pachetelor poate să difere, amestecătorul înfăptuieşte sincronizarea lor şi generează singur un flux de protocoale RTP. Cu toate acestea toate pachetele RTP transmise au in calitate de sursă de sincronizare amestecătorul.
• Translator: O sistemă intermediară, care redirecţionează pachetele RTP, fără a schimba identificatorii surselor de sincronizare. Aşa sisteme se folosesc pentru reorganizarea sistemei de codificare, trecerea de la multicast la unicastul tradiţional sau la lucrul cu Firewall.
• Monitor: Aplicaţia, care primeşte pachete RTP, trimise de către membrii sesiunii RTP, în particular mesaje di diagnostică, apreciază calitatea legăturii şi păstrează pe mult timp statistica de schimb.

RFCs

• RFC 3551, Standard 65, RTP Profile for Audio and Video Conferences with Minimal Control
• RFC 3550, Standard 64, RTP : A Transport Protocol for Real-Time Applications
• RFC 1890, Obsolete, RTP Profile for Audio and Video Conferences with Minimal Control
• RFC 1889, Obsolete, RTP : A Transport Protocol for Real-Time Applications
• RFC 2250, Proposed Standard, RTP Payload Format for MPEG1/MPEG2 Video