- Purple, 4500 points or more
I am testing several scenarios in my lab with two separate (non-clusted) CUC nodes and I have come across some peculiar behavior with cross-cluster login and cross cluster transfer.
CUC Version: 7.1(3b)SU2 (7.1.3ES26.32900-26)
CUCM 7.1(3b)SU2 (two node cluster)
CUC-A (single node CUC)
CUC-B (single node CUC)
For sake of this discussion, assume the following:
PhoneA - Cisco IP phone with extension configured on CUC-A
PhoneB - Cisco IP phone with extension configured on CUC-B
PhoneC - PSTN phone (or Cisco IP phone with no voicemail)
PhoneD - PSTN phone with DN set as an alternate extension for PhoneA on CUC-A
1. Transfers from CUC-B to CUC-A (and vice-versa) works. Example, PhoneC calls CUC-B and gets general greeting. PhoneC enters extension for PhoneA and is transferred.
2. Users on CUC-B sending messages to CUC-A (and vice-versa) works. Example, PhoneA calls CUC-A and logs in. PhoneA user chooses to create a message (opt 2) and adds a recipient from CUC-B (e.g. PhoneB user). Message sent and received OK.
3. Users calling from phones that are not configured as a subscriber extension or alternate extension works. Example, PhoneC calls CUC-A and presses "*" to enter Sign-in dialog, user provides PhoneB extension and PhoneB voicemail password. CUC-A says "one moment please" and successfully sends caller to CUC-B. User is logged in and hears the review messages prompt.
4. Callers with DNs that are configured as alternate extension can access their voicemail box if they call the correct CUC server. Example, PhoneD calls CUC-A. CUC-A prompts the caller for this voicemail password (i.e. CUC-A does not ask for mailbox extension).
What doesn't work:
1. If PhoneA calls the pilot number for CUC-B, the CUC-B server says "one moment please". At this point, CUC-B is trying to log the user into CUC-A but this fails. The issue happens if PhoneB calls CUC-A as well (more details below).
2. If PhoneA forwards their phone to CUC-B and any caller calls PhoneA, they land on CUC-B and receive OpenTrees (standard opening greeting).
3. If PhoneD (which is an alternate extension for PhoneA on CUC-A) calls CUC-B, the CUC-B server says "one moment please". At this point CUC-B is trying to log the user into CUC-A but this fails. (more details below).
I used "Remote Port Status Monitor" on both CUC-A and CUC-B during testing. From these tools I can see that in failure scenario #1 and #3 (under "what doesn't work") are doing the same thing. Using the examples provided, CUC-B recognized the extension (primary or alternate) correctly. It then attempts to connect to the CUC-A server and execute a login sequence. The CUC-A server asks for the password but the CUC-B server never asked the user for this information, therefore it can't provide the password (maybe it sends blank?). In either case, the login fails and the callers receive the message "sorry your cisco unity connection home server cannot be reached at this time". After this, they receive the open trees greeting for CUC-B.
Interestingly enough, if you do either #1 or #3 more times than allowed by your user's credential policy, you can lockout the user account. That's awesome.
For issue #2, the CUC server receiving the initial call setup receives the proper CLID information but doesn't appear to be checking extensions that are in partitions from the other CUC system. I have checked partitions and search scopes and I don't see a conflict.
The Use Case and Why is this a problem?
The use case illustrated by issue #3 under "what doesn't work": Customer has two CUC clusters for 15,000 users. They have a toll free number they give to users to call into voicemail. This toll free number points to CUC-A but there are users on CUC-B that will call that toll free number. If we stop here, then there is no issue. BUT, if the user wants to add their mobile phone or home phone as an alternate extension, then no CUC-B user will be able to use the toll free number to access voicemail. Worse, if they try it a few times (which they likely would) then their account will get locked out. While I am sure that this isn't a universal use case, I definitely don't think it is unique.
The use case for issue #1 is similar to #3 but it is less likely to be a problem. Internal phones will likely hit their messages button which is mapped to the correct server. Communications can be provided to ensure people know their correct internal number (if needed) and, in the worst case scenario, a translation can be used to "trick" users into dialing the correct number.
While issue #2 by itself is not a viable use case, what it tests actually may be. The scenario is "overflow". Let's say the customer uses IMAP. This limits them to 72 ports on the mcs7845. Further assume the customer needs more than 72 ports for audio during peak busy hour and/or burst. Now, if the cluster is healthy we can overflow to the second server in the cluster. But if the cluster takes a hit and the customer wants to "overflow" to the second cluster, forwarded calls will not integrate. I assume that one could try to use call handlers to pick out certain NPANXX ranges and then have the call handler transfer to a CTI RP on the CUCM using some funky prefix which will send the call to the other cluster. But I haven't tested that yet and it is kinda ugly.
OK, so this was long winded but I don't like thread-banter so I figured I would provide all details. While I could see where issue #2 and my argued use case is probably outside of scope for the feature provided by CUC cross cluster transfer/login. I definitely think the use case for issue #3 is valid and I don't see anything in the documentation that suggests it wouldn't be. So, in this case I am either running into a defect or I have a configuration issue. Therein lies my question.
Thanks for tuning in and thanks in advance for any advice you provide.