All, I have a 7960 phone that is fowarded to an analog port off a VG248. out CM, went down last night for unknown reasons and now the call is stuck in call forward. You can push the CFwdall button on the phone and the call forward goes away, but all the calls still get forwarded. any help would be appreciated.
You could take a CCM detailed trace, if in there you see that the call is still forwarded (checking the forwarding table rules) then most likely the information is stuck in cache and the only way to remove this information is rebooting the server.
If you go to the Device>Phone page for the 7960 on CCM try deleting the Call Forward and resetting the phone. I've had this type of lockup happen before and this always worked.
Hope this helps!
If Rob's trick doesnt work.
Last ditch effort would be to delete the phone, and reconfig it. I've had this problem before as well.
I have been very successful using the CCMuser page to fix this issue. I have the user login or I change their password and login as the user and I forward their phone to my phone click update and then turn off the forwarding by unchecking the box to forward it. This has worked 19 out of 20 times. The other time I had to reset the phone.
I had a similar issue may not be exact. All phones in CM could forward but not unforward. From the publisher restarted Cisco RIS Data Collector and Cisco Database Layer Monitor. Problem has not come back since.
Hello, I'm currently looking into a similar issue as well. Here's the scenario:
One user with 7960/7914, it's our operator phone. When she covers the lobby desk she cfwdall to the lobby phone. Cfwdall is updates but you receive a busy signal when you dial the number. I have tried all the solutions I've read in the threads of this post with no success. So what I came up with is I changed the dn on the line, left the test label so the user wouldn't notice, created a translation pattern for the original ext. to forward to the new dn...problem temporarily solved. This isn't the first time I've had to do this for this ONE particular phone/ext. Just to throw another curve ball in the mix, today the 'temp ext.' did the same dang thing! So I tried all the listed suggestions again with no solution, so once again I had to change to yet another 'temp ext.' and change the translation to point to that one.
If anyone has any toubleshooting steps and/or resolution to this issue, I would greatly appreciate it as it just doesn't make sense to me. Cfwdall works on all other phones?! It's almost like that particular dn record is getting stuck somewhere??
Jason, make sure to add a CSS on the CFwdALL field that can reach the lobby's phone, must likely you are not able to reach that phone. Open the CCMAdmin webpage go to Device --> Phone and search the operator's phone then go to the line that is been forwarded and assign a CSS on the CSS field of the CFwdALL option.
Thanks for the prompt reply. One of the steps I tried was to change the CSS for the cfwdall to a different CSS, reset, and tested again with no resolution.
Do you have a recomendation on tracing where the failure is occurring?
The best way to troubleshoot CCM is with detailed traces, on this case you need a CCM detailed trace:
the trace must be taken on the server were the phones are registered, so is better to have the calling party and the called party on the same server
Do you have more than one Call Manager server? I ran into this problem after doing some updates. I updated my 3 CCM servers, but I didn't update my dedicated MOH server that was also running Call Manager. Eventhough the server wasn't used to register phones, it was causing a problem. Once I updated it to the same version and rebooted everything, the issue was resolved.
I was also told by TAC that pressing **##*35 is supposed to refresh the call forward database.
Thanks for the reply, this issue has occurred before and updates. That's the frustrating thing is that there isn't a correlation to anything and it's only one user with this specific issue. Now we have had a mass cfwdall issue a couple times in the past when a restart of the database layer monitor service resolved this issue, but not in this case. I'm going to try the trace logs after hours, hopefully that will turn up something.
Curious, I tried the **##*35 on my phone just because....and nothing happened, I also tried it after hitting the settings button with the same result.