bizarre rad message configuration

[ausername]

Hey guys,

I can`t explain why this situation is going on:

Hunt group mode: Terminal
Hunt group type: Rad
COS: 8   (the proper one)
Hunt group member: 6015

6015 is part of the VM Ports form.  Its being listed as a Prime Directory Number associated with Port ID 15.

In the VM Greetings form, Port ID 15 is configured with Greeting: Rad Set 10

When I dial 6015, immediately I get a constant tone on the line.  There`s no ringing, just a persistent tone.

Now, I find this issue weird because VM port 6020 is working fine at the moment and is configured with Rad Set 10.  If I dial 6020, the line rings briefly and the message of Rad Set 10 is being heard.


What`s going on with port 6015?

HALP

[JasonTL]

If you look in the station attributes form does 6015 have the same COS as the working port of 6020?

[ausername]

If you look in the station attributes form does 6015 have the same COS as the working port of 6020?

yup, they're all using COS 8

[ralph]

When you say "persistent tone" do you mean on long tone or a broken tone the keeps going?

Under maintenance, do a "Locate Feature <ext>".
I'm betting you'll find the RAD in DND.

Ralph

[ausername]

When you say "persistent tone" do you mean on long tone or a broken tone the keeps going?

Under maintenance, do a "Locate Feature <ext>".
I'm betting you'll find the RAD in DND.

Ralph

You sir are correct:
VM Port : 714                                                                   
Circuit Location : 1 4 27 15 1                                                 
Extension : 6015                                                               
Active Features :                                                               
Do Not Disturb                                                                 
Service Level: Full                                                             
Zone ID: 1

[ausername]

I fixed it by finding out what was my "do not disturb - cancel remote"  feature access code and then dialing that code followed by the extension.

thanks!!

[ralph]

The reason a RAD will go into DND is because the message is longer that the expected off hook timer or the RAD doesn't answer.

The message length timer will cut off the message if it's shorter than the message.

I generally max both of those out.

Ralph

[ausername]

The reason a RAD will go into DND is because the message is longer that the expected off hook timer or the RAD doesn't answer.

The message length timer will cut off the message if it's shorter than the message.

I generally max both of those out.

Ralph

I've set the timer for RAD: Answer Plus expected off-hook timer to its maximum value of 255 seconds.  Is there anything else I should do?

edit:  i've also maxed out RAD: answer plus message length timer to 120 seconds

[ralph]

You should be good.  As long as the port answers it shouldn't go into dnd.

Ralph

[Dogbreath]

Pretty sure you can also avoid this problem by disabling DND in the CoS for the RAD port. I did this for a customer where they had a large spike in call volume and the RADs for their main ACD path kept going DND. I can't find where I read that this was recommended but I can find something that contradicts it :

http://micc.mitel.com/kb/KnowledgebaseArticle51359.aspx

Also, if you're not on site, you can use the DND form to take a RAD out of DND.

[ZuluAlpha]

That article that contradicts keeping a RAD port out of DND is strange. What conceivable reason would one have for putting a RAD port in DND?

[Dogbreath]

"failed to answer" is one reason, apparently:

Time  10:50:39
Source  Call Control - Software
Description  CPRADP: RAD failed to answer. RAD Extension: 4002

and it's the system that does it, not a person.