I would like to know how does UDP achieve continuity in VOIP or in any streaming service.
The audio data is "time-compressed" when transmitted.
Imagine a 800 byte UDP datagram carrying 8 kHz 8-bit VoIP data.
The 800 samples cover 1/10th of a second (or 100 ms) when played back. That datagram takes 800 + 8 + 20 + 38 = 866 bytes on the wire (payload + UDP overhead + IPv4 overhead + Ethernet overhead), or 6,928 bits. Using Fast Ethernet (100 Mbit/s) these bits take just .06928 ms for transmission - instead of the 100 ms they represent.
So, a single 100M interface could handle 14,400 such streams at the same time without dropping a frame.
(In reality VoIP packets are smaller, increasing the overhead portion but I wanted to get the point across.)
Another point with streaming services is that there is a delay.
For 2-way calls they try to keep the delay under a second so you do not notice.
For video streaming of live events the delay can be significant. Having a 1-2 minute delay can significantly help the reliability of the stream by preventing stuttering/buffering, but that is not always acceptable to viewers (sporting events come to mind).
HTTP live streaming (HLS) is pretty complex. Rather than one large TCP stream, the video is broken into many small segments (could be 10 seconds each for a “live” stream). The viewer downloads them and plays them back-to-back. If there is a problem getting one 10-second URL the viewer can freeze for 10 seconds and go on to the next one.
If the viewing is 60-seconds delayed from live, that gives companies like Akamai time to distribute the 10-second segments through their global caching infrastructure, allowing viewers to download from a “close” server for better performance. The delay also allows the viewer to attempt a second download if the first one fails, perhaps getting the segment before a “freeze” is necessary. The segments also allow starting to view the live event in the middle without downloading the whole show.