CTI RP Tranf to DN but won't go to their VM

[MitelInMyBlood]

UCXN 8.02
CUCM 8.62

I have a CTI RP sending calls to a call hdlr, then menu options that tranf callers to either one of two (different) CTI RPs. I have these secondary RPs set up in multiple user profiles so that the end user(s) can use CCMUSER to change the on-call person at will. All this works as intended.

The end users want to send callers to their internal DNs (this works) and then if no answer have the call drop into the (respective user's VM (this doesn't work).

Instead of releasing the call to VM, UCXN appears to be performing a supervised xfr, even tho the menu options are set to release the call to the switch. Callers hear 'sorry that ext doesn't answer' etc.

Obviously I've missed something in programming this, but it's not readily obvious. Do I need to add these 2 secondary CTI RPs as alternate exts in the end user's VM profile? Can multiple UCXN end users even have (share) the same alternate ext? (or did I miss something in programming the secondary CTI RPs?)

Thanks in advance.


Original MUG/NAMU Charter Member

 

[MitelInMyBlood]

Some correction here in the trouble report.

After researching this further, the CTI RP can successfully transfer calls to the end user's DN, but when the call is unanswered it is landing in VM without integration.

VM is seeing the DN of the CTI RP instead of the DN that the call was transferred to.

The client swears this was working, and doesn't know when it broke. However, we recently upgraded the call manager from 8.0.2 to 8.6.2(a)

Original MUG/NAMU Charter Member

 

[MitelInMyBlood]

ANYONE?

Port monitor in UCXN is seeing the DN of the CTI RP rather than the DN that the CTI RP is transferring to. Hence the internal ext is ringing as it should, but the call retains the identity of the CTI RP when the call goes to VM. We need it to assume the identity of the transfer-to destination. The problem is this destination DN is an internal number.

If the user presses iDivert during the ring cycle the call goes into voice mail correctly, but if allowed to simply get to VM as a result of expiry of the CFNA timer (or if the user is set for CFA) it lands in VM looking for a mailbox matching the DN of the CTI RP.

We cannot use "Alternate Extension" in the user's VM profile because the CTI RP is shared among many users who change the 'forward-to' number weekly based on their callout schedule.

Why the user insists on after-hours on-call going to their internal Dn then to internal VM for their on-call notification beats the proverbial deficatory waste out of me, but it's what they've historically used in the past and being creatures of habit they're not embracing change.

a Call Handler can do this but the problem is they have no means to change the on-call person at will with a call-handler without pestering us to make the (weekly) change for them.

thanks

Original MUG/NAMU Charter Member

 

[MitelInMyBlood]

Hack:

By creating a new partition, CSS and route pattern to permit a specific internal number to hair-pin out & back in through the PSTN, I've been able to achieve what I needed to do. Arguably a kludge, but works. However, a new glitch was discovered in that the hack does not work if the internal (destination) DN is CFA or CFB to Voice Mail. The call still sets up but UCXN will not release the caller into the final destination mailbox if the DN is CFA to VM. As long as the call is first allowed to ring on the destination DN then it will find its way into the assiciated mailbox.

This looks like a bug in the code someplace as we can dupe this rather easily. Reduced to simplest terms, the bug is that one UCXN mailbox cannot send a call to another mailbox on the same system if there is a CTI RP in the call path, i.e., anywhere in the path between the 1st and 2nd mailbox.

Example, mailbox 5101 accepts caller input to send the caller to DN 5103 and if no answer then to mailbox 5103. This works. However, if mailbox 5101 sends the caller to CTI RP 5102 which in turn sends the call to DN 5103, the DN (5103) will ring but the call will never find its way into mailbox 5103.

Why would someone even want to do this in the first place? Because they are using the CTI RP to periodically change the destination, depending upon who is on call. In other words, they are using CCMUSER to manage the CTI RP forwarding destination.


Original MUG/NAMU Charter Member