0

I would like to know how does UDP achieve continuity in VOIP or in any streaming service.

Improve this question
1
  • As @Zac67 pointed out, links are much, much faster than VoIP, especially if sound compression is used, as is common. Also, remember that non-VoIP traffic (traditional POTS) is almost always digitized at some point and multiplexed onto virtual circuits that are carried across something like SONET.
    – Ron Maupin ♦
    Nov 1, 2019 at 23:18

2 Answers 2

Reset to default
3

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.)

Improve this answer
2
  • So from what you are saying is that sample are sent periodically. (ie every 50 ms)
    – A NASR
    Nov 3, 2019 at 4:48
  • Samples in packets are sent as often as required to provide a continuous output, e.g. 800 samples every 100 ms, 80 samples every 10 ms, or equivalent.
    – Zac67 ♦
    Nov 3, 2019 at 7:53
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.