cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
293
Views
0
Helpful
3
Replies

one ring dead air

admin_2
Level 3
Level 3

When calling an extension on a Unity 2.4.6 running on Windows NT platform, I get one ring followed by dead air. The 7960 can go over a minute before dropping the call. The CM is running CCM 3.09 and the u ports have been setup.<br><br>

3 Replies 3

Not applicable

It could be a TAPI/WAV issue. Does the event log show any errors or warnings when this happens?

Steve Olivier
Software Engineer
Cisco Systems

Not applicable

For anyone that is interested, Xipina and I had a little discussion on the side. There weren't any eventlog errors, so the TAPI/WAV configuration was correct.

The Unity system had two NICs and that was causing problems. He pulled the one that was not being used and all is well. Thanks to Keith C out there for sending an email out last week to some of us with an excellent description of a very similar issue.

Steve Olivier
Software Engineer
Cisco Systems

For those who are interested, the following is a stripped down version of my original email:

All phone calls to and from Unity were getting one-way audio. This included calls from IP phones as well as the PSTN. The caller could hear Unity but Unity could not hear the caller.

My first thought was that this had to be a network problem of some sort, but the customer had a very basic flat network. They had 10 IP phones plugged into a single Cat 3524 with Unity and one IP phone plugged into a hub. No VLANs, no routers, no firewalls, no nothing. The customer had a 192.0.0.0/16 address scheme. From the Unity server I could ping the IP phone just fine. I could also initiate a TRAP connection and MWI even worked.

At this point I was stumped. It was like the TSP was getting the packets but it was not passing them to the MIU or something. I thought just maybe the TSP was corrupt. I had the customer uninstall the TSP and then reinstall with no luck. Calls were still getting one-way audio. Before I escalated to Seattle I wanted to get a sniffer trace to make 100% sure that the Unity was getting the RTP traffic from the IP phone. The customer plugged her sniffer into the hub and made a call to Unity from the IP phone that was also plugged into the hub.

At first the trace looked fine to me. I saw the phone sending and receiving RTP traffic like I would expect, but then I noticed something strange. The phone was sending packets to 169.254.181.225. The customer said the Unity IP address was 192.0.0.20. As I examined the trace further I saw that the source address of the RTP traffic from Unity was 169.254.181.225. The source address of the skinny traffic to the CallManager from Unity was 192.0.0.20 however. Both packets were coming from the same MAC address.

It turns out that the customer built their own Unity server (not supported) and it had 2 NICs. One of them had the address 192.0.0.20 assigned and the other was not plugged in. The interface that was not plugged in was given 169.254.181.225 from Windows. This is a normal Windows 2000 function to make networking easier. After we disabled this interface and reboot he Unity server 2-way communication resumed.

Unity’s RTP traffic had apparently bound to the wrong IP address. This behavior is very similar to what we see in router land and the reason that we have the 'h323-gateway voip bind srcaddr' command. This is also the reason that CallManager does not support a second NIC.

Keith


Keith Chambers
Customer Support Engineer
Cisco Systems
keithc@cisco.com

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: