Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

one ring dead air

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
Anonymous
N/A

Re: one ring dead air

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

Anonymous
N/A

Re: one ring dead air

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

Gold

Re: one ring dead air

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

168
Views
0
Helpful
3
Replies