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?
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.
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: email@example.com Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...