Multimedia Networking

Svar: Sampling er å måle signalverdien med jevne mellomrom (f.eks. 8000 ganger per sekund for telefon). Kvantisering er å avrunde hver måling til nærmeste tillatte verdi (f.eks. én av 2⁸ = 256 nivåer hvis vi bruker 8 bits per sample). Resultatet er en strøm av tall — bits.

Hvorfor: Et nettverk kan bare sende bits, men lyd er en kontinuerlig analog størrelse. Sampling gjør tiden diskret; kvantisering gjør amplituden diskret. Bitraten = samplingsrate × bits per sample. Telefon: 8000 × 8 = 64 kbps. CD-musikk: 44 100 × 16 ≈ 1,4 Mbps — det er denne forskjellen som gjør at musikk krever mye mer båndbredde enn tale.

Svar: Spatial (romlig) koding utnytter redundans innenfor ett enkelt bilde — store områder har samme farge, så vi sender fargen og antallet piksler i stedet for hver enkelt piksel. Temporal koding utnytter redundans mellom påfølgende bilder — vi sender bare differansen fra forrige bilde i stedet for hele det neste.

Hvorfor: Rå video er enormt båndbredde-tung. De to redundansformene er komplementære: spatial fjerner det som er likt innen et bilde, temporal det som er likt mellom bilder. Utdraget viser at komprimering kan lage flere versjoner av samme video (f.eks. 300 kbps, 1 Mbps og 3 Mbps) slik at klienten velger etter tilgjengelig båndbredde.

Svar: CBR (Constant Bit Rate) bruker en fast bitrate hele veien gjennom videoen, uavhengig av hvor komplekst innholdet er. VBR (Variable Bit Rate) varierer bitraten — få bits i en stille scene, mange bits i en actionscene.

Hvorfor: CBR er enklere å planlegge for nettverket og lagring, men kaster båndbredde i enkle scener og gir for dårlig kvalitet i komplekse. VBR gir bedre kvalitet per bit ved å plassere bits der de trengs, men gir uforutsigbar trafikk som er vanskeligere for nettverket — buffrene i begge ender må være større for å absorbere svingningene.

Svar: (1) Streaming av lagret innhold — YouTube, Netflix, Spotify; ferdig innspilt, klienten kan bygge opp buffer før avspilling. (2) Samtale (VoIP/videosamtale) — interaktiv, ekstremt forsinkelses-sensitiv (over 400 ms ødelegger samtalen). (3) Live streaming — sanntid, men ikke interaktivt; tåler noen sekunders forsinkelse, men kan ikke spole frem.

Hvorfor det viktig å skille: Alle tre er tidssensitive — bits som kommer for sent er verdiløse — men toleransen er fundamentalt forskjellig. Lagret video tåler sekunder med initial buffring; VoIP har et budsjett på 150 ms ende-til-ende. Løsningene er forskjellige fordi kravene er forskjellige; det er derfor det er meningsfullt å behandle dem som tre ulike problemer.

Svar: Når avspillingen først har begynt, må den fortsette med jevn rate — videoen ble spilt inn med fast rate og må spilles av med samme rate. Hvis pakker ikke er kommet frem i tide, fryser videoen.

Hvorfor: Nettverket leverer pakker med variabel rate x(t) (jitter), mens klienten tømmer playout-bufferen med konstant rate r. Bufferen tømmes bare hvis gjennomsnittlig x(t) < r over tid — korte perioder med x < r tåles fint så lenge bufferen ikke når null. Tommelfingerregel (Wang et al. 2008): hvis gjennomsnittlig TCP-throughput er rundt 2r, gir HTTP-streaming minimal frysing og lav playout-forsinkelse.

Svar: Lengre initial forsinkelse gir mer buffer å falle tilbake på når nettverket er tregt — robust avspilling. Kortere initial forsinkelse gir raskere oppstart for brukeren — bedre opplevelse. De to står i direkte konflikt.

Hvorfor: Tiden t_p = Q/x det tar å bygge opp Q bits før avspilling starter er den eneste forsvarslinjen mot perioder med x < r etter at avspillingen har begynt. Stor Q = trygg buffer mot frysing, men brukeren vil ikke vente. Streamingtjenester velger typisk 1–3 sekunder som kompromiss; kortere føles raskt men risikerer frysing, lengre føles tregt og brukeren klikker bort før videoen i det hele tatt har startet.

