![]() So in this example, if a user of this phone picks up the line and dials an international number, the blocking translation pattern will be matched first since its partition is in the line-level CSS. The phone-level CSS contains partitions that allow PSTN calls to be routed to the local gateway or trunk. Next, the line-level CSS of a user’s phone has the CSS that contains the blocking partition for international calls. Notice the “Block this pattern” radio button is selected. Translation Pattern is created to block international calls. The configuration would look like the following: In this example, the desired effect is for international calls to be blocked while all other calls should be routed. Since the recommendation is to block calls at the line level, this is usually accomplished by creating translation patterns to match the various call types and to specify that if a call matches the translation pattern, it should be blocked instead of routed. ![]() If neither CSS contains the called partition, then the call will fail. If the partition of the called number is not in the line-level CSS, then the system will check the phone-level CSS. When a CSS is applied at both the line and phone level, the CUCM will check the call against the line-level CSS first. ![]() In order to properly preserve a user’s call permissions in a mobile environment, the recommended approach is to apply a restrictive (blocking) CSS at the line level (which follows the user), while applying a permissive CSS at the physical phone level, simply pointing all calls to the appropriate gateway or trunk. Therefore, it is possible to have different permission sets as you log into different phones, as the phone-level CSS may differ by phone. But when a user logs into a phone, the profile CSS is applied, by the system, to the line level while preserving the physical phone’s CSS at the phone level. When configuring Extension Mobility, you configure a CSS as part of the user’s profile parameters. If your organization has deployed Extension Mobility or Device Mobility, then applying the CSS at the phone level will give the users unexpected call results. However, this approach has some limitations. The goal, of course, is to specify what partitions are allowed to be called. Quite often, an administrator will pick the phone-level CSS and configure it there so that it applies to all calls made from all lines. So the questions often become: Where should you apply the CSS, and why are there two places to apply it? One approach is to simply pick one of the parameters and apply the permissions there. As you explore the parameters of the phone and its associated lines, you will see that the CSS can be applied at the phone level or at the line level. The point of confusion focuses on applying the CSS to the phone to define what calls an end user can make. A CSS can be assigned to anything that can originate a call, such as a line, phone, gateway, trunk or even a translation pattern. A CSS can contain one or more partitions. The CSS is effectively the “key ring” that contains call permissions. No one can call that number unless they have a CSS that contains that partition. Applying a partition to a number effectively locks access to that number. In CUCM, call permissions are defined by using the constructs of partition and CSS. One of the areas I am sometimes asked about is the use of Calling Search Space (CSS) and where to best configure it. For those of you who are learning to configure Cisco Unified Communications Manager (CUCM), some aspects of the configuration might seem ambiguous or confusing.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |