Unity connection cluster - Delay after signin

[emorgan]

Hi,

Brand new CUC 7.1.3 cluster.

CUCM 4.2

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.

Version: 7.1.3ES26.32900-26

DNS not configured.

Replication state is good on both servers (state=2).

Thanks for your help,

Eric

[David Hailey]

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.

Hailey

Please rate helpful posts!

[emorgan]

Hi,

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,

Eric

CUC pub:

One port group

7601-7610 (accept calls)

7615-7619 (MWI, trap, ...)

CUC sub:

One port group (same as pub)

7621-7630 (accept  calls)

7631-7639 (MWI, trap, ...)

On CUCM:

One hunt pilot (7600)

One hunt list

One line group with ports 7601-7610+7621-7630.  Default parameters.

[David Hailey]

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

Hailey

Please rate helpful posts!

[David Hailey]

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

[emorgan]

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:
127.0.0.1 localhost
::1 localhost
10.201.1.22  QUBC1-TMEVP01
10.201.1.23  QUBC1-TMEVP02

on the sub:
127.0.0.1 localhost
::1 localhost
10.201.1.23  QUBC1-TMEVP02
10.201.1.22  QUBC1-TMEVP01

CUC cluster management shows server names in lower case.  Could this be a lower case/upper case problem?

Eric

[David Hailey]

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

port configs.

Sent from my iPhone

On May 3, 2010, at 2:08 PM, emorgan

[emorgan]

Hi,

Just created two line groups.  One for sub answering ports and one for pub answering ports.  Both are top down.  Sub has first priority.

Same problem.

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?

Eric

[David Hailey]

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.

Hailey

Please rate helpful posts!!!