"Can you hear me now?" is more than a catch phrase in wireless telephony commercials. It is the fundamental check that voice or video connectivity exists in both directions between two endpoints of a call. Calls that operate in only one direction may have one of several causes. The symptom is that one party to a call cannot hear the other participants, but the other participants can hear (or see) the affected party.
Understanding Call Connectivity
To diagnose the source of one-way audio or video calls, it is necessary to understand how calls operate. To start, each endpoint registers with the call controller. This way the controller knows the phone number and the IP address of each endpoint. Calls proceed as shown in Figure 1.
Figure 1. Call Operation
1. Phone 1 goes offhook.
2. The call controller collects the digits as they are dialed.
3. The calling phone is given a ringtone to play, indicating that the call is in progress.
4. The call controller uses the dialed phone number to look up the IP address of the destination phone, Phone2 in this case.
5. The call controller tells Phone2 to play a ringtone to alert the recipient of an incoming call.
6. The recipient answers the call, causing an offhook event to be sent to the call controller.
7. The call controller instructs both endpoints, Phone1 and Phone2, to establish an RTP session between them.
One-way voice occurs when the RTP stream between Phone1 and Phone2 is not established or maintained in both directions.
A similar process is used to establish a call between Phone3 and the Voice Gateway. Connectivity problems that affect Call 2's path can also result in one-way audio.
Call complexity is increased when the calls use different codecs, such as when one phone is in the WAN and is configured to use G.721 while the phones located in the LAN use G.711. If both phones only support one codec, a Session Border Controller (SBC) or other device that contains Digital Signal Processors (DSPs) must be used to convert from one codec to the other, a function called transcoding. The transcoder then becomes an intermediate endpoint between the phones, causing the call to have two legs: between Phone1 and the transcoder, and between Phone2 and the transcoder.
Similarly, conference calls rely on a Multipoint Control Unit (MCU) to relay the voice and/or video data stream to all participants. So each phone that is participating in a conference call must have bi-directional connectivity to the MCU.
With the above understanding of call connectivity, we now have a basis for understanding the sources of one-way audio or video calls.
Routing and Packet Filtering Problems
The most common problem within enterprises is due to routing problems in which one call endpoint doesn't have a clear routing path to the other endpoint. Many IT professionals think that as long as the endpoints can communicate with the call controller, the calls should proceed without problems. But this isn't true; as noted in the call connectivity description above, the endpoints normally communicate with each other directly.
The missing route could be intentional, due to limits on the distribution of routing information, or it could be accidental, caused by improper route propagation and filtering. I've seen an enterprise that was running MPLS have parts of the network that couldn't talk with other parts of the network, even though the voice network was supposed to have full connectivity. In some cases, asymmetric routing may cause packets in one direction to encounter a firewall or other unplanned filter.
Firewalls, packet filters, Network Address Translation (NAT) and Port Translation (PAT) could also be causing one-way audio as the packets are filtered and headers are re-written, so look at packet filter and firewall rules that may be causing large numbers of packets to be dropped.
Diagnosis of routing problems is typically done with tools like ping and traceroute. The diagnostic tests have to be conducted from the router interface that is on the same subnet as one of the endpoints that is experiencing the problem. If there are firewalls in the path, the tests may need to be done using UDP packets that are using the same port range as the voice/video system. Try to use these tools to identify the part of the network where connectivity is failing, then focus attention on that part of the network.
Packet capture diagnosis may be needed after the general location of the problem is found. Look for the absence of packets in one direction, packets with different addresses or port numbers, etc.
When attempting to diagnose one-way connectivity, it is useful to gather as many data points as possible. Is the problem only affecting one endpoint? Are multiple endpoints on the same subnet affected, either source or destination? Some specific tests may need to be performed to determine which endpoint is experiencing the problem and if the problem is only with a subset of other endpoints.
Transcoder DSP Failure
When two endpoints in a call use different codecs, perhaps because one endpoint is in the WAN and the other is in the LAN, a pair of Digital Signal Processors (DSPs) are used to convert between the codec encodings. As noted above, this function is called transcoding.
Two DSPs are needed: one DSP is used to perform the conversion from source to destination and another DSP transcodes the flow from destination to source. In rare instances, bugs in the DSP implementation can cause a DSP to crash, resulting in a one-way conversation. DSP hardware failure produces the same symptoms. A power supply failure, or intermittent power supply problems in a DSP chassis can cause multiple, simultaneous one-way calls. When this happens, the call must be re-established.
Diagnosis and troubleshooting of DSP failures is best performed by using DSP and hardware management tools that track the status of each DSP and of the hardware platform that contains the DSPs.
Multipoint Control Unit (MCU) Failure
Conference calls of three or more endpoints require the use of an MCU, which replicates the call's data flows between all participants, perhaps also adding features like microphone selection and video source control. Each endpoint must have a bi-directional connection to the MCU, so there are opportunities for routing failures on each endpoint path, as described above.
However, there are also possible failures within the MCU as the flows are merged and converted to the codecs used by each endpoint. And there is also the possibility that the MCU itself will experience a hard failure, such as a power supply problem or an over-temperature situation. Most failures won't result in one-way connectivity, because the failure affects the entire MCU. But there are cases where routing, packet filtering, or an internal DSP failure can create one-way connectivity.
Fortunately, MCU failures typically affect all calls in both directions. In rare cases, there may be individual DSP failures that create one-way calls. The most frequent sources of one-way calls will be due to routing or packet filtering, as described above. When problems are reported, it is easy to check the MCU system status to make sure that there isn't an internal failure.
Summary
There are a number of documents on the web that discuss diagnosing one-way audio. I found that most of them cover NAT as a potential source and that very few of them mention DSP or MCU problems. Methodical collection and analysis of diagnostic information is the best way to determine the cause of one-way calls.
Related documents:
Cisco: "Troubleshooting One Way Voice Issues"
