Voice Communication over TCP/IP

Question

I'm currently developing application using DirectSound for communication on an intranet. I've had working solution using UDP but then my boss told me he wants to use TCP/IP for some reason. I've tried to implement it in pretty much the same way as UDP, but with very little success. What I get is basically just noise. 20% of it is the recorded sound and the rest is just weird noise.

My guess for the reason is that TCP needs to read all the accepted data several times until it gets the final sound I can play.

Now two questions:

• Am I on the right tracks? Is it even good idea to use TCP/IP for this kind of application (voice conferencing of sorts)?
• I'm doing it in C# but I don't think this is language specific.

Answer 1

No, using TCP is a terrible idea. UDP in this case will perform much better and dropped / out of sync packets won't matter!

If your boss can't understand the technical details, tell him or her that virtually all VOIP systems currently existing use UDP and there must be a reason: Skype, ventrilo, teamspeak, World of Warcraft's, etc

Answer 2

To answer this question correctly I feel that some of the key concepts of VoIP need to be explained.

Firstly, UDP is the most popular and widely used method for VoIP. Remember that an IP network is packet switched and ideal for non-real-time data communication and not designed for real-time VoIP.

To overcome this problem UDP is used. UDP is unreliable and connectionless protocol. Although UDP will lose packets the speech audio can still be understood, the brain will effectively compensate for the errors. Thats why you can still speak to someone on a phone with a 3 bars of signal.

Packet Loss and Burst Lengths

Packet loss often occurs due to congestion, so the amount of packet loss will depend on how well equiped the network is. Packet loss in VoIP using UDP will most often occur in burst lengths. A burst length is a the number of packets lost in succession in transmission, so a burst length of 3 means 3 packets in a row were lost.

Packet Loss Compensation

Where packet loss occurs simple packet loss compensation techniques will surfice and the Quality of Service will not be seriously effected, speech can still be understood even in cases where 20-30% of packets are lost. Methods include:

1. Repeat the last successfully received packet.

2. Fill in - Play silence in the gap.

3. Splicing - Effectively this can be thought of taking removing the gap caused by the burst length by pushing the start and end of the gap together.

4. Interpolation - Use knowledge of speech before and after to interpolate lost packets within the gap e.g. mean between the packets successfully recieved before and after the burst length.

A good method of reducing size of burst lengths is known as interleaving and thus increasing QoS is interleaving. A block interleave function takes the speech and splits it into a set of packets. These packets are loaded into a buffer the shape of a matrix (e.g. 4 by 4), a function is used rotate or transpose the buffer so the packets are not in order. On the reciever side the inverse of this function is used to re-order the packets. This method is simple and effective, See the figure below:

alt text http://img688.imageshack.us/img688/3962/capturevnk.png

I recently created a small VoIP app. over a wireless LAN using UDP. I am not really sure of the exact requirements of your application but generally VoIP applications (between two hosts) can implemented as follows:

alt text http://img338.imageshack.us/img338/6566/captureec.png

In the diagram the application defines it's own packet design. The header could just be the packet number (using 1 byte) and the payload the audio data (n bytes, size of payload). Defining this allows better packet compensation techniques and allows for a logical flow for programming.

TCP is a bad choice for VoIP for several reasons. A quick google of 'TCP VoIP' reveals why the first result backing this view.

TCP is a reliable, connection-orrientated protocol, this means that packets which are lost in transmission will at some point be resent from the other host. This retransmission is impractical for real-time services and will increase jitter, latency and possibly increase packet loss (in some cases).

Answers to Your Questions

What I get is basically just noise. 20% of it is the recorded sound and the rest is just weird noise.

TCP should not introduce noise, it should introduce jitter and latency. Sockets tend to have an automatically defined time-out time, do you define the time-out time? If not what happens why you do not recieve the correct packet in time before playback?

Am I on the right tracks? Is it even good idea to use TCP/IP for this kind of application (voice conferencing of sorts)?

No do NOT use TCP/IP it is not a good idea. It appears that your manager has incorrectly assumed that any packet loss is a terrible thing.

Summary

Some general key concepts have been shown here to try and help as much as possible for this specific problem, however this should not be considered exhaustive. Make sure the VoIP system also uses some underlying principles of speech coding/signal processing techniques.

The key points to remember are:

• Use UDP for VoIP.

• Implement packet loss compensation
  techniques.

• A block interleaver is a simple and
  effective method to increase QoS.

I hope this helps.