Help with Route Pattern please

[Midstream]

I have a Cisco Call Manager 6 with h.323 trunks to an Avaya CM4. The PSTN comes into the Cisco and feeds the Avaya where needed. I've got a block of DID's that I had pointed at the Avaya using a route pattern with some wild cards. 63XX pointed to the gateway for the Avaya CLAN which controlled the signaling group. I deleted that route pattern and replaced it with the individual entries for the respective DID numbers now that I need some DID's to remain within the Cisco. My problem is that the entire range still routes as if the route pattern with the wild cards is in place. I've deleted it, it's no longer there.

I'm new to Cisco with 20 years on the Avaya side so my UDP tables are easy to manage. I'm trying to mentally compare these route patterns to UDP tables. I'm not having a lot of luck.

Do I have to reset something within Cisco to make this change permanent?

Thanks,

Phil

 

[whykap]

So the DID's that are supposed to stay local to the cucm are configured to point to active devices but still routing to the AVAYA? I have never seen that so I would say it is a configuration issue.
Either your RP are not correct or your calling search spaces are messed up causing the calls to somehow route to AVAYA.

What happens if you entirely delete all RP pointing to the AVAYA?
Do they work then? I would start there.

What is the exact version of 6 you are on?

 

[Silverblade]

I think you should take a look at you calling search spaces. Since the call manager always takes the best match. So if a wildcard exists and you have a complete defined number it should take de complete defined number as best result.

So there for it should be something in the calling search space that makes the call manager not to look at the complete define number

 

[Midstream]

We're running 6.1.1.2000-3

The Calling Search Space configurations were not administered for the addition of these new DID numbers. This block of DID's was just activated. The only configuration change made was to the RP.

On my Avaya system I can run a software trace to see what's going on. I'm trying to find and learn a similar tool on the Cisco. I've downloaded the Real Time Monitoring Tool and am pecking away at that.

Here's an example of what I can get out of my Communication Manager and I'm looking for something similar in my Cisco:

list trace tac 710

LIST TRACE

time data

08:20:06 Calling party trunk-group 10 member 1 cid 0x2d61
08:20:06 Calling Number & Name NNNXXX7912 NO-CPName
08:20:06 active trunk-group 10 member 1 cid 0x2d61
08:20:06 dial 1860
08:20:06 term announcement 4101 cid 0x2d61
08:20:06 active announcement 4101 cid 0x2d61
08:20:06 hear annc board 01A11 ext 4101 cid 0x2d61
08:20:06 G729 ssff ps:20 rn:20/1 172.16.10.1:17624 192.168.6.6:63548
08:20:06 xoip: fax:Relay modemT tty:US 192.168.6.6:63548 uid:0x50020
08:20:10 idle trunk-group 10 member 1 cid 0x2d61
08:20:38 Calling party trunk-group 10 member 1 cid 0x2d62

This shows my test call coming across the h.323 trunks from the Cisco.

 

[Midstream]

Deleted all the RP's in the Cisco that point 63XX range at Avaya. No change in behavior. Even deleted the specific RP for my DID number [1851] and my calls still come through to my Avaya phone. I don't relish the thought of this, but I think I'm going to bounce the system later on tonight to reset it.

 

[whykap]

Go to route plan report and look for all unallocated/unassigned DN's. If any of your 63XX are stil there delete them and test again.

 

[Midstream]

Already tried that. There is nothing in there for the 63XX range. I tried putting in unique entries for all the individual numbers that I want to route to Avaya as Route Patterns and I tried putting in a Translation Pattern to have one number [6319] forward to a local extension on the Cisco. I got fed up and deleted every one of the RP's for 6300-6318. When I look at the Route Plan Report the only 6XXX range number that shows up is 6319.

 

[whykap]

Just to make sure we are on the same page. Searching in the route plan report only shows you active DN's. You have to specifically search for unassigned. It sounds like you did but just making sure.
next step would to ensure your publisher and subscriber databases synchronized? It sounds like they might be out of sync. You would verify that from the CLI on each server on the cluster.

 

[Midstream]

I didn't search the unassigned DN's until you mentioned it. Thanks for pointing that out. Now that that's been eliminated I'd like to verify the sync via the CLI. I can log in to 172.16.10.1 but I can't determine the proper syntax to check the synchronization.

Is it too much to ask for a nudge in the right direction, please?

 

[whykap]

So it's still not working?
There's three different ways to verify replication as the link below describes but I like the CLI as it checks directly on the database level and it is always accurate.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/trouble/7_1_2/tbsystem.html#wp1172876

 

[Midstream]

show perf query" wasn't an option, so I used the Unified Reporting function and got this:

Unified CM Database Status Shows if replication is good or bad.
RTMT Counter Information
All servers do not have a replication count of 392.
All servers have a good replication status.

 

[whykap]

You must be typing it wrong then. it is case sensitive and needs to be exactly as the doc shows.
it doesn't sould like you have a replication issue so you should be good to go now.

 

[soleman52]

rockspop here is a url from cisco about did's it might help

http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00801c43f6.shtml