Route Plan Questions

[jerake75]

I am in the middle of a new CCM implementation (replacing our old servers with new models, not restoring from backup, putting all info in fresh), and am curious as to how other people have set up their route plans using NANP (we're in the Chicago area). I want to revamp and redesign our route plan; it was one consultants set up for us years ago, and it's a bit less restrictive than I'd like. I would love to get other people's feedback on:

- Do you use route filters or explicit route patterns?
- How do you block international numbers that are within the NANP (Canada, Puerto Rico, etc.)?
- Do you make special provisions for in-state calling, i.e. do you have a separate partition/CSS for state area codes vs. local area codes?
- How many route patterns do you have in your system, if you're using explicit route patterns?

My bosses have accused me of overthinking this, but I think it's better to have restrictions in place then to get caught with a huge phone bill because 600 of our users discovered they can direct-dial Canada even though they only, theoretically, have access to U.S. long-distance numbers (long story).

Any feedback/info/insight would be greatly appreciated.

TMH

 

[pndscm]

I am a big supporter of Route Filters. You can get very restrictive using them if necessary or they can really simplify your route patterns. It's much easier in my opinion to use a Route Filter, define all your local area codes and putin 1 or 2 Route Patterns. Then put in another Route Filter with 'Area-Code-Exists' for your Long Distance calls. I put all the blocked numbers in a couple Route Filters also and have the 1-2 RP's block the calls. 1 Route Filter for all Toll Free and you use 1 RP for Toll Free instead of 5-6 explicit RP's.
A lot depends on your topology when you talk about numbers of RP's. If you have 1 location, you could probably have under 10 RP's with RF's, more locations, more RP's. With explicit RP's, the sky's the limit depending on the topolgy.

 

[jerake75]

Thanks for your input, pndscm -

I'm running into an issue where, since Canada uses NANP, and my long distance pattern (or the route filter for long distance you described above) is allowing calls to Canada to go through. The only way I've come up with to restrict these is to put in all the area codes for Canada and block them in my LD CSS-es.

We have three locations, with two PRI's per location, one for inbound and one for outbound. Right now, I have about 200 route patterns for all the different types of dialing (you wouldn't believe who and what these people call).

I've never been a big fan of route filters, because I could never get them specific enough to block or allow. I'm currently using explicit route patterns and no route filters. But, I will give them a shot, since we're in the Chicago area (literally right next to the city), we have many area codes plus they are adding more overlay area codes to the surrounding suburbs.

TMH

 

[ys211]

We use explicit route patterns for both Chicago and remote office in Atlanta. First, I inherited the route plan the way it is. Second, we are only restricting 900 calls, not LD and Intl.
I guess route filters would minimize our route plan but changing the current setup would be a very big job.

 

[jerake75]

That's what I'm running into, ys211...I also inherited our old route plan, and redoing it is turning into a very slow and painful nightmare...

I guess I'm going by the principal of, give access to only those who need access. And that can get extremely detailed very quickly.

You know they have overlays planned for 630, 708, and 815 (like 847 outside of Chicago), and another overlay for the city of Chicago (312 and 773)? What a mess.

 

[ys211]

I'm actually thinking of getting a very simple GW with FXS/FXO port so I can test dial plans in lab environment. It is very hard to test during normal hours without possible disruptions. That way there is enough time to test any changes.
Your bosses should have an office policy regarding phone usage. And you just implement the policy. Unless you are the person making that policy. It can get political and very ugly and I try to stay away from things like that.

 

[jerake75]

That's a good idea. I have a VG200 - ancient, but I can test out patterns and dial plans with my test CCM lab. It's got 4 FXO ports hooked up to 4 POTS lines, good enough for testing. In real life, however, we have a 6608 T1 PRI gateway, which acts completely different from a VG200...

Well, I'm not the person that supposed to be making this policy, but I end up making the decisions anyway. My bosses are, like you said, more interested in political gain than in creating actual policy, unless it has some sort of political advantage for them. I try to avoid it as much as possible.

TMH

 

[pndscm]

HHHHMMM. Your right. The only way to block Canada is to specifically block them. I'd still build them in a Route Filter and then Block them in a Route Pattern just like you do 900 numbers. It would take multiple Route Filters but it would be much easier than building each specific RP for all of them even with Wildcards or [ ]. I once worked on an account that wanted specific local and LD numbers blocked, around 500 of them. Took forever but it worked well and we only had to use 8-9 RP's to do it. Putting more than about 15 clauses in a RF just slows down the process waiting on CCM to respond. Made it much easier to find if there is a problem by using descriptive names for the RF.

 

[jerake75]

What I ended up doing, to block the Canadian area codes, was to create a separate partition, create one translation pattern per Canadian area code (23), throw them in that partition, and then add it to our LD CSSes. With translation patterns, I can just add the 9.1XXX and it immediately blocks it as soon as a user dials the area code...

I've never messed around too much with route filters, I will have to test them out more on my test lab...sounds like they might be more efficient in certain routing cases...

TMH

 

[ys211]

hey j, if you want to chat feel free to buzz me on yahoo id yshraybm. we are neighbors afterall.