There's a mobile version of our website.
I have a CUC 8.0(2) pair that is integrated with a CUCM 8.0(2) cluster. Originally, the Unity Connection publisher was the only server integrated with the CUCM cluster for voicemail. I recently added the remaining ports on the Unity Conection subscriber into the port group, and added the additional ports in CUCM as well.
The additional ports registered just fine in CUCM, however in Unity Connection it tells me that the port group needs to be reset. I reset the port group, but it just sits there with no change and continues to tell me that the "port group needs to be reset"
Failover works just fine; if I shut down the CUC publisher, all calls to voicemail roll over correctly the CUC subscriber. The only thing that appears to be broken is MWI - it does not light on or off. I can check a voicemail, listen to it, and delete it, however visually inspecting the user's MWI status in the CUC gui still indicates that the MWI is "off."
I beleive this has something to do with the underlying issue of my port groups not resetting. Everything, inlcuding MWI, was working fine prior to adding the subscriber's ports. Has anyone experienced anything similar and have a fix? I've tried restarting the Conversation Manager as suggested in another thread, but no luck.
It turns out the partition that the MWI ports are in were mistakenly removed from the voice mail port's CSS in CM. That solved the MWI issue.
I attempted to reset the conversation manager service again and it also resolved my "port group needs to be reset" problem. It looks like I just needed to give it another try.
With respect to setting specific ports on the subscriber for MWI only, is this a requirement, or optional? It all appears to be working fine if my ports are set for all (answer, message, mwi, etc). Users don't really use voicemail a lot and I have plenty of ports. It seems to me that setting specific ports for MWI only would be desireable in a large volume call environment.
Thank you for your response.
Nice to hear you got things working
The set up of MWI Ports on both the Pub & Sub is a requirement
for redundancy purposes;
•The number of voice messaging ports that are assigned to the functioning Cisco Unity Connection server must be sufficient to handle all of the voice messaging traffic for the system (answering calls and dialing out).
•The functioning Cisco Unity Connection server must have voice messaging ports that will answer calls and that can dial out (for example, to set MWIs). For details, see Chapter 8 "Configuring Voice Messaging Ports for a Cisco Unity Connection Cluster."
If the functioning Cisco Unity Connection server does not have voice messaging ports for answering calls, the system will not be able to answer incoming calls. Similarly, if the functioning Cisco Unity Connection server does not have voice messaging ports for dialing out, the system will not be able to dial out (for example, to set MWIs).
"May your heart always be joyful
May your song always be sung" - Bob Dylan
I found that stopping the primary server from taking calls will allow you to test redundancy but if you leave the primary server in its role and stop it from taking calls MWI will not be updated. Turns out MWI is only updated via the primary server so a better way to test is by making the secondary server the primary for the test instead of just stopping calls on the primary. I have the port rest issue you described and I will restart my conversation manager to see if it resolves my issue.
Login to share your discussion activity with your friends on Facebook. You can control what you share and turn off sharing anytime.
Your Facebook friends can now see that you have started this discussion
Your Facebook friends can now see that you have commented on this discussion
Your Facebook friends can now see that you have read this discussion