The first thing to do is to get the duplex behaviour working faultlessly. Before you look at your PG arrangement, ensure that the fault-tolerant functionality of the central controller is correct

1. Shut everything down on both sides

2. Start logger A.

3. Start router A.

4. Immediately display the router A window. It will only have a couple of lines and will pause operation and will say:

"Trace: GetInSync: Synchronization holdoff disabled."

5. Within 30 seconds, select side B from the Service Control window and start router B. Watch the output of router A. As soon as router B starts, router A will start to download its configuration from the logger. If you wait more than 30 seconds it will start to do this anyway as it's operating in simplex mode.

6. Once it's complete, look at router B. It will have a line near the top that says:

"Duplex initialization complete".

7. Start logger B. Watch router A. It will show some trace and then pause with lines like:

"side b clgr is OK"

"side b hlgr is OK" (this is on ICM 7.1. For ICM 6.0 you will have one logger)

8. On side A, run rttest

rttest /cust lab /node routera

9. At the prompt, type status. All services on each side should be up and "Router Sync" at the top should say A->B

If you don't have this correct, you can easily be misled by PG install, thinking you have it right but it's only simplexed. If it's not working correctly, check that the public NIC is first in the binding order and your private configurations through ICM Setup are all exactly right.

PG stuff later. ;-)

Regards,

Geoff

Dear Geoff,

Thank you very much.

You had told me how to trace the duplex problem of ICM, but i don't know how to configure the PG to duplex model when there are multiple callmanagers and virs in ipcc.

I had created a PG and 2 PIM, one pim for ccm, and one pim for ivr. can you help checking my configuration from attachments? thanks a lot

You have two VRUs, one at 10.1.178.26 and one at 10.1.178.27. You need to have a PIM for each one. When the call arrives at a route point on CallManager you check to see if your first IVR is on-line through PG.PIM.Online, and if it is, use a translation route to move the call over there. If it's not on-line, then check the other PIM. If it's on-line, trans route to it. If neither are on-line - you have a big problem. ;-)

If you want develop a scheme to load balance you can do that but need to be careful that you are not combining the trans routes and exceeding your licencing rights. Unless you have very low powered machines with a large number of CTI ports, load balancing is not worth the trouble.

For the side A and side B CallManager PIMs ... you must be playing with a lab system, because Cisco will not support a production system with a PUB-SUB arrangement. If your SUB fails and phones fail over to the publisher, you are violating the requirements of the SRND. You must have PUB-SUB1-SUB2.

That said, the PIM connects to the CTI Manager through JTAPI. On side A you point to one box, and on side B you point to the other one. Only one CTI Manager will get connected - and messages for phones on the other one will be transmitted between members of the cluster through intra-cluster signaling.

If you set this up as above, and go onto the connected CallManager and stop the CTI Manager service, you will see the other JTAPI go active.

This is explained in the SRND.

Regards,

Geoff

Thanks a lot.I will test these in a lab system.

By the way , my msn is zhaoye@188.com,can you add it to your msn messager?thanks.