Realtime Transport Protocol

Real-time Transport Protocol, afgekort RTP, is een protocol dat een gestandaardiseerd pakketformaat definieert om audio en video over het internet te verzenden. Het is oorspronkelijk ontworpen als een multicastprotocol maar is ook in veel unicastapplicaties toegepast. RTP wordt vaak gebruikt voor streamingmediasystemen (samen met RTSP) en voor videoconferentiesystemen (samen met H.323 of SIP). RTP is de technische grondlegger van de Voice over IP-industrie. Het Real-time Transport Control Protocol (RTCP) dat samen met RTP gedefinieerd is in RFC 3550, handelt feedback, synchronisatie en de gebruikersinterface af.^[1]

UDP wordt op grote schaal gebruikt voor client-server RPC. Ook wordt UDP veel gebruikt voor realtime-multimedia-applicaties. Maar, door de toenemende populariteit van internettelefoon, videoconferenties, video on-demand en andere multimedia-applicaties kwamen applicatieontwerpers tot de conclusie dat ze eigenlijk allemaal bezig waren om min of meer hetzelfde real-time transportprotocol uit te vinden. De indruk ontstond dat het een goed idee zou kunnen zijn om een generiek realtime-transportprotocol te hebben voor verschillende applicaties. In die tijd ontstond RTP, het realtime-transport protocol. Het is beschreven in RFC 3550^[1] en wordt nu op grote schaal toegepast voor multimediatoepassingen.

RTP is ontwikkeld door de Audio-Video Transport Working Group van het IETF en is gepubliceerd in 1996 als RFC 1889.^[2] RTP is tevens gepubliceerd door het ITU-T als H.225.0. Het protocol bestaat als een Internet Draft Standaard, gedefinieerd in de teksten RFC 3550^[3] (recenter dan RFC 1889) die het protocol specificeert en in RFC3551^[4] (recenter dan RFC 1890) die een specifiek profiel definieert voor audio- en videoconferenties.

We beschrijven twee aspecten van real-timetransport. Het eerste is het RTP-protocol voor het transporteren van audio- en videodata in pakketten. Het tweede aspect wordt voorzien door het RTCP-protocol. Dit is de verwerking die plaatsvindt voor het merendeel bij de ontvanger om de audio en video op het juiste moment af te spelen. Deze functies passen in de protocolstack zoals weergegeven in figuur 1. RTP loopt normaal gesproken in de gebruikersruimte over UDP (in het besturingssysteem). Het werkt als volgt. De multimedia-applicatie bestaat uit verschillende audio-, video-, tekst- en mogelijk andere stromen en verpakt ze in RTP-pakketten, die vervolgens via een socket worden verzonden. Aan de besturingssysteemkant van de socket worden UDP-pakketten gegenereerd om rond RTP-pakketten te wikkelen en aan IP overhandigd voor transmissie over een link zoals Ethernet. Bij de ontvanger vindt het omgekeerde proces plaats. De multimediatoepassing ontvangt uiteindelijk multimediadata van de RTP-bibliotheek. Deze is verantwoordelijk voor het afspelen van de media.

De basisfunctie van RTP is verschillende realtime-gegevensstromen te multiplexen tot één stroom UDP-pakketten. De UDP-stroom kan worden verzonden naar één bestemming (unicasting) of naar verschillende bestemmingen (multicasting). Omdat RTP alleen normale UDP gebruikt, ondergaan de pakketten in de routers geen specifieke behandeling tenzij er een Quality of service (QoS) functionaliteit mogelijk is. Er zijn in ieder geval geen garanties over aflevering en pakketten kunnen verloren gaan, worden vertraagd of geraken beschadigd. Het RTP-format bevat verschillende functies die ontvangers helpen met multimedia-informatie te werken.

Elk pakket in een RTP-datastroom krijgt een nummer toegewezen dat één hoger is dan het vorige pakket. Aan de hand van deze nummering kan de bestemming bepalen of er pakketten ontbreken. Als er een pakket ontbreekt, hangt de beste actie van de bestemming af van de toepassing. De actie kan bijvoorbeeld het overslaan van een videoframe (bij video) of het invullen van een ontbrekende waarde door interpolatie (bij audio) zijn. Opnieuw verzenden is niet praktisch, omdat het opnieuw verzonden pakket veel te laat zou arriveren. Daarom heeft RTP geen bevestigingen en geen mechanisme om te verzoeken om pakketten opnieuw te verzenden.

Het gegevensveld van een RTP-pakket kan verschillende samples bevatten en deze kunnen op elke manier gecodeerd zijn die de applicatie maar wil. Om met de verschillende netwerken te kunnen werken definieert RTP verschillende profielen en voor elk profiel kunnen verschillende coderingsindelingen toegestaan zijn. Bijvoorbeeld, een audiostroom kan worden gecodeerd als 8-bit PCM op 8kHz. RTP bevat een headerveld waarin de bron de codering kan specificeren, maar bemoeit zich verder niet met de manier waarop de codering wordt uitgevoerd.

