Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

SIP TRUNKS and RUN on ALL ACTIVE CM NODES

 

 

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.

 

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

Comments

As usual , Great Document. Many thanks for you.

New Member

Thank you very, very much Aokan!

Amir

Ayodeji

As always this is an excellent document !!! Thank you very much for sharing all your experience including the test scenarios and test results. This indeed very much helpful to all. + 5

Regards

Lavanya

Technical Community Manager

VIP Super Bronze

Thank you Lavanya.

New Member

Thank you!, excellent document, very usefull.

VIP Super Bronze

Thanks, I am glad you find it useful

New Member

Good Job.

A question about redundancy in 8.6:

- 3 Servers (A,B,C)

- Checked "Run on all Node" in RL.

- Checked "Run on all Node" in Sip Trunk.

- One Sip Trunk (APV) with 2 IP destinations (IP_SCB_MAD,IP_SBC_BCN).

- One RL_APV-->RG_APV->Sip Trunk (APV)

If a Phone are registered in server A, the "Route Local" logical will send the call to the same server where phone is registered. But if two IP Address configured in SIP trunk are not available (routing problem only from server A), the call is loss. There are not redundancy in this case.

You can tell me that configure a new Sip Trunk and insert  into the RG, but the IP address can not be duplicate in multiples SIP Trunks.

Do you know some alternative?

Thanks.

New Member

Hi jcgutierrez,

Do you have SIP OPTIONS PING enabled on the SIP Profile of the SIP Trunk?

Juan

New Member

Hi jsalas,

Yes, I have enabled, but maybe is not working because the SIP Options send Header "Max-Forwards: 0" and my ISP Provider not support this value, they are sending me message "483 Too Many Hops".

I´m trying found where change this value in services parameters or with Sip Normalization Scripts but I do not found nothing.

Do you know if Sip Options start working the issue will be solve?

Thanks.

New Member

jcgutierrez,

I understand that you receive the "483 Too Many Hops" when you are not being affected by the ip routing issue, that should keep the SIP Trunk up. Also I am assuming that you lose connectivity with the SBCs but not between the CUCM nodes in the cluster.

So, did you try disabling the "Run on all nodes" in the SIP Trunk (just use a DP with a CUCM group that cointains CUCM A, B and C)?  Then, keep Run no all nodes only in the Route List.

Acording to SRND 8.x:

"If both the route list and the trunk have Run on all Active Unified CM Nodes enabled, outbound call distribution will be determined by the node on  which the inbound call arrives. When the selected outbound trunk uses  Unified CM Groups instead of running on all nodes, Unified CM will apply  the route local rule if an instance of the selected outbound trunk  exists on the same node on which the inbound call arrived. If an  instance of the trunk does not exist on this node, then Unified CM will  forward the call (within the cluster) to a node where the trunk is  active."

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/8x/uc8x/trunks.html

New Member

Hi jsalas,

It's true that response "483 Too Many Hops" is valid for keep the SIP Trunk Up.

11:51:39.432 |//SIP/Stack/Info/0xf99e298/####Response code = 483, Source = External, set ping status to TRUE|1,100,230,1.49^172.31.20.36*

About to disable "Run on All Nodes" in SIP trunk, the behavior is the same.

I'll try open a case to TAC.

Thanks for your time.

VIP Super Bronze

jcgutierrez,

There is no alternative when both your trunks are down. Dont mix the two things up. The run on all active nodes helpd you chose which node your call will orginate from, not where it will go. There is no redundancy after the two destinations are tried and they are both out of service. I dont know what you mean  by problem with CUCM A, I guess you  mean that the other servers can still reach the destination...I dont think it works that way. As far as CUCM is concerned it has selected a node for the outbound call, its not going ot try another node to make the call

1902
Views
24
Helpful
12
Comments