Svar: HTTP/TCP passerer brannmurer lettere enn rå UDP-video, kan serveres fra en vanlig webserver uten spesialinfrastruktur, og TCP gir pålitelig, ordnet levering så applikasjonen slipper å håndtere tap selv.

Hvorfor — praksis trumfer teori: UDP gir lavere forsinkelse og ingen retransmisjon, som teoretisk er bedre for streaming. Men UDP-trafikk blokkeres ofte av brannmurer, og UDP-streaming krever egen serverinfrastruktur og egen tapshåndtering. Avveiningen — høyere playout-buffer for å jevne ut TCPs variable sende-rate — er akseptabel for lagret video. YouTube, Netflix og stort sett alt i dag bruker DASH oppå HTTP/TCP.

Svar: Prefetching er at klienten laster ned raskere enn forbruksraten r — overskuddet bygger en reserve i applikasjonsbufferen som beskytter mot kortvarige nedganger i nettverksraten. Når brukeren spoler, sender klienten en ny HTTP GET med en byte-range header som ber serveren begynne fra et bestemt punkt i filen.

Hvorfor: Prefetching skjer "automatisk" gjennom TCPs metningskontroll — TCP prøver å bruke tilgjengelig båndbredde, og applikasjonsbufferen tar imot overskuddet. Når bufferen blir full, "back-pressurer" det tilbake til serveren via TCP-flytkontroll. Byte-range er det som gjør HTTP til streaming i utgangspunktet: klienten "late-binder" til filen i stedet for å laste ned alt på én gang. Pris: båndbredde brukt på prefetcha innhold går tapt hvis brukeren forlater siden — derfor begrenses prefetch-mengden, særlig på mobil.

Svar: Lyden deles i 20 ms biter — hver bit er 160 bytes med PCM-kodet tale (8000 samples/s × 8 bits/sample × 20 ms = 64 kbps). Til hver bit legges en applikasjonsheader, og resultatet pakkes i et UDP- eller TCP-segment. Senderen sender én pakke hvert 20. millisekund under en snakkefase (talk spurt) — ingenting under stillhet.

Hvorfor 20 ms: Det er et kompromiss. Kortere chunks gir mer overhead per bit lyd (header dominerer), lengre øker pakketiseringsforsinkelsen som er en hard nedre grense på ende-til-ende-forsinkelsen. At senderen veksler mellom snakkefaser og stillhet er det som lar adaptiv playout justere forsinkelsen i pausene uten at lytteren merker det.

Svar: (1) Pakketisering (~20 ms, hard nedre grense fra koding), (2) transmisjon (L/R), (3) propagering (avstand/v), (4) køforsinkelse i rutere — hovedkilden til jitter, (5) prosessering, (6) playout-forsinkelse hos mottaker (typisk 50–200 ms).

Hvorfor det betyr noe: De fem første styres av nettverket og er stort sett utenfor applikasjonens kontroll. Bare playout-forsinkelsen kan applikasjonen justere — hele hemmeligheten ved VoIP-design ligger i å sette den så lavt som mulig uten å miste for mange pakker. Køforsinkelsen er den mest variable av nettverkskomponentene; det er den som skaper jitter og som playout-bufferen må absorbere.

Svar: < 150 ms: bra — samtalen føles naturlig. 150–400 ms: merkbart, men brukbart. > 400 ms: uakseptabelt — samtalen bryter sammen.

Hvorfor det kollapser ved 400 ms: Hjernen forventer svar nesten umiddelbart i en samtale. Over 400 ms vet ikke partene om det ble en pause eller om den andre faktisk svarer — resultatet er den pinlige "snakket du? nei, du først"-dansen, og samtalen kollapser. Forsinkelsen inkluderer alt: pakketisering (20 ms), nettverket og playout-bufferen hos mottakeren. Det er derfor playout-forsinkelse må holdes lav selv på bekostning av noe pakketap — VoIP tåler tap bedre enn lang forsinkelse.

Svar: (1) Nettverkstap — IP-datagram droppes pga. metning i ruterbuffere. (2) Forsinkelsestap — pakken kommer fysisk frem, men etter sin playout-tid; effektivt det samme som tap. Mottakeren kan bruke packet repetition eller interpolation (feilretting ved mottaker) for å fylle korte hull.

