Jump to content


< Back to Forum


 

Answer Detection For Call Out Is Too Slow. (Vg 7.5 With Hmp On Esxi)


  • Please log in to reply

#1 iTime 29 March 2017 - 10:29 AM

Hello Support,

 

Our VG has an issue with  detecting when user answers calls.

The attached log shows one Dial-out activity; the VG started processing about 10 seconds after the user kept saying, "hello."

The delay period varies but it is usually really slow to determine a user has answered the call.

 

Would it be a  configuration issue or VoIP?

Please help.

 

Thank you.

 

 



#2 SupportTeam 29 March 2017 - 10:49 AM

That system was set to perform a determination on that outgoing call of whether the outgoing call was answered by a human or an answering machine.

 

To make that determination to party answering the call has to say/play something. Then HMP/VoiceGuide can decide whether the sound that it hears is from an answering machine/voicemail or from a live person.

 

The number that was dialed was: 1234567890@ld01-05.fs.broadvox.net

 

What happened when that number was answered? Was there perhaps a 10 second silence before any sound was transmitted on the connection?

 

Can you please load another call to this number but this time disable the answering machine detection on that call, and just start a script that consists of a single "Record" module upon call answer.

Then please .ZIP up the recorded sound file and post it here.

 

 

vgEngine trace shows:

170606.974  15               dial  some calls found ID/GUID=446/ec417ac1-61f0-4320-8aee-3131cb225b8b, tel=, sTaskTimestamp=170606.973, diff=00:00:00.0010001

170606.986   8   3   1       dial  StartOutgoingCall start tel[1234567890@ld01-05.fs.broadvox.net] live[C:\Program Files (x86)\VoiceGuide\Scripts\IntelliTime\Login.vgs] am[C:\Program Files (x86)\VoiceGuide\Scripts\IntelliTime\HiringLeaveMsgForAM.vgs] fax[] onNotAnswered[C:\Program Files (x86)\VoiceGuide\Scripts\IntelliTime\VbsExecutable\vbsExePostHangUp_Hiring.vbs] onRetriesEnd[] rv[[UserID]{78297},[ShiftID]{2413067},[IsHiring]{true},[AutoNotifyCallID]{442},[LeaveMsgOnAM]{1},] CampaignName[442] options[] ID=446

170606.996   8   3   1 state Dialing (auto) 1234567890@ld01-05.fs.broadvox.net

170607.009   9   3   1 ev    ktTel_Completion (genericEv) 10000 0,Completion_MakeCall, crn=8000001, 134217729,0,0,1234567890@ld01-05.fs.broadvox.net,,<result>ok</result><crn>134217729</crn><crnx>8000001</crnx>

170607.015  23   3   1 ev    CallState GCEV_DIALING, crn=8000001, iEvent=0 ,16,0,16, s1:, s2:, s3:]. build_date: 11-Oct-16 13:57:17.75

170612.264  23   3   1 ev    Dialogic 2081,GCEV_ALERTING, crn=8000001, 2081,0,0,,,

170621.399  23   3   1 ev    CallState GCEV_CONNECTED, crn=8000001, iEvent=0 ,256,2,4, s1:, s2:, s3:]. build_date: 11-Oct-16 13:57:17.75

170632.093  23   3   1 ev    Dialogic 133,TDX_CALLP, crn=8000001, 10,3,0,CR_CNCT,CON_PVD,

170632.099   8   3   1 state Human answer. Start [C:\Program Files (x86)\VoiceGuide\Scripts\IntelliTime\Login.vgs]

ktTel trace:

437 170607.000  6028   3 fn    LineMakeCall(iLineId=3, iCallRequestId=0 (ignored), strNumberToCall=[7143932211@ld01-05.fs.broadvox.net], callprog=DX_PAMDOPTEN, timeout=30, params:0,0,cidtosend=[],opt=[])

465 170607.013  5876   3 ev    GCEV_DIALING crn=8000001 crn_lastMakeCall=8000001

