Call Manager 4.1 Route Pattern Issue

Unanswered Question
May 28th, 2008

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.7 (3 ratings)
Loading.
thisisshanky Wed, 05/28/2008 - 06:08

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.

xcz504d1114 Wed, 05/28/2008 - 06:20

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?

thisisshanky Wed, 05/28/2008 - 06:23

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.

xcz504d1114 Wed, 05/28/2008 - 06:42

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

Attachment: 
evanrichards Wed, 05/28/2008 - 13:37

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.

xcz504d1114 Thu, 05/29/2008 - 05:13

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

evanrichards Thu, 05/29/2008 - 07:22

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.

xcz504d1114 Wed, 05/28/2008 - 07:04

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.

thisisshanky Wed, 05/28/2008 - 07:34

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

xcz504d1114 Wed, 05/28/2008 - 07:53

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

thisisshanky Thu, 05/29/2008 - 07:40

Craig,

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

Actions

This Discussion