Transfers through call director to ACD dropping calls.

[JoeShmo]

We're experiencing dropped calls when being transferred through a NuPoint schedule callflow that automatically blind transfers to an ACD queue.

Heres what happens:
End user calls our 800#, hits 1 and talks to an agent in a particular department.  That agent needs to forward the call to another department (Lets say Student Accounts).
Student account's main number (example 1234) is on a phantom IP set so we can reroute always to NuPoint.
NuPoint has a CallFlow only mailbox 1234, which has a schedule.  Off hours, it plays a message, then hangs up.  On-Hours, it blind transfers to their ACD queue (lets say 4567), with a supressed prompt (so all the caller hears is a kind of double or studdered ring as nupoint transfers the call).

Now, it seems if the queue is totally empty, all is fine.  However, if theres any wait, the call gets silently dropped.
I'm GUESSING that NuPoint isn't getting the answer supervision from ACD, and thus the default 20 second "Time to No Answer" is kicking in.

In another post: http://mitelforums.com/forum/index.php/topic,1731.msg6429.html#msg6429 there was talk about this, but an ACD was not involved.  The user was able to cheat and just loop the call back to the final destination when it returned to nupoint.  I think doing this with an ACD group would be a mess.

Now, to make things MORE fun, NuPoint hangs off of controller #4 (a vMCD box).  All phones also hang off of that box.  However, the ACD paths are on controller #2 (an MXe II, which basically acts as a media gateway).

all MCDs are ver 4.2 SP2 (10.2.2.10)
NuPoint is 14.2.1.21.01

Any help would be appreciated.  And sorry if I missed somethinghere, i always seem to leave off a detail (like a version number) but in this case, I've included those.

Edit:  The obvious solution would be to have everyone transfer to the queue pilot number instead of the pubished number, as that would avoid nupoint all together...  is there any other way?)

[ralph]

Double check your ACD path to be sure it has RADs then call each RAD to be sure they're working.
Secondly, verify the ACD path overflow timer and what it's overflowing to.   If the timer is too short and the action on timeout is drop this could cause the symptom you have.
Also, call the ACD path by dialing it directly via a phone.   Test what happens when there are no agents avail.

Ralph

[JoeShmo]

Thanks for the replies and suggestions.
I've checked the RADs, and they seem to be working (at least when I checked them).
There are 2 skill groups.  The 3rd skill group ID is blank.  Interflow enabled after 15 minutes, and goes to NuPoint (where in NuPoint, I havnt traced yet, but thats 15 minutes away...)

Note (which I forgot to mention... I always seem to leave a detail out) Is that when the first agent was able to transfer directly to that 2nd queue (via a system speedcall that hit their ACD queue as opposed to going throught the schedule in NuPoint), it worked perfectly fine for months.  But as soon as I redirected to callflow to put that schedule in there, thats when we started having this problem.
Thus, I'm thinking its some sort of multi-transferring issue (transferring a call to someone else whos transferring a call)... recall times can get fun in these situations.  Especially when dealing with trunking between these nodes (all nodes clustered)