477 170612.264  5876   3 ev    GCEV_ALERTING crn=8000001 (ktTel_HMP30vista v7.5.5, Oct  7 2016 17:44:48)

507 170621.397  5876   3 ev    GCEV_CONNECTED (ktTel_HMP30vista v7.5.5, Oct  7 2016 17:44:48)

523 170632.092  5876   2 ev    TDX_CALLP (Call Progress Completed)
524 170632.093  5876   3       TDX_CALLP CR_CNCT (called line was connected)
525 170632.093  5876   3       TDX_CALLP CR_CNCT CON_PVD (connection due to Positive Voice Detection)


#3 iTime 30 March 2017 - 10:03 AM

 

 

What happened when that number was answered? Was there perhaps a 10 second silence before any sound was transmitted on the connection?

 

The call was answered by our tester; it was a test call on our test server, and he spoke "Hello" immediately. Please note that the status monitor shows "Dialing....", not status of showing detecting AM or anything even after the user's greeting.

And the Answering machine detection has already been disabled, thus I can say this 10 seconds of duration was not taken by Dialogic determining if it is an answering machine.

 

The funny thing is that I noticed today that Answer detection (the 10 seconds duration) is much faster after the very first call from restart of VG service (The log from the previous post is gained after service restart; we were restarting the VG service frequently yesterday for our testing)

In another words, It seems that response time gets shorter after the first call out. (The server has been up and running for a day and it works normal now)

 

Let me try a bit further on this symptom and contact you for this matter if it happens again.

Thanks.



#4 SupportTeam 30 March 2017 - 10:27 AM

The Answering Machine detection was enabled on that call.

 

Here is the call that was made:

170606.996   8   3   1       dial  making call LineState settings: tel[1234567890@ld01-05.fs.broadvox.net] live[C:\Program Files (x86)\VoiceGuide\Scripts\IntelliTime\Login.vgs] am[C:\Program Files (x86)\VoiceGuide\Scripts\IntelliTime\HiringLeaveMsgForAM.vgs] fax[] noAnswer[C:\Program Files (x86)\VoiceGuide\Scripts\IntelliTime\VbsExecutable\vbsExePostHangUp_Hiring.vbs] retriesEnd[] OnHangup[] rv[[UserID]{78297},[ShiftID]{2413067},[IsHiring]{true},[AutoNotifyCallID]{442},[LeaveMsgOnAM]{1},[OutDial_RetriesLeft]{0}[OutDial_CampaignName]{442}[OutDial_ID]{446}[OutDial_GUID]{ec417ac1-61f0-4320-8aee-3131cb225b8b}] options=[]

Note that the Answering Machine script is specified:

 

C:\Program Files (x86)\VoiceGuide\Scripts\IntelliTime\HiringLeaveMsgForAM.vgs

 

 

If you want to disable the Answering Machine detection then please specify:

 

disable

 

for the Answering Machine script. (see: http://www.voiceguid...ntroduction.htm )

 

If the Answering Machine detection is disabled then the "Live Answer" script will start intermediately when the call has been answered.

 

 

 

 

The Line Status Monitor should have been giving feedback on the 'Connected' event,

 

The 'state' of the line is included in vgEngine trace, and that is the state that is reported by the Line Status Monitor.

here is what it should display for that line (note number of "." at end of first 3 states) :

 

 

When the Dial command has been sent to HMP:

170607.015   8   3   1 state Dialing (auto) 1234567890@ld01-05.fs.broadvox.net .

When the HMP confirmed it is dialing:

170607.015  23   3   1 ev    CallState GCEV_DIALING, crn=8000001, iEvent=0 ,16,0,16, s1:, s2:, s3:]. build_date: 11-Oct-16 13:57:17.75
170607.026   8   3   1 state Dialing (auto) 1234567890@ld01-05.fs.broadvox.net ..

