RTP

Protocolul de transport în timp real (sau RTP de la engl. Real-time Transport Protocol) 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 checksum. 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 posibil la nivel de rețea.

Trebuie de luat în considerație că 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 separat de protocolul RTCP (protocolul de control RTP). 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 câteva 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

+ Biți 0-1 2 3 4-7 8 9-15 16-31 0 Ver. S Ex CC M SU Numărul secvenței 32 Timp la transmitere 64 identificatorul SSRC 96 ... identificatorii CSRC ... 96+(CC×32) Antet adițional (opțional), indică lungimea "AHL" 96+(CC×32) + (Ex × (AHL + 16))   Data

Câmpurile au următoarea semnificație:

• Ver. (versiune - 2 biți) indică versiunea protocolului RTP utilizată. Versiunea actuală este 2.
• S (spațiere - un bit) este folosit pentru a indica dacă există informație suplimantară la finalul pachetului RTP.
• Ex (extensie - 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 (marcaj - 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.
• SU (sarcina utilă - 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

Lectură suplimentară

• Perkins, Colin (2003), RTP, Addison-Wesley, ISBN 978-0-672-32249-5 
• Peterson, Larry L. (2007), Computer Networks (ed. 4), Morgan Kaufmann, ISBN 978-0-12-374013-7 
• „RTP”. Network Protocols Handbook. Javvin Technologies. 2005. ISBN 978-0-9740945-2-6. 
• „RTP”. Broadband Networks. Ministry of Human resources, India. 2008. 

Legături externe

• oRTP, RTP library from Linphone written in C Arhivat în 9 decembrie 2013, la Wayback Machine.
• Henning Schulzrinne's RTP page (including FAQ)
• GNU ccRTP
• JRTPLIB, a C++ RTP library
• Managed Media Aggregation Arhivat în 9 ianuarie 2018, la Wayback Machine.: .NET C# RFC compliant implementation of RTP / RTCP written in completely managed code.
• RTPMobile .NET, an open source .NET RTP library Arhivat în 9 mai 2012, la Wayback Machine.
• LScube project, providing a full streaming suite including experimental SCTP capability