Brand new CUC 7.1.3 cluster.
When calling a port on the secondary server (subscriber), there is about 30 seconds of dead air after signin (after password). The same goes for leaving a message: long delay before hearing the "beep".
Everything works fine if I call a port on the primary server.
If I make the subscriber the primary CUC server, then it starts working well, and the problem is moved to the publisher.
DNS not configured.
Replication state is good on both servers (state=2).
Thanks for your help,
Can you give me details on how you you have your Telephony System, Port Groups, and Ports set up in CUC? In addition, please give me a rundown of how you have your Line Groups configured in CUCM. CUC can be pretty picky about port allocation and usage.
Please rate helpful posts!
Here are the port allocations. Note that for the tests I am calling directly the appropriate port on the CUC pub or sub (ex: 7601 or 7621). Since Unity responds fine, I don't see the problem as being on the CUCM side. The delay happens after logon and somehow seems to be related to the CUC secondary server trying to access the message store for message deposit or retrieval.
Thanks for your help,
One port group
7601-7610 (accept calls)
7615-7619 (MWI, trap, ...)
One port group (same as pub)
7621-7630 (accept calls)
7631-7639 (MWI, trap, ...)
One hunt pilot (7600)
One hunt list
One line group with ports 7601-7610+7621-7630. Default parameters.
I understand your thought process. Technically speaking, I believe it is recommended that the Subscriber ports be configured with the lowest-numbered DN's (this is more on the CUC side in terms of operation). This may be unrelated to your issue; however, I'm just putting the info out there. Trust me when I say that I have seen some situations where CUC was rather picky about how the ports are configured when clustering 2 servers. On the CUCM side, you would want to make sure your Subscriber ports are higher in priority than the Publisher. You really want the Publisher to (in normal operations) only do DB and Web services (IMAP, Administration, PCA) and the Subscriber to answer calls. I'm not looking at the original thread so I apologize if you already noted this - If you call a port on the Publisher directly, do you have this same issue (i.e, Pub is primary)?
Please rate helpful posts!
Can you do me a favor and also run the following on each server from CLI and verify that your hosts files contain only IP addresses:
show tech network hosts
Thanks for the line hunt notes. When all this is over I will play with the line group so the subscriber (secondary) is hit first.
The delay after signin only occurs on the server assuming the secondary role (the sub in my case). Once following a reboot, I noticed that the subscriber had assumed the primary role and the problem had moved to the now secondary-publisher. So the problem may be related to the secondary role instead of a specific server.
Here are the host files:
on the pub:
on the sub:
CUC cluster management shows server names in lower case. Could this be a lower case/upper case problem?
No, that's not an issue. Typically, you should make your server names
IP addresses especially if you're not using DNS. I honestly think you
should reconfigure your ports as I mentioned -little work on both CUCM
and CUC. Have 2 line groups - 1 for each node then have sub be ordered
higher than pub. CUC wants top down hunt within a group per design
guide. Once your ports are squared away, I can get you to do some
testing and see if things change. If not, we've ruled out suboptimal
Sent from my iPhone
On May 3, 2010, at 2:08 PM, emorgan
Just created two line groups. One for sub answering ports and one for pub answering ports. Both are top down. Sub has first priority.
Let me know what other things you feel I could work on.
Do you think this might be deep enough to require a TAC case?
I would recreate the ports - in downtime, if possible. Assign all the lowest numbered ports to the Sub and the higher numbered ports to the Pub. I believe CUC uses this info in some capacity for determining how to break up functions across servers during normal operations (like Pub handle MWI first). Of course, calls come in on the port they are sent to...so it can't do much there. So, example:
If the Pub has ports 1000 - 1010 and Sub has 2000 to 2010, I'd swap that from a DN perspective. Once you do that, you're pretty much inline with what I recall as being the recommendations from a configuration standpoint.
You could open a TAC case - I wouldn't tell you not to - however, they are going to look at all of these things first. You shouldn't, in my experience, have a large gap in performance (even for login) between the 2 servers. I just finished a CUC cluster build for a large client and in my failover testing on what is the same version of code I believe (7.1.3b-su2), I didn't experience any issues such as this.
Please rate helpful posts!!!