When Telco advised that destination number is ringing:

170612.264  23   3   1 ev    Dialogic 2081,GCEV_ALERTING, crn=8000001, 2081,0,0,,,
170612.265  23   3   1 state Dialing (auto) 1234567890@ld01-05.fs.broadvox.net ...

When call was answered:

170621.399  23   3   1 ev    CallState GCEV_CONNECTED, crn=8000001, iEvent=0 ,256,2,4, s1:, s2:, s3:]. build_date: 11-Oct-16 13:57:17.75
170621.400   8   3   1 state Dialing (auto) 1234567890@ld01-05.fs.broadvox.net ... connected

When HMP started trying to decide if call was answered by human or by machine/voicemail:

170621.406   8   3   1 state Dialing (auto) 1234567890@ld01-05.fs.broadvox.net ... connected, doing answer detection... (DX_PAMDOPTEN)

When HMP decided that it was a human:

170632.093  23   3   1 ev    Dialogic 133,TDX_CALLP, crn=8000001, 10,3,0,CR_CNCT,CON_PVD,
170632.099   8   3   1 state Human answer. Start [C:\Program Files (x86)\VoiceGuide\Scripts\IntelliTime\Login.vgs]

and then the VoiceGuide script started running:

170632.140  25   3   1 state [CheckTaskType] RunScript vbs, onhold=
170633.351  30         rem   remoting link constructor activated: vgServices_CommandLink
170633.364  30   3   1 rem   RvSet_RvList [PlayWelcomeGetEmpNumber]{550500}[GetAppointment]{}[GreetFilePath]{WAV Files\Login_OutdialLoginGreet.wav,WAV Files\Common_CallingFor.wav}[blnIsAppointmentValid]{true}[blnIsMultipleAppointment]{false}[intRetries]{5}[intRetriesTemp]{6}[EmpName]{ RACHEL POTTER}[GreetPasswordPath]{WAV Files\Login_OutdialLoginPassword.wav}
170633.366  30   3   1 rem   Run_ResultReturn [success] 7
170633.373   8   3   1 state [IsHiringRequested] Evaluate ["$RV[IsHiring]" = "true"]
170633.385   8   3   1 state [IsRevertedFromAM] Evaluate ["$RV[RevertAMDetection]" <> ""]
170633.395   8   3   1 state [PlayCallOutGreetings] tts generate start (len=14)
170633.487   8   3   1 state [PlayCallOutGreetings] Playing wav (WAV Files\Login_OutdialLoginGreet.wav,WAV Files\Common_CallingFor.wav, C:\Program Files (x86)\VoiceGuide\temp\tts_3_1.wav)
170639.866  23   3   1 ev    PlayEnd 3 394050 [bytes_played=0:0, bytes_in_file=49787]
170639.878   8   3   1 state [GetPasswordForDialOut] Playing wav (WAV Files\Login_OutdialLoginPassword.wav)

Must say we would expect to see the execution speed between states to be faster though...

 

This system is running on ESXi. What is the actual hardware that it is running on and how many Cores and how much memory has been exclusively allocated to the VM on which VoiceGuide is running on?

 

 

 

NB. System is running VoiceGuide v7.5 version, and is running on Windows Server 2008 R2, on ESXi :

170456.352   6               ------------------------------------------------------------------------------------------------------
170456.352   6               vgEngine : 7.5.6128.25119 RELEASE options75
170456.352   6               Compiled : 11-Oct-16 13:57:17.75
170456.352   6               Location : C:\Program Files (x86)\VoiceGuide\vgEngine.dll
170456.353   6               Written  : 2016-10-10 21:32:16
170456.353   6               trace lvl=10, encoding=System.Text.ASCIIEncoding (ASCII)
170456.353   6               ------------------------------------------------------------------------------------------------------


#5 SupportTeam 30 March 2017 - 10:39 AM

Are you able to post the full hardware description of the base system and the configuration of this ESXi instance that shows allocated cores/memory/etc ?

 

