Problem with CMS load balancing configuration.

[li007il89]

Hello!

Could you please help me such issue:

I've tried to configure load balancing on 2 demo Cisco Meeting Servers.

I have 2 CallBridges (in the cluster), created 1 CallBridgeGroup, assigned CallBridges to CallBridgeGroup.

On CUCM I've created 2 sip trunks (sip profile with Accept replaces header field), created Route Group and Route List. Also, I've created Test Space on CMS cluster with number 7000, created route pattern on CUCM, assigned to it Route List with 2 my CMS trunks. 

I've tried to make a call, first my phone connected without any problem, but the second one not.

Logson CMS 1:

2017-09-06 12:27:07.582 Info call 15: incoming SIP call from "sip:+12125556017@dcloud.cisco.com" to local URI "sip:7000@cms1.dcloud.cisco.com:5060"
2017-09-06 12:27:07.606 Info replace query for conference 41b72c3b-9b79-4363-9629-14749577fad3: response from 'cms1_callbridge' (priority: 0, load level: 0, conference is running: 0)
2017-09-06 12:27:07.761 Info replace query for conference 41b72c3b-9b79-4363-9629-14749577fad3: response from 'cms2_callbridge' (priority: 1, load level: 0, conference is running: 0)
2017-09-06 12:27:07.761 Info replace query for conference 41b72c3b-9b79-4363-9629-14749577fad3: using local server 'cms1_callbridge' (priority: 0, load level: 0, conference is running: 0)
2017-09-06 12:27:08.129 Info participant "+12125556017@dcloud.cisco.com" joined space 72df31ae-517c-47b2-b687-7ce9f2a9ce38 (TestSpace)
2017-09-06 12:27:08.129 Info conference "TestSpace": unencrypted call legs now present
2017-09-06 12:27:12.943 Info replacing call 'b421d580-9af1e9a0-607-38512c6@198.18.133.3' from server 'cms2_callbridge' into conference 41b72c3b-9b79-4363-9629-14749577fad3
2017-09-06 12:27:12.943 Info call 16: outgoing SIP call to "+14085556018@dcloud.cisco.com" from space "TestSpace"
2017-09-06 12:27:12.955 Info call 16: ending; remote SIP teardown with reason 18 (not found) - not connected after 0:00
2017-09-06 12:27:26.914 Info call 15: ending; remote SIP teardown - connected for 0:19
2017-09-06 12:27:26.915 Info participant "+12125556017@dcloud.cisco.com" left space 72df31ae-517c-47b2-b687-7ce9f2a9ce38 (TestSpace)

Logs on CMS2:

2017-09-06 12:27:11.863 Info call 3: incoming SIP call from "sip:+14085556018@dcloud.cisco.com" to local URI "sip:7000@cms2.dcloud.cisco.com:5060"
2017-09-06 12:27:11.883 Info replace query for conference 41b72c3b-9b79-4363-9629-14749577fad3: response from 'cms2_callbridge' (priority: 1, load level: 0, conference is running: 0)
2017-09-06 12:27:12.031 Info replace query for conference 41b72c3b-9b79-4363-9629-14749577fad3: response from 'cms1_callbridge' (priority: 0, load level: 0, conference is running: 1)
2017-09-06 12:27:12.031 Info replace query for conference 41b72c3b-9b79-4363-9629-14749577fad3: using remote server 'cms1_callbridge' (priority: 0, load level: 0, conference is running: 1)
2017-09-06 12:27:12.032 Info replacing call 'b421d580-9af1e9a0-607-38512c6@198.18.133.3' to conference 41b72c3b-9b79-4363-9629-14749577fad3 on server 'cms1_callbridge'
2017-09-06 12:27:22.033 Info call 3: ending; local teardown, timed out - not connected after 0:10

Thanks a lot!!!

[Zoltan Kelemen]

Hi,

Clustered CMS callbridges must accept calls incoming to their own IPs.

See CMS 2.2 Scalable and Resilient Deployment guide section 6.6.1, page 68.

[Hatem_Hamdi]

Hello,

I am having the exact same issue with a two CMS cluster.

Did you manage to solve it? and how you did?

Best Regards,

Hatem

[Nick Halbert-Lillyman]

Assuming you have clustering working OK before you configure the Callbridge groups, check the following:
Inbound dial rules to their own IP's and hostnames match and search for spaces

Outbound dial rules for their own IP and hostname targets their own IP and hostname (e.g. outbound dial rule for 10.1.1.1 uses SIP proxy 10.1.1.1)

Check the "Reroute Calling Search Space" on the CUCM trunks

[Hatem_Hamdi]

It was the rerouting Calling Space which was missing under the SIP trunks configuration. As soon as I corrected it the issue seems to be resolved.

Thank you for the hint.

[Nick Halbert-Lillyman]

No problem, it caught me out recently even though I'd done it before :)