i was thinking about Cisco suggested partition and CSS best practices that i want to summarize:
1. Create a Partition with all Blocked numbers (eg: Blocked_PT)
2. Create a Partition with all Allowed numbers (eg: Allowed_PT)
3. Create a CSS with the Blocked_PT partition first and the Allowed_PT after.
This is also useful for centralized multisite enviroment because the Blocked_PT is the same for all sites, while we must only create 1 Allowed_PT for each site (because it's linked to the site gateway or Route List).
That is ok, but now i need to do some considerations and questions about real life examples: the procedure i wrote is good for sites that have 1 CSS and all users with same calling privileges, but must be different for multi-CSS CUCM systems.
I want to submit an easy example:
1. I have 3 type of users with 3 calling privileges: local, long distance, mobile
4 Create 3 Route Patterns: 1st linked to local_PT, 2nd linked to long_distance_PT , 3rd linked to mobile_PT. All these patterns are blocked.
5. Create a Route Pattern that contains all dialable numbers (eg: 0.!) linked to allowed_PT. I route this pattern.
So, since i have different user privileges i need 3 CSS made like this: (tell me if my route plan is correct)
Local_CSS Long_distance_CSS Mobile_CSS
long_distance_PT mobile_PT allowed_PT
Explainig these CSS is simple: for example Local_CSS have partitions in an order that block long_distance and mobile numbers allowing only local calls. So Cisco best practices must be modified because i need more than 1 partition blocking. My considerations and questions are:
A. i must think about EVERY dialable blocked number (eg: service, call center, toll, etc...) and create a partition linked to a Route pattern
B. For low privileged users, i will have a CSS with a long list of blocked partitions: can be this too much processor intensive ? Or can be a configuration problem ? The CUCM must examine a long list of blocked patterns before allowing the call...
The way you are explaining it sounds like the best practice from CCM 4.1 and is no longer current. The SRND for UCM has been updated multiple times since then. The more modern design is summarized as all dialing restrictions are placed on the LINE CSS while all route-related patterns/partitions are placed on the DEVICE CSS. I won't go into all the design implications to that since it takes the SRND roughly 100 pages to document everything out.
Essentially you will create a CSS per restriction level (local, long distance, etc) and apply that to the directory number. You will also create a CSS with one or more partitions and include the necessary route patterns. This will be applied to the device. Until UCM 7 this typically resulted in a new device-level CSS per site; however, the Local Route Group can negate this in some designs. The LRG allows you to add a route group to the device pool and instruct route patterns/route lists to use the routes included in whatever the user's LRG is.
Read the dial plan chapter of the SRND. It's long but walks you through all of this.
thank you for reply. I will use the line/device approach putting a CSS that permits all destinations on devices and another CSS that blocks desidered patterns on the line. I have another question: with this method i can reduce the number of partitions. If i have, for example, a network with 1 main site and 100 remote sites i need:
- 1 partition for all internal IP phones
- 100 partitions (1 for each site). Then i associate them with the Route Patterns containing the Gateway/route list specific for each site.
- N partitions for Class of Services
My question is: can i use the "Standard Local Group" feature to reduce the 100 site partitions to 1 (using 1 Device pool for each site containing the reference to the local Voice Gateway) ?
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 ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...