Additional Calls to Welcome Greeting Busy while Greeting is Playing

[tyler.smith]

I am attempting to establish a help desk hunt pilot utilizing CUC to play a welcome greeting before transferring the caller to the hunt pilot members. Current setup is CUBE ISR 4431 to CUCM CTI Route Point to CUC System Call Handler to playing the greeting to CUCM Hunt Pilot. Any initial call, whether internal or external, functions as intended. However, any additional call, whether internal or external, will get a busy tone ONLY while the greeting message is playing. If the initial call passes through to the hunt pilot members and is answered, the next call can proceed to the greeting and follow through to the hunt pilot members. The line group I have configured for the CTI route point voicemail is 10 voicemail ports configured in there and I have 75 total voicemail ports configured on Unity and CUCM. There is something that I am missing that is preventing additional calls to be received while the welcome greeting is playing. This also affects voicemail calling in general. If one extension calls into voicemail, another extension cannot call into voicemail either. 

[Carlo Poggiarelli]

Hi,

I guess that after the Call Handler greeting you are sending the call to a cucm Hut pilot —>Hunt List—>Line Group where you added some DN.

Which is the the Line Group distribution algorithm?

What is the value of revision timer?

Also, make sure that all phones you added to that line group have “logged on hunt “ is checked.

Please let me know 

Regards

Carlo

[tyler.smith]

Line group distribution is broadcast and 20 on the timer. Yes all members are logged in to the hunt group. As I said in the initial post, the members ring and can receive the call it is only additional calls while the greeting is playing for the first call. It also does it just attempting to call into voicemail from a second phone and extension it is busy unless the first extension is done calling into voicemail.

[Carlo Poggiarelli]

Hi,

Try to change the distribution algorithm from broadcast to top down and see if it makes the difference.

HTH

Regards

Carlo

[tyler.smith]

It doesn't. I had tried that already. Since it does not pertain only to the hunt pilot, and causes the same issue with the voice-mail directly, I believe the issue lies within CUC and the voice-mail ports although I have deleted these all and reconfigured them it isn't not accepting additional calls as if it were related to port exhaustion. 

[Carlo Poggiarelli]

Ok,

If all VM ports are correctly registered, reset the hunt list related to VM line group. Than on UCNx reset the port group.

Also reset the conversation manager service on UCNx

Please let me know 

Regards

Carlo

[Maren Mahoney]

What you are experiencing is normal behavior. CUC will play a greeting sequentially, not in parallel.

If your purpose is to play a greeting before extending the call to a Hunt Pilot, may I suggest that you set up Native Call Queuing on the Hunt Pilot, and then only roll to voicemail when the call is not answered. This would simplify your call handling (CUBE to Hunt Pilot - Normal Call Distribution - Roll to VM) with no CTI Route Point or loop to and from CUC needed. The greeting can be played in parallel. As an added bonus, CUCM will provide simple call queuing in the event your line group members are busy.

The above link is a practical How-To for Native Call Queuing. Here is a link to that feature in the Feature Guide for CUCM 14 which has more detail: Feature Configuration Guide for CUCM 14 - Chapter: Configure Call Queuing 

Maren

[Carlo Poggiarelli]

Hi @Maren Mahoney  

What @tyler.smith  is experiencing doesn’t seem to be a normal behavior while (AFAIK) multiple calls are allowed to voicemail pilot and call handlers regardless the greeting is playing or not. 

Maybe I’m missing the point.

Cheers

Carlo

[Jonathan Schulenberg]

Agreed. Since this is a SCCP integration instead of SIP, my first guess is that the hunt for CUC VM ports itself isn’t configured properly; that CUCM isn’t hunting to a subsequent VM port. This would impact all types of calls to CUC (e.g., two people leaving a message concurrently), not just this call flow though. You could also use the the rPSM tool to see if the second call ever touches CUC.

[tyler.smith]

What I had was the RTMT running logs in real time and I had it up and running on both the CUC and CUCM. CUC did not see the call attempt but CUCM did. 

[Carlo Poggiarelli]

Hi Tyler,

Please double check the VM line group. It seems that you have VM port on that.

Also a screenshot of your VM Line group would be useful

Thanks a lot

Carlo

[Maren Mahoney]

And also a screenshot from CUC showing the configuration (as in: enabled for what) of the ports you have carved out for the CTI Route Point connections. What made you decide to have a set of dedicated ports for the CTIRP rather than sending the calls to the whole group of 75 ports?

@Carlo Poggiarelli and @Jonathan Schulenberg - You are right about the behavior. I'm not sure what I was thinking....

Maren

[tyler.smith]

Attached are the ports configured on CUC. This is only a small number of them but they are all configured the same. I built a system on 12.5 a while back and had this entire system working without issue and no CTI route point configured. All voicemail and hunt pilot to greetings were working flawlessly. We had to expand our dedicated VLAN for VoIP and change the network the original servers were hosted in to a new one, and I took that opportunity to build new servers running version 14. I configured everything the same as the 12.5 environment, minus the adjustments for IP space, and it never worked the same. I messed around for a few weeks then pulled in Cisco TAC and they had me configure the CTI route point based on their documentation for a setup like this. I have also been sending logs and days of troubleshooting with them now to solve this issue with no solution. 

[Pranjol Saikia]

Hi tyler.smith
In case your requirement is still open please check if below 3rd party solution "MARS Agent Greeting" for Cisco CUCM solves your requirement.
https://developer.cisco.com/ecosystem/cpp/solutions/181073/