Een andere faciliteit waaraan veel behoefte is bij realtime-applicaties is timestamping. Het achterliggende idee is dat de bron een tijdstempel plaatst bij de eerste sample in elk pakket. De tijdsstempels zijn relatief ten opzichte van het begin van de stroom, dus alleen het verschil tussen tijdsstempels is belangrijk. De absolute waarden hebben geen betekenis. Zoals we weldra zullen beschrijven, kan hierdoor de bestemming op beperkte schaal bufferen en elke sample weergeven op het juiste aantal milliseconden na het begin van de stroom, onafhankelijk van het moment waarop het pakket met die sample arriveerde. De tijdsstempel vermindert niet alleen de effecten van de variatie in netwerkvertraging, maar ook kunnen verschillende stromen met elkaar worden gesynchroniseerd. Een digitaal televisieprogramma kan bijvoorbeeld een videostroom en twee audiostromen hebben. Deze twee audiostromen kunnen het stereogeluidsignaal bevatten of twee soundtracks in verschillende talen, die de kijker naar keuze kan beluisteren. Elke stroom is afkomstig van een ander fysiek apparaat, maar als ze een tijdsstempel gebruiken die afkomstig is van één teller wordt het mogelijk om ze synchroon weer te geven, zelfs als de stromen discontinu zijn verzonden en/of ontvangen.

De RTP-header bestaat uit drie 32-bit woorden en eventueel enkele extensies. Het eerste woord bevat het version-veld dat nu al de waarde 2 heeft. Het is te hopen dat deze versie de ultieme versie al dicht benadert omdat er nog maar één versienummer vrij is (hoewel 3 erdoor gedefinieerd zou kunnen worden dat de werkelijke versie in het extensiewoord staat).

De P-bit geeft aan dat het pakket opgevuld is tot een veelvoud van 4 bytes. De laatste opvulbyte geeft aan hoeveel bytes gebruikt zijn voor de opvulling. De X-bit geeft aan dat er en extensieheader aanwezig is. De indeling en betekenis van de extensieheader is niet gedefinieerd. Het enige dat wel gedefinieerd is, is dat het eerste woord van de extensie de lengte ervan bevat. Dit is een noodvoorziening voor de toekomst.

Het CC-veld geeft aan hoeveel bronnen gebruikt worden en kan een waarde hebben tussen 0 en 15. Het M-bit is een applicatie-specifieke markeringsbit. Het kan worden gebruikt om het begin te markeren van een videoframe, het begin van een woord in een audiokanaal of iets anders dat de applicatie begrijpt. Het gegevensveld geeft aan welk coderingsalgoritme is gebruikt. Omdat elk pakket dit veld bevat, is het mogelijk om tijdens de verzending over te stappen op een andere coderingsmethode. Het sequentienummer is een teller die na elk verzonden RTP-pakket met één wordt verhoogd. Hiermee kunnen kwijtgeraakte pakketten worden gedetecteerd.

De tijdsstempel wordt gegenereerd door de bron van de stroom om aan te geven wanneer het eerste sample in het pakket gemaakt werd. Deze waarde kan helpen om de variatie in de timing, de jitter, bij de ontvanger te verminderen door het weergavemoment los te koppelen van het moment dat het pakket arriveert. De synchronization source identifier geeft de stroom aan waar het pakket bij hoort. Hierbij wordt dezelfde methode gebruikt als bij het multiplexen en demultiplexen van verschillende gegevensstromen tot één stroom UDP-pakketten. Ten slotte maakt men gebruik van de contributing source identifiers wanneer er mixers in de studio worden gebruikt. In dit geval is de mixer de synchroniserende bron en worden de te mengen stromen gesommeerd.

Er is ook een 'secure'- of veilige versie van RTP, namelijk SRTP. Deze veilige versie is beschreven in RFC 3711^[5].

• Tanenbaum, A. (2003). Computer Networks. Upper Saddle River: Prentice Hall.
• Schulzrinne, H. (2003). RTP: A Transport Protocol for Real-Time Applications. Columbia University. Geraadpleegd op 3 december 2013. (RFC 3550)
• Lazzaro, J. (2006). RFC4571: Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport. UC Berkeley. Geraadpleegd op 3 december 2013. (RFC 4571)
• Perkins, C. (2003). RTP: Audio and Video for the Internet. Boston: Addison-Wesley.

• (en) oRTP, RTP library from Linphone written in C
• (en) Henning Schulzrinne's RTP page (including FAQ)
• (en) GNU ccRTP
• (en) JRTPLIB, a C++ RTP library