If you deal with Voice over IP (VoIP), you must have come across this scenario at one time or another: A user complains that when they answer their phone, the caller can’t hear them, even though they can hear the calling party. Or, it may be that neither party can hear the other and there is just silence on the line.

This is the classic case of one-way or no-way audio, where a voice call is successfully completed, but either the voice packets only successfully travel in one direction, or neither end successfully receives voice packets. It may be difficult to understand why this happens, especially since the phone does ring, both physically for the called party and via the ring-back tone for the calling party. It seems counterintuitive that the transmission of voice packets could be unsuccessful if the call was successfully set up.

This is a scenario that comes up a lot on our tech support calls at TeleDynamics. Here we list four of the most common culprits of this issue and suggestions for how to tackle them.

It is important to remember that the call control procedures which include call setup and teardown, call routing, ringing, connecting, codec choices and other such processes are independent from the exchange of voice packets. In a sense, call control occurs on a different “channel” from that of the voice packet exchange. Consequently, call control packets are handled differently from voice packets and as a result, a call may go through all of the proper call control procedures flawlessly while the voice stream may encounter obstacles in one or both directions.

Call control for the Session Initiation Protocol (SIP) occurs using the TCP or UDP transport protocol on ports 5060 and 5061. Interestingly enough, SIP is only involved with call control; that is, the signaling portion of a communication session and is not responsible for the transmission of voice packets. In most implementations, the protocol that carries voice packets is the Real-time Transport Protocol (RTP), a protocol designed for real-time applications such as voice and video. The range of ports used by RTP for voice packets varies by manufacturer and is typically, although not always, from 16384 to 32767.

Having said that, it is quite clear that if the ports used by RTP are being blocked somewhere in the voice stream, but the SIP control ports are not, then calls can be set up and teared down successfully without any successful exchange of voice packets. The vast majority of one-way or no-way audio problems are a result of the blockage of RTP ports for the voice stream.

There may be many reasons why these ports would be blocked. Some of the most common are:

(1) Network Address Translation (NAT)

This is especially true if one of the telephony endpoints is on one side of the NAT router and the other is on the other side, namely, the Internet. As is well known, NAT will block all transmissions from the Internet. This is perfectly fine, and is desirable in most cases. However, it can be terrible when trying to employ VoIP. You can easily configure the router to unblock the two SIP control ports and allow for call control to occur, but since the voice packets pick a random port from within a range of over 16,000 ports to use for each call, it would not be safe or proper to unblock the whole range and open up the network to potential attack. There are several techniques for allowing VoIP to function over NAT, including drastically reducing the RTP port range, using UDP Hole Punching or Session Traversal Utilities for NAT (STUN). For more details on how to resolve NAT-related audio issues, see our article on how to resolve one-way or no-way audio on VoIP calls.

(2) Firewall

If specific ports within the RTP range are being blocked by the firewall, then the voice stream will be impeded. A solution to such a problem is to implement a second- or third- generation firewall, either of which have the capability of examining more than just port numbers to determine if a voice packet stream should be allowed to flow through the firewall. One security component of a firewall specifically designed for voice is the SIP Application Layer Gateway (ALG). SIP ALG is a firewall setting that can either be enabled or disabled -- generally, the audio issues occur when it's enabled.

(3) Incompatible Codecs

When a VoIP call is initiated between two phones, they negotiate and choose a codec that is available to both devices. If this process of agreement is unsuccessful, either because they don’t support a common codec or there is a misconfiguration in one of the two phones, calls may be completed without any voice packets being exchanged. When troubleshooting, make sure there is a common codec supported by both endpoints (including any voice gateways that may exist in the voice path), and that these are included in the available list of codecs for each device.

(4) Network Routing

VoIP uses IP for the transmission of voice packets at the Network layer, and that means it is subject to the same behavior as network traffic. When implementing routing, it is a basic principle that if you can route from one source to a specific destination, it does not necessarily mean that the opposite is true. If such a routing misconfiguration is present, one-way audio can result. Such situations can be dealt with in a similar manner to traditional networking and routing problems, usually using a bottom-up troubleshooting approach for static and dynamic routing configurations.

CONCLUSION

One-way and no-way audio can be frustrating for telephony administrators, especially when traditional troubleshooting is insufficient to discover the problem. Hopefully these common culprits can be a good starting point for dealing with such issues.

You may also like:

How to resolve one-way or no-way audio on VoIP calls

Hello? Hello? Why some VoIP calls get dropped

E911: emergency calls using a VoIP phone system