Post Reply
Why Does RTP use UDP Instead of TCP:

Posts: 27

Joined: 08 Oct 2010 16:36

01 Sep 2012 18:04

Why Does RTP use UDP Instead of TCP:

Why Does RTP use UDP Instead of TCP:

UDP is used wherever data is send that does not need to be exactly received on the target, or where no stable connection is needed. UDP does not care about reliability of the communication, and will not slow down or re-transmit data.

TCP is used if data needs to be exactly received, bit for bit, no loss of bits. TCP is about getting a reliable data stream, and will slow down transmission, and re-transmit corrupted packets, in order to achieve that. If your application needs a reliable data stream, for example, to retrieve a file from a web server, you choose TCP.

If your application doesn't care about corrupted or lost packets, and you don't need to incur the additional overhead to provide the additional reliability, you can choose UDP instead.

VOIP is not significantly improved by reliable packet transmission, and in fact, in some cases things in TCP like retransmission and exponential back off can actually hurt VOIP quality. Therefore, UDP is a better choice.

The important fact is that some data that arrives too late is worthless. What good is the missing data for a frame that should have been displayed a second ago?

If you were to use TCP (which also guarantees the correct order of all data), then you wouldn't be able to get to the more up-to-date data until the old one is transmitted correctly. you have to wait for the re-transmission of the old data and the new data (which is now delayed) will probably be just as worthless. The reason is simple, Delay. VOIP tries very hard to minimize the amount of delay from the time someone speaks into one end and you get it on your end, and your response back. Otherwise, as errors occurred, the amount of delay between when the person spoke and when the signal was received would continuously grow until it became useless

Remember, each delay from a retransmission has to be replayed, and that causes further data to be delayed, then another error causes an even greater delay. The only workable solution is to simply drop any data that can't be displayed in real-time. A 1 second delay from retransmission would mean it would now be 1 second from the time I said something until you heard it. A second 1 second delay now means its 2 seconds from the time i say something until you hear it. This is cumulative because data is played back at the same rate at which it is spoken, and so on...

So RTP does some kind of best-effort transmission in that it tries to transfer all available data in time, but doesn't attempt to re-transmit data that was lost/corrupted during the transfer. It just goes on with life and hopes that the more important current data gets there correctly.

RTP is fairly insensitive to packet loss, so it doesn't require the reliability of TCP.

UDP has less overhead for headers so that one packet can carry more data, so the network bandwidth is utilized more efficiently. UDP provides fast data transmission also.

So UDP is the obvious choice in cases such as this