DNA shows DN in Wrong Partition not confg on Phone or DN

gregory wenzel · ‎02-26-2008

Calls are blocked to dn 1201. Route Plan Report shows all are correct.

Dialed Number Analyzer shows dn is in some other partition that is not configured on the phone nor the dn configuration. 4 digit on-net calls from any remote site to this site get a fast busy to this dn only. we have other sites that are cfg'd exactly the same.

Can someone help?

Has anyone ever had an issue similar to this one?

We have a publisher and subscriber system

CallManager ver 4.1(3)sr5d.

Its looking like we can not delete the dn from the partition within the database.

All 4 digit Calls to these DN's 12[01][29] extensions work fine. Our problem is extension 1201 gets a fast busy. How come whem we run the DNA that this extension shows up in another sites Partition. We have been cleaning up this particular customers botched Callmanager installation from some other resellers poor installation. We think somewhere down the line that this number may have been used elsewhere. We tried to delete the users dn last night but the DNA still shows Ext 1201 in the whitehouse partition. Its actually configured in the Scotch Plains partition and wonder why it shows up as an alternate option.

We are using this number also as a hunt pilot and that portion is working fine.

I double checked the configuration in

Callmanager and the phone and the DN

associated to that phone and its in the

correct partition.

Jaime Valencia · ‎03-01-2008

have you tried rebooting the server or doing a cluster reboot?

i've seen in many cases that even if the config shows up fine in CCMAdmin if you look thru the traces they will show up something different

in a couple of cases since the user was not willing to reboot i did the following:

create a translation pattern with the old DN config, the CSS for the TP must be able to reach the 'new' DN, under called party transformation mask use the 'new' DN

cucm reached the info he thought was right and i redirected the number to the new one

in many cases the information stays in cache memory and a reboot clears this

HTH

HTH

java

if this helps, please rate

gregory wenzel · ‎03-03-2008

Yes, and thank you for replying. The reboot was only a temp solution. Cisco came back and said this was a bug and the SR6a patch would fix the issue

vince.castro · ‎03-10-2008

Try to bring up the Route Plan Report then do a search for 1201 (contains). This will show you if another device or whatever has this dn. If you find it just delete it all. I would also make sure the SQL replication is happening on all the Servers, use DBLHelper to verify this and also to re-initialize. Do the DNA again, it should show as no DN to match. Hope this helps...