CUCM HA Configuration.

[Ritesh Desai]

Hi folks,

CUCM in contact center deployment, i would like to clarify my understanding prior deployment. This is my 1st deployment.

I'll deploy 1 Pub and 2 Sub for redundancy.

In Cisco IOS side, defining 2 subscribers under SCCP CCM group 1, CCM-SUB1 - priority 1 and CCM-SUB2 - Priority 2. By this configuration, will I achieve high availability.

Along with above configuration. would I also require CUCM Dial-peer for extensions. If Yes, then only single dialpeer pointing to CUCM-Publisher will be right OR ELSE 2 dial-peers pointing to CUCM Sub-1 and Sub2 with preference 1 and 2 command.

Almost, 40000 calls per day is expected. 

Please clarify.

regards,

Ritesh Desai.

[Aaron Harrison]

Hi

You would use SCCP on IOS for things like FXS ports or transcoder/conferencing registration. For these, you need to define both CUCMs.

Call  routing is done seperately (assuming you have some PSTN connectivity on this IOS router) so yes, you would define dial-peers for SIP/H.323 (whichever you are using) in order to route calls when one CUCM is down.

If you are using MGCP then the gateway will auto configure itself if you have set it up correctly to do so.

Aaron

[Ritesh Desai]

Hi Aaron,

Thanks for guidance sir!

Yes. I do have TDM network. So I would require 2 configurations on Cisco IOS,

1st: resource allocation conference, MTP and Transcoding resources for which i have to configure.

2nd: 2 Dial peer's for routing calls on extensions. My earlier idea was to point CUCM Publisher IP address. But in case, if Publisher is not reachable then it will cause impact.

Query1:

I went through SRND guide, command #monitor probe icmp-ping which i entered in CUCM dial peer. This will ping CUCM every 10 seconds. If no ping response then dial peer will shutdown. BUT in case, CUCM Publisher comes up and listens to ICMP (ping echos) then automatically DP will come UP?

Query2:

I can also add DNS SRV records locally on Router. Also DNS SRV records on DNS Server. This will also help in redundancy. right Aaron?

Thanks and would appreciate for clarifying doubts.

regards,

Ritesh Desai.

[Aaron Harrison]

Hi

Q1: the GW will sequentially try each dial-peer that matches a certain destination. You can set preference on them to select the order.

Q2: No need to overcomplicate it. You can just have two dial-peers with 'preference' set so that one will be used, and if that fails the next will be used.

Are you using SIP or H.323? Each of these has a method to ensure that the failover between dial-peers happens quickly.

Aaron

[Ritesh Desai]

Hi Aaron,

Thanks for guidance. Yes. I will be using SIP protocol inside the contact center network. For quick failover, I've planned to add command "monitor probe icmp-ping.

Would like to hear more suggestions from you.

thanks & regards,

Ritesh Desai.

[zuberjasat]

Hi Aaron,

We have been having issue with UCCX server.  Our publisher uccx engine keeps failing.  All this trouble started with our VM power supply shut down and UCCX shut down.  We have since rebuilt the publisher  and yet it still keep failing. 

When on failover we have no issues.    We are running on 8.3 su3. 

1096317: Nov 25 08:38:25.117 EST %MIVR-MGR_MGR-0-THREADS_DUMP:Java Virtual Machine Threads Dump: Message=null,Exception=com.cisco.lang.DeadlockError: potential deadlock detected

1096318: Nov 25 08:38:25.117 EST %MIVR-MGR_MGR-0-EXCEPTION:com.cisco.lang.DeadlockError: potential deadlock detected

1096319: Nov 25 08:38:25.117 EST %MIVR-MGR_MGR-0-EXCEPTION:      at com.cisco.app.impl.ApplicationManagerImpl$TaskImpl.checkForDeadlock(ApplicationManagerImpl.java:4218)

1096320: Nov 25 08:38:25.117 EST %MIVR-MGR_MGR-0-EXCEPTION:      at com.cisco.app.impl.ApplicationManagerImpl$TaskImpl.access$700(ApplicationManagerImpl.java:3668)

1096321: Nov 25 08:38:25.117 EST %MIVR-MGR_MGR-0-EXCEPTION:      at com.cisco.app.impl.ApplicationManagerImpl$3.run(ApplicationManagerImpl.java:1027)

1096322: Nov 25 08:38:25.117 EST %MIVR-MGR_MGR-0-EXCEPTION:      at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.runCommand(ExecutorStubImpl.java:690)

