Help with Directory Number issue. We are experiencing a sporadic, yet consistent issue where directory numbers, when called, go straight to voicemail. DND is not active, the device is on-hook and the max call/busy trigger is set to 4/2 respectively. BLF Speed Dials of the affected number show the line in a constant "off-hook" status on "Watcher" devices. The only workaround we have found is to delete and recreate the DN. The only similarity we can find is that the issue has been recorded only on Cisco 6945's (SCCP6945.9-4-1-3). We have many other models in our environment, but this issue has not been recorded on any other model.
FYI - I have a case open with Cisco and have collected many GB's of traces and have heard nothing back...going on 3 months now.
The phone is configured correctly, including the VM portion. 6945 phones at a particular location are all configured the same with the exception of the line appearance.
This is not an issue for just this one device, but many devices are experiencing the issue. Restarting the Call Manager service, or deleting/recreating the directory number is the only workaround I have found.
You ask for logs from CM, I have about 10 GB's of logs that TAC has been sifting through since late June. That being said, It would be difficult for me to extract 1GB of traces pertinent to identifying the issue.
I have attached a picture that helps describe the issue.
I would like to also point out that increasing the max call/busy trigger from 4/2 to 4/3, 4/4, calls ring the device, but the "watcher" device still shows the line being "off-hook". It's as if the busy trigger is set to one.
Is it possible the user is pressing the Do Not Disturb key? That would explain the behavior. I'd need to see CallManager traces from the last successful call up until the first call that went straight to voicemail in order to troubleshoot the issue fully.
DnD is not active. Traces have been collected, but chances are you would not find what you are looking for as the file is 12GB and we are limited to what we can upload to the forum. We cannot recreate the issue...it happens sporadically.
First off, if you have a TAC case open and you are not receiving a response for 3 months then you need to call TAC and get the case changed to another engineer. Ask to speak with the Duty Manager and be the squeaky wheel. They will get your case moving through the system.
This is an odd condition for sure. I am wondering if you have looked at the following:
1. Enable presence/blf for Corporate Directory (Enterprise Parameters) and look up the DN from corporate directory. Is the line presence showing/changing correctly?
2. Does the phone show registered in UCM (Device Config Page)?
3. What happens when you reset/restart the Cisco 6945?
4. When you say that this is only seen on Cisco 6945s, what does that mean? Meaning, what is the relative distribution ration of 6945s to other phones? What is the distribution ration of 6945s as BLF targets vs. other phones?
For instance, if you only have one other non-6945 configured as a BLF target. This data point is not really useful.
I am inclined to recommend checking the bug search tool and firmware release notes to see if you can find a root cause. I started looking but came up blank. May look at it later.
Have you checked and made sure that the same directory number doesn't exist in two different partitions nested in the same CSS? Ive had this happen at times where someone mistakenly creates a directory number in the wrong partition then change it to be correct but not delete the one created by mistake causing this kind of issue. When I get this kind of complaint the first thing I do is go to route plan report and check to make sure that there aren't identical directory numbers in different partitions.
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...