Unity Connect UCM port registration

[b.eman]

Currently have a Unity Connect set up in a failover configration at two diffrent datacenters. UCM is also located at multiple locations, cluster includes 4 subs.  My goal is to make sure that the primary UC appliance registers to the Sub located in the same datacenter.  Vice Versa I would like the secondary UC appliance to register to the sub in the same location.

It is my understanding that the UC port registration priority order is not controled by UCM device pool.  I belive it is controlled within UC Telephony port config.  The issue I have is you can only put port priorities on the UCM servers.  Even with the port priority that does not garentee where the UC server will register.

Is there a way to garentee which UCM box that UC registers to?  For example UC box 1 registers to Sub1, Sub2, then Sub3,  Where UC box 2 registers to Sub3, Sub4, then Sub1.

Thanks

[Jonathan Schulenberg · Accepted solution]

You can control this by assigning a CallManager Group with only the desired nodes that you want each server to communicate with. The CMG is an ordered list so that will address your need to set a preferred order. Create two different device pools and assign the appropriate CMG to each.

If you're using SCCP set the Device Pool appropriately on the Voicemail Ports. If you're using SIP set it on the SIP Trunk.

[b.eman]

Thanks for the quick reply makes sense, thanks for your help.

[William Bell]

Actually, I think that the Port Group configurations in CUC would override the CMGroup settings in CUCM. At least, on a quick check in my lab I can juggle registrations simply by modifying the Port Group settings on my CUC system. I did not need to modify CUCM groups or device pools. To me this means that CUC Port Group settings are at least as important as CMGroup configurations in CUCM.

I don't have a definitive answer for the OP yet. I don't have a cluster built to easily test. I believe that you have to manage port group configurations on each CUC cluster node independantly. If this is true, then I have a hypothesis that I cannot directly confirm at this time. You can create different Port Group server assignments on each CUC cluster node. So, for example, the publisher node uses CUCM-A, CUCM-B, CUCM-C in the CUC Port Group while the subscriber node uses CUCM-C, CUCM-B, CUCM-A.

Assuming my hypothesis is correct, I would also suggest matching the CUCM CMGroup configurations to the CUC Port Group configurations. Even if behavior shows that the Port Group configurations take precedent, I still think it best to make sure they match up. In the past I have seen odd behaviors when CMGroups didn't align with trunk members on ICTs.  Similar connection type here.

Again, I am not able to test this with my current lab setup.

HTH.

Regards,
Bill

[Jonathan Schulenberg]

Excellent input William; I overlooked that part. +5

[b.eman]

That is what I was afraid of.

If that is true and I have total of 144 ports I would have to divide my ports into two groups?  For example PhoneSystem-1 would contain Sub1, Sub2, Sub3 in that priority order and would consist of 72 ports.  Then I would create another group PhoneSystem-2 that would contain Sub3, Sub2, Sub1 in that priority order.  I guess I would have to delete all ports currently associated with my secondary UC box and readd them using PhoneSystem-2 Group.

I also would have to make sure any UCM server I add in UC I would also be in my Device Pool.

Am I close?  Seems like lot of work.

[Jonathan Schulenberg]

That sounds correct. Another option would be to use a SIP integration instead which eliminates the CUCM-side mess but you'll still need to split your port groups up on Unity.

[b.eman]

Thanks, I will try.

[William Bell]

Yes, something along those lines. Again, I can't test step-by-step procedures at the present moment.

I know it may not be pertinent, but I am wondering why you want to do this. Certainly, I can understand the initial inclination of segregating your environment to have call control traffic stay within distinct geographic locations.  However, I am wondering if you have found any problems to reinforce this initial inclination. I guess I am thinking about ICCS and other realtime communications that happen between CUCM and CUC cluster notes. If the network is capable of providing reliable delivery of these communication channels, then why wouldn't it be able to handle 144 SCCP connections (or 1 SIP connect)?  The bandwidth for the SCCP connections will be quite small and if that was a concern, then SIP could be a viable alternative (though, there are potential trade-offs here as well).

Anyway, it is a tangent question. I am not trying to dissuade you. I am just curious as to what problems you may have seen with the current setup. Note that you don't have to see problems to warrant change, I am just gathering data for my own education.

HTH.

Regards,

Bill

[b.eman]

No evidence or hard facts to substantiate the move more just thinking of a best practice.  This was something I have never really paid attention to but a customer was asking me why the ports did not use the Device Pool for priority order so figured it was time to discover how this works. Seems to me that by keeping the UC and UCM registration at the same location could eliminate some unforeseen network issues if they were to happen.

Thanks for your help, I will update after I make the changes.