I have a customer who running CM 3.1.3, and Unity 2.4.6.
The customer has DIDs as well as an AA.
There is one employee who has 2 offices, one with a Nortel system and the other with the Cisco CM. When at the office with the Cisco phones, he forwards his Nortel extension to his DID associated with the Cisco phone.
When when a call comes into the Nortel extension, the call is forwarded to and rings the Cisco phone, but after the default number of rings, rather than bounce to vmail if he does not answer, the call heads to the AA.
However, when the person's DID is called, the phone rings its default # of rings and then bounces to his vmail if he does not pick up. The same can be said if a call comes in from the AA and his extension is dialed from there.
I believe that I have checked the most obvious things, what Unity is set to do when a call comes into it, what CM does with the call forwards, etc. I have been running ccapi debugs and see the call come in and hit the dial peer, and am sure that this has something to do my dial peer configuration, but after 4 hours of looking at it, I am at a loss. I am sure that it is obvious, and I am blind.
Has anyone seen this before? I have captured the debugs and can post them if necessary.
Often times complex troubleshooting issues are best addressed in an interactive session with one of our trained technical assistance engineers. While other forum users may be able to help, its often difficult to do so for this type of issue.
Use the Call Viewer application in the Unity folder in the start menu to observe the difference between a working forward (to the DID) and a failed one (to the Nortel phone) to see what the TSP is getting from the phone system on the incoming call.
For this to work like you want it to, the information should show up the same on both calls. Identifying the difference might help isolate what needs to be changed in order to resolve this.
I ended up speaking w/ a Cisco TAC engineer, and he had me uncheck Redirectin Number IEDelivery Inbound on the gateway and restart the CM services (techinally ir should have been a simple update and reset of the gateway, but for me that didn't work).
I am not sure if it was the services restart or the unchecking, but either way the situation seems to be resolved.
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...