Hvorfor tap tåles: I motsetning til filoverføring, der hver tapt byte er katastrofal, er stemme svært tapstolerant — 1–20 % pakketap kan tåles med riktige teknikker. Kombinert med FEC og adaptiv playout fungerer VoIP brukbart selv ved 5–10 % tap. Retransmisjon er ikke et alternativ — én RTT er for dyrt i et 400 ms-budsjett.

Svar: Jitter er variasjonen i pakke-til-pakke-forsinkelse gjennom nettverket. Senderen klokker ut pakker hvert 20. ms, men de ankommer med ujevne mellomrom fordi køforsinkelsen i rutere varierer per hopp og per pakke.

Hvorfor det krever en buffer: Avspilling krever jevn rate. Selv om gjennomsnittsforsinkelsen er 50 ms, vil en pakke forsinket til 200 ms bryte avspillingen hvis vi ikke har bygd opp en buffer. Playout-bufferen absorberer jitter ved å vente med avspilling (forsinkelse q), slik at sene pakker fortsatt rekker frem i tide. Jitter er dermed forskjellig fra både tap (pakker forsvinner) og total forsinkelse (alle pakker er like sene) — det handler om uforutsigbarheten.

Svar: Mottakeren estimerer gjennomsnittlig nettverksforsinkelse d og avvik v fortløpende med glidende gjennomsnitt (utdraget bruker vekter α og β på nye målinger):
d_i = (1−α)·d_i−1 + α·(r_i − t_i),
v_i = (1−β)·v_i−1 + β·|r_i − t_i − d_i|.
Playout for første pakke i ny snakkefase: tj + dj + K·vj (K typisk 4).

Hvorfor lik TCP: Utdraget sammenligner bevisst med RTT-estimering i TCP (kapittel 3): et glidende gjennomsnitt av forsinkelse pluss et ledd proporsjonalt med variasjon gir en dynamisk sikkerhetsmargin. Når jitter er lav, holder vi forsinkelsen stram; når den øker, øker bufferen. Justering skjer bare ved snakkefasens start — under en snakkefase spilles alle 20 ms-biter av med faste mellomrom.

Svar: I kapittelutdraget beskrives at mottakeren kan undersøke signalenergien i hver mottatt pakke: lav energi tyder på stillhet, høy energi på tale, slik at starten av en ny snakkefase kan skilles fra pauser i støy.

Hvorfor: Adaptiv playout justeres ved starten av hver ny snakkefase; mottakeren må da vite når snakkefase starter. Utdraget fokuserer på energimåling i mottatte samples.

Svar: For hver gruppe på n lydbiter genererer senderen én ekstra redundant pakke ved å XOR-e alle de n originale sammen. Senderen sender altså n+1 pakker per gruppe (overhead: 1/n, dvs. 25 % ved n = 4). Hvis én pakke i gruppen tapes, kan mottakeren rekonstruere den ved å XOR-e de øvrige. Hvis to eller flere går tapt, fungerer det ikke.

Hvorfor — og hva det koster: XOR er reversibel: så lenge bare én pakke i gruppen er ukjent, kan den finnes fra paritet ⊕ resten. Prisen er ikke bare båndbredde, men også økt playout-forsinkelse — vi må vente på hele gruppen før gjenoppretting kan skje. Det er derfor piggyback-FEC ofte foretrekkes: gjenoppretting skjer umiddelbart fra neste pakke uten å vente på en hel gruppe.

Piggyback: hver pakke bærer en lavkvalitetskopi av forrige chunk (f.eks. nominell 64 kbps PCM + redundant 13 kbps GSM). Hvis én pakke tapes, kan forrige chunk gjenopprettes fra neste pakke i lavere kvalitet. Krever ekstra båndbredde (~13 kbps i eksempelet), men ingen ekstra ventetid utover én pakke.

Interleaving: hver 20 ms chunk deles i fire 5 ms enheter, og enhetene fra ulike chunks blandes mellom pakkene. Hvis én pakke tapes, forsvinner bare én 5 ms enhet fra fire ulike chunks — mange små hull i stedet for ett langt sammenhengende.

Hvorfor begge finnes: Trade-offen er forskjellig. Piggyback bruker båndbredde, interleaving bruker tid (mottakeren må vente på flere pakker for å sette sammen igjen) men gir null båndbredde-overhead. Begge angriper det samme problemet — sammenhengende tap er hørbart, distribuerte små tap er det ikke.

