This is actually a little complicated to try and explain without some visuals. We do know that the Device Level CSS is easier to configure for Single-Site deployments but becomes very complicated and config intensive for Multi-Site deployments. When using the combination of Line/Device (recommended for Multi-Site) a combination of the two CSS levels is used to provide Calling restrictions/routing. Here are some clips along with links to an "in-depth" look;
Classes of Service with the Device CSS - Single-site deployment
With Cisco Unified CallManager, you can define classes of service for IP Telephony users by combining partitions and device calling search spaces with external route patterns, as follows:
â¢Place external route patterns in partitions associated with the destinations they can call. While you could place all route patterns in a single partition, you can achieve more refined call restriction policies by associating the route patterns with partitions according to the destinations they can call. For example, if you place local and international route patterns in the same partition, then all users can reach both local and international destinations, which might not be desirable. Cisco recommends that you group route patterns in partitions according to the reachability policies for the various classes of service.
â¢Configure each calling search space to be able to reach only the partitions associated with its call restriction policy. For example, configure the local calling search space to point to the internal and local partitions, so that users assigned to this calling search space can place only internal and local calls.
â¢Assign these calling search spaces to the phones by configuring them on the Cisco Unified CallManager device pages. In this way, all lines configured on the device automatically receive the same class of service.
With this approach, the device calling search space performs two distinct logical functions:
The calling search space contains specific partitions, which in turn contain specific route patterns that point to specific PSTN gateways through route lists and their associated route groups.
â¢Class of service
By selectively including certain partitions and not others in the device calling search space, you effectively apply calling restrictions to certain groups of users.
As a consequence, when you apply this approach to a multisite deployment with centralized call processing, you have to replicate partitions and calling search spaces for each site because for each site you have to create classes of service and, at the same time, route the PSTN calls out of the local branch gateways
Classes of Service with the Line/Device Approach - Multi-Site Deployments
The traditional approach outlined in the preceding section can result in a large number of partitions and calling search spaces when applied to large multisite deployments with centralized call processing. This configuration is required because the device calling search space is used to determine both the path selection (which PSTN gateway to use for external calls) and the class of service.
It is possible to significantly decrease the total number of partitions and calling search spaces needed by dividing these two functions between the line calling search space and the device calling search space, in what is called the line/device approach.
Keeping in mind how the line calling search space and the device calling search space for each given IP phone are combined within Cisco Unified CallManager, and how the line calling search space partitions appear first in the resulting calling search space (see Calling Privileges in Cisco Unified CallManager), you can apply the following general rules to the line/device approach:
â¢Use the device calling search space to provide call routing information (for example, which gateway to select for PSTN calls).
â¢Use the line calling search space to provide class-of-service information (for example, which calls to allow).
When applied to centralized call processing deployments with large numbers of sites, the line/device approach drastically reduces the number of partitions and calling search spaces needed. For example, a deployment with 100 remote sites and 4 classes of service requires at least 401 partitions and 400 calling search spaces with the traditional approach but only 105 partitions and 104 calling search spaces with the line/device approach.
However, the line/device approach relies on the fact that you can globally identify the types of PSTN calls that must be restricted for certain classes of service (for example, local, long-distance, and international calls). If the national numbering plan of your country does not allow this global identification of the different types of calls, the efficiency of this approach (in terms of configuration savings) is lower than that indicated in the formulas above.
For example, in France the numbering plan is based on five area codes, from 01 to 05 (plus the 06 area code for cellular phones), followed by eight digits for the subscriber number. The key characteristic is that each PSTN destination is reached by dialing exactly the same number (for example, 01XXXXXXXX for Paris numbers, 04XXXXXXXX for Nice numbers, and so on), whether calling from the same local area or from a different area. This means that it is not possible to block access to long-distance calls with a single partition and a single route pattern because the concept of "long-distance call" changes depending on the area where the calling party is located. (For example, a call to 014455667788 is a local call if the caller is in Paris but a long-distance call is the caller is in Nice or Lyon.)
In such cases, you will have to configure additional sets of blocking calling search spaces and partitions, one for each area within which local and long distance calls are dialed the same way. In the example of France, you would have to defining five additional blocking calling search spaces and partitions, one for each area code.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.