Enterprise Alternate Numbers Forwarding to Unity Connection

[Joseph Innis]

I recently setup a +E.164 dial plan that also utilizes 7-digit Enterprise Alternate Numbers (EANs). When dialing the EAN internally and allowing the unanswered call to forward to Unity, we found that CUCM is sending +1???XXXXXXX (replace the Xs with the actual digits) to Unity Connection. To allow the unanswered call to the 7-digit EAN to hit the correct voicemail account, I created an alternate extension on the account using exactly what CUCM is sending to Unity (+1???XXXXXXX) and it works. While troubleshooting a related issue, we used the Remote Port Status Monitor to watch the inbound call from CUCM to Unity and found that CUCM is using the 10-digit voicemail pilot to send the 7-digit EAN to Unity, which is why CUCM is appending +1??? to the front. Below are some of the line configs that I am using:

Line DN - \+1XXXXXXXXXX in the 10-Digit-Internal-PT

EAN DN - XXXXXXX in the 7-Digit-EAN-Internal-PT

Voicemail Profile consists of:

10-Digit voicemail pilot - +12215000000 masked with +1XXXXXXXXXX

Has anyone else experienced this? I have also set up a CTIRP with a *XXXXXXX pattern associated with a 7-digit voicemail profile that allows users to forward calls to voicemail, which means I now have to have two alternate extensions associated to the voicemail account: +1???XXXXXXX & XXXXXXX. Not ideal, but its working.

Thanks,

Joe

[Maren Mahoney]

I set this up in my lab just now to look at the problem and am getting the same results. I'm curious what is causing you to mask the phone number in the voicemail profile if your internal DNs are already in E164 format? With both SCCP and SIP integrations, the E164 number is passed to CUC in plus format.

As for the EANs, yes you must have an alternate extension set in CUC to match the EAN. But if you are not masking the dialed number at the voicemail profile then you would only need a single alternate extension in CUC.

[Maren Mahoney]

Although it also occurs to me that you could have the call route on Last Redirected number rather than the original dialed number. If you dial an EAN, Unity Connection will set that as the original dialed number, but will include the parent DN as the Last Redirected number.

This setting can be changed at: System Settings -> Advanced -> Conversations

The parameter name is: Use Last (Rather than First) Redirecting Number for Routing Incoming Call

But it is a system-wide setting and so will also affect calls to numbers that have been forwarded to another extension by having the call roll to the voicemail box of the forwarded party (rather than the forwarding party which would be the original dialed number). This may not suit your enterprise.

[Joseph Innis]

Hi Maren,

Thank you so much for your replies and I apologize that its taken me almost a month to respond. I think its important to also note that I'm currently having to support two dial plans in this environment: 4-digit and +E.164. That explains the need for the mask on the voicemail profile. Eventually, the 4-digit legacy dialing will go away as will the 4-digit voicemail pilot, which I believe will ultimately solve all my problems. I think the immediate solution here lies in your second response regarding the last redirecting number. Unfortunately, I have not been able to apply that theory in this environment since its a global setting.  If I get the opportunity to test that solution, I will be sure to respond with my results.

Thanks again,

Joe Innis

[Maren Mahoney]

Do you have two voicemail profiles configured? One for the 4-digit extensions and one for the E.164 extensions? The profiles can go to the same pilot and the same server, but can have different masks.

If the 4-digit extensions are masked at the profile for +1NPANXXxxxx then the EAN should mask out as well. You would have to have a different profile with a different mask for each NPANXX combination, but all of the numbers would port in E164 format without having to change the parameter. (Which really is not a good one to change anyway.)

[Joseph Innis]

Yes, I do have multiple voicemail profiles in place:



2215 masked as XXXX

2215000 masked as XXXXXXX

+12215000000 masked as +1XXXXXXXXXX



Are you saying that I should be able to use 2215 for all three, but just mask each voicemail profile according to whichever dial-plan is invoking the pilot? For instance:



2215 masked as XXXX for 4-digit DNs

2215 masked as XXXXXXX for 7-digit EANs

2215 masked as +1XXXXXXXXXX for +E.164 DNs

[Maren Mahoney]

The mask does not change the pilot number for VMs, the mask alters the user's number before it is sent to Unity Connection...so I'm not sure I understood what you wrote just now. But here is a more thorough explanation of what I was thinking:

Assumed: All of the users in Unity Connection have an E164 number as their extension and a 7-digit EAN as an alternate number:

For users who currently have their DN in E164 format, have a voicemail profile that does not mask the number as all. E164 and EAN should match.

For users whose DNs are 4-digits, have a voicemail profile that masks +1703555XXXX (or whatever). Providing the last four of the EAN is the same as the DN then calls should match the primary extension regardless of whether the 4-digit DN or the 7-digit EAN is dialed. Once those users are converted over to E164 DNs, change their profile over to the first one.

Repeat the previous for all NPANXX combinations like +1703222XXXX and +1408777XXXX etc.

If all of your users will be converted to E164 numbers eventually, changing their Unity Connection extension to that now is work you'd have to do at some point anyway.

Does this match what your environment, or did I miss something?