Transfering calls to a menu prompt stopped working

[phlegmer]

Greetings all,

A couple weeks ago, our PBX went down due to power issues. Never a good way to bring a PBX down I know but it is what it is. Ever since that has happened, our front desk person claims that she can no longer transfer calls to our menu prompts.

All of our menu prompts are housed and managed by CallPilot (version 3 on an i201). We have sort of a mix of how the menu prompt DN's are programmed. Some are ACD's which forward to Call Pilot and others are phantoms which also forward to Call Pilot. Either way this is done, the result is the same.

When a caller is transferred to a menu, the caller hears a second or two of dead air, then a fast busy signal. When I've tested this, I've discovered as long as I can transfer the caller before the menu prompt answers, the transfer will work. However, this is quite difficult since the menu prompts almost answer instantly. I have yet to do it successfully on a 3904 since I have to wait for the transfer soft key to pop up again. I can do it on a 2008 / 2616 with hard keys but it needs to be done VERY fast.

I've chatted with someone about this and he was telling me that you can not do a "blind" transfer to a menu prompt. That is why it doesn't work when it answers.

Well, our front desk never had any problems transfering callers to menu prompts prior to the power outage. So something changed. I've already reboot Call Pilot and that didn't make a difference. If menu prompts truly can't take "blind" transfers, is there any way to keep it from answering so fast? Perhaps within App Builder do a ring back or two first?

If more details are required, please let me know.

Thanks all in advance!

 

[phlegmer]

Sorry, the Call Pilot is on a 201i not an i201. And the PBX is a 61C

Thanks

 

[johnpoole]

usually when things change post reboot... look at your rcaps.. what can happen is someone makes a change on a dchannel or even the cdb.. the reboot redownloads the msdl cards.. or the check sum sees a cfn change and reloads that file...

look at the cdn and acd for mail.. they may have does the same thing...

your looking at anything that modifies answer supervision.. {asup}.. it could even be a timer.. but timers would be my last guess...

i know i didn't help much, but something that writes on just a reload changed.. (a lot of ground to cover)

john poole
bellsouth business
columbia,sc

 

[phonz1]

can you hit the menu from an internal call?

 

[phlegmer]

Yes, calling the menu directly from internal and external works fine. Transferring to ACDN's and other DN's work just fine also. It's only menu prompts.

 

[phonz1]

in call pilot there is a session trace and in the PBX, you can trace the number dialed. If you are positive that nothing has changed, then you'll have to see where that call IS going by tracing it

 

[phlegmer]

I've asked some of my colleagues about what you suggested and they don't know how to do a session trace. They've heard of MCT (Malicious Call Trace) but have never messed with it. Where would one find info on how to set this up?

Thanks!

 

[phonz1]

a session trace is a pretty detailed report run in Call Pilot, it'll track events of a call from the time it hits the voice mail system. I would try to find out more in the NTP's, not hard to set up but a couple of steps to it

 

[phlegmer]

Would the session trace be the one under LD 36 (Trunk Diagnostic)

 

[phonz1]

no, it is in call pilot

 

[phlegmer]

I'm sorry but I can't find what it is that you are referring to. Every week we have a company wide PBX meeting and I brought this topic up. No one seemed to know where in CP to do this trace you mentioned. Someone suggested to adjust the RCO for the menu prompt. However, after doing a little more reading on RCO, that won't help either. RCO is the number of ring cycles before CFNA.

Could you shed a little more light as to how this trace is accomplished?

Thanks