Is VoiceGuide perhaps assigned a 'hyper-threaded' core and the other part of that physical core is used by another system?

 

Please ensure that ESXi is not doing "Hyperthreaded Core Sharing". Please set the ESXi "Hyperthreaded Core Sharing" option to "none".



#6 iTime 31 March 2017 - 03:42 AM

Thanks for your reply.

Please see below questions and answers to your questions above:

 

Note that the Answering Machine script is specified:

 

C:\Program Files (x86)\VoiceGuide\Scripts\IntelliTime\HiringLeaveMsgForAM.vgs

 

 

We "disabled" the following selection in vg.ini: AM_DetectionMode=Disabled

That being said, the vg.ini configuration will be overridden if the script path for "am[]" is sent?
 

 

170612.265  23   3   1 state Dialing (auto) 1234567890@ld01-05.fs.broadvox.net ...

When call was answered:

170621.399  23   3   1 ev    CallState GCEV_CONNECTED, crn=8000001, iEvent=0 ,256,2,4, s1:, s2:, s3:]. build_date: 11-Oct-16 13:57:17.75

 

Even though the log shows the person picked up and answered in 10 seconds, what actually happened was that the tester picked up the phone and said "Hello" almost immediately when phone started ringing. I was observing the status monitor at that time, and could tell VG was still showing "Dialing...." during that 10 seconds even after the phone was answered.

 

 

Are you able to post the full hardware description of the base system and the configuration of this ESXi instance that shows allocated cores/memory/etc ?

 

Memory: 128 GB RAM
CPU: 16 Cores (2 oct cores) -  Intel® Xeon® CPU E5-2630 v3 @ 2.40GH

RAID PLUS SAN environment: Please note this IVR server with VG is running on SAN environment. (Would it cause the problem?)

 

We have 4 VMs under this box, and most of the configurations are set to use default values. 

 

Please ensure that ESXi is not doing "Hyperthreaded Core Sharing". Please set the ESXi "Hyperthreaded Core Sharing" option to "none".

 

We can change the setting to "none" as suggested, but would it be OK for other VMs under this hypervisor performance wise?

 

 

Thanks again for your tip and help!



#7 SupportTeam 31 March 2017 - 03:50 PM

We "disabled" the following selection in vg.ini: AM_DetectionMode=Disabled

That being said, the vg.ini configuration will be overridden if the script path for "am[]" is sent?
 

Yes. If the 'Answering Machine' script is set then the AM detection is enabled on that call.
Confirming as advised before: If you want to disable the Answering Machine detection then please specify:

disable

for the Answering Machine script.

 

 

Even though the log shows the person picked up and answered in 10 seconds, what actually happened was that the tester picked up the phone and said "Hello" almost immediately when phone started ringing.

 

Please make multiple tests to check exactly what is going on on this system.

 

Recommend using WireShark to track SIP mesage s as they arrive. Use this in the WireShark's Filter text box:

 

sip

 

It's very important to confirm that you have reliable SIP comms and that SIP mesages that arrive at your system represent what is actually happening..

 

For testing purposes are you able the see/hear the dialed telephone at the same time as seeing the screen with the WireShark trace and the VoiceGuide Line Status Monitor ?

 

 



#8 iTime 01 April 2017 - 01:38 AM

Thanks for the tip.

I actually was going to test this with Wireshark this time, but could no longer reproduce the symptom.

I could not try to set the option of Hypervisor, "Multithreaded sharing" to "none" because our network admin did not like the idea, reason being it may adversely affect other 3 VMs under the machine.

However, he moved the HardDrv from SAN to one of a local RAID drive, making it faster; I am not sure if that was the cause but the symptom went away at some point of time with this change.

If this happens again, I will try to use Wireshark to see if SIP (or RTP) reaches to the server as suggested.

 

I guess we may close this case at this point, but thank you again very much for all of your help.