Outdial Call Recipients Complain About Pauses

[MannyTC]

I am getting complaints from some of my customers that the outdial calls they are receiving have what seems to be long pauses in the area of the TTS where the Result Variables are inserted. They also complain that they are not getting prompted for a response which means that VG is detecting as an answering machine when in fact human. When I test this myself things seem to work fine with the exception of the occasional false human/answering machine detection. I have gotten about 25 complaints in the last 2 weeks about this so I know it must really be happening.

 

Can you suggest where I should start looking for the problem? I am using Windows 2000 SP4 with a D4/PCI card currently using just 1 line. I am using the Neospeech TTS engine. The system is a P4 2.66 with 512MB RAM and Voiceguide is the only app running on this system.

[SupportTeam]

If the answered call is judged by the Dialogic card to be an answering machine then VoiceGuide will wait until there is some silence on the line before it will play the answering machine script.

 

Length and level of silence is regulated in these VG.INI settings:

 

AM_SilenceDetectLength

AM_SilenceDetectLevel

 

by default I think Length is set to 2 seconds which is a bit long, so you can adjust that down...

 

If calls are made on low quality phone connections then the Dialogic card will mistake more human answers for an answering machine answer...

 

You can set the answering machine script to "ignore" if you wand all answered calls to be treated as human answers.

 

Also, you should not start the script with TTS - start it with a pre-recorded sound file - that way there will be no delay at all due to TTS generation.

 

Could you please post a copy of VoiceGuide's Debug Printout which captures the outgoing call this will allow us to see how long the TTS generation takes (it should only be a small fraction of a second...)

 

 

When running the script click on VoiceGuide's View menu and select 'Event Trace Log' option - any log information will then appear in this window. You must open the trace window before making the call.

 

You can enable the automatic saving of the logs to files in \log\ directory as well.

[MannyTC]

I will get the logs posted here tomorrow most likely. I did try to have the script first play a pre-recorded wav instead of TTS and had the same problem as in another post I made on the forum a week or so ago. There is about a 2 second pause between the two play modules even though I have the first one set with a path of timeout 0 pointing to the second module. This happens even if they are both pre-recorded. I will get logs for you on this as well.

[SupportTeam]

There is about a 2 second pause between the two play modules

Have you checked that the sound files themselves do not have any silence recorded at their beginning and end?

 

Please post a trace just showing two Play modules playing pre-recorded files one after another.

 

We have not seen any delays with starting of playing of sound files in following modules, so I suspect that your problems are related either to TTS or to the silences within the sound files themselves...

[MannyTC]

ok here is the log from the most recent person that complained. I wish we had a copy of the TTS.wav file that was generated to hear what was on it in case somehow this is a TTS issue.

 

182613.12 5 timer fired EV_TIMEOUT_ATERIDLE_ALLOWOUT

182613.13 5 ScriptEventCode 9013 iLineState=900

