Unity plays error, then plays Call Handler Standard Greeting anyway

[Melinda Merrick]

Hello,

I have a customer with a UCCX script that allows callers to enter 1-digit menu options, or a 4-digit extension, the latter of which transfers the call to CUCM and rings the phone/DN for that extension.  When entering most 4-digit extensions (e.g. 5501) the user's phone rings, then connects to Unity as expected if they don't pick up the call.

I have a specific DN - 5099 that is behaving differently.  That DN is set to Forward All to Unity Connection since it does not live on a physical phone.  In Unity there is a Call Handler with 5099 as the extension.   When dialing 5099 from that prompt, callers hear the Unity error "I did not recognize that as a valid entry" but then it immediately connects to the Standard Greeting for the Call Handler with 5099.  

I'm quite stumped, and would love to hear if anyone else has an idea why that error would play but still connect the caller to the Standard Greeting.

Regards,

Melinda 

[jasonlnielsen]

If your Unity Connection is integrated via SIP, I would do this...

1. Remove the DN number of 5099

2. Add a route pattern of 5099 that points to the UCXN SIP Trunk Route List

or

1. Remove the DN Number of 5099

2. Add a route pattern of 5099 that points to the UCXN SIP Trunk Route List

3. Remove the number assigned to the Call Handler

4. Create a Direct Routing rule to send he call to the appropriate Call Handler.

"Dialed Number" "In" "5099"

Send Call to:

Select the "Call Handler" radio button and then choose the Call Handler you would like to send the call to.

The caller should hear the Call Handler greeting every time.

When you create a DN with a call forward, it is looking for a voicemail box. You can use RTMT to view the incoming called number and how it is handled.

Jason

HTH

[Melinda Merrick]

Hi Jason,

Can you help me understand why a Route Pattern would behave differently/better than a DN?  I have used DNs in the past to route to Call Handlers with no issue.

I am hesitant to switch to a Route Pattern in case they want to add the DN to a phone, to answer it live or use it for MWI in the future. 

Regards,

Melinda

[jasonlnielsen]

I was nearly explaining how I would do it from experience.

1. With Routing rules I can be more flexible in Unity Connection.

2. If you are creating a DN that is not assigned to a device, then I have experienced issues where if you search for unassigned DN's, and want to delete them because they are no longer in use or seem to be because they aren't assigned, that "active" DNs were accidentally deleted and has caused major issues.

It is all on how you choose to manage your Dial Plan in CUCM.

Everyone does things differently for sure. I believe it is good to see how others do it as it certainly has helped me to refine my methods.

Unity Connection is very flexible.

With your transfer from UCCX, what time of transfer are you using?

Jason

[Melinda Merrick]

As part of my troubleshooting I actually assigned the DN to a CTI Port so it had a "device" associated, which I assigned to the same DP, CSS, etc as an existing branch phone. This didn't change the behavior.  

I've seen some people use dummy MACs (e.g. 0000ABCD1234) for this type of DN, but that uses licenses, while a CTI Port (not a CTI Route Point) acts like a device, but does not consume any licenses. At least it didn't before the new CUWL user model. 

Would setting up a Unity Routing Rule work if it was still a DN? I've never worked with those before, since Unity usually just happily routes your call correctly based on the Extension.

I have attached the part of the script doing this transfer (a standard call redirect) in my original post.

Melinda

[jasonlnielsen]

It is been my experience, when transferring calls from UCCX to UCXN, that a supervise transfer works best.

Call Redirects handle calls differently into UCXN vs a Supervise Transfer.

This is true when sending calls directly to a voicemail box.

I use a Supervise Transfer and then use the Direct to Voicemail option, such as *5099. I will always go directly to the box.

Think about it this way...

You are transferring the call to voicemail. If I were on the call with a person and I wanted to send the caller to the users voicemail, how would I do it.

1. Put the caller on hold

2. Dial the number to send the caller directly to VM ie. *5099

3. Press Transfer

So I would use a "supervise transfer" as my UCCX transfer option.

I hope that explanation helps

Jason

[Deepak Rawat]

What happens if you call 5099 directly rather than the call being routed through UCCX.

Regards

Deepak

[Melinda Merrick]

Hi Deepak,

When an employee dials the DN 5099 from his phone, it connects to the greeting for that Call Handler with no error.

This leads me to believe that more than just the "5099" digits are being passed from UCCX to CUCM (and then on to Unity), but I can't find any place in the script that would happen. 

Regards,
Melinda

[Deepak Rawat · Accepted solution]

Melinda that definitely points that in both these scenarios the redirecting id is not the same and hence behaviour is also different. How about running a Port Status Monitor and verifying and then if needed play with Routing Rules or something on CUCM to parse on the exact digits Unity is expecting.

Regards

Deepak

[Melinda Merrick]

With a colleague's help at the customer site, were able to figure out what was happening, and resolve this issue. 

Using Port Status Monitor we saw that an extra DTMF digit [9] was being passed to Unity while the Standard Greeting on the Call Handler was playing.  That extra digit caused the Error greeting to play before continuing with the Standard Greeting. 

We added a Delay 2 sec step right before the Redirect step in the UCCX script, and it no longer sent that extra DTMF digit to Unity. Problem solved.

Regards,

Melinda

PS I'm still a little perplexed why that extra digit was being sent, since I've used that same Redirect step in many scripts over the years with no issue.