Calls Terminate On What Should Be A Successful Connection

[capitalfinanceone]

we have a new problem we have ran the phone system under a test and we have found that when real calls are accepted the phone system is hanging up. What do you advise?

 

In summary this is what's happening outbound calls gets made and the caller picks the phone up and the Voice Guide terminates the call.

 

The number in particular is 07939402308 I will attach the respective files.

[SupportTeam]

Please post the vgEngine and ktTel trace files (.ZIPed) and we can then look at the traces and advise what happened on that call.

[capitalfinanceone]

Here are the respective files!

1112_ktTel.zip

1112_1710_vgEngine.zip

additional.zip

[mji2010]

I am having the same exact problem. It dials the number and then when some one picks up, the message doesn't play and then after a while... the call will just hang up.

 

From time to time it will work, but not constantly.

[SupportTeam]

Mark_I - please start a new topic and post the post the vgEngine and ktTel trace files (.ZIPed) from your system which capture the outgoing call. Please indicate the telephone number and/or time of the call so we can identify which call in the traces to look at.

[SupportTeam]

Arun:

 

From the traces provided in the "additional" ZIP it looks like you have ACD agents logged in and you would like for incoming calls to be sent to them, correct? Right now the script that you are using to answer incoming calls is the default "Credit Card Payment" script. This script does not put the incoming callers into an ACD queue - so calls never get routed to agents which are waiting for ACD calls to be directed to them.

 

You should edit VoiceGuide's Config.xml file to ensure that any incoming calls are answered by your script that then puts callers in the ACD queue - so VoiceGuide's ACD can then forward those calls to the agents.

 

 

The other vgEngine log file provided is 7MB in size and contains about 400 outbound calls. On many of the calls the Dialogic card reported that most likely an Answering Machine answered the call (see attached grep output), and looks like the outbound calls loaded specify that in cases when an Answering Machine answered the call then a dial RETRY should be made - so the call is hung up and that number is dialed again at a later time. (ie. a RETRY setting is specified in the Answering Machine script field).

If you think that too many of the outgoing calls get mistakenly detected as 'Answering Machines' then you can use a script that places all calls categorized as 'Answering Machines' into the ACD queue as well, and let the agents leave a message on the answering machine, or speak to the person if that call was in fact answered by a live person. ie. just specify DISABLE in the Answering Machine script field - then every answered call gets immediately placed in ACD queue and connected to agent.

StateHangingUp.txt

[capitalfinanceone]

Thanks Support!

 

However note I am not concerned about inbound calls right now as we are dealing with that outside of Voiceguide. So therefore I have not implement ACD to take inbound as we are only dealing with outbound using VG.

 

What should I change to try and ensure we can get real calls and not have them incorrectly identified! The number which I provided before was that classed as a answermachine.

 

Do we need to adjust a setting on the dialogic or a setting in VG? Also what is a grep output?

 

I do not want to allow all answermachine calls through as we would not get the full benefits of VG. However if there is nothing I can change then I will have to start accepting answermachine calls!

 

Please advise me what our options are and what we must do!

 

Regards,

[capitalfinanceone]

Also how do I use the AMorLA.vgs answermachine script so that I can pass this to the agent for Outbound dialing?

[SupportTeam]

Trace shows that Dialogic card reported that 07939402308 was answered by an Answering Machine.

 

Please read: http://www.voiceguide.com/vghelp/source/html/detectcallanswer.htm section "False reports of an Answer Machine answer when a Live Peron actually answered the call"

 

On outbound calls you can run a script when Answering Machine answer is detected instead of just specifying "RETRY", and in this script you can play a message that asks person to press 1 to be connected to operator. If no "1" press is made then the script can just hangup as most likely this call was in fact answered by an answering machine. You can also use the $RV[AmWelcMsg] (as described in help file) to try to further classify if call is Live or AM.

 

Many call centers have agent leave a message on answering machines as well - so it doesn't matter to them whether call is answered by Live or AM - in which case you do not need to do any Live/AM detection at all, and just connect call to agent when outgoing call is answered - you can do this as you are using an ISDN system that informs you instantly when outgoing call is answered.

To make this happen just disable the answering machine detection by specifying DISABLE in the Answering Machine script field.

 

 

 

112150.760 408 28 fn LineMakeCall(iLineId=28, iCallRequestId=0 (ignored), strNumberToCall=[907939402308], callprog=DX_PAMDOPTEN, timeout=60, params:0,0,cid=[(null)],opt=[])

...

112201.065 3408 28 CtEventProcess idx=327 : evttype=2082(2082), crn=02800034, data=08868108(08369B30), len=28(28) q: 0/1

112201.065 3408 28 ev GCEV_CONNECTED (ktTel_SR60 v7.1.0, Aug 25 2009 14:39:20)

112201.065 3408 28 routing voice to network as Dial_zsOtherCallProgressSettings=[]

112201.065 3408 route resources (dtiB1T10) call

112201.065 3408 28 Route_VoiceResource_To_dti begin dxxxB3C2:30 to dtiB1T10:28 (linedev=28)

112201.252 3408 call progress: started listening on chdev 30

112201.252 3408 28 GCEV_CONNECTED gc_GetCallInfo >> ATDX_CONNTYPE=4, iRet=0, strConstName=[GCCT_NA], strRet=[]

112201.252 3408 28 t_info: gcValue=0(0x0) gcMsg=[success] ccLibId=2 ccLibName=[GC_ISDN_LIB] ccValue=[0x0] ccMsg=[No error] additionalinfo=[]

112201.252 3408 28 CTelProxy::Event_CallState GCEV_CONNECTED iLineCallState=256, hCall=41943092 m_pktTelProxyClient=0068140C

112201.252 3408 28 r CallState GCEV_CONNECTED

...

112204.168 3408 30 CtEventProcess idx=333 : evttype=133(133), crn=00000000, data=08868228(0831F7F0), len=0(0) q: 0/1

112204.168 3408 30 ev TDX_CALLP (Call Progress Completed)

112204.168 3408 30 TDX_CALLP CR_CNCT (called line was connected)

112204.168 3408 30 TDX_CALLP CR_CNCT CON_PAMD ( connection due to Positive Answering Machine Detection)

112204.168 3408 30 shortlow 0ms, longlow 0ms, ansrsiz 0ms

112204.168 3408 28 CTelProxy::Event_CallState TDX_CALLP_CR_CNCT iLineCallState=256, hCall=41943092 m_pktTelProxyClient=0068140C

112204.168 3408 28 r CallState TDX_CALLP_CR_CNCT

112204.168 3408 28 r Dialogic TDX_CALLP 133 (10 4 0 TDX_CALLP CR_CNCT CON_PAMD)