ro RTP

Protocolul de transport în timp real^[1]^[2] (sau RTP, prescurtarea din 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 și schimbarea ordinii în procesul de transmitere. De asemenea, timpul de transmitere a pachetelor variază la distanțe mari. Aplicațiile multimedia pun condiții foarte dure asupra mediului 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, se înregistrează reperul de timp și se monitorizează transmiterea datelor. Aplicațiile folosesc, de obicei, RTP implementat peste UDP, pentru ca să se poată folosi de posibilitatea sa de multiplexare și de 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 luat în considerare faptul 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 dintre utilizatorii care schimbă informații.

Protocolul RTP nu este un protocol strict, care poate să transmită informația unei aplicații, modulele funcționale ale lui neformând un strat aparte, dar mai des integrându-se î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 și altul pentru schimbul de pachete RTCP. Acești parametri trebuie să fie cunoscuți tuturor membrilor conferinței. În funcție de cerințe, pachetele de coordonare pot fi codate. În timpul conferinței, fiecare membru trimite pachete audio mici codate, timpul de transmitere fiind de 20ms. Fiecare informație din acest pachet este înglobată în câmpul de date RTP care, la rândul său, se integrează în UDP. Antetul pachetului RTP determină ce fel de codare audio este folosită (PCM, ADPCM sau LPC), ce permite transmițătorului să schimbe algoritmul de codare în timpul transmiterii, dacă la conferință s-a conectat un utilizator nou, cu anumite restricții, sau dacă viteza de transmitere a informației prin rețea trebuie micșorată.

În timpul transmiterii sunetului, o parte importantă este 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 regenerarea ordinii fragmentelor, dar și pentru a afla numărul de fragmente pierdute în timpul de transmitere.

Deoarece în timpul conferinței pot să apară noi utilizatori, sau alții să se retragă după propria dorință, trebuie cunoscut cine din ei sunt în rețea la momentul dat și dacă informația transmisă către ei ajunge la destinație. 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, ci și video, ele se transmit independent unul față de altul prin fluxuri diferite încorporate în protocolul UDP. pachetele transmise prin RTCP se transmit indiferent pentru fiecare sesiune în parte.

La nivel de RTP nu este nici o legătură între semnalele audio și video. Numai pachetele transmise prin RTCP transmit numele membrului.

În unele cazuri, putem să ne întâlnim cu situația când unul dintre membrii conferinței este conectat la un canal de viteză mică. Nu va fi chiar bine dacă va trebui să cerem transferul pe criptare de la acești utilizatori. Pentru ca să scăpăm de aceasta se poate instala un reformator (așa numitul amestecător), în imediata apropiere de canalele de viteză mică. Amestecătorul transformă pachete de flux audio în conformitate cu canalul de viteză mică. Aceste pachete pot fi unicast (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, care se află după Firewall). Pentru acest tip de noduri de rețea, nu este nevoie de amestecător, aici folosindu-se un alt nivel de transmitere a protocolului RTP, așa numitul translator. Se instalează două translatoare câte unul de fiecare parte a Firewall-ului. 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: transformarea pachetelor din IP/UDP în pachete ST-II în cazul unei conferințe video.

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 suplimentar (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 suplimentară 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 nivel de 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 payloadului și determină interpretarea de către aplicație.
SSRC - indică sursa de sincronizare.

Atribuții

Câmpul de date RTP: Informația transmisă în pachetul RTP, de exemplu: fragmentul de sunet sau informația video compresată.
Pachetul RTP: Pachet de informație, care conține un antet fixat. Un pachet de nivel inferior, de exemplu, UDP, conține un pachet RTP, dar aceasta nu e obligatorie. Câmpul pachetului poate să 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

Note

^ ing. Cristina-Gabriela Gheorghe. „Subsistemul Multimedia IP” (PDF). Asociația Generală a Inginerilor din România. p. 71.
^ Rețele de calculatoare, ediția a patra. Editura Byblos. 2004. p. 474. Text "Andrew S. tannenbaum" ignorat (ajutor)

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

[1] . Cristina-Gabriela Gheorghe. „Subsistemul Multimedia IP” (PDF). Asociația Generală a Inginerilor din România. p. 71.

[2] Rețele de calculatoare, ediția a patra. Editura Byblos. 2004. p. 474. Text "Andrew S. tannenbaum" ignorat (ajutor)

[1]

[2]

RTP