Why I will never use it again.
Moving up in the world as a UC Engineer you are always trying to use the latest technology. In this case, I should have just stuck with the old school mentality of using individual CUBEs, but I have always wanted to work with a set of CUBEs in HA running HARP between the outside interfaces and the inside interfaces to get the best of both worlds. What I found was, yes, it can work…3 TAC cases later. Cisco has documentation that does a great job of walking you through how to set up HA on 4K and 8K routers. What they fail to explain, is how the IPSLA helps you fail over or why you need to set up two of them.
One issue that presented itself was inbound PSTN calls to CCX. If the call was placed on hold by the CTI port for longer than 30 seconds the call would drop and show a disconnect code of 16 indicating normal call clearing. With more digging and testing, it was discovered that the CUBE was sending the disconnect to the CUCM and PSTN. The CUBEs were hitting the default 30 second timer of no media so they disconnected the call. With the busy hours of a call center and hold times well over that it was hard to catch. It wasn’t every call either which was so much harder to find. Isolating the call to standalone CUBEs there were no issues detected.
Another issue was with calls from the PSTN to Unity. External callers leaving voicemails longer than 30 seconds were being disconnected with the CUBE sending the disconnect.
There is a timer within the config that will kill the connection if there is no media, (see step 8 of the deployment guide). With this configuration it will drop a call after 30 seconds if there is no media directed.
Unfortunately, the following work-around defeats the whole purpose of having the cubes in HA:
ip rtcp report interval 60000 gateway media-inactivity-criteria all timer receive-rtcp 480 timer receive-rtp 28800
This sets the media detection timer from 30 seconds to 8 hours. Thus, fixing the issue but presenting an issue for fail-over as calls could get stuck on the non-active CUBE.
Though the solution is a relatively easy fix, in this case it is almost easier to just build out the CUBEs as standalone, have a /29 network from the carrier, and have them list the two different IPs on their side. In this scenario, build out two SIP trunks and one Route List in CUCM.