I have a 7940 that recently began having a problem. It is exten 8420. In CallMgr 4.2 it is set to go to voicemail after four rings. Instead after its four rings it produces a busy signal. I thought there may be something wrong with the mailbox setup etc, so I changed the RNA target to a known working extension. Same result. After four rings, it produces a busy. No matter what I list in RNA or Busy fields, it goes to a busy signal. I have deleted the extension and re-added it.. Same result.. I have deleted the phone and re-added it same result. I noticed when adding the extension back in even after I deleted it some of the information was retained by CM. Is there any way of clearing that information out totally to be sure we are starting from scratch? I have compared this phone setup with others and its identical. Everything is setup as it should be. Please help with any ideas on why this may be producing a busy after it needs to go to its CFB or RNA targets....??
first go to call routing--> route plan report to see if there are any confilcts/miconfigured/... route patterns, translation patterns, call park patterns, call pickup groups patterns,....etc
sometimes some misconfigured patterns may cause confilcts and cause like ur problem ..
another note when a DN has not been deleted totally (i mean not just to replace existing DN with a new DN and then click save button) CCM will retain the old DN settings (like partition, Alert name, text lable,....etc)
make sure from the report plan there is no shared DNs like this.
second check ur partitions for ur internal DNs if u specified partitions and did not leave DNs in None partition, also check the device/line CSS for the originating DN (that is to be forwarded to VM or another extension when RNA)
please remember to rate helpful posts
Yes I looked at the route plan report already... all that is there for that extension is just the main phone and its shared line appearance on the secretaries phone. I have poured through both to verify all is ok, and it is. I actually had DELETED the extension off of BOTH phones, not replaced, but deleted. The information was still retained as when I went to put it back the alert name, forwarding destinations etc were all there...
Partitions are all correct. I have compared apples to apples this phone/setup with other working extensions and its only this one that has the problem. It is very very strange.
Anyone- any other thoughts?
You might be running into this "Unassigned DN" issue where the info for 8420 needs to be cleared out so you can start over fresh. I'm guessing the issue can be resolved this way. Have a look;
CallManager 4.x: Delete Unassigned Directory Numbers Configuration Example
Cisco CallManager 4.x has a new concept called Unassigned Directory Numbers (DNs). When a DN gets removed/updated from a device or a phone gets deleted, the associated DNs are not removed from the Cisco CallManager database as in earlier versions. They still exist in the Cisco CallManager database as Unassigned DNs. You can see a list of DNs that are not associated with phones in the Route Plan Report menu option.
Note: In Cisco CallManager releases earlier than 4.0, DNs were automatically deleted when a device was deleted. Because line group support is a feature of Cisco CallManager Release 4.x, keeping unassigned DNs is a requirement.
From this good doc;
Hope this helps!
Hi Rob, your information was helpful. It helped me to go to the route plan report and remove the exten completely (it was in there...) I removed it and set it back up the way it should be (compared again to other working phone, line by line) and still after the set number of rings, it produces a busy. So I changed the extension on the phone to the next avail 8421, leaving everything else as is... and it works fine.. When I got back to using 8420, (even after completely removing every existance of that number, it bombs)... The phone works fine using 8420.. when you call it, it rings. It can be answered... but if left unanswered for any fwd target to kick in, no matter where I attempt to send the call, it goes busy.
Hmmmmmmmmm is right! If possible I would remove the 2 phones completely. Both the primary and the "shared line" phones.And then re-build just the primary. It seems like some remnant info is lurking around that pertains to 8420. The other thing I might try is stopping/starting the Database Layer Monitor Service.
Let us know,
I think I have done that Rob, but I don't remember the sequence of when I removed them and completely rebuilt them.. Im also even going to try another phone on Monday (working on this remotely so I can't do anything physical until then) although I doubt its anything hardware, but you never know in this weird case.
As far as stopping/starting the database layer monitor service, will that cause any disruptions anywhere? This is a hospital so anything like that that would affect everything is hard to accomplish.. If it won't I can give that a shot easy enough.. Many thanks
If you remove the related phones and then remove 8420 from the "unassigned DN's" When you go back and add 8420 to a phone do the Call Forward settings still populate?
Was 8420 ever on a 3rd phone? If yes, have you done a reset on this phone as well?
If none of this works, then you probably could try a reboot of the Pub/Subs or perhaps open a TAC case to remove the remaining references of 8420 so you can start fresh :(
Hope this helps!
hey Rob... The settings did not populate at all when I had removed the addtl info in the route plan report. The number was only on two phones, which I completely removed... removed from route plan report, stopped and started the service you mentioned, rebooted the publisher (that was the most I could get away with)... I added it back to just one phone on line one (a different phone altogether) and same result... ring 4x then produces busy signal.
I believe next step is a tac case as you mention unless you think of something else.. It is very very weird.
I think the TAC case is an excellent idea especially given the nature of your Hospital environment :)
Sorry I couldn't have been of more help!
Let us know how this pans out.