182613.51 5 dial [6165,*82,(999) (555-5555),501252204,1800,2030,MoTuWeThFrSaSu,,dxxxB1C1,,0,,C:\RemPlus\Human.vgs,C:\RemPlus\Ans_Mach.vgs,[RecordID]{20050112113808126793TWARD012505}[PatFirstName]{Lind

}[Appt_Date]{Friday, January 28}[Appt_Time]{1:00 PM}[Dr_LastName]{Smith},60,2,30,C:\RemPlus\No_Ans.vb script:[C:\RemPlus\DBAnsMac.vgs]

182715.36 0 LoadedVgs_Find C:\RemPlus\DBAnsMac.vgs at idx=7

182715.39 5 tapi Reply (LineEvReply) ok 66405 0

182715.41 5 timer clear

182715.44 5 [update Database] Running VB Script...

182715.45 5 rv replace start (strlen>500)

182715.47 5 rv ns [RecordID]{20050112113808126793TWARD012505}[PatFirstName]{Linda}[Appt_Date]{Frid

y, January 28}[Appt_Time]{1:00 PM}[Dr_LastName]{Smith}[OutDial_RetriesLeft]{2}[scriptEnd_Time]{1/26/2005 6:26:51 PM}[scriptEnd_Goto_Script]{C:\RemPlus\Ans_Mach.vgs}[scriptEnd_Goto_Module]{}[scriptStart_Time]{1/26/2005 6:26:51 PM}[scriptStart_CalledFrom_Module]{Update Database}[scriptsPath]{C:\RemPlus\}[Hangup Time]{1/26/2005 6:27:14 PM}

182715.50 5 eng copy of script ran: vbs_5_1.vbs

182715.53 5 Run Script waiting. iRunWait=1 (shellid=600, process=1840)

182715.56 5 timer set 1 EV_TIMEOUT_CHECKONSTATE

182716.56 5 timer fired EV_TIMEOUT_CHECKONSTATE

182716.58 5 ScriptEventCode 9007 iLineState=1501

182716.59 5 LsRunWaitTillFinished EV_TIMEOUT_CHECKONSTATE

182716.61 5 task completed (shellid=600, process=1840) vgm=16, iRunWait=1, iRunWait_ExeResult_NextVgm=0

182716.64 5 No information returned from program to VG (no VGRUNRESULT_5.TXT or SHLRESLT.TXT)

182716.66 5 rv add [Hangup Time]{1/26/2005 6:27:16 PM}

182716.67 5 Hanging up call... [WaitTillFinished - next module not specified]

182716.69 5 HangupCall_Common Mode=AfterHangupRun

182716.72 5 ReinitTelephony due to IDLE

182716.75 5 tapic lineDeallocateCall(MainCall:66456) 0

182717.39 5 lineOpen(5)=>

182717.41 5 Waiting for a call...

182717.44 5 LineHandle=66029

182717.47 5 timer set 10 EV_TIMEOUT_ATERIDLE_ALLOWOUT

 

By the way, the people complaining about this issue are not always detected as an answering machine. Not sure why you added that to the subject of this post.

[SupportTeam]

Have you adjusted these VG.INI settings?:

 

AM_SilenceDetectLength

AM_SilenceDetectLevel

 

What are the current values for the above settings on your system?

 

The trace shows Dialogic indicated that an answering machine answered the call - so right there the system would wait until there was AM_SilenceDetectLength of silence on the line before it would even allow the script to start.

 

And the trace shows that the outgoing script is still beginning with a TTS generated sound file instead of a pre-recorded one.

 

Trace shows that TTS generation takes about 300ms here, which is a bit long as well - but if your AM_SilenceDetectLength is still set to 2 seconds then most of you delay will come from there...

 

And although transitions between states do seem a bit long, overall the TTS sound file starts playing about a second after the silence is reported on the line:

182651.36 5 LsDialoutRecAnswerMachineWelcMsg EV_SILENCE_DETECTED

...

182651.73 5 LsDialoutRecAnswerMachineWelcMsg EV_REC_FINISHED

...

182652.16 5 tts generate start[Hello this is XXXXXXXX calling to remind Linda, that you have an appointment with Doctor Smith on Friday, January 28, scheduled for 1:00 PM. Please contact us at least 24 hours in advance if you must cancel or ree schedule your appointment. Goodbye.]

182652.27 5 tts generate wait

182652.48 5 tts generate finish. lineCallState=DISCONNECTED

182652.50 5 [On Answering Machine] Playing (C:\Program Files\VoiceGuide\data\tts_5_1.wav)

 

Do you by any chance have the Log Trace window opened while making these calls?

It's best to close the window - the log files will still be created in \log\ subdirectory.

 

If you have the log window opened it will slow down the printing of the log tracing and this will affect the speed of the whole system...

 

If you have any examples of calls where people were complaining of slow start of play when the Dialogic card detected them as 'live human' instead of answering machines?

[MannyTC]

I do not have the trace window open. I do always have the logs on though. Can you tell me why the RV replacement that precedes the TTS generation shows the same two lines twice? Should I be concerned about this?

 

I am going to change the script and have it start with a prerecoded file next. Here is the contents of the related section of the vg.ini

 

;AnswerMachine Silence detect length. In 100ms units (20 = 2 seconds)

AM_SilenceDetectLength=15

 

;AnswerMachine SilenceDetectLevel: range: 0-100.

;0 - don't detect silence, 100 - detect loud background noise as silence.

AM_SilenceDetectLevel=10

 

;Minimum length the answering machine message must be.

;Anything less then that will be regarded as a live answer.

;In 100ms units. 20 = 2 seconds

AM_WelcMsgMinLen=20

 

I don't have any specific examples of complaints when detected as a live human answer. Will get those when I can from the person talking these complaints. Any ideas why the transitions see long to you? The system specs on this machine are pretty good and there are not other foreground apps running. There is AntiVirus and UPS monitoring software but no major background services. It is a P4 2.66 with 512MB RAM so it should be fast.

 

I also wanted to upgrade to the latest version of VG. I was going to just download the full setup from the website but was nervous because you have stated in the past that the install will remove completely the previous version. I don't want to lose my calls that are queued up are any other important things. I ended finding the vgmulti3053 file posted elsewhere here and used that. Is that ok?

 

Lastly, is the Dialogic for Analog version something that would speed things up with the ommision of the TAPI layer?

[SupportTeam]

Try

 

AM_SilenceDetectLength=5

 

or even just specify:

 

ignore

 

for the 'Answering Machine' script.

 

There is AntiVirus

...First thing I'd be doing is totally deleting the Antivirus. Depending on which one it is that has the potential of really slowing down your entire system.

 

Some Antivirus do not even delete properly and you end up having to re-install

Windows altogether to get it working properly again...

 

Updating to latest VgMulti.exe is sufficient.

 

The delays you are seeing here have nothing to do with TAPI layer - it's mainly the pause that VG waits for after 'answering machine' message finishes.

[MannyTC]

We are using McAfee Viruscan Enterprise 7.1. I do have the Anti-Virus excluding the VG folder as well as the TTS engine folders to cut down on the possibility of that slowing things down.

 

I can lower the SilenceDetectLength a bit but I do not want to ignore the AM detection completely. I do want to use a different script for when an AM answers. The script for a live person answer prompts for responses that the AM script does not.

[SupportTeam]

So looks like the test should be to set AM_SilenceDetectLength=5 and then start the script with a pre-recorded sound file - judging by the traces from your machine that will save you another 300ms.

 

And I would still remove the virus scan...