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>
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.
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 188.8.131.52. 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 184.108.40.206 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 220.127.116.11 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.
Unitys 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 Chambers Customer Support Engineer Cisco Systems email@example.com
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...