Deleted Directory Number but it still rings.

[rona.venida]

I've already deleted a certain Directory Number but when I try to call that number, it rings. I've checked the Route Plan Report and the directory number does not exist. If the number is already gone in the CUCM, why does it ring? Any idea?

[Jaime Valencia]

Has it been deleted from the unassigned DNs as well??

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

[Jayant Kohli]

If it has been deleted, then i believe we have some major database replication issues

Regards

Jayant

[Clifford McGlamry]

Make sure it's deleted in the Route Plan report when you pull an unfiltered report on unassigned numbers.

If it's still ringing at that point, you may need to think about rebooting the cluster and checking dbreplication.

If rebooting everything is problematic for you, you could restart the RIS Data Collector and the DBReplication service on all servers.  That *might* resolve your issue as long as everything else is good.

[rona.venida]

The problem is, there is only ine DN that behaves like this. Whenever I try to delete another DN and make a test call, it doesn't ring.

[phooghen]

There is a known bug about this : CSCsj95732

Try to apply the workaround.

Symptom:

Calls placed to a DN that has been deleted from a phone are forwarded to the CFA destination set on the DN when it was deleted.

Conditions:

A phone has a DN assigned to it and the phone has a CFA destination configured.  The DN on the phone is deleted from the phone, but CM still routes calls to the CFA destination

Workaround:

Add the DN back to the phone, remove the CFA setting and update the phone.  This will remove the improper CFA and the DN can then be removed without this issue.

[rona.venida]

Hi,

We've tried doing the workaround but the problem is still there. Do you have any idea?

Thank you.

[Clifford McGlamry]

Make sure you have it deleted from the unallocated numbers in the Route Plan Report.

Once you've done that, use the Dialed Number Analyzer to figure out what exactly it's hitting.  You may be hitting a route or translation pattern that is sending it off somewhere else unexpectedly.

Cliff    

[rona.venida]

Hi,

Yes, I have deleted it. Whenever I search it in the Route Plan Report, 0 record found.

Also, I've tried testing it using Dialed Number Analyzer but the Match Result = BlockThisPattern.

[Jayant Kohli]

Hey,

Whats the state of database replication?? May i know the call manager version as well?

Regards

Jayant

[Clifford McGlamry]

Ok.   We need to dig a bit deeper here:

1.  What's the Callmanager software version?

2.  How many servers are in the CCM cluster?

3.  How many phones?

It sounds like you may have an issue with database replication.  If your installation can support it, kill the callmanager service on all the subscriber servers and allow the phones to reregister to the CCM Publisher.  Make sure your gateway is configured to support this as well.  Once you're running in this single server mode with everything registered to the Publisher, repeat your test and see if the call still goes to the non allocated DN.

If the call goes through in this mode, you're dealing with database corruption.  If it doesn't, you have an issue with database replication.

Try this out, and advise which way it goes.

Cliff

[rona.venida]

Hi guys,

1.  What's the Callmanager software version? 6.1.4.2190-3

2.  How many servers are in the CCM cluster? 8 servers

3.  How many phones? 10659 including analog phones

4. State of DB Replication - Running.

We will try that and let you know the results.

Thanks guys!

[Clifford McGlamry]

Ok.  That's too many phones to shut down to a single server.

Several things you can look at here:

1.  Open the command line on the publisher.  Run the following command:

utils dbreplication status

It will dump its output back to a file in the activelog directory.  If you post that back here, we can help you look at it.

2.  Open the CCM admin interface.  In the upper right hand corner navigation drop down, select Cisco Unified Reporting and hit GO.  You'll need to log in with the application admin login, and not the platform admin login here.

On the menu, select system reports ==>  Unified CM Database Status.  Scroll down the page and look for ANYTHING that's not reporting OKAY.

3.  You can use the RTMT tool.  Log in with the application administrator login and point at the publisher.  Select CallManager ==> Service ==> Database Summary.  Scroll to the bottom to the table.  Anything that is not a replication status of 2 is an issue that should be looked at.

All these get you similar information...some more than others though.  Take a look and let us know.

Cliff

[rona.venida]

Hi Cliff,

I can't seem to find the database status in CLI and in RTMT. Attached here is the Database status found in Cisco Unified Reporting in CUCM. As per checking, the replication status is good. Can you help me with this?

Hope to hear from you soon.

Thank you.

[vakkera]

Hello Rona,

Based on the problem description and the 'CM Database Status' report, it very much sounds like a DB notification issue. The changes made to the the database are not being notified to the CM service of one of more nodes. Since call rounting is performed based on the CM service cache memory, it is logical that the server which did not get  the notification, sitll thinks that the DN exists.

To clear this issue, you might want to restart the following services on all nodes or rebot the cluster

1. CM service

2. Cisco Database Layer Monitor

Based on your previous posts I see it is a 8 node cluster and any resets as such would be a challenge. To identify which node is the problematic node, you could run 'show tech notify'  while doing an SSH to the node and verify to see if 'CCM' exists. If it does not exist on any particular node, you could reset the CM service on that node and that should very likely clear the issue.

To identify the root cause, you would need the following the logs from when the system was fine to the pt where notification failed.

1. DB notification logs

2. DBL library

3. Cisco Database Layer Monior

Hope this post helps!

Regards,

Sunny