# Translating the Called Destination Number
# Feature Overview
Policy rule with Called Number Modifiers are very similar to Cisco Callmanager "Translation Patterns". These rules can change the called number before the call is routed to it's original destination.
You can build static rules to change the called number, or use Apps to change the called number dynamically.
Or you can use this to change the called number to a new number, based on dynamic data, like a lookup to a CRM or Spam Robocall Score API.
# Feature Requirements
- Call Telemetry 0.7.0 or later
- Call Telemetry Community or Higher License
- Callmanager 8.5 with CURRI Integration to Call Telemetry
- Configured Active Call Policy Inspection - A route pattern, translation pattern, or phone extension must be enabled for Call Telemetry Policy inspection. If Call Telemetry is not inspecting the call, it will not be able to see the ip phone call history.
- Note that a new CSS will used to route the new call - the CSS of the CURRI / ECC profile will be used to route the new call.
# Why not just use standard Cisco Translation and Transformation rules?
Rules can reroute based on Called Party or Calling Party matches, without changing any Partitions or Calling Search Spaces, just by using a policy on the pattern or device. That's not possible with standard Callmanager Translation Patterns.
Aside from easy of configuration, and better matching, you can also leverage APIs to change call data or route differently based on dynamic data gathered in realtime.
Callmanager will query Call Telelmetry for policy changes via CURRI. Calls are matched by the specific match. If nothing is matched, Callmanager will continue with the original call data.
# Static Destinations - Route the call to a new destination
You can use this feature to route calls to a new destination based on a match. This is similar to a Callmanager Translation Pattern, but without the need to change any partitions or calling search spaces.
# Translate New Called Number by static entry
Enter a new number in this field, and Call Telemetry will request that the call be routed to this new number.
Here is an example routing a call to a new destination of 1012 within a rule.
# Dynamic Destinations - Route the call to a new destination based on a lookup
You can use this feature to route calls to a new destination based on a lookup to a CRM or other API. This is similar to a Callmanager Translation Pattern, but without the need to change any partitions or calling search spaces.
Some examples of dynamic translations might be:
- On-call scheduling routing via API to specific team members
- CRM lookup for routing to team members
# Modifiying the New Called Number based on a lookup
Enter a valid workflow variable in this field, and Call Telemetry will request that the call be routed to this new number based on the variable data.
This is an example of using workflow data to change caller ID and called number in a rule.
