# Policy Routing Design Concepts

Cisco Callmanager provides a native API called CURRI (Cisco Unified Real-Time Reporting Interface) that allows you to inspect and control calls in real-time. This guide will help you understand how to design your policies to work with the CURRI API.

# Key Concept - Design for Inbound Matching

Cisco CURRI API / Extended Call Control Profile only triggers an on inbound request towards a Route Pattern, Translation pattern or Directory Number. Your actual call direction might be inbound or outbound from your perspective, but for the CURRI API to trigger, the matched called route or translation pattern or directory number must have an Extended Call Control Profile profile assigned.

# Inbound Matching Examples

The following examples show how to design your policies to work with Call Telemetry and the CURRI API.

Illustration of how CURRI API inspects calls

# Example 1: Inspecting Inbound Calls via DID Patterns

Apply your CURRI / ECC Profile on the inbound translation patterns from CUBEs to inspect all inbound DID patterns.

Screenshot showing inbound calls inspected as they pass through DID patterns

# Example 2: Inspecting Inbound Calls on a Phone Extension

You can apply an ECC profile on one or all your phones. All calls received on phones with a valid profile will be inspected. You can use Bulk Tools like BAT for applying profiles in bulk.

Screenshot of inspection shown on a phone extension

# Example 3: Inspecting on Translation or Route Patterns

You can also apply a policy on patterns to inspect outbound calls,like 911 patterns, or Outbound Route Patterns for compliance reasons, or alerting. Only calls that pass inbound to a pattern will be inspected.

Example showing outbound call inspection

← Introduction to Call Policies Your First Policy Integration →