Introduction to Call Policies

In this section, you'll learn the concepts of Call Policies, Rules, and how to apply them to your Cisco Callmanager environment.

How does Call Telemetry work with Cisco Callmanager?

Call Telemetry uses the Cisco CURRI API or CUBE XCC to servce as a call policy engine for Cisco Callmanager, or Cisco IOS CUBE routers.

CURRI API and Call Telemetry

Cisco's Callmanager CURRI API is a stateful protocol which queries a third party policy engine that can be used to influence call routing ( similar to translation or routing patterns) or inject greetings.

A keepalive signal is maintained to the API to indicate if the policy server is online. If the heartbeat stops or there's an incorrect response, calls go back to the default "Call Treatment on Failures" plan in the CURRI / ECC Profile. This is usually set as "Allow" by most customers to fallback to a permit action.

There is never a single point of failure to stop callflow, as Cisco Callmanager CURRI API will fail "open" in any unresponsive scenario. If the Call Telemetry Server is not available, calls will continue to route as normal. If the server becomes available again, it will resume policy enforcement.

Call Telemetry and Cisco IOS CUBE XCC

For deployments at scale, or even those without Callmanager, Cisco IOS CUBE XCC is used. XCC is another Cisco API for IOS Routers that provides a similar call routing control - with keepalives, and failover to continue callflow. (Cisco XCC Integration)[../policies/cube-xcc-integration] covers this more more detail. This guide will continue to use CURRI as our integration point, but concepts are the same for CUBE XCC..

What is a Call Telemetry Policy

A Call Policy is a collection of rules that can be applied to a call event. In Cisco Callmanager terms, it is called an External Call Control Profile. The first and most specific rule that matches is applied. Rules can be used to block calls, permit calls, or modify caller name or number. Rules can also be used to trigger instant alerts, webhooks to other APIs.

Check out our Design guide for Call Policies to learn how how Cisco Callmanager patterns interact with the Call Telemetry CURRI API.

Policy Rules

Policy Rules are the building blocks of a Call Policy. A rule is a trigger that results in a required policy action, and optionally any call modifiers, alerts and apps associated.

Let's dive a little deeper and talk about this process.

Policy Actions - Permit or Block a Call

These are basic call actions of permit or deny / block callers.

If you are ready to jump straight into blocking calls, check out our Call Blocking with Call Telemetry Guide section.

Rule Pattern Matching

The rule trigger pattern that best matches the longest prefix is applied. The rule action can also be used to influence call routing - like modifying the caller ID or name based on a query to a CRM, or querying the reputation score for a caller to block or redirect them. Further, a rule can also triggering alerts, webhooks, or other Apps/Integrations.

Rule features are covered in more detal in each section below:

Rule Triggers - Matching a Rule

Triggers define the call patterns that will match the rule. Like Cisco Callmanager, the most specific rule will match. Rules are processed in an order:

• Global Block List
• Call Block Rules
• Call Permit Rules

Call Modifiers - Greetings or Different Destinations

Modifiers can change the callflow, or modify the caller ID or name before it shows up to a Cisco IP Phone. More importantly, they can query other systems, like a CRM API, to change the caller ID or name in realtime. They are similar in concept to Callmanager Translation Rules and Transformation Rules.

Alerts - Notifications for Rules

You can get instant alerts for calls. Alerts can send a custom template message to SMS, Email, or Webex Teams messages. You can build a custom alert and see a preview of the alert based on the previous call test.

Apps - API Integrations

Apps are integrations that query or send data to APIs, or a generic webhook App. You can even use Apps to lookup a name from a database or CRM API and change the caller ID of the call. Apps are used to share data with CRMs and other APIs, query APIs to influence callflow to permit, redirect, or block the call, or modify the caller ID or name to display on Cisco IP Phones.

Greetings - Play a wav file before connecting

Greetings can be used to play a Cisco Callmanager greeting or announcement to the caller before the call is connected. For example, you might want to inject a greeting that says "Your call may be monitored or recorded for quality assurance purposes".

Watch Triggers - Monitoring for Suspcious Call Activity

Watch Triggers are used to monitor call activity and add numbers to a watch list. When a trigger condition is met, the calling number is added to the target Watch List.

Learn More about Watch Lists and Triggers