Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Bronze

Call Manager 4.1 Route Pattern Issue

I'm running CCM 4.1, and I was working on eliminating post dial delay using route patterns to match numbers.

Currently the setup uses 9.@ with route filters, but isn't working the way it is intended, some outgoing numbers connect fine, others wait for the t302 timer before dialing.

Yesterday I threw 2 new route patterns in:

9.[2-9][02-9]xxxxx

9.[2-9]x[02-9]xxxx

and it did not help the issue any.

So I removed the route patterns and reset the route list. When I removed those 2 route patterns I had put in there people were no longer to make outgoing local calls.

How is it that the system works fine before those route patterns, but once those patterns were removed the system no longer works. I had to put those route patterns back in in order to resolve the calling issue.

Also on the post dial-delay if I dial a number, it can take up to 10 seconds (thats what the 302 timer is set for) to connect the call, but if I hit redial on the same number it connects immediately.

Thanks for any help,

Craig

14 REPLIES

Re: Call Manager 4.1 Route Pattern Issue

Craig,

I would double check the following things:

a. No numbers (route points, DNs, call park etc) start with a 9. 9 should only be on route patterns and/or translation patterns.

b. Make sure all translation patterns if starting with a 9 has outside dial tone check box checked.

c. Make sure all route patterns starting with a 9 has outside dial tone checked.

d. go to route plan report and see how many patterns start with a 9 and make sure they all are uniform (as in not variable length). 9.@ is a macro that expands or matches various patterns like 911, local, LD, International etc (NANP).

HTH

Sankar.

Bronze

Re: Call Manager 4.1 Route Pattern Issue

Sankar,

Very good call on checking for DN's that start with 9, I hadn't considered that, and sure enough I have some. So that is at least a good place for me to start.

Sometimes I'm surprised this network works at all, when I first got here they had over 1800 topology changes over the course of 13 minutes, that's almost 3 topology changes every second.

Any idea why inputting the above route plans, then removing the above route plans would cause my external dialing to completely stop working?

Re: Call Manager 4.1 Route Pattern Issue

When you deleted the route patterns that you added earlier, did you try various numbers to see if outbound calls completely was broken ? (Local, LD, 911, International numbers).

I suspect an incorrect Route filter configuration in the first place.

Bronze

Re: Call Manager 4.1 Route Pattern Issue

We could call LD, I'm assuming Intl and 911 worked as well (we have to have prior coordination to test 911), and if we dialed 10 digit local it worked fine, but 7 digit local dialing did not work.

Surprisingly, with just 1 pattern:

9.[2-9]x[02-9]xxxx

if I dialed 310-1234, it would not work, even though it matches that pattern, when I added the second back to the route pattern:

9.[2-9][02-9]xxxxx

310-1234 would then work, again I'm bewildered.

The route patterns they have setup are attached, you can see the 2 patterns I added, and here is the setup for the HQ Local Calling:

Outside Dial tone is unchecked

Route filter:

Area Code DOES NOT EXIST

Office Code == XXX

I used the same partition and route list for the two that I created, the 2 I created obviously I didn't apply the route filter to. They all have the outside dial tone unchecked.

Thanks again Sankar

New Member

Re: Call Manager 4.1 Route Pattern Issue

I've experienced the same behavior on a 4.1(3) cluster I have. I had a pre-existing route pattern that was working. I made a modifaciton in hopes of changing it and it quit working. I then changed it back to the original, previously working config and it still didn't work. A good old fashioned Windows reboot fixed it.

Bronze

Re: Call Manager 4.1 Route Pattern Issue

That's odd, I wonder what would cause that, there's no way I'm going to reboot my cluster :) So it will have to stay that way until we migrate to 6.1 this summer :) Hopefully I'll have it hashed out and cleaned up before we upgrade though. If I get resolution I'll post my update.

Thanks again everyone.

Craig

New Member

Re: Call Manager 4.1 Route Pattern Issue

Are you on the most current service release? 4.1(3)SR7. If not, it always helps to stay up to date. You could plan a maintanance window, and the SR requires a reboot, so you could kill two birds with one stone.

Bronze

Re: Call Manager 4.1 Route Pattern Issue

Actually were on SR5b, that's not a bad idea. Thanks.

Bronze

Re: Call Manager 4.1 Route Pattern Issue

As for the route plan report, I'm assuming you are only talking about the ones that begin with "9" and not the "9."

I have all kinds of variable lengths in there, I have 94 numbers taht begin with "9", that includes DN's, translation patterns, and 3 911 route patterns.

They range from 90010 to 913xxxx to 913xxxxxxx to 913xxxxxxxxxx (i have no idea what they were doing / thinking with those 3 DN's)

Translation patterns are also variable with no outside dial tone checked.

Re: Call Manager 4.1 Route Pattern Issue

You need to get rid of DNs that start with 9. If this canno tbe changed for any reason, you should consider using 8 or 7 as the trunk access code

Bronze

Re: Call Manager 4.1 Route Pattern Issue

Sankar,

Thanks I really appreciate your help and patience, you've given me another good place to start attempting to clean up one of the many messes in this network.

Thanks again,

Craig

Re: Call Manager 4.1 Route Pattern Issue

Craig,

I am glad that helps

Sankar.

Re: Call Manager 4.1 Route Pattern Issue

Craig,

I am glad that helps. Thanks for the ratings

Re: Call Manager 4.1 Route Pattern Issue

Craig,

Also on rebooting the cluster, its a good practice to reboot servers from time to time on a maintenance window.

330
Views
11
Helpful
14
Replies
CreatePlease login to create content