embedded RAD is cut off before playing entire message

[jjirishnh]

I am having a hard time trying to figure out which timer is causing the problem I will describere here. Any help would be greatly appreciated.

I have recently updated the 2nd (and repeated message) from our call center ACD path.
I am on a MItel 3300 using embedded VM as my RAD source.

This morning the recordings were changed, and the first recording plays fine ... I have the timer set in the ACD path to play the second recording after 1 minute. It plays at the right time but it cuts out before the entire message has played. The message about 15 seconds long. In the COS for my embedded RADs the options are set like this

Answer Plus Delay To Message Timer 0

Answer Plus Expected Off-hook Timer 27

Answer Plus Message Length Timer 17

Answer Plus System Reroute Timer 0

Recorded Announcement Device Yes

Recorded Announcement Device - Advanced Yes


I have changed the Answer Plus Message length timer to larger values, but the message always cuts out at the same place.

When I go and listen to the recording from the admin VM box the entire message plays, but when I call the pilot number for the hunt group that the rad is in, the message does not finish playing.

What am I missing here?

Thanks in advance for any help

 

[Mitel_specialist]

What happens when you dial the number of the RAD instead of the hunt group number where the RAD is in?
Does the huntgroup has call rerouting on it? Remove this and test again.
When I make a RAD the 'Answer Plus Expected off-hook timer' is 2 seconds longer then the 'Message lenght timer'. In your case it is 10 seconds longer.

 

[Billz66]

do you have the same cos applied to the RAD hunt group ?
how many ports are in the group

i had these notes
The ANSWER PLUS - Message Length Timer should be 2 secs longer than the message and the
ANSWER PLUS - Expected Off-hook Timer should be 5 secs longer

if the expected off-hook timer is too long the system detects that the RAD has failed to clear down,
then it is placed into an internal do not disturb state when the timer expires. "


If I never did anything I'd never done before , I'd never do anything.....

 

[jjirishnh]

Here's an update, I assumed (wrongly) that both my RADs shared the same COS. They do not. Once I figured that out and adjusted the timers in the correct cos it worked out fine.

The one problem that continues is that I have noticed that each of the RADs on a couple of accions in the past 7 days have been put into DND. Could this be the result of improper timing between the first and second message?

I know in the past, the way call center agents would logout vs make busy would cause DND condition to happen. Any ideas?

 

[Billz66]

direct calls to rads can cause that , also the pabx can do it sometimes
- make sure that dnd is enabled in the COS as the MICC server should be able to remove the DND status

If I never did anything I'd never done before , I'd never do anything.....