Calls dropping due to RAD ports in DND

[AH64Armament]

I thought I'd share this experience with everyone.

Customer was getting complaints that calls were dropping before answering. During my investigation, I found that the calls weren't being answered by the agents, and they were dropping from the CO at exactly 1:00 minute. This was telling me that the carrier wasn't recognizing that the call had been answered.

As a band-aid, we set the interflow for 40 seconds while we investigated the issue.

When I tested, I thought it was odd that I was only hearing ringback, but I didn't connect that dot until I woke in the middle of the night to let the dogs outside... hmm, DND???

I checked this morning and sure enough, all their RAD ports were in DND. I cleared them. Adjusted the interflow time back to 1:30 and called in... it played the RAD greetings appropriately and rolled to their answering service properly at 1:30.

I grabbed a stopwatch and timed all 3 of the greetings. I separated the 3 greetings into 3 Classes of Service, and adjusted each COS for the length of each greeting plus 2 seconds.

I tested to ensure they could clear DND from their phones and provided instructions as to how to check.

I would have thought that DND set like this wouldn't survive a reboot.

Does anyone have experience with this issue? How have you solved it?

 

[Valamagules]

DND on RAD ports is not uncommon. Have seen this alot, especially on Embedded VM ports.
Raised issue Mitel a couple of times and upgrade was the identified solution.
I think it's something to do with timers.

What version SW you running?

I don't see the reason for creating 3 separate CoS for each greeting.
As it work well with adjusting the Answer Plus Message Length Timer to be equal or longer than the longest RAD message.

I have prefered going dynamic RAD (MiCC) or NuPoint if they are available.

Clever men learns what Wise men shares!

 

[AH64Armament]

The system is running MiVB 8.0 SP1 PR3

I've had this issue in the past at other sites and the RADs switching to DND tends to get overlooked when troubleshooting... just as this did. I was troubleshooting this as a carrier issue last Friday and through the weekend... as the call was dropped from the carrier side at exactly 1 minute.
To band-aid this, we dropped the interflow timer to 40 seconds and they didn't lose the calls.
While testing, I had noted that I didn't hear the RAD - only ringback, but I didn't connect the two until I woke in the middle of the night to let the dogs out.

Anyhow, I cleared the DND and it resolved the issue for the moment.

I agree with you that only one RAD COS should be used, but previous troubleshooting at other locations indicated that the RAD COS would need to be split up to the timers adjusted to a couple seconds longer than each RAD.

I haven't used any MiCC RADs aside from the MiCC training class. NuPoint does work well, but this site doesn't have NuPoint. So I'm using some ports of the Embedded Voicemail... overall this has worked pretty well.

My original issue though is frustrating - Since the call isn't being answered by a device - RAD, ACD Agent, User, Auto Attendant; the carrier isn't recognizing that the call has in fact been answered by the ACD path.... so it drops the call at 1:00 minute.

 

[jpruder]

I make sure to put them in a rad hunt group

 

[thohiopatriot]

My experience is the same as above it is normally always a timer in the COS. The timer must be fairly close to the actual length of the recording.

 

[Bigsin]

I have seen this for many years.
Mitel never able to solve this.
What I lately have done is programmed 15 Embedded rad ports for a customer.
Number 16 in de rad group was an MiCC IVR Rad port.
If all 15 embedded Rad ports are working fine, number 16 will never be used.
Until all 15 embedded ports are in DND.

I programmed in the RAD workflow an email instruction.
The email instruction is sending an email to the servicedesk.
In the body of thes email I put instructions how to get rid of the DND of the embedded RAD ports.

If this problem occurs it's now fixed within minutes.