cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

SIP TRUNKS and RUN on ALL ACTIVE CM NODES

36890
Views
329
Helpful
27
Comments
Mentor

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)

 RLSIP 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)

 RLSIP 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)

 RLSIP 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 algorithm to determine which node the call will originate 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 1Header 2Header 3Header 4
 

RL (192.168.131.11)

Sip Trunk (192.168.131.12 )

IP Phone(192.168.131.11)

 RLSIP 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 algoritm to determine which node the call will orginate 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)

 RLSIP 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)

 RLSIP 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 and NOTselected on the RL, the Route Local feature uses this algorithm to determine which node the call will orginate 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 1Header 2Header 3Header 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 USE 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.

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 because calls will always originate 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 appropriate 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.
  • Ensure you add the subnet of your CUCM nodes to your IP address trust list when using CUBE(s) with run on all active nodes

Enough of my babbling for now..Hope you find this useful!

27 Comments
Beginner

Thank you very much for this documentation!

Amir

Amir,

I am glad you found it useful. Dont forget to rate it, if you like it.

Advocate

Thank you for the document .

Rising star

Informative one !!!

Beginner

Nice work again AoK 

Respect...

Cisco Employee
Cisco Employee

This is an awesome document. Thanks.

Beginner

hello

Whats the advantage of using this feature in 8.6 CUCM SME where in I use only trunks with leaf clusters or cubes or other SIP gateways and no endpoints like phones or MGCp GW's

 

Also I had a question if I had already created multiple CUCM groups with load balanced Nodes and I use it in RL and the same group in SIP trunk Device pool CUCM group would it be a load balanced approach?

 

Say

site 1 sip trunk has CUCM Group 1 =>A1 and B1 and I assign this in both Trunk CUCM group as well the RL CUCM group

Site 2 SIp trunk has CUCM Group 2 => B1 and A1 with assignment same as above

what will be the behavior on above scenarios

Also for Intercluster SIP trunks Im planning to build two trunks put in route group with circular algorithm and each trunk will have different CUCM group say [A1,B1 for TRNK1] and [B1, A1 for TRNK2] and also the remote address in SIP trunk points to different nodes in leaf cluster

Im still not confident with Run on all nodes features, may be Im missing a thing about it

 

Thanks

Chandramauli

Chandramauli,

Whats the advantage of using this feature in 8.6 CUCM SME where in I use only trunks with leaf clusters or cubes or other SIP gateways and no endpoints like phones or MGCp GW's

The first question to answering your question is this: How many nodes do you have in your SME cluster. If you have more than one, then you need to bear this in mind...If you use this feature, the route local rule will still apply. what that means is that, to choose which server the call will originate from CUCM SME will

  • Use the node that the inbound call arrived on

So if calls are directed to all of your nodes, then this feature will work well for you. Your calls will be load balanced across your servers

Question 2.

Also I had a question if I had already created multiple CUCM groups with load balanced Nodes and I use it in RL and the same group in SIP trunk Device pool CUCM group would it be a load balanced approach?

As long as the "run on all active cucm  node is selected on both RL and SIP trunks, then yes. Since the node that will be used will be the node your IP phone is registered to. Once your phones are distributed across all your nodes, then calls will be load balanced across your cluster.

 

The logic for this feature is that it will use the Route local feature. what that means is that it will use the node that the call arrives on. It could be a phone or a trunk. Understanding that should help you understand how you plan your configuration.

Hope this help clarifies things. The feature is great. Use it.

Participant
Excellent post and very informative. Can anybody tell me if I use run on all active cm nodes for a sip trunk connecting to unity connection does this then require any additional configuration in unity connection. For example I currently have configured in cucm 2 sip trunks, 1 for the cuc publisher and 1 for the subscriber both in a route group with a route list pointing to this route group. Both the route list and sip trunks don't use run on all active cm nodes so it will use the cucm group. In unity connection we point it to cucm specifying the 3 servers used in the cucm route list and sip call manager group. If I select run on all active cm nodes on the route list and sip trunk in cucm then I assume the call could then come from 1 of 6 call processing nodes that I have in the cluster. Will unity connection accept a call if it comes from a cucm server it doesn't have specified in its config or do I need to add all cucm call processing nodes into unity connection? Thanks, Carl Ratcliffe

Hi Carl, Yes you need to add all the call processing servers in unity connection. It will not accept call from any server that is not defined in its config. It works the same way as cucm.

thanks for very informative blog. 5 points from my side.

Thanks this is a great report. We run a complex environment and I would like to share a scenario:

 

We have SIP Trunks in CUCM connected to SIP Cubes

We have RL used for TEHO into another country

Both of these had the " Run on all CUCM nodes" check box selected.

 

Phones registered to two of our subscribers were experiencing calls that were being routed out our SIP cubes and NOT via the TEHO RL and RG's associated to them.

In this case, just for this TEHO scenario it appears unchecking "Run on all CUCM nodes" on the TEHO RL forces the calls to use the TEHO RL and not the local sip cubes - saving international costs.

 

Seems to work, ok Intracluster communications comes into play but this scenario is only used in TEHO RL..

Keen to see if you guys have any other ideas or better ways to implement...

 

 

Dwayne,

This feature controls which node the call will originate from, I doubt if it determines which trunk the call is sent to. There may be something else at play here and only by looking at cucm logs, can we accurately determine why TEHO calls are routed via the CUBE. I am not convinced it has anything to do with this feature.

Participant

Good stuff. More babbling on other subjects will be tolerated as long as they're as informative as this one = ).

Thanks Ayodeji,

 

The thing is when " Run on All active Nodes" feature is checked the outbound calls are routed by using the route local rule. In the scario that I have noted this rule always picks the trunk associated with this RL and ignores other RG with gateways. It always uses the standard local route group.

Unchecking Run on all active nodes is a workaround for us with no other issues :-). Very interesting arcticle and very informative!

Content for Community-Ad