11-07-2011 06:08 AM - edited 03-16-2019 07:55 AM
These are just some basic questions:
If you have a call manager cluster of one Publisher and two Subscribers
System version: 7.1.5.32900-2
Can calls be load balanced across the three servers, or is only one of the three serviceing calls?
If only one, what determines which one is "active"?
11-07-2011 07:01 AM
Technically speaking, calls aren't load balanced across multiple nodes in a cluster. For IP phones, you can load balance registrations across nodes. You accomplish this by leveraging Call Manager groups and device pools. Let's say you have two call processing nodes in the cluster: CM1 and CM2 and you want to load balance.
You can create two CUCM Groups:
1. CM1-CM2
2. CM2-CM1
Then create two phone device pools:
1. Phones1_DP (assigned CUCM group CM1-CM2)
2. Phones2_DP (assigned CUCM group CM2-CM1)
Then, if you had 100 phones you can assign 50 to Phones1_DP and 50 to Phones2_DP. Doing so balances registrations and, if calling behavior is uniform, should roughly balance call processing.
The same logic can be applied to DSP resources like transcoders, MTPs, TRPs, and conference bridges.
You can also apply logic to gateway devices that actively register. Specifically, MGCP and SCCP (for analog ports on vg224).
For ingress calls from gateways running SIP or H.323 you can load balance the calls using dial-peers with equal preference/priority. If they are equal, the gateway will more or less round robin. Though, I prefer a more deterministic call presentation from the gateways. For ingress/egress on gateways you also have to contend with how the carrier presents calls on carrier trunks as well as routelist/route group configs, gateway device pools, and route list CM group assignment.
In your specific case, I wouldn't load balance across three nodes. I would take advantage of your cluster model and keep call processing on the two subscribers only. I would provision the publisher so that it is not running the CM service and is, therefore, not a call processing agent. I would also run TFTP on this node and possibly IPVMS, depending on the number of devices you have in the cluster. The goal being to allow call processing needs focus on call processing and move anciliary tasks to the pub.
These are all general guidelines. Your specific use case may impose other considerations.
HTH.
Regards,
Bill
Please remember to rate helpful responses and identify
11-07-2011 07:14 AM
Currently we have a SIP implementation and the carrier is sending calls to our CUBE routers in a round robin mode.
You are saying it is possible, if we have a gateway and subscriber in HQ and a gateway and subscriber in DR, we could send all inbound calls from the CUBE to their respective subscriber, correct?
That is not how it is currently set up. The dial peers in both CUBE routers are sending to the same subscriber.
What determines which is the "active" subscriber?, If the dial peer in the DR site was changed to send to the DR subscriber, is this all that is needed for that subscriber to process those calls?
11-07-2011 07:34 AM
I assume that the CUCM-side of the CUBE is SIP as well. So, when you create dial-peers that point to the CUCM cluster you can have multiple dial-peers with the same destination-pattern. Within these voip dial-peers you have a "preference" command option where you can enforce a priority scheme.
So, let's say you have dial-peers like these:
dial-peer Voice 2110 voip
description CUCM node mycmnode02
preference ?? (see below)
destination-pattern 443100....
Voice-class codec 1
session protocol sipv2
session target ipv4:10.10.10.10
voice-class sip options-keepalive
dtmf-relay rtp-nte
ip qos dscp ef media
ip qos dscp cs3 signaling
no vad
!
dial-peer Voice 2111 voip
description CUCM node mycmnode03
preference ?? (see below)
destination-pattern 443100....
Voice-class codec 1
session protocol sipv2
session target ipv4:10.20.10.10
voice-class sip options-keepalive
dtmf-relay rtp-nte
ip qos dscp ef media
ip qos dscp cs3 signaling
no vad
!
Dial-peer 2110 and 2111 are essentially identical. Without a preference command, they have the same preference which leads to a round-robin call behavior (well, more or less. Other factors aside). In your HQ site, let's say you prefer host "mycmnode02" (see descriptions) you would then have the following:
dial-peer voice 2110 voip
preference 1
!
dial-peer voice 2111 voip
preference 2
!
In your DR site, let's assume you prefere "mycmnode03". Your dial-peers could be configured as:
dial-peer voice 2110 voip
preference 2
!
dial-peer voice 2111 voip
preference 1
!
The effect is that when your SIP carrier presents calls to the HQ CUBE, it will prefer mycmnode02. The DR CUBE will prefer mycmnode03. If your carrier is load balancing calls across the two CUBEs, then you are extending that load balancing model into your cluster.
HTH.
Regards,
Bill
Please remember to rate helpful responses and identify
11-07-2011 08:14 AM
Thanks for the reples,
We currently have the dial peers set up with a preference, both Gateways are pointing to the same subscriber.
Just so I am sure to understand, it does not matter which member of the cluster (theoretically) the calls go to, they should be processed by that Call Manager server?
We recently had an IP Address change on one of our servers, the change was reflected on the HQ side, but not on the DR side CUBE router.
HQ side was working with no problem, DR side not.
In DR, the dial-peer that was preference 1 was pointing to a non existant server, preference 2 and three were part of the cluster, but the calls from PSTN were not getting processed.
Is there anything in Call Manager that would have prevented the prefence 2 dial-peer to not be used?
11-07-2011 09:57 AM
Well, it does "matter". Your choices here must support and be supported by your overall design. But, more to the point of your question, any call processing node can handle any call request. For instance, if cm02 is handling calls from the SIP trunk in HQ and the IP phone party is register to cm03 then what you have is:
SIP->CUBE->CM02-(ICCS)->CM03->Phone (signaling path)
SIP->CUBE->Phone (media path, unless you have some MTP in play we haven't discussed)
In the signal path you will see (ICCS). This is the real-time Intra-Cluster Communication Signaling that CUCM nodes use to slice and dice call setup. It is also used for other things and there are non-realtime ICCS traffic streams, but that is a bit off topic.
For the failover issue you had, it is hard to say what was happening without seeing configs and/or traces. I suspect that you may want to look at the "retry" options under sip-ua in the IOS config on CUBE.
HTH.
Regards,
Bill
Please remember to rate helpful responses and identify
11-07-2011 10:47 AM
Thanks for the excellent responses.
Forgive me as I am learing this.
I see now that the "active" CUCM server would be the one the devices are registered to. I do see the MTP RPs registed for IPCC, but all of the gateways are showing up "unknown" under Registration on the device information page.
How do I verify which CUCM server the gateway is registered to?
11-07-2011 11:33 AM
Hi,
If your gateways are H323 ir SIP they WILL show as UNKNOWN.
This due to peer to peer nature of these protocols.
Your MGCP gateways should be registered with the CUCM from their
relative CUCM-GROUP int their device pools
(MGCP is a client/server protocol)
HTH
Alex
11-07-2011 01:05 PM
Alex is correct (+5 A.). It is normal to see unknown for H.323 gateways and SIP trunks when communicating to IOS devices. The IOS devices don't actively register to the CUCM.
Regards,
Bill
Please remember to rate helpful responses and identify
11-08-2011 06:20 AM
Ok,
Thanks very much for the replies.
Please let me know if I have the following correct:
We have IPCC and end our users registered to HQ side CUCM server.
We have HQ CUBE (preference 1) dial-peer pointing to HQ CUCM sub in cluster, we have DR CUBE (preference 1) dial-peer pointing to DR CUCM sub in cluster.
For outbound calls, the end users will use the CUCM server they are registered to.
For in bound calls, since there is no active registration between our SIP CUBE routers, they will send calls to any CUCM server in the cluster (desigantated by dial-peer), the cluster knows that HQ CUCM has the registered endpoints and processes the call accordingly.
Correct?
11-08-2011 06:31 AM
Yes, that is correct.
Please remember to rate helpful responses and identify
11-08-2011 07:31 AM
Thank you william,
I am getting a much better understanding,
Since all DR calls are destined for the HQ side CUCM server (directly via dial peer), does it matter much if the DR CUBE sends the call directly to the HQ side, or would there be an improvemenet in sending to the call to the DR CUCM and let the call be processed across the link via inter cluster communication?
11-08-2011 08:36 AM
Hi,
The CUBE can be set up with 2 VOIP dial peers,
1st choice pointing at your primary call processor CUCM
2nd choice pointing at your backup call processor CUCM
E.g.
Here are a couple of H323 peers but SIP are similar
!
dial-peer voice 100 voip
description *** VOIP PEER 1ST CHOICE ***
preference 1
destination-pattern 7823...
incoming called-number .
voice-class codec 1
voice-class h323 1
session target ipv4:10.10.10.100
dtmf-relay h245-alphanumeric
ip qos dscp ef media
ip qos dscp cs3 sig
no vad
!
dial-peer voice 200 voip
description *** VOIP PEER 2ND CHOICE ***
preference 2
destination-pattern 7823...
incoming called-number .
voice-class codec 1
voice-class h323 1
session target ipv4:10.10.10.200
dtmf-relay h245-alphanumeric
ip qos dscp ef media
ip qos dscp cs3 sig
no vad
The preference statements are an ordered list of which peer to try 1st.
If pref 1 fails a 2nd attempt to route the call is made on pref 2
So if you had 5 call proessors you could have 5 similar dial peers
HTH
Alex
11-08-2011 10:19 AM
Below is how we have our dial peers set up. After reviewing all of the above posts, I still do not see why the call on the DR side did not get processed, as it should have gone to the next available dial peer, but it did not.
What we had was the dial peer preference 1 server's IP Address changed, so preference 1 session target was changed on the HQ side, but not the DR side. The DR gateway did not try the second dial peer (preference 2), what happened was the carrier was receiving 403 forbidden message and a 603 denied message when the DR side was trying to process the calls.
Once I changed the DR side to the correct session target, DR side worked with no problem.
The Preference 2 and 3 dial peers are pointing to valid CUCM servers in the cluster.
I was thinking that perhaps it did not work because the server that the CTI RP for the IPCC server was registered to, is the new CUCM (preference 1), but why didn't the DR side send the call to the Preference 2 dial-peer and inter cluster communication send to the HQ CUCM, where the CTI RP was registered?
!
dial-peer voice 2 voip
preference 1
destination-pattern [1,3]...
session protocol sipv2
session target ipv4:10.1.1.1:5060
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 3 voip
preference 2
destination-pattern [1,3]...
session protocol sipv2
session target ipv4:1.2.1.2:5060
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 4 voip
preference 3
destination-pattern [1,3]...
session protocol sipv2
session target ipv4:1.2.1.3:5060
dtmf-relay rtp-nte
codec g711ulaw
no vad
! !
11-08-2011 08:52 AM
Wilson,
I prefer to keep the DR CUBE talking to the DR CUCM during normal "healthy" conditiions. The idea is to minimize impact in the event of outage. The link between DR CUBE and DR CUCM is more reliable than the WAN link between HQ and DR. Put another way, say that in a given year you take 2 hits on the WAN/MPLS(whateve) connection between HQ and DR and you take 0 hits on the link between DR CUBE and DR CUCM. Given this, by having the DR CUBE prefer the DR CUCM you have proactively avoided 2 outage windows, however small they are.
At least, that is how I think about it. Granted it is a small consideration in the grand scheme but these concepts are part of a good design foundation. My opinion, anyway.
HTH.
Regards,
Bill
Please remember to rate helpful responses and identify
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide