Category Archives: CCVP

Blocking Calls at the Gateway by Caller ID

Posted on by
1

Sometimes administrators have to block calls harassing, scam, or other undesirable calls. In newer versions of CUCM, this can be done in CUCM, or it can be done on an h.323 or SIP gateway.

Which should you use? There are good reasons to use both. Blocking on CUCM centralizes call routing, so you don’t need to touch gateways, and can be configured so that placing a number in once blocks it at all gateways. Blocking it at the gateway can be easier to implement, and stops the call at the ingress, so that no internal resources are ever used. Properly configured, blocking at the gateway will maintain protection in SRST, as well. So either way has benefits, use the one that fits into the existing environment best.

Blocking on the gateway uses translation profiles, which can be applied to the ingress port, and the inbound or outbound dial peers. Placing the blocking patterns on the port stops them right away, but may require placement on multiple ports. Continue reading →

Time of Day Routing in CUCM

Posted on by
Reply

Time of Day routing allows for calls to be treated differently based on the time of day and day of week. This allows for things like automatically rerouting calls to a different destination when the company is closed, not allowing PSTN calls after hours, or requiring a Forced Authorization Code outside of business hours. Another real-world example I have worked with is patient rooms in hospitals, which should not receive outside calls at night.

CUCM uses the standard Partitions and Calling Search Spaces, with the addition of a Time Schedule that specifies when the Partitions will be active, to perform time of day routing. Outside the time schedule, the partition is effectively invisible to call routing. Appropriate ordering of in a CSS allows the calls to be routed to an alternate number when the partition is not available.

An important consideration in designing the Partitions and CSSs is whether you want calls to be able to route to the phone off hours at all. For instance, with the patient room example, should internal numbers be able to call the rooms, and only outside calls be blocked? We will look at two examples, one that allows for some calls to go through, one that does not.

Continue reading →

Blocking Calls by Caller ID in CUCM

Posted on by
1

PBX administrators are sometimes called on to block calls coming from specific numbers, such as telemarketers or other harassing calls.

Until Communications Manager 8.x, the only way to block incoming calls based on the calling number was to use an H.323 or SIP gateway, and use translation rules on the gateway to reject the number. While there are still good reasons to do this, starting in 8.0, UCM has the ability to block or reroute based on calling number via the “Route Next Hop By Calling Party Number” feature on translation patterns.

Depending on the circumstances, blocking at the gateway may still be your best option, but by configuring it in UCM, you can apply the same blocked numbers to multiple gateways.

The rest of this post, we will build an example of the configuration described in this Technote.

We are assuming a basic setup with all internal phones in a partition called “Internal_DNs_PT,” a gateway with a CSS “Inbound_Routes_CSS” that searches for translations in a partition called “Inbound_Routes_PT”

Call flow for inbound calls:

  • PRI to MGCP Gateway
  • Receiving 10 digits from Telco
  • Translation pattern in “Inbound_Routes_PT” Translates 123555XXXX to XXXX
  • CSS “Internal_Routes_CSS” finds 4 Digit DNs in the Internal_DNs_PT.

Goal: Block all inbound calls from (890)555-1212.

Step 1: Create a Partition named “Blocked_Numbers_PT” and CSS named “Block_By_Calling_CSS”.

Step 2: Create a Translation Pattern in “Blocked_Numbers_PT,” with a pattern of “!” to match all calls, and a CSS that includes Internal_DNs_PT. This allows any calls not specifically blocked to be routed. No actual number translations should be performed.

Step 3: Modify the translation pattern in Inbound_Routes_PT to use the Block_By_Calling_CSS, and select the option to “Route Next Hop by Calling Party Number.”

xlate-for-blockingAt this point, a call comes in, 10 digits are presented from the Telco, the translation pattern in Inbound_Routes_PT strips the initial digits to leave the 4 digit extension. UCM then looks in Blocked_Numbers_PT, finds the ! pattern, which does not make any changes, but searches Internal_DNs_PT for the extension, and passes the call on.

Step 4: Create translation patterns in Blocked_Numbers_PT with the number to be blocked as the pattern, remembering to include any access codes, etc. that the number would have at that point, and the Route Option set to Block This Pattern with the error you want.

blocking-xlate

Alternatively, you could translate the called number to a security officer or something similar. I personally want to route one to Unity Connection or a CCX application playing this recording, but I have never gotten the chance to.

Once you have this configured, you can test it by blocking a number you have control over, like your cell phone, and making sure it is blocked.

If you want to only block calls to a specific number, leave the 123555XXXX to XXXX translation pattern using a CSS searching the Internal_DNs_PT, and then create more specific translations that route through the blocking configuration.

For instance, creating a translation pattern for 1235550987 to XXXX using Block_By_Calling_CSS, and the “Route Next Hop by Calling Party Number” option will only block calls to 1235550987 from the numbers in Blocked_Numbers_PT, but allow those numbers to call other DNs. An instance where you might use this if a FAX machine keeps calling a voice line, and you want to prevent those calls while still allowing FAXs to be sent to legitimate FAX machines.

Interested in learning more about CUCM? Check out our other posts here.

Assigning permissions in UCM

Posted on by
1

Cisco Unified Communications Manager allows for very granular assignment of permissions, using the concept of roles and groups to assign specific permissions to users. A role is a list of permissions around a function, and a group is a list of roles, which can then be assigned to a user.

Permissions are assigned to Roles. An example of a role might be “Backup Administrator,” with permissions like “DRF Restore Warning Page,” “DRF Schedule Page,” “DRF Show Dependency Page,” and “DRF Show Status Page.” A role is specific to an application group, such as Cisco Unified Reporting, Cisco Call Manager Serviceability, or Cisco Call Manager Administration.

Permissions can include Read and Update, so a user could be given rights to view configuration elements, but not update them. This could be useful for auditing purposes, or for users that may need to verify a configuration, but not change it, such as a helpdesk user.

An Access Control Group contains a list of Roles. An Access Control Group might be something like “OS Administrators” which could include Roles like “Backup Administrator,” “LDAP Administrator,” etc. While a Role is specific to an Application, an Access Control Group can contain Roles from different Applications to create a comprehensive list of permissions, while limiting the number of groups a user must be assigned to to properly do their job.

Users are assigned to groups either in End Users configuration or in Access Control Group Configuration. Configuring in End User configuration is usually more efficient at assigning multiple groups to a user, while Access Control Group Configuration is going to be better for assigning multiple users to a single group.

Although you can see roles assigned to an end user in the End User Configuration Page, roles are not assigned directly to users. Users are assigned to groups, which contain roles, and the roles contain specific permissions within an application.

Configuration example after the fold.

Continue reading →