Changes to dial plan aren't taking effect

robluechtefeld · ‎03-30-2010

I have a situation where I have made changes to the routing for a couple of DNs, but it doesn't take effect. My configuration consists of a publisher and 4 subscribers. The publisher does not have the call manager service active, and therefore doesn't provide call routing. The call manager version is 4.1.3.

In the original call routing design, I have two DNs, 8605895 and 8605896, that were routed across a gatekeeper controlled ICT. The route pattern would transform the DNs to 8603128 and 8603129 respectively. I wanted to stop using the ICT for these calls and instead, route them back out the PSTN over my 3845 gateway. To do this, I went into the route pattern for each number and changed the route list to point to my 3845 gateway. After making this change however, I found that the calls were still being routed over the intercluster trunk.

Next, I deleted the route patterns, and replaced them with translation patterns. I set up the translation patterns to dial 98603128 and 98603129 with the appropriate CSS to place local calls. Still, the calls were being routed across my ICT.

Next, I deleted the translation patterns, which completely removed the configuration for 8605895 and 8605896. In doing this, any calls to those DNs should follow my default routing for unassigned numbers in the 860xxxx range, which is a voicemail call handler that plays a message stating that the number is unassigned. Using Dialed-Number-Analyzer, I verified that the system agrees that the calls should route there. I also checked the route plan report and it shows there are no patterns that contain 8605895 or 8605896. However, any calls to those numbers are still being routed across my ICT.

Thinking that I have an issue with my route changes not being propagated from the publisher to the subscriber, I restarted the database layer monitor service on the publisher and subscriber, but that didn't help. I also rebooted the publisher, but that didn't help either. I haven't rebooted the subscriber because that has a greater impact on the users and will need to be scheduled.

Any thoughts as to what my issue could be will be greatly appreciated.

Robert

David Hailey · ‎04-03-2010

Rob,

A few years back, I worked on a 4.1(3) cluster that was fully built (1 Pub, 8 Subscribers, 2 TFTP). The cluster homed about 12,000 phones. One of the things we started to see as 4.1 grew older was that there were a number of little anomalies such as the one you describe. In some cases, DB replication was bad and we could trace to the route of the problem. A few cases; however, were much more curious so we opened a TAC case. In one of those cases, we had made changes to some DN's but the changes were not being reflected in behavior of the phones and call routing to those DN's. DB replication would display as healthy and etc. Long story short, the result of the TAC case was something we had assumed but wanted to verify with TAC. There are a few bugs along these lines documented for 4.1 as well (I apologize I don't have the details of those anymore) but in some instances, you may make a change to a component within CCM and, while everything seems healthy from a system level, one (or more Subscribers) is still working off a configuration that is loaded in the cached memory of the server. In these cases, the only way to ensure that the entire cluster was healthy was to do a scheduled, systematic reboot of all the servers in the cluster. It's always possible that you have something else at play; however, you may find that ultimately you need to simply reboot the cluster and consider it part of a maintenance window.

Hailey

Please rate helpful posts!