![]() ![]() 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. Note: This can only block unwanted calls based on DNIS information and not on the ANI information.įor more information, refer to Route Pattern Configuration.For those of you who are learning to configure Cisco Unified Communications Manager (CUCM), some aspects of the configuration might seem ambiguous or confusing. In this case, the "knob" that is used to block the call is the Route or Block this pattern option. To do this, the DNIS or called number can be specified in a route pattern, then applied to the gateway. To block calls in the same manner at the Cisco CallManager level, use translation patterns. Note: This method of blocking calls can only be accomplished based on the DNIS information (called party number) and not on the ANI (calling party number) information. This sends the call nowhere, and the calling party receives a reorder tone. Give the x-lation pattern a CSS that has access to NOTHING. Then, the gateway in Cisco CallManager must be configured to have a Content Services Switch (CSS) with access to this x-lation pattern first, based on the x-lation pattern partition. This is accomplished through translation patterns in the Cisco CallManager configuration.Īn x-lation pattern in Cisco CallManager must be created to match the inbound DNIS information (called party number). If a Media Gateway Control Protocol (MGCP) gateway (controlled by Cisco CallManager) is used, the only way to block unwanted calls is based on the DNIS information. If an H.323 gateway is used, incoming calls can be blocked based on ANI and DNIS information through translation rules on the gateway configuration.įor more information on how to block incoming calls with an H.323 gateway, refer to How to block incoming calls based on calling number and called number information with a Cisco IOS H.323 gateway. Then, make sure to consider any limitations of the gateway being used. To determine the appropriate procedure, first determine whether it is desirable to block unwanted calls based on Automatic Number Identifier (ANI), or Dialed Number Identification Service (DNIS) information, or both. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |