Cisco ANI Based Call Routing - Part II

This two-part training series focuses on Cisco Unified Communications call routing using ANI and DNIS. In this second part, we work through a CCIE-style challenge and use CUCM Translation Patterns to make routing decisions based on the calling and called numbers.

The goal is to show how Cisco Unified Communications Manager can apply different routing behavior depending on who is calling, which number was dialed, and what call-routing policy is required between sites.

Understanding ANI and DNIS

ANI and DNIS are two important concepts in voice call routing.

• ANI refers to the calling number, or the identity of the endpoint that originates the call.
• DNIS refers to the called number, or the destination number that the caller dials.

In CUCM, call-routing decisions are normally based on the called number, but the calling number can also be used as part of the routing logic.

This makes it possible to create scenarios where two users dial the same destination but receive different routing behavior based on their ANI.

Lab Scenario

In this lab, two Cisco Unified Communications Manager environments are connected through a trunk between Site A and Site B.

Users at each site include different roles such as staff, managers, and secretaries. The routing requirement is not based only on the destination number. The result of the call also depends on the identity of the caller.

For example, one user may be allowed to reach a destination directly, while another caller dialing the same number may be redirected to a different extension such as a secretary.

This type of requirement is useful for understanding advanced CUCM digit manipulation and call-routing behavior.

Using CUCM Translation Patterns

A Translation Pattern in Cisco Unified Communications Manager can be used to match dialed digits and then modify the calling number, called number, or routing behavior before the call continues through the dial plan.

Translation Patterns can be combined with partitions and calling search spaces to control which devices can access a specific routing rule.

A typical configuration can include:

• A translation pattern matching the destination number
• A partition assigned to the translation pattern
• A calling search space controlling access to the pattern
• Calling-party transformation settings
• Called-party transformation settings
• A route pattern, trunk, or internal directory number used after translation

Calling and Called Party Transformations

CUCM provides separate mechanisms for modifying the calling and called numbers.

The calling party number identifies the originator of the call, while the called party number represents the destination.

During a call-routing workflow, CUCM can manipulate either value before sending the call to the next routing component.

For example, a translation pattern can transform the called number so that a manager's call is routed directly to another manager, while another user's call can be redirected to a secretary or alternate extension.

ANI-Based Routing Logic

ANI-based routing becomes useful when the same destination must behave differently depending on the calling number.

The basic logic is:

1. A user originates a call.
2. CUCM receives the calling number and called number.
3. The dial plan matches the appropriate translation or routing pattern.
4. The configured calling-search-space and partition relationship determines which routing rule can be used.
5. Digit manipulation is applied where required.
6. The call is sent to the appropriate destination or trunk.

By combining these mechanisms, CUCM can implement routing policies that are more flexible than simple destination-based routing.

Verification and Troubleshooting

When testing ANI-based call routing, verify both the calling and called numbers at every important stage of the call.

Useful checks include:

• Confirm the calling number presented by the originating device.
• Verify the called digits before translation.
• Check the partition assigned to the Translation Pattern.
• Verify the calling search space applied to the calling device or line.
• Confirm any calling-party or called-party transformations.
• Verify the selected route pattern or trunk.
• Test the same destination from multiple calling numbers.
• Use CUCM traces when the actual routing decision does not match the expected behavior.

Testing the same called number from different source extensions is especially important in an ANI-based routing design because the result should change according to the caller.

Video Demonstration

The video below demonstrates the ANI-based call-routing scenario and the related Translation Pattern configuration in Cisco Unified Communications Manager.

Conclusion

ANI-based call routing provides a way to build more advanced Cisco Unified Communications dial plans by considering both the identity of the caller and the destination being dialed.

By combining ANI, DNIS, Translation Patterns, partitions, calling search spaces, and digit manipulation, CUCM can implement routing policies where the same destination behaves differently for different callers.

This lab is designed to help you understand that call routing in CUCM is not limited to simple destination-number matching and can be adapted to more complex enterprise requirements.