I have another issue with Unity Auto Attendant and I hope you guys can give me some suggestions. The ingress gw calls a CCM CTI route point and transfer to a customized openning greeting in Unity. While I am in AA, I can transfer the call to an extension in CCM but with one-way audio. I tried to hard-coded the codec to g711ulaw in my gw and it didn't help. The CTI route point and the voice mail ports are in the same region "default" using g711 as codec. Calls from the gw directly to the IP phone work with g711 or g729 codec.
BTW, if I transfer to extension's greeting in my call handler and my subscriber set to send to greeting, I can hear the greeting. But if I tried to transfer to a extension and let the phone rings and when it goes back to the VM, I can't hear the greeting any more but I still am able to record message.
MTP degrade the Quality of sound for calls. So I have to disable it.I don't why yet, but I guess it has something to do with DSP for the T1s.
It is very strange, I can record greeting using my IP phone, I can call into Unity no problem, the issue arises when Unity AA tries to transfer the calls to CCM since I setup to forward calls to extension if caller dial the extension during the openning greeting. After the calls get transferred, caller can't hear anything or if it goes to VM, caller can't hear the VM greeting.
The network setup is a little bit complicated. RTR-A connects to RTR-B through a GRE Tunnel. CCM is connected to RTR-B and RTR-B connects to another RTR-C. RTR-C connect to Unity. There is a PIX between RTR-B and RTR-C. All my IP phones are connected to RTR-A. If I call from the IP phone to Unity, seems ok. When the PSTN callers call into the Unity, problem arise. RTR-A connects to RTR-D where the T1s are.
Unity isn't doing anything different with the call that a standard IP phone wouldn't do. You can test this by putting an IP phone on the same network segment as Unity, give it the same Partition and CSS in CCM as the Unity ports. Now call into this phone and use it to manually perform your transfer. I would expect the same one-way audio problem.
I don't have any guesses on where the audio is getting lost. I would start collecting sniffer traces a different points in the audio path. Cisco TAC may also be able to help by looking at debug traces from your routers.
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...