Wikipedia

Real-time Transport Control Protocol

Real-time Transport Control Protocol (RTCP) wordt samen met RTP beschreven in RFC 3550.[1] Het protocol handelt feedback, synchronisatie en de gebruikersinterface af. Het transporteert geen mediasamples, maar kan worden gebruikt om informatie terug te koppelen naar bronnen over vertraging, variatie in vertraging (jitter), bandbreedte, congestie en andere netwerkeigenschappen.

Toepassingen

bewerken

De informatie kan worden gebruikt door het coderingsproces om de overdrachtssnelheid te verhogen (dus ook de kwaliteit van de verzending) wanneer het netwerk goed werkt en de overdrachtssnelheid te verlagen wanneer er een probleem in het netwerk aanwezig is. Door voortdurend terug te koppelen naar de coderingsalgoritmen wordt het mogelijk om optimale kwaliteit te leveren onder de huidige omstandigheden. Als bijvoorbeeld de bandbreedte toe- of afneemt tijdens de verzending kan het coderingsalgoritme indien gewenst van MP3 naar 8-bit PCM of deltamodulatie worden omgeschakeld. Het gegevensveld wordt gebruikt om de bestemming te vertellen welk coderingsalgoritme wordt gebruikt voor het huidige pakket, waardoor het mogelijk wordt om dit tussentijds te wisselen. Een probleem met het leveren van feedback is dat de RTCP-rapporten naar alle deelnemers worden verzonden. Voor multicasttoepassingen met een grote groep moet de bandbreedte die door RTCP gebruikt wordt snel groot worden. Om te voorkomen dat dit gebeurt, schalen RTCP-zenders hun rapporten omlaag, zodat ze gezamenlijk niet meer dan bv. 5% van de mediabrandbreedte gebruiken. Hiertoe moet elke deelnemer de mediabrandbreedte kennen die hij leert van de zender en het aantal deelnemers dat hij kan schatten door naar andere RTCP-rapporten te luisteren. RTCP zorgt ook voor de synchronisatie tussen stromen. Het probleem is dat verschillende stromen mogelijk werken met verschillende snelheden. Om deze te synchroniseren kan RTCP worden gebruikt. Ook biedt RTCP de mogelijkheid om verschillende bronnen te benoemen. Deze informatie wordt weergegeven op het scherm van de ontvanger om aan te geven wie op een bepaald moment aan het woord is.

Afspelen met buffering en jitterbeheersing

bewerken

Als de media-informatie de ontvanger bereikt, moet ze op het juiste moment worden afgespeeld. In het algemeen zal dit niet het moment zijn dat het RTP-pakket bij de ontvanger arriveerde, omdat pakketten een iets andere tijdsperiode nodig hebben om het netwerk te passeren. Zelfs als de pakketten met exact dezelfde tussenpozen bij de zender wordt ingebracht, zullen ze de ontvanger op verschillende relatieve tijden bereiken. Deze variatie in vertraging wordt jitter genoemd. Zelfs een kleine hoeveelheid van pakketjitter kan storende media-artefacten veroorzaken, zoals schokkerige videoframes of niet verstaanbare audio. De oplossing voor dit probleem is het bufferen van pakketten bij de ontvanger voordat ze worden afgespeeld om de jitter te verminderen.

Voorbeeld

bewerken
 
Afvlakken van de uitvoerstroom door het bufferen van pakketten

Een stroom pakketten wordt met aanzienlijke hoeveelheid jitter afgeleverd. Pakket 1 wordt op t=0s vanaf een server verzonden en arriveert bij de client op t=1s. Pakket 2 heeft meer vertraging en doet er 2s over om te arriveren. Als de pakketten arriveren zijn ze gebufferd op de clientcomputer. Op t=10s begint de weergave. Op dit moment zijn de pakketten 1 tot en met 6 gebufferd zodat ze met uniforme tussenpozen uit de buffer kunnen worden verwijderd voor regelmatig afspelen. In het algemene geval is het niet nodig om uniforme tussenpozen te gebruiken, omdat RTP-tijdstempels aangeven wanneer de media zou moeten worden afgespeeld. Helaas zien we dat pakket 8 zoveel vertraagd is dat het niet beschikbaar is wanneer het aan zijn beurt is om afgespeeld te worden. Er zijn twee opties. Pakket 8 kan worden overgeslagen waardoor de speler kan doorgaan naar de volgende pakketten. Een andere mogelijkheid is dat de weergave stopt totdat pakket 8 arriveert, wat een irritante onderbreking in de muziek of film veroorzaakt. In een live-mediatoepassing wordt het pakket gewoonlijk overgeslagen. Bij streamingtoepassingen zou de weergave even kunnen pauzeren. Dit probleem kan worden verlicht door de starttijd nog meer te vertragen, door een grotere buffer te gebruiken. Voor een streaming-audio of videospeler worden vaak buffers van circa 10 seconden gebruikt om ervoor te zorgen dat de speler alle pakketten (die niet in het netwerk worden weggegooid) op tijd ontvangt. Voor live-toepassingen zoals videoconferencing zijn korte buffers nodig voor responsiviteit. Een belangrijke overweging voor regelmatige weergave is het playbackpoint, of hoelang de ontvanger op de media moet wachten alvorens af te spelen. Besluiten hoelang je moet wachten hangt af van de fluctuaties. De gemiddelde vertraging tussen veel en weinig jitte hoeft niet veel te verschillen, maar bij veel jitter moet het playbackpoint mogelijk veel verder weg liggen om 99% van de pakketten op te vangen dan bij weinig jitter.

 
(a) Veel jitter. (b) Weinig jitter

Keuze playbackpoint

bewerken

Om een goed playbackpoint te kiezen kan de toepassing de jitter meten door het verschil tussen de RTP-tijdsstempels en de aankomsttijd te meten. Elk verschil geeft een sample van de vertraging, plus een willekeurige, vaste verschuiving. De vertraging kan echter in de tijd variëren als gevolg van een ander, concurrerend verkeer en veranderlijke routes. Om deze verandering een plaats te geven, kunnen toepassingen terwijl ze runnen hun playbackpoint aanpassen. Als dit echter niet goed gebeurt, kan het veranderen van het playbackpoint een waarneembare hapering voor de gebruiker opleveren. Een manier om dit probleem voor audio te vermijden is het aanpassen van het playbackpoint tussen talkspurts, in de stiltes binnen een gesprek. Niemand zal een verschil opmerken tussen een kortere en een langere stilte. Voor dit doel laat RTP toepassingen de M-markerbit instellen om het begin van een nieuwe talkspurt voor dit doel aan te geven. Als de absolute vertraging voordat het medium wordt afgespeeld te lang is, hebben live-toepassingen ervan te lijden. Niets kan worden gedaan om de voortplantingsvertraging te verminderen als er al een direct pad in gebruik is. Het playbackpoint kan worden ingetrokken door gewoon te accepteren dat een groter deel van de pakketten te laat zal arriveren om te worden afgespeeld. Als dit niet acceptabel is, dan is de enige manier om het playbackpoint in te trekken het verminderen van de jitter door het gebruik van een betere QoS, bijvoorbeeld door de spoedeisende forwarding differentiated service. Dit wil zeggen: er is een beter netwerk nodig.

Overgenomen van "https://nl.wiki.x.io/w/index.php?title=Real-time_Transport_Control_Protocol&oldid=63358190"