This document explains the problem and solutions related to the one-way audio problem associated with Cisco Unity and Cisco CallManager.
Note: This is based on Cisco Unity for Exchange integrated with a Cisco CallManager.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
This problem involves when users hear prompts, but are not able to record. This document is written with the assumption that normal call initiation works correctly (IP phone can call Cisco Unity and the call is answered). This document assists the user with narrowing down the point of failure.
Check the NT event log for wave record errors to identify if this is a Unity wave problem. If wave record errors are found, contact Cisco Technical Support with the event log messages. If wave record errors are not found, it could be a network and/or firewall configuration problem.
Routers/firewalls must allow RTP bi-directional streaming for audio to reach Cisco Unity from an IP phone. These RTP streams typically use UDP ports 16384 and later. Therefore, the network must allow traffic on these UDP ports to go both ways. Complete these steps to troubleshoot RTP streaming from the phone:
Verify RTP data is sent.
While you attempt to record a personal greeting, push the info button twice on the IP phone. One of the items on the display is Tx packet Count. This increases as you speak. If it does not increase, this means that RTP data is not being sent. The next step is to enable the RTP data streaming, which is not in the scope of this document.
Verify the network does not drop packets.
If RTP data is being sent, but the problem still exists, it can be because the network gateways are not configured properly. Place a computer on the same hub / switch and subnet as the phone and configure it to use the same gateway as the phone. Try to ping the Cisco Unity server from this computer. The next step is to troubleshoot the network, which is not in the scope of this document.
Verify a firewall does not drop packets.
If RTP data is being sent, but the problem still exists, it can be because a firewall silently drops packets. Place a phone on the same hub / switch and subnet as the Cisco Unity box and try to call other IP phones. Also try to do this with Media Master. Audio should stream both ways between the test IP phone and other phones. If it is not, something in the middle is blocking that traffic. The next step is to troubleshoot the firewall, which is not in the scope of this document.
Note: This test does not always diagnose a firewall configuration problem. Sites have been seen that allow traffic on UDP ports 20000 and above. Cisco Unity usually uses ports between 19000 and 20000. The phones usually use UDP ports above 20000. In this configuration, audio streams between the two phones, but audio does not stream from the phone to Cisco Unity. There is not a simple way to diagnose this problem. If these conditions are true, it is assumed that this is a firewall problem:
Users hear prompts, but cannot record.
There is a firewall between the phone and Cisco Unity.
You can ping Cisco Unity from a computer on the same hub / switch as the phone that is configured to use the same gateway as the phone.
The audio works properly when Cisco Unity is called from a phone on the same hub / switch as Cisco Unity.
Note: If Cisco Unity answers a call, but the users cannot hear Cisco Unity, it can be that RTP streaming only works from the IP phone to Cisco Unity, but not from Cisco Unity to the IP phone.
One-way voice issues can occur if dual-network interface cards (NICs) enter your system. Refer to Configuring and Troubleshooting Dual NICs for Cisco Unity for more information. Use this procedure as a workaround.
Disable one of the NICs.
Configure the NICs in an active-passive manner.
When a user calls from a remote site through the Public Switched Telephone Network (PSTN) to Cisco Unity, dead air is received on the voicemail prompts.
The PSTN calling party is not able to hear the greetings configured on Cisco Unity. The Cisco Unity Port Status monitor shows that Unity answers the call. Cisco Unity sends the greeting audio stream to the caller, but the calling party is not able to hear the greeting. Internal calls to Cisco Unity function properly, and callers are able to hear the greetings.
This is a one-way audio issue that affects calls through the PSTN [gateway] into Cisco Unity. This problem results when Cisco Unity sends the Real-Time Protocol (RTP) packets to the wrong interface on the gateway. For example, Cisco Unity sends packets to the loopback interface instead of the FastEthernet interface, which is the "bound" interface for the Media Gateway Control Protocol (MGCP) process.
You can issue these commands to find out whether Cisco Unity currently sends RTP packets to the wrong interface on the gateway.
Complete these steps in order to resolve the issue:
Issue the no mgcp command to shut down the MGCP process.
Remove the mgcp bind control and mgcp bind media commands from the router configuration.
Re-issue the mgcp bind commands.
Issue the mgcp command again to allow the gateway to register to Cisco CallManager.
Test the call again and issue the show commands mentioned earlier to verify that Cisco Unity sends the RTP stream to the correct (bound) MGCP interface.
Users are unable to hear voicemail when trying to access their voicemail box. This is a one-way audio issue when the user attempts to retrieve a voicemail message from Cisco Unity.
When a Unity subscriber tries to access voicemail from an external phone, dead air is received when the voicemail is played. This is an issue with one-way audio (external to Unity only as DTMF tones are being transmited to the Unity but audio from Unity is not reaching the External phone).
G729 codec can cause this problem. A gateway that negotiates a G.729 codec with 20 bytes in the call setup might send 40 bytes instead. When Unity receives 40 byte packets, it drops them.
The resolution to this problem is stop the advertising G729 codec Annex B in the Cisco CallManager Service parameters.
Upgrade your voice gateway to Cisco IOS® Software Releases 12.2(11)T5 or 12.2(11)T6. The fix will also be in Release 12.2(13)T3 when it becomes available. Cisco IOS Software Release 12.2(13)T1 does not have the fix.
Refer to Voice mail messages on Unity from external callers using G.729 codec are blank. Field Notice for more information.
Calls from the MGCP PRI gateway disconnect and reconnect mid-stream so that Cisco Unity sees two calls instantaneously and gives a busy signal. When this happens, typically calls from the outside that route to the main 800 number receive a busy signal.
When you use the MGCP PRI gateway with a DMS-100 or DMS-250 protocol, check Send Extra Leading Character in DisplayIE in the gateway configuration page.
Note: This check box only applies to the DMS-100 and the DMS-250 protocol. By default this setting is disabled (unchecked).