CUCM Call Distribution Mechanism in SIP/H323 Trunk

Introduction

This document describes the modus operandi used by Cisco Unified Communications Manager to decide which CUCM nodes are used to send calls out via Session Initiation Protocol (SIP) or H.323 based Trunks.

Prerequisites

Requirements

Cisco recommends that you have prior knowledge of these topics:

• Cisco Unified Communications Managers (CUCM) basic Call routing Concepts

Components Used

 The information in this document is based on Cisco Unified Communications Managers (CUCM) 8.x and later.

 The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

SIP trunks and H.323 Gateways do not register with the CUCM  (unlike  MGCP Gateways). Instead, the CUCM Group associated to the Device pool attached to the Trunk or Gateway determines, where they will be active. For instance, if they are active on 2 or 3 nodes, what mechanism does CUCM utilize to decide which server to send the call out on.

The objective of this document is to explain how call routing decisions are made and how load balancing can be achieved for outbound calls via SIP Trunks or H.323.

Callrouting Mechanism Pre-CUCM 8.5 (not using Run on all Active Unified CM Nodes feature)

General logic: For an outbound call, once CUCM has gone through Digit analysis, it extends the call to the RouteList or the end device.  (RouteList gets registered to a particular node, which depends upon the CUCM group)

RouteList control identifies the list of devices and queries the Device manager.
Device manager gives device Process ID (PID) (example: (2,100,25,45), in this example the device is active on node 2)

RouteList control checks the status of the device (is the target device active, idle or busy) and extends the call to the trunk or gateway.

Since SIP Trunks / H.323 Gateways can be active on multiple nodes, the question now begs which node is selected as active PID by the device manager?

These use-case scenarios shed further light on this:

Use-Case 1: IP Phones Registered to Node 1. No RouteList Configured.

In this SIP Trunk is active on node 1 and 4.

• General logic remains the same, CUCM does Digit analysis on node 1 where the phone is registered. Since no RouteList is configured, Route Pattern is directly associated to the SIP trunk.
  
  
• CUCM on node 1 queries the Device manager on node 1.
  
  
• Device Manager (DM) always check Local Table first, and return local device if there is one, to avoid unnecessary inter cluster communication/traffic.

In this case, SIP trunk is active on node 1 where the phone is registered so CUCM extends the call from node 1 (every time). Random logic is not applied here and there is no load-balancing since the call is extended from Node 1 in every case.

Use-Case 2: IP Phones Registered to Node 1. RouteList Registered to Node 2.

In this SIP Trunk is active on node 2 and 4.

• After Digit Analysis (DA) results, CUCM node 1 extends the call to the RouteList Control in node 2.
  
  
• RouteList Control on node 2 queries the Device manager on node 2.
  
  
• DM always checks Local Table first, and return a local device if there is one, in this case the SIP trunk is local to node 2.

As a result, no matter where the phone is registered, since the RouteList is registered to node 2 and Sip trunk is active on the same node, all the calls are source from Node 2. Again, random logic is not applied.

Use-case 3: IP Phones Registered to Node 1. RouteList Registered to Node 2.

In this H323 Gateway is Active on Node 1 and 4.

• After DA results, CUCM on node 1 extends the call to RouteList control on node 2.
  
  
• RouteList control on node 2 queries the Device manager on node 2.
  
  
• Device Manager (DM) always checks Local Table first, and returns local device none.
  
  
• Device Manager looks up RemoteTable, and sees H.323 Gateway active on node 1 and 4.

It applies the random logic, and gives an active PID randomly to the RouteList control. Since it is sent randomly between node 1 and 4, calls are load balanced in CUCM.

Conclusion

CUCM checks whether the SIP trunk/H.323 Gateway is active on the same node as the Calling device. If so, then it always uses the local node to send the call out.
If the SIP trunk/H.323 Gateway is not active on the same node as the calling device, then it sources randomly from the nodes where the trunk/device is active.

Note: The calling device can be either a phone or a RouteList.  If Route pattern is matching a RouteList, then the Calling party is the RouteList. If the Route pattern is associated directly to the SIP/H.323 device, then the calling party is the phone.

Load-Balancing

