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

9.@ w/ Route Filters

I would love someone from Cisco to respond to this post.

I heard some interesting information from a TAC Engineer. He does not recommended using the 9.@ route pattern. His reasons were, when using the 9.@ route pattern it adds 300 or more entries (clauses or whatever you would like to call them) to the sql database per route pattern. For this very reason when making changes to 9.@ route patterns, sql completely rebuilds the external call routing table and this can disrupt call processing for up to 45 seconds (depending on the number of 9.@ route patterns). I use 9.@ route patterns with route filters on a consistent basis. Has anyone experienced problems with this? If this is the case, why give the option?

Cisco Employee

Re: 9.@ w/ Route Filters

The recommendation sounds like a case of throwing the baby out with the bathwater, but the concerns are not unfounded.

When Cisco CallManager registers an @ pattern, it does perform a "macro expansion" of the @ pattern to about 300 individual patterns. This work occurs on the main thread, so it does run the risk of suspending the router thread.

For a single @ pattern, this isn't a big deal... the break is very short. Where this really bites you is if you configure something like a route list that has hundreds of @ patterns. Sometimes, customers do this in order to provide for authentication codes... a pattern like 9.123456@ will require users to dial a long prefix string before the call routes... giving each user a specific code makes for a large number of @ patterns.

The problem that occurs is that when you change the route list, ALL patterns associated with the route list get reregistered at once. Now a short real-time break becomes a long real-time break--200 @ patterns times 300 individually expanded patterns requires 60,000 pattern insertions--that can starve the watchdog thread. Having a large number of @ translation patterns could cause the same issue.

What is the limit? You're probably okay with around 100 or so @ patterns associated with any single route list, but you'll be pushing it if you go much past that.

The upshot is that the @ pattern is, in itself, a fine thing but that you can take a good thing too far. CallManager has very, very few 'hard' limits encoded into it. This is a good thing, since customers are always finding ways to use CallManager in ways the designers didn't expect, but it can be a bad thing, since it makes it very very difficult for technical marketing to provide information about what safe deployable limits are.

Furthermore, future releases of CallManager are attempting to address these performance issues with the @ pattern. In the meantime, if the @ pattern makes your system administration easier, don't shy away from it on account of its scalability issues if your particular configuration doesn't test the limits.

CreatePlease to create content