Svar: I utdraget tildeles hver klient en ikke-NATet super peer; klienten initierer en sesjon dit (tillatt ut fra NAT). Når Alice ringer Bob, koordineres kallet via super peers. Trengs relay, velger to super peers en tredje relay peer som ikke er bak NAT; Alice og Bob initierer så hver sin sesjon til relayen, som videresender tale.

Hvorfor: NAT blokkerer innkommende oppstart fra utsiden; løsningen er alltid utgående sesjoner som allerede er åpnet. Det gir ekstra hopp og belastning på relay, men gjør samtale mulig når direkte peer-forbindelse feiler.

Svar:

(1) Payload type (7 bit) — hvilken koding (f.eks. 0 = PCM µ-law, 3 = GSM, 33 = MPEG-2 video). Senderen kan bytte koding midt i samtalen.
(2) Sequence number (16 bit) — øker med 1 per pakke; lar mottakeren oppdage tap og rekonstruere rekkefølge.
(3) Timestamp (32 bit) — samplingsøyeblikket for første byte; for 8 kHz audio +160 per 20 ms pakke. Klokken tikker også gjennom stillhet.
(4) SSRC (32 bit) — tilfeldig identifikator for denne mediestrømmen i sesjonen.

Hvorfor RTP eksisterer: RTP gir tre ting UDP mangler — type-info, rekkefølge, timing — som er nødvendige for sanntidsavspilling. Men RTP gir ingen garanti for levering, rekkefølge eller forsinkelse: rutere ser bare et UDP-segment og behandler det best-effort. All intelligens (adaptiv playout, FEC, feilretting ved mottaker) ligger i endepunktene.

Svar: Video bruker en hel størrelsesorden mer båndbredde enn musikk og betydelig mer enn bildetung surfing — typisk 2 Mbps for HD-streaming mot ~128 kbps for Spotify og ~160 kbps for bildetung surfing. Cisco anslo at video ville utgjøre rundt 80 % av all forbruker-Internett-trafikk i 2019.

Hvorfor: Video kombinerer høy oppløsning med 24–30 bilder per sekund, hver med millioner av piksler. Selv med spatial og temporal koding er datamengden enorm. Musikk er én-dimensjonal lyd, bilder er statiske — video er begge deler i bevegelse. Det er denne dominansen som gjør designvalg for video-streaming så kritiske for hele Internett-økosystemet, og hvorfor CDN-er har vokst frem som arkitekturisk svar.

Svar: Utdraget beskriver DASH som adaptiv HTTP-strømming: flere komprimerte versjoner av samme video, slik at klienten kan bytte kvalitet etter målt båndbredde og buffer. Klienten henter data med vanlige HTTP GET-forespørsler over TCP.

Hvorfor: All adaptiv logikk ligger i klienten; serveren kan være en vanlig webserver. Når kapasiteten faller, velger klienten lavere bitrate (dårligere bilde); når den stiger, kan den gå opp igjen. YouTube og Netflix bruker slike løsninger i utdraget.

Svar: (1) Pakkegjentakelse (packet repetition) — erstatt tapte pakker med en kopi av den siste mottatte pakken før tapet. (2) Interpolering (interpolation) — bruk lyden før og etter tapet til å konstruere en erstatning.

Hvorfor: De kompletterer FEC og interleaving: først prøver man å unngå eller reparere tap; hvis en pakke likevel mangler ved playout, må mottakeren fylle hullet. Interpolering gir bedre kvalitet enn gjentakelse, men koster mer CPU.

Svar: Mottakeren bestemmer en fast forsinkelse q og spiller hver lydbit nøyaktig q ms etter at den ble generert av senderen — altså ved tid t + q hvis pakken har tidsstempel t. Hvis pakken ankommer etter t + q, regnes den som tapt (for sen).

Trade-offen: Stor q → færre pakker er "for sene" → lavere tap, men lengre samtaleforsinkelse. Liten q → bedre interaktivitet, men flere pakker rekker ikke frem i tide og må skjules som tap. Trade-offen er fundamental — derfor finnes adaptiv playout, som justerer q automatisk basert på nettverksforholdene i stedet for å låse en konstant verdi for hele samtalen.

Svar: Justeringen skjer bare ved starten av en ny snakkefase. Stillhetsperiodene mellom setninger blir litt komprimert eller forlenget for å absorbere endringen. Selve snakkefasen spilles av med faste 20 ms-mellomrom — der må man ikke endre noe.

