In the past two weeks, I have been involved in troubleshooting issues relating to sip trunk and run on all active nodes. In both cases call routing was affected and this led to some form of outage. I have therefore decided to write a short blog on this. In this blog I will be looking at the pros and the cons of using this new feature. As good as it looks; it has its downfalls which without careful planning could create potential issues for you in your network. So before you check that tick box, make sure you read this blog. Do your colleagues a favour too, send it to all of them and if you are a team leader ensure all your team members read, understand and digest this article before deploying that sip trunk. Happy reading
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 originating and terminating calls from and to a sip trunk.
Calls over a Single SIP Trunk.
There are two things to consider when SIP trunks are involved.
- Source Node for outbound trunk calls
- Destination/Remote Servers
The source node specifies which CUCM node the call will originate from ( not necessarily the node that your endpoint is registered to). This is very crucial as you will in the coming paragraphs.
The destination node(s)/Remote servers specify which serves the call is sent to.
SIP Trunk connections configured in each cluster may be using standard Unified CM Groups or the Run on all Active Unified CM Nodes feature.
I shall attempt to cover CUCM call routing decisions on both scenarios.
CUCM NODE SELECTION FOR OUTBOUND CALLS
CUCM uses a process called Route Local feature to influence which server is used to initiate outbound calls. This feature selects the CUCM node depending on a number of factors described below:
Using Standard Unified CM Groups with SIP Inter cluster Trunks (PRE-CUCM 8.5)
Before the run on all active unified CM node feature was introduced. The standard behaviour was to use cucm groups with SIP Trunks. There are two scenarios to consider with this type of deployment:
- Route-List in USE
- In this scenario, a Route list is in use and points to one or more Route Groups
NB: The Route List is active only on the primary CUCM in the RL’s Call Manager Group
The cucm node that will be used for a call in this scenario is determined as follows:
When a trunk is used with Route List and Route groups, the Route List is considered to be the calling device.
- If the calling device (Route List) is not registered to a CUCM server that is part of the selected outbound Trunk’s Call Manager Group;
- Then CUCM will randomly distribute calls across the servers in the Trunk’s Call Manager Group to initiate outbound Trunk calls. This is recommended, because in this scenario calls are load balanced across your CUCM servers.
- If the calling device (Route List) is registered to a CUCM server that is also a server in the selected outbound Trunk’s Call Manager Group;
- Then use this server to initiate the outbound Trunk call (i.e. the server the RL is registered to)
A word of caution, as you can see this is a bad idea. You do not get any load balancing with this; hence it is recommended that you DO-NOT-CO-LOCATEthe RL and Trunks in the same CUCM group.
Single ICT---No Route List in USE
In this scenario an ICT is in use and the route pattern points directly to it
The cucm node that will be used for a call in this scenario is determined as follows:
- If the endpoint is registered to the same CUCM server that is part of the CUCM group assigned to the sip trunk, then use the server the phone/endpoint is registered to to initiate the outbound call
- If the endpoint is registered to a CUCM server that is not part of the CUCM group assigned to the sip trunk, then cucm will randomly distribute the call across the servers in the trunk’s CUCM group
Using Run on All Active Unified CM Nodes with SIP Trunks
The second deployment type is using the new feature “Run on all active unified CM Nodes”
This feature is available for both the SIP trunk and the Route List. In Pre CUCM 8.5, your RL is only active on one CUCM node, which in some cases means that all outbound calls will originate from the NODE the RL is registered to. That as you can see is not efficient and doesn't give any form of load balancing. For the sip trunks, you can only have up to 3 CUCM NODE to make outbound calls.
This feature enables you to use up to 16 CUCM nodes to initiate outbound calls compared to only 3 you have when using standard CUCM group.
The other excellent thing about this is that you can now have up to 16 CUCM nodes to set as your destination address as compared to the 3 in previous releases. Another advantage of this is that it reduces the intra cluster signaling within the cluster, because the call is routed out locally from the node it arrived on, rather than choosing another node and thereby creating a need for Intra cluster signaling.
Deployment Considerations and Call routing
For single Trunks
When the Run on all Nodes feature is selected on a SIP trunk, then The Route Local rule selects the node to originate calls from as the same node that the inbound call arrives on. i.e. The CUCM node the endpoint is registered to.
Multiple Trunks using Route Lists
When the Run on all Nodes feature is selected on a SIP trunk and the corresponding RL, then The Route Local rule selects the node to originate calls from as the same node that the inbound call arrives on. I.e. The CUCM node the endpoint is registered to.
There are some scenarios where this feature may be enabled on the RL but not on the SIP trunk (not recommended and you will see why). The next few lines details the outcome of test results for all of these scenarios.
Scenarios and Tests results
The tables below consist of different scenarios in which an outbound call originated from a cucm node. The tests and results detail which cucm node is chosen in a particular scenario. These tests uses the following elements
- Route List (Registered to a CUCM node)
- SIP Trunk (CUCM Group)
- IP Phone (Registered to a CUCM Node)
Table 1: Route List enabled with "Run on all Node", SIP Trunk not Enabled for "Run on all CM Node"
| Feature |
|
|
|
| |
RL (192.168.131.11)
|
SIP TRUNK
(192.168.131.11,
192.168.131.12 )
|
IP Phone-(192.168.131.12)
|
| |
RL |
SIP Trunk |
|
|
Run on all Active
CM Nodes (1a)
|
X(checked) |
--(NoT checked) |
|
| |
NB: With this
featureenabled:
The cucm group is
irrelevantThe RL
registers with server
with highest cti id
|
|
Call Routing decision
If the phone-node is not in the cucm group
of the trunk, use the trunk cucm group
if the phone-node is in the cucm
group of the trunk, use the phone-node
|
| |
|
|
(SIP TRACE showing node call originated from)
INVITE sip:755670001@192.168.131.40:5065 SIP/2.0
Via: SIP/2.0/TCP 192.168.131.12:5060;branch=z9hG4bK10d6f8419c
From: < sip:804453121@192.168.131.12>
|
|
scenario 2 (phone registered
to a diff cucm)
|
|
|
|
| |
RL (192.168.131.11) |
Sip Trunk
(192.168.131.11,
192.168.131.12 )
|
IP Phone(192.168.131.11)
|
| |
RL |
SIP TRUNK |
|
|
Run on all Active CM Nodes (1b)
|
X (checked) |
---
(NoT checked)
|
|
| |
|
|
Call Routing decision
(phone-node i.e. cucm phone is registered to was used)
|
| |
|
|
(SIP TRACE showing node call originated from)
INVITE sip:755670001@192.168.131.40:5065 SIP/2.0
Via: SIP/2.0/TCP 192.168.131.11:5060;branch=z9hG4bK27e119bbd50
From: < sip:804453121@192.168.131.11>
|
|
Scenario 3
(phone registered to a
cucm that is not in the
sip trunk cucm group)
|
|
|
|
| |
RL (192.168.131.11)
|
Sip Trunk
(192.168.131.12 )
|
IP Phone(192.168.131.11)
|
| |
RL |
SIP TRUNK |
|
|
Run on all Active CM Nodes (1b)
|
X (checked)
|
---
(NoT checked)
|
|
| |
|
|
(Call Routing decision)
(sip trunk cucm group used)--because phone
node is not in cucm group of sip trunk
|
| |
|
|
(SIP TRACE showing node call originated from)
INVITE sip:755670001@192.168.131.40:5065 SIP/2.0
Via: SIP/2.0/TCP 192.168.131.12:5060;branch=z9hG4bK14c3ad4a4a9
From: < sip:804453121@192.168.131.12>
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
SUMMARY: TEST 1
When the "Run on all active CM Node" is selected on the RL, but not on the SIP trunk, the Route Local feature uses this algoritm to determine which node the call will orginate from;
- If the phone-node is in the cucm group of the trunk, use the cucm server that the phone is registered to
- If the phone-node is not in the cucm group of the trunk, use the trunk cucm group
Table 2: Route List and SIP TRUNK enabled with "Run on all Active CM Nodes"
| Header 1 |
Header 2 |
Header 3 |
Header 4 |
| |
RL (192.168.131.11)
|
Sip Trunk (192.168.131.12 )
|
IP Phone(192.168.131.11)
|
| |
RL |
SIP TRUNK |
|
|
Run on all Active CM Nodes
|
X (Checked) |
X (Checked)
|
|
| |
|
|
(Call Routing decision)
Result (phone-node used)
|
| |
|
|
(SIP TRACE showing node call originated from)
INVITE sip:755670001@192.168.131.40:5065 SIP/2.0
Via: SIP/2.0/TCP 192.168.131.11:5060;branch=z9hG4bK2a2769f1013
From: < sip:804453121@192.168.131.11>
|
SUMMARY: TEST 2
When the "Run on all active CM Node" is selected on the RL and on the SIP Trunk the Route Local feature uses this algorithm to determine which node the call will originate from;
- Use the node that the inbound call arrived on. e.g CUCM server IP Phone is registered to.
Table 3: SIP TRUNK enabled with "Run on all Active CM Nodes, RL NOT Enabled"
| |
|
|
|
| |
RL (192.168.131.12)
|
SIP Trunk
(192.168.131.12)
|
IP Phone
(192.168.131.11)
|
| |
RL |
SIP TRUNK |
|
|
Run on all Active CM Nodes (3a)
|
---(Not CHecked) |
X (checked) |
|
| |
|
|
(Call Routing decision)
Here the call proceeds as when standard
cucm group is used the node on which the
RL is registerd becomes the node
to use for outbound call, if it exist in the
sip trunk's cucm group.Because run on all node
is selected on the sip trunk, The cucm group
is irrelevant and the all the active nodes match.
Since the Node that the RL is registred to
is one of the active nodes,then the server
the RL is registered to is always the server used.
|
| |
|
|
(SIP TRACE showing node call originated from)
INVITE sip:755670001@192.168.131.40:5065 SIP/2.0
Via: SIP/2.0/TCP 192.168.131.12:5060;branch=z9hG4bK1591a496e66
From: < sip:804453121@192.168.131.12> ;
|
| Scenario 2, with different CUCM Group in SIp Trunk |
|
|
|
| |
RL (192.168.131.12)
|
SIP Trunk (192.168.131.11)
|
IP Phone
(192.168.131.11)
|
| |
RL |
SIP Trunk |
|
|
Run on all Active CM Nodes (3b)
|
---(Not CHecked)
|
X (checked)
|
|
| |
|
|
Result (same as 3a above).
Even though SIP Trunk CUCM Group was different
|
| |
|
|
INVITE sip:755670001@192.168.131.40:5065 SIP/2.0
Via: SIP/2.0/TCP 192.168.131.12:5060;branch=z9hG4bK1641d2fda0b
From: " bob banks2" < sip:800193850@192.168.131.12> ;tag=552~736dccb8-3be2-4f69-88f8-ec5946dd6872-47142526
To: < sip:755670001@192.168.131.40>
|
SUMMARY: TEST 3
When the "Run on all active CM Node" is selected on the SIP Trunk andNOTselected on the RL, the Route Local feature uses this algorithm to determine which node the call will originate from;
- The Route list be comes the calling node. If the CUCM node the RL is registered to is part of the active CUCM node in the cluster, then use this node. As you can see the node the RL is registered to will always be used. This is a bad idea.You dont want to do this.
Table 4: SIP TRUNK enabled with "Run on all Active CM Nodes, RL NOT IN USE"
| Header 1 |
Header 2 |
Header 3 |
Header 4 |
| |
|
SIP Trunk (192.168.131.11) |
IP Phone (192.168.131.11) |
| |
Direct SIP TRUNK |
|
|
|
Run on all Active CM Nodes (4a)
|
X (checked) |
|
|
| |
|
|
|
| |
|
|
INVITE sip:755670001@192.168.131.40:5065 SIP/2.0
Via: SIP/2.0/TCP 192.168.131.11:5060;branch=z9hG4bK2e34502f9f4
From: <sip:804453121@192.168.131.11>
|
Table 4: Scenario 2: IP Phone registred to a Different CUCM
| |
|
|
|
| |
|
SIP Trunk (192.168.131.11)
|
IP Phone (192.168.131.12)
|
| |
Direct SIP TRUNK
|
|
|
|
Run on all Active CM Nodes (4b)
|
X (Checked) |
|
|
| |
|
|
Result (Phone-node used)
|
| |
|
|
INVITE sip:755670001@192.168.131.40:5065 SIP/2.0
Via: SIP/2.0/TCP 192.168.131.12:5060;branch=z9hG4bK16e914be66
From: " bob banks2" < sip:800193850@192.168.131.12>
|
SUMMARY: TEST 4
When the "Run on all active CM Node" is selected on the SIP Trunk WITH NO RL in USEthe Route Local feature uses this algorithm to determine which node the call will originate from;
- Use the node that the inbound call arrived on. e.g CUCM server IP Phone is registered to.
DEPLOYING CUBE SIP TRUNK WITH "Run on all active node"
A new feature introduced with 15.(1)2T is the default behavior of a toll-fraud prevention feature. With this feature CUBE(or any IOS gateway) will check any source address against its trusted source list before allowing the call. The router will automatically add any destinations that are defined as an ipv4 target in a VoIP dial-peer to the trusted source list.
The implication of this, when using "run on all active node" is that if a call arrives to the CUBE from a CUCM node that is not defined in the ipv4 target on its VoIP dial-peer, that call will be rejected. This will lead to a scenario where some users will report that they are unable to make outbound calls.
To prevent this ensure that you add the subnet of your CUCM nodes in your IP address trust list as follows:
voice service voip
ip address trusted list
ipv4 10.10.10.0 255.255.255.0 (assuming 10.10.10.X is the subnet of your cucm nodes)
CONCLUSIONS AND RECOMMENDATION
Finally we are here. If you have stayed to read this bit, then I am sure you love what you do and want to do it better. So based on the test results, documentation and results here are my recommendations when deploying sip trunks
- If you are not using the "run on all active CM node" feature, DO-NOT-CO-LOCATE your RL and SIP trunk CUCM group. What this mean is that do not assign a server in your RL CUCM group to the SIP trunk CUCM group. If you do this, you will not have any load balancing across your cluster because calls will always t from the node the RL is registered to.
- When using "run on all active CM node" feature ensure that this is selected on both the ROUTE LIST and the SIP TRUNK. Doing this on one and not the other leads to an undesirable outcome
- When Troubleshooting SIP trunks related issues, understand how the call is routed so that you can collect your traces from the appriopriate node(s).
- Finally, always use the "run on all active CM node" feature. It simplifies troubleshooting, reduces ICCS in the cluster and gives you a greater amount of nodes to use for call routing.
- NB: When using this over SIP ICT Trunks, ensure that you define in your remote cluster all the IP addresses of servers that have CUCM service active on them. This is because a SIP trunk will reject any call that doesn't have its sip daemon running on. It populates this from the destination address.
Reference:
Here is an excellent document created by TAC to reference on this subject.
https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213361-cucm-call-distribution-mechanism-in-sip.html
Enough of my babbling for now..Hope you find this useful!