If load balancing wants to be achieved, then it is not advisable to  co-locate the RouteList or phone with the CUCM nodes that the SIP/H.323 gateways are associated to i.e if they are both active on the same node, then calls will be sent out from the local node (always) .

In other words, the SIP trunk/H.323 Gateway needs to be configured such that they are not active on the nodes where the RouteList or phones are registered.

From CUCM version 8.6 onwards, CUCM introduced a new features called Run on all active Unified CM Nodes for both RouteList/SIP trunks.     

This is another way to efficiently load balance the outbound calls and reduces the number of signals exchanged within the cluster.

Callrouting Mechanism Post-CUCM 8.5 (Run on all active Unified CM Nodes feature being used)

In CUCM 8.5 and above Cisco introduced a new feature on sip trunks and Route List called Run on all active unified CM nodes. This basically removed the dependency of the sip trunk and the route list on the CUCM group assigned to them. This implies that you can have more than three CUCM servers that originate and terminate calls from and to a sip trunk.

SIP Trunks – Run on All Nodes and the Route Local Rule

When Run on all Active Unified CM Nodes option is checked on a SIP trunk, Unified CM creates an instance of the SIP trunk daemon on every call processing subscriber within the cluster, thus allowing a SIP trunk call to be made or received on any call processing subscriber. (Prior to this feature, up to three nodes could be selected per trunk by using Unified CM Groups.)

With Run on all Active Unified CM Nodes enabled, outbound SIP trunk calls originate from the same node on which the inbound call (for example, from a phone or trunk) is received (based on the Route Local rule). The Run on all Active Unified CM Nodes feature overrides the trunk's Unified CM Group configuration.

For SIP trunks, this is how the Route Local rule operates:

For outbound SIP trunk calls, when a call from a registered phone or inbound trunk arrives at a Unified CM node, Unified CM checks to see if an instance of the selected outbound trunk exists on the same node where the inbound call arrived. If so, Unified CM uses this node to establish the outbound trunk call.

To enable Run on all Active Unified CM Nodes on SIP trunks is highly recommended because this feature allows outbound calls to originate from, and be received on, any call processing node within the cluster. Run on all Active Unified CM Nodes can also eliminate calls from being set up between call processing nodes within the same cluster before being established over the outbound SIP trunk.

As with all Unified CM SIP trunks, the SIP daemons associated with the trunk accepts inbound calls only from end systems with IP addresses that are defined in the trunk's destination address fields.

When multiple SIP trunks to the same destination(s) are using the same call processing nodes, a unique incoming and destination port number must be defined per trunk to allow each trunk to be identified uniquely.

Route Lists – Run on All Nodes and the Route Local Rule

Although this is not specifically a SIP trunk feature, running route lists on all nodes provides benefits for trunks in route lists and route groups. Running route lists on all nodes improves outbound call distribution by using the Route Local rule to avoid unnecessary intra-cluster call setup traffic.

For route lists, this is how Route Local rule operates:

For outbound calls that use route lists (and associated route groups and trunks), when a call from a registered phone or inbound trunk arrives at the node with the route list instance, Unified CM checks to see if an instance of the selected outbound trunk exists on the same node as the route list. If so, Unified CM uses this node to establish the outbound trunk call.

• If both the route list and the trunk have Run on all Active Unified CM Nodes enabled, outbound call distribution is determined by the node on which the inbound call arrives.
  
  
• If the selected outbound trunk uses Unified CM Groups instead of running on all nodes, Unified CM applies the Route Local rule if an instance of the selected outbound trunk exists on the same node on which the inbound call arrives.
  
  
• If an instance of the trunk does not exist on this node, then Unified CM forwards the call (within the cluster) to a node where the trunk is active.
  
  
• If the route list does not have Run on all Active Unified CM Nodes enabled, an instance of the route list will be active on one node within the cluster (the primary node of the route list's Unified CM Group).
  
  
• If the selected outbound trunk is also active on the primary node of the route list's Unified CM Group, the Route Local rule is applied, resulting in sub-optimal outbound call distribution because all outbound trunk calls originate from this node.

Cisco strongly recommends enabling Run on all Active Unified CM Nodes on all route lists and SIP trunks.