Hvorfor det fungerer: Hvis vi endret playout-forsinkelsen midt i en setning, ville lyden hakke eller bli unaturlig dratt. Men korte stillhetsperioder (selv små pauser mellom ord) kan strekkes eller komprimeres med titalls millisekunder uten at hjernen registrerer det. Det er denne "skjulte slakken" som lar bufferen vokse når jitter øker, og krympe når nettet roer seg, helt uten at samtalen forstyrres.

Svar: Peers er organisert i et hierarkisk overlay der hver peer er en super peer eller en vanlig peer. En indeks som mapper Skype-brukernavn til gjeldende IP-adresse (og port) er distribuert over super peers. Når Alice vil ringe Bob, søker klienten i denne indeksen etter Bobs IP. P2P-teknikker brukes også i relays: hvis begge parter er bak NAT, velger to super peers en tredje ikke-NATet super peer som relay peer som videresender data mellom Alice og Bob.

Hvorfor: Super peers støtter både lokalisering og NAT-traversering; relay gir en sti når direkte peer-forbindelse ikke lar seg gjøre.

Svar: RTP-pakker er innkapslet i vanlige UDP-segmenter. Rutere underveis ser bare et IP-datagram med en UDP-header og behandler det med vanlig best-effort — de "vet" ikke at det er RTP og gjør ingen spesiell innsats for å levere det raskere eller mer pålitelig.

Hvorfor: RTP er bare en konvensjon for applikasjonsdata — felter som hjelper mottakeren tolke pakken (payload type, sekvens, tidsstempel). Det er ingen egen «RTP-kø» i rutere. RTP kan derfor ikke i seg selv gi QoS, garantert levering eller garantert forsinkelse — det er ikke svikt, det er design.

Svar: Tidsstempelet er samplingsøyeblikket for første byte i pakken — målt i en applikasjonsspesifikk klokke (ikke wall-clock-tid). For 8 kHz audio øker tidsstempelet med 1 per sample (125 µs), altså +160 per 20 ms-pakke. Klokken tikker videre også gjennom stillhet, selv om ingen pakker sendes da.

Hvorfor: Sekvensnummeret forteller bare rekkefølge (øker monotont per pakke), tidsstempelet forteller når i mediet pakken hører hjemme. To stillhetsperioder kan være ulike lange — uten en klokke som tikker gjennom stillhet, ville mottakeren ikke kunne plassere neste snakkefase riktig på tidslinjen. Tidsstempelet er også det som lar mottakeren beregne nettverksforsinkelsen (r_i − t_i) for adaptiv playout.

Svar: En retransmisjon krever minst én ekstra rundtur (RTT) — pakken må først detekteres som tapt, så bes om på nytt, og kommer tilbake. Det gir merkbar ekstra forsinkelse.

Hvorfor det dreper VoIP: VoIPs hele forsinkelsesbudsjett er omtrent 400 ms. En retransmisjon bruker fort mye av det, og pakken blir uansett «for sen» hvis playout-tiden allerede er passert. For filoverføring er ekstra forsinkelse ofte irrelevant — det viktige er at hver byte til slutt kommer korrekt frem. For samtale er bytene verdiløse hvis de kommer for sent. Derfor bruker VoIP UDP (ingen retransmisjon) og takler tap med FEC, interleaving og error concealment (f.eks. pakkegjentakelse og interpolering) — ikke primært retransmisjon.

Svar: Bufferen absorberer jitter ved å vente med avspilling, men det å vente legger til forsinkelse — den introduserer altså mer av det vi prøver å minimere. Den løser jitter ved å konvertere variasjon til økt deterministisk forsinkelse.

Hvorfor — fundamentet: Hvis nettverket har 200 ms gjennomsnittsforsinkelse, kan ingen mottakerbuffer redusere det til mindre. Bufferen kan bare sørge for at avspillingen er jevn — ved å vente til alle pakker er ankommet med stor sannsynlighet. Vi kan ikke sende pakker tilbake i tid. Det er derfor man for VoIP fokuserer så hardt på å holde nettverksforsinkelsen lav (geografi, ruting, lite kø) i stedet for å forsøke å håndtere det med større buffer i etterkant.

Svar: Senderen kan bytte koding under samtalen — f.eks. fra PCM (64 kbps) til GSM (13 kbps) hvis nettverket blir tregt — og mottakeren ser endringen umiddelbart i payload-type-feltet og bytter dekoder uten å måtte forhandle på nytt.

Hvorfor: Adaptiv koding er en kraftfull respons på endrede nettverksforhold: senderen kan bytte til lavere bitrate-koding uten å avbryte samtalen, så lenge mottakeren leser payload-type-feltet. Dette gjør VoIP mer robust når nettet blir mettet eller tap øker.

Svar: Telefon: 64 kbps (8 kHz × 8 bit). CD: 1,411 Mbps (44,1 kHz × 16 bit, stereo). MP3: 96–160 kbps. Internett-telefoni: helt ned til 5,3 kbps med god koding.

Hvorfor så stor spennvidde: De to faktorene er samplingsrate og bits per sample. Telefon bruker lav sampling (8 kHz) fordi tale dominerer i frekvenser under 4 kHz; CD bruker høy sampling for å fange hele hørselsspekteret. MP3 oppnår dramatisk reduksjon ved psykoakustisk komprimering — fjerner detaljer øret ikke oppfatter likevel. Disse tallene er fundamentet for å forstå hvorfor tale-strømming er trivielt mens HD-musikk-streaming krever mer båndbredde.

Svar: tf = (B − Q) / (x − r), der B er bufferstørrelsen, Q er det som var bygget opp før avspillingen startet, og (x − r) er overskuddsraten klienten henter inn med.

Hvorfor: Fra det øyeblikket avspillingen starter med Q bits i bufferen, vokser bufferen med rate (x − r) — forskjellen mellom innfyllingsrate og avspillingsrate. Den når full kapasitet B etter (B − Q)/(x − r) sekunder. Når B er nådd, bremser TCPs flytkontroll serveren ned til r — kontinuerlig avspilling resten av videoen er da garantert. Hvis klienten kan prefetche fortere enn forbruksraten, slipper den varig frysing-risiko helt.

Svar: Hvis klienten har lastet ned B bits og brukeren spoler videre eller forlater siden, er alt det prefetcha innholdet kastet — båndbredden og serverressursene som ble brukt på det er bortkastet.

Hvorfor det er kritisk: Særlig på mobilnett, der båndbredde er begrenset (og koster penger), er det sløsing hvis mye innhold forhåndslastes som aldri spilles av. Systemer balanserer derfor mellom buffer-trygghet og hvor mye som lastes ned på forhånd.

Svar:

(1) Server-side TCP-sendebuffer — TCP-stack hos serveren skriver til denne, klokker pakker ut på linken.
(2) TCP-mottakerbuffer hos klienten — TCP-stack hos klienten samler innkommende segmenter og leverer dem ordnet til applikasjonen.
(3) Applikasjonsbuffer (playout-buffer) — videospilleren leser fra denne med fast rate r.

Hvorfor pipeline-en virker: Et fullt applikasjonsbuffer setter en indirekte øvre grense på sende-raten. Når videospilleren slutter å lese fra TCP-recv-bufferen, blir den full → TCP-flytkontroll bremser senderen via vindusstørrelsen → server-bufferen back-pressurer applikasjonen. Hele systemet selvjusterer så ingen av de tre buffrene flyter over. Det er denne egenskapen som lar variabel TCP-rate produsere jevn avspilling uten ekstra koordinering.

Svar: 0 = PCM µ-law (64 kbps audio). 3 = GSM (13 kbps audio). 26 = Motion JPEG (variabel video). 33 = MPEG-2 video (variabel).

Hvorfor det er standardisert: Hver verdi peker på en standardisert koding som mottakeren vet hvordan dekode. Tabellen er en del av RTP-standarden, så to applikasjoner fra forskjellige leverandører kan kommunisere så lenge begge støtter samme payload-type.

Svar: RTP kjører oppå UDP og leverer ikke selv pakker over nettverket — det er bare et felt-rammeverk lagt rundt mediedata. UDP gjør all transporten; RTP legger bare til informasjon mottakeren trenger for å tolke pakken (payload-type, sekvens, tidsstempel).

Hvorfor skillet er viktig: Mange forveksler RTP med en alternativ til UDP/TCP, men det er feil. RTP bytter ikke ut UDP — det utvider UDPs payload med strukturerte felter. Fra ruteres og IP-lagets synspunkt er en RTP-pakke bare en vanlig UDP-pakke. Den semantiske forskjellen er at RTP gir applikasjonen et standardisert vokabular for "hva er dette" — uten å introdusere noen ny transport-mekanisme. Dette er hvorfor RTP ikke kan gi QoS, levering eller pålitelighet — det er ikke svikt, det er design.