1096323: Nov 25 08:38:25.117 EST %MIVR-MGR_MGR-0-EXCEPTION:      at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:486)

1096324: Nov 25 08:38:25.117 EST %MIVR-MGR_MGR-0-EXCEPTION:      at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:762)

1096325: Nov 25 08:38:25.117 EST %MIVR-MGR_MGR-0-EXCEPTION:      at com.cisco.executor.impl.ThreadStubImpl$RequestImpl.run(ThreadStubImpl.java:570)

1096326: Nov 25 08:38:25.117 EST %MIVR-MGR_MGR-0-EXCEPTION:      at com.cisco.util.ThreadPoolFactory$ThreadImpl.run(ThreadPoolFactory.java:853)

//This deadlock started affecting all of the calls been handled by the UCCX at that time:

1096327: Nov 25 08:38:25.117 EST %MIVR-APP_MGR-2-DEADLOCK_DETECTED:Potential deadlock detected: Application=ITSrvcDeskApp,Task id=125000001088,Thread=MIVR_ENG_TASKS-33-2-TASK:0x1d1a94a640_ITServiceDesk.aef,Info=step=com.cisco.wf.steps.iaq.SelectResourceStep

1096328: Nov 25 08:38:25.117 EST %MIVR-APP_MGR-1-MGR_PARTIAL_SERVICE:Application Manager in partial service

1096329: Nov 25 08:38:25.117 EST %MIVR-MGR_MGR-1-MGR_PARTIAL_SERVICE:Manager Manager in partial service

1096330: Nov 25 08:38:25.117 EST %MIVR-APP_MGR-2-DEADLOCK_DETECTED:Potential deadlock detected: Application=YRMainApp,Task id=125000001089,Thread=MIVR_ENG_TASKS-33-16-TASK:0x1d1a94a641_SServices/YR_Main.aef,Info=step=com.cisco.wf.steps.iaq.SelectResourceStep

1096331: Nov 25 08:38:25.118 EST %MIVR-APP_MGR-2-DEADLOCK_DETECTED:Potential deadlock detected: Application=TransitApp,Task id=125000001090,Thread=MIVR_ENG_TASKS-33-18-TASK:0x1d1a94a642_Transit/Transit.aef,Info=step=com.cisco.wf.steps.iaq.SelectResourceStep

1096332: Nov 25 08:38:25.118 EST %MIVR-APP_MGR-2-DEADLOCK_DETECTED:Potential deadlock detected: Application=YRMainApp,Task id=125000001091,Thread=MIVR_ENG_TASKS-33-21-TASK:0x1d1a94a643_SServices/YR_Main.aef,Info=step=com.cisco.wf.steps.iaq.SelectResourceStep

1096333: Nov 25 08:38:25.118 EST %MIVR-APP_MGR-2-DEADLOCK_DETECTED:Potential deadlock detected: Application=YRMainApp,Task id=125000001092,Thread=MIVR_ENG_TASKS-33-14-TASK:0x1d1a94a644_SServices/YR_Main.aef,Info=step=com.cisco.wf.steps.iaq.SelectResourceStep

1096334: Nov 25 08:38:25.118 EST %MIVR-APP_MGR-2-DEADLOCK_DETECTED:Potential deadlock detected: Application=YRMainApp,Task id=125000001093,Thread=MIVR_ENG_TASKS-33-15-TASK:0x1d1a94a645_SServices/YR_Main.aef,Info=step=com.cisco.wf.steps.iaq.SelectResourceStep

//Now the Engine goes to partial service as the Manager Manager is been affected by the deadlock:

1096350: Nov 25 08:38:25.669 EST %MIVR-CLUSTER_MGR-7-UNK:JavaService66: Cisco Unified CCX Engine on node 1 change state from IN SERVICE to PARTIAL SERVICE

1096351: Nov 25 08:38:25.669 EST %MIVR-CLUSTER_MGR-7-UNK:JavaService67: Manager Manager on node 1 change state from IN SERVICE to PARTIAL SERVICE

1096352: Nov 25 08:38:25.669 EST %MIVR-CLUSTER_MGR-7-UNK:JavaService83: Application Manager on node 1 change state from IN SERVICE to PARTIAL SERVICE

1096353: Nov 25 08:38:25.669 EST %MIVR-CLUSTER_MGR-7-UNK:Node 1 change state from IN SERVICE to PARTIAL SERVICE