I currently have a single CM 3.1.3a cluster connected to Unity 3.1.4 with Exchange 5.5 as the UM message store off-box. I will be installing a second CM cluster in a new location. The two CM clusters will be connected with an H.323 intercluster trunk. I will connect the new cluster to the same Unity server.
Once this is in place, all of the users in CM Cluster 1 (old location) will be physically moving to CM Cluster 2 (new location) over several weeks. They will get a new extension in the new cluster.
Here is my question - If I configure each current subscriber with an alternate extension that matches their new DN in the new location after they move, does anything else need to happen? Does Unity know which cluster the calls come from? Does it care? I'm trying to make the move process as much "hands-off" as I can to allow them flexibility on moving users.
If just the alternate extensions are added, Unity will still try to send MWI to the originally entered subscriber DTMF ID. It might make sense to change the primary DTMF ID altogether. If that's not feasible, there is also support for Alternate MWIs. Unity will send MWI to the primary and any alternate MWIs set. If the primary MWI in Unity is no longer valid, there will be a ton of event log errors from the TSP.
As long as the Unity server has MWI ports connected to each cluster, it should be allright. Unity won't really know which cluster it is connected to and for the most part doesn't care (there is one technicality I'll discuss in a moment).
You'd probably want to make sure tha the bulk of the Unity ports that handle incoming calls are all connected to the cluster that will have the most Unity calls and forwards. For instance if all Unity subscribers will move form C1 to C2, and the port assignments don't move, all voice to Unity will (unecessarily) traverse the inter-cluster trunk.
There will be one condition where Unity will "care" about clusters: any transfers Unity does that traverses clusters. If a call originating from C1 goes into Unity and Unity transfers the call to a phone on C2, the calling party on C2's phone will be the extension of the Unity port doing the transfer. If that call to C2 forwards back to Unity, Unity will not accept the call if the extension numbers of the Unity ports are entered on the SA. Unity will "see" that a call is coming from itself and won't answer it. If the extension numbers are not on the Ports page, this won't happen.
Just to be clear, when the user moves to the new location, their phone gets a new DN. I will pre-configure each current subscriber with an alternate extension to match the new extension they will get when they move. Now, when the new phone forwards to Unity, I'm hoping it will still go to their mailbox since their new DN matches their alternate extension.
Thanks for the MWI info. I'm planning on cleaning up each subscriber account after the users moves so the old extension is removed and the new extension is configured as the primary in Unity. This will also clean up dialing by extension or by name from the main menu.
For the ports, I understand that I need to have one Unity port per cluster dedicated for MWI. The remaining ports can be allocated to the two clusters. I'll plan on reallocating the distribution of ports as users move from C1 to C2 to keep the traffic local.
I'm not clear on the issues with clusters. If someone calls a phone on C1, the call forwards to Unity, the caller then somehow is able to transfer to a phone in C2, and that call rolls to voicemail, Unity will not accept the call. Did I get that right? What did you mean by "If the extension numbers are not on the Ports page, this won't happen"?
It doesn't sound like your site uses autoattendant transfers so you may not need to worry about this.
If you do use transfers, Unity will by default attempt transfers to the subscriber's primary DTMF Id. After you adjust this (change subscriber's transfer string to transfer to their new alternate extension or change their primary DTMF Id to match their new extension), then you take a look at the issue with transfers across Inter Cluster Trunks that Steve describers. The details are in CSCdu64641.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...