cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1397
Views
65
Helpful
16
Replies

Questions about Call Manager cluster

wilson_1234_2
Level 3
Level 3

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"?

16 Replies 16

William Bell
VIP Alumni
VIP Alumni

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

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

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?

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

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

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?

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

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

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?

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

Regards, Alex. Please rate useful posts.

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

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

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?

Yes, that is correct.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

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?

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

Regards, Alex. Please rate useful posts.

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

! !

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

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: