Ruch multimediów, w skład którego wchodzi znaczna część potencjalnego ruchu emisji pojedynczej i (szczególnie) multiemisji, posiada właściwości, które różnią się od konwencjonalnego ruchu sieciowego i w związku z tym ma inne wymagania. Jeżeli na przykład dany odbiorca czeka na retransmisję TCP, to występuje zauważalna i niedopuszczalna przerwa w odbiorze danych audio, wideo lub innych danych wrażliwych na opóźnienia. Ponadto mechanizm powolnego startu kontroli przeciążeń TCP (patrz: rozdział 7) może kolidować z prędkością odbioru audio i wideo. Ponieważ nie ma żadnej stałej ścieżki, po której datagramy mogłyby przepływać przez Internet, nie ma w tradycyjnej transmisji TCP żadnego mechanizmu gwarantującego, że będzie dostępna szerokość pasma potrzebna do przesyłu multimediów, a protokół TCP nie zapewnia informacji o synchronizacji, co jest wymogiem kluczowym w przypadku obsługi multimediów.
W związku z niestosownością transmisji TCP wzrasta znaczenie stosowania protokołu UDP do transmisji multimediów w czasie rzeczywistym. Protokoły wysokopoziomowe, takie jak protokół transportowy czasu rzeczywistego (RTP), protokół kontrolny czasu rzeczywistego (RTCP) oraz protokół przesyłania strumieniowego czasu rzeczywistego (RTSP) zazwyczaj działają poprzez UDP, chociaż ich definicje nie wykluczają stosowania innych protokołów. Protokoły te wymagają gwarantowanej szerokości pasma i są tutaj opisane w kontekście zarówno UDP, jak i Jakości usługi (QoS)