VoIP Networks and One Way Audio

There are many interesting new issues that seem to have come with the addition of voice and video to the data network. Most of the engineers that are now working on VoIP networks come from either a pure data network background or a traditional phone system background. Each network offered certain issues that where common to those specific networks. As the world of networking converged these two networks over the past dozen years or so, there have been many new issues to overcome and learn how to solve. The growing pains associated with the shift from two networks into one seem to still be mounting based on the amount of technical support calls and forum questions on the common issues of a data/voice/video network.

Many different types of issues are common with data/voice networks such as bad voice quality relating to issues such as delay, jitter, and dropped packets. These issues usually can be fixed with the proper configuration of your Quality of Service settings.

One Way Audio Troubleshooting Methodology

One issue that seems to materialize more frequently is the issue of “One Way Audio”. This scenario occurs when party A in a call can hear party B, but party B cannot hear party A.

One-Way Audio Issues in an IP Telephony network can be varied, but the root of the problem usually involves IP routing issues. Here are a few items to check to make sure routing issues are eliminated as the root cause of the one way audio issues.

1. Always check basic IP reachability first. Because Real-Time Transport Protocol (RTP) streams are connectionless (transported over UDP), traffic may travel successfully in one direction but get lost in the opposite direction. This diagram shows a scenario in which this can happen:

Subnets A and B can both reach Subnet X. Subnet X can reach Subnets A and B. This allows the establishment of TCP connections between the end stations (A and B) and the Cisco CallManager. Therefore, signaling can reach both end stations without any problems, which allows the establishment of calls between A and B.

Once a call is established, an RTP stream that carries the audio must flow in both directions between the end stations. In some cases, Subnet B can reach Subnet A, but Subnet A cannot reach Subnet B. Therefore, the audio stream from A to B always gets lost.

This is a basic routing issue. Use IP routing troubleshooting methods in order to successfully ping Phone A from Gateway B. Remember that ping is a bi-directional verification. This document does not cover IP routing troubleshooting, however, you should confirm these as some initial steps to follow:

  • Default gateways are configured at the end stations.
  • IP routes on those default gateways lead to the destination networks.

2. Bind the H.323 Signaling to a Specific IP Address on the Cisco IOS Gateway and Routers
When the Cisco IOS gateway has multiple active IP interfaces, some of the H.323 signaling may be sourced from one IP address and other parts of it may reference a different source address. This can generate various kinds of problems. One such problem is one-way audio. In order to get around this problem, you can bind the H.323 signaling to a specific source address. The source address can belong to a physical or virtual interface (loopback). Use the h323-gateway voip bind srcaddr ip-address command in interface configuration mode. Configure this command under the interface with the IP address to which the Cisco CallManager points.

3. Bind the MGCP Signaling to the MGCP Media Packet Source Interface on the Cisco IOS Gateway
One-way voice can occur in Media Gateway Control Protocol (MGCP) gateways if the source interface for signaling and media packets is not specified. You can bind the MGCP media to the source interface if you issue the mgcp bind media source-interface interface-id command and then the mgcp bind control source-interface interface-id command. Reset the MGCP gateway in Cisco CallManager after you issue the commands.


One Way Audio on Cisco IP Communicator

With regards to issues involving IP Communicator, the issues mentioned above could still apply. Investigate those possibilities first. If the above issues seem to be in check then one of the following should be investigated.

1. Version Control
Software VPN clients are overlaid on top of an existing IP network, meaning that there are essentially two IP addresses on the computer when a VPN is in use:

  • The IP address from the underlying network
  • The IP address provided by the VPN client that is used by parties on the other side of the connection to communicate with applications on the computer

Some VPN clients, such as Cisco Systems VPN Client 3.x, assign the VPN IP address at a very low level, which makes it difficult for Cisco IP Communicator to specify the correct address. To eliminate this problem, Cisco IP Communicator queries the Cisco VPN client directly.

Other VPN Clients, such as the Microsoft PPTP client and Cisco VPN Client 4.x simply appear as alternative network interfaces. In these cases, the IP address can be selected with the same auto-detection process that is used to resolve selection when there are multiple interfaces.

Other third-party VPN clients might be unsupported and result in one-way audio. Fix the problem by running the Cisco IP Communicator Administration Tool to create a getIP.asp audio IP address reflector web page. Once that is complete, specify the URL for the web page in Cisco CallManager Administration. Cisco IP Communicator will attempt to fetch this reflector page rather than using other methods of auto-detection.
The reflector page returns the IP address from which it sees the request originate, which is a relatively reliable way to identify Cisco IP Communicator’s VPN IP address. See the opening paragraphs of this section (Resolving Audio IP Address Auto-Detection Problems) for more information on completing the getIP.asp tasks.

By making sure your PCs are running the latest VPN client (VPN 5.x as of today), and the CIPC application (CIPC 7.0.3 as of today), you will eliminate most of the one way audio issues that were part of the earlier versions of these applications.

Summary

As with most issues in technology there is not one correct answer to every problem. In that most networks are very different from each other not all answers will work on every network. The information above has been found to be the most common fixes for most one way audio issues, but most certainly will not be the fix in every network.

References

Author: Paul Stryer

In this article

Join the Conversation

4 comments

  1. Katie Tam Reply

    I’m was able to build a Voice Terminal using Cisco AS5350 and ASA5400 about 7 years ago. Now they are upgrading to Cisco ASA5350XM and ASA5400XM. Great package for voice.

  2. Comwave Reply

    Thanks for the great information. Very helpful.

  3. voip Reply

    Thanks for the post information. Very helpful.

  4. Graham Allen Reply

    I found a very detailed explanation of why this occurs with SIP when traversing a NAT.
    It also has the fix.
    http://think-like-a-computer.com/2011/03/14/one-way-audio-sip/