SIT 'Unknown' tone

[MannyTC]

I have a setup that dials between 75-100 numbers each day using a D/4PCI. I typically will get 5-10 of those numbers reporting a result of SIT Unknown. If I manually call these numbers to verify the result, I find that most of them go through just fine and are actually good phone numbers. I will hear a SIT tone and message on 1-2 of them when I call but as I said most of them are fine. As another test, if I queue all the SIT Unknown numbers up again most of them will dial and complete the script just fine. The only thing I can think of is that we are having a situation where there is no circuit available on some occasions which I really can't believe happening 5-10 times a night. I would also imagine that if it was a no ciruit issue that the number would then show in the OutDial_SIT_NoCircuit.txt log. Actually the only OutDial log I have on our system is OutDial_SIT_Unknown. I do not have any of the others. Do you have any ideas on what could be the problem? Is it possible to change VG to give me an option to retry those SIT Unknowns if I choose? That might help a little but it doesn't explain why I am having the problem to begin with.

 

On another topic, is there a way to do some further tweaking to get the answering machine detection to be a bit more accurate? We have the usual types of things I hear about like detected a human as an AM and vice versa.

 

Also, is there a way to have the script start playing sooner when a human answers? We find that a lot of people hang up because it takes VG about 2 seconds after the remote party answers and says hello and they think no one is there.

 

Any progress reports on the VG for Analog Dialogic?

 

Thanks for a great product and great support.

[SupportTeam]

We have not had any problems with the Dialogic card falsely detecting SIT tones before. A SIT tone is so specific that it's hard to get a false detection of it... I'd say thtat they are actually happening - but there is no way to really confirm this without independantly recording what is happening o the phone line...

 

I'd recommend just setting retries to 1 or higher - that way even if you get a SIT tone on a call then at least VG will try calling the number at a later time.

 

The answering machine detection really cannot be tweaked - it's all up to the Dialogic card - although it should not take two seconds after 'Hello' for it to indicate that a human has answered the call, usually it's less then a second...

 

VoiceGuide for Dialogic is getting closer to be available for general download - but there is no date yet...

[MannyTC]

As far as I can tell, VG is not properly adhering to the retry parameter I am sending in the XML. The retry is set for 2 on all my numbers. I went through the log in VG and found that for those particular phone numbers, VG tried once OR twice but never three times. In other words, sometimes it runs the OnNotConnected script after the first try and sometimes after the second try. When there is a No Answer or Busy scenario, VG properly retries twice giving me a total of 3 tries. So I think there is a bug somewhere in the retry.

 

I am attaching the log file so you can see this for yourself. The phone numbers (with area codes stripped) that had SIT Unknown are as follows:

 

8632703

6676860

2229816

9444546

6673763

6784099

 

For comparison, the one phone number that had no answer is:

 

4959005

 

Please let me know what you find. I still wish I could tell why it is reporting SIT Unknown. As I said in my first message if I call myself on the same phone line that VG is using the call goes through fine. If we can get the retry to work more reliably that may help some.

1028vgm.txt

[MannyTC]

Sorry, didn't realize there was a little on what could be posted. Please see the original message 2 messages above. I am attaching the log again here in zip format so hopefully that will work.

 

It would be nice if this forum allowed a member to edit his/her post in cases like this.

1028vgm.zip

[SupportTeam]

Please update your VoiceGuide v5.2.3 installation with the attached .exe - this should fix the issue that you are seeing where the 'redial reties' are not correctly counted when a SIT tone is encountered.

VgMulti_5.2.3039.zip

[MannyTC]

Thanks for the prompt fix. Will install it now and let you know if I have any more problems.

[MannyTC]

Okay, I have more to report. Today is the first day of outdialing since installing the new version you sent in the post above. First off, now I am getting SIT_NO CIRCUIT entries when I never got them before. I had suspected that is really what was happening but all I ever got was SIT_UNKNOWN. As I had stated in my earlier post I was surprised that I had never gotten any other SIT messages other than SIT_UNKNOWN since I have been using the product for the last few months.

 

The other thing I checked in the log was to see if these numbers reporting the SIT_UNKNOWN and SIT_NO CIRCUIT were really doing the proper retries. It looks like they are but things seem a little screwy. I had a hard time understanding the log on some of these and it just doesn't look right. As an example on one of the numbers I checked that reported SIT_NO CIRCUIT it looks like VG says an AM was detected. Also the Run VBSCRIPT module that I call at the end of the script has the wrong variables in it. Again, I have to admit it looks all screwy to me. I am included the full log from today and the log from yesterday so you can see the entries of the adds to the queue.

 

Here are the numbers that appeared in the SIT_NO CIRCUIT file.

 

11:01 AM 01/11/04, "*82,438-8503", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20040923110518707545KATHRYN103104}[PatFirstName]{Zakiyyah}[Appt_Date]

Wednesday, November 3}[Appt_Time]{9:00 AM}[Dr_LastName]{Deadrick}[OutDial_RetriesLeft]{0}

07:00 PM 01/11/04, "*82,955-1716", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041020091538010381MARIBEL103104}[PatFirstName]{Alana}[Appt_Date]{We

nesday, November 3}[Appt_Time]{9:30 AM}[Dr_LastName]{Davey}[OutDial_RetriesLeft]{0}

07:01 PM 01/11/04, "*82,438-9013", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041006072206395910ANGELAP103104}[PatFirstName]{Ronald}[Appt_Date]{W

dnesday, November 3}[Appt_Time]{7:00 AM}[Dr_LastName]{Davey}[OutDial_RetriesLeft]{0}

07:02 PM 01/11/04, "*82,992-3276", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041019113545990580TOBEY103104}[PatFirstName]{Maria}[Appt_Date]{Wedn

sday, November 3}[Appt_Time]{1:15 PM}[Dr_LastName]{Brennan}[OutDial_RetriesLeft]{0}

07:03 PM 01/11/04, "*82,667-6680", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041029081106164391KATHRYN103104}[PatFirstName]{Paula}[Appt_Date]{We

nesday, November 3}[Appt_Time]{7:45 AM}[Dr_LastName]{Brennan}[OutDial_RetriesLeft]{0}

07:03 PM 01/11/04, "*82,955-5554", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041028101907779476VERONICA103104}[PatFirstName]{Lucien}[Appt_Date]{

ednesday, November 3}[Appt_Time]{7:30 AM}[Dr_LastName]{Brennan}[OutDial_RetriesLeft]{0}

07:04 PM 01/11/04, "*82,248-8189", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041026090148391997KATHRYN103104}[PatFirstName]{Nicole}[Appt_Date]{W

dnesday, November 3}[Appt_Time]{10:45 AM}[Dr_LastName]{Smith}[OutDial_RetriesLeft]{0}

07:04 PM 01/11/04, "*82,524-9969", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041027135046024575DONNA103104}[PatFirstName]{David}[Appt_Date]{Wedn

sday, November 3}[Appt_Time]{9:00 AM}[Dr_LastName]{Smith}[OutDial_RetriesLeft]{0}

07:05 PM 01/11/04, "*82,864-2782", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041026132347364458KATHRYN103104}[PatFirstName]{Linda}[Appt_Date]{We

nesday, November 3}[Appt_Time]{1:00 PM}[Dr_LastName]{Reed}[OutDial_RetriesLeft]{0}

07:06 PM 01/11/04, "*82,931-4058", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041029154917055361KATHRYN103104}[PatFirstName]{Patricia}[Appt_Date]

Wednesday, November 3}[Appt_Time]{9:45 AM}[Dr_LastName]{Reed}[OutDial_RetriesLeft]{0}

07:07 PM 01/11/04, "*82,907-0425", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20040928152223282471TOBEY103104}[PatFirstName]{Judy}[Appt_Date]{Wedne

day, November 3}[Appt_Time]{9:00 AM}[Dr_LastName]{Reed}[OutDial_RetriesLeft]{0}

07:08 PM 01/11/04, "*82,831-6252", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041011104400990998IVY103104}[PatFirstName]{Joanna}[Appt_Date]{Wedne

day, November 3}[Appt_Time]{2:45 PM}[Dr_LastName]{Deadrick}[OutDial_RetriesLeft]{0}

07:08 PM 01/11/04, "*82,369-1949", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041012154013144822KATHRYN103104}[PatFirstName]{Laura}[Appt_Date]{We

nesday, November 3}[Appt_Time]{2:00 PM}[Dr_LastName]{Deadrick}[OutDial_RetriesLeft]{0}

07:10 PM 01/11/04, "*82,674-0391", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041028092022376520CINDY103104}[PatFirstName]{Corinne}[Appt_Date]{We

nesday, November 3}[Appt_Time]{10:00 AM}[Dr_LastName]{Deadrick}[OutDial_RetriesLeft]{0}

07:10 PM 01/11/04, "*82,218-6902", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041011144132224140KATHRYN103104}[PatFirstName]{Nina}[Appt_Date]{Wed

esday, November 3}[Appt_Time]{9:30 AM}[Dr_LastName]{Deadrick}[OutDial_RetriesLeft]{0}

 

Here is one number that appeared in Uncontactable_NoAnswer

 

07:08 PM 01/11/04, "*82,(602) 544-2320", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041028102024142672KATHRYN103104}[PatFirstName]{Lynette}[Appt_Date]{

ednesday, November 3}[Appt_Time]{9:15 AM}[Dr_LastName]{Reed}[OutDial_RetriesLeft]{0}

 

And the last is a number that appeared in SIT_Unknown

 

07:08 PM 01/11/04, "*82,(602) 544-2320", 0, 30, , C:\RemPlus\Human.vgs, C:\RemPlus\Ans_Mach.vgs, [RecordID]{20041028102024142672KATHRYN103104}[PatFirstName]{Lynette}[Appt_Date]{

ednesday, November 3}[Appt_Time]{9:15 AM}[Dr_LastName]{Reed}[OutDial_RetriesLeft]{0}

 

I think I am going to go back to the previous version until we can figure this out because I fear that things were all screwed up tonight. Also, Is there a way to put a delay in VG between calls? I wonder if the No Circuit is because VG is picking up the line to make the next call too quickly. Please let me know. Thank you for you great support.

[MannyTC]

Sorry forgot to include the log. It is attached here.

1101vgm.txt

[MannyTC]

Problems again with the upload. Trying again......

1101vgm.zip

[SupportTeam]

We had a quick look here and all seems normal.

 

We traced dialing to one number (955-1716) and found that this number was called 4 times as expected (3 retries were specified when number was loaded) and on each time when calling VG got SIT_NO_CIRCUIT tone, and after 4th dial it stopped dialing that number.

 

If you feel that something is still not right please identify and point out a specific example and we can then have a look at it.

 

The Answering Machine detections that we've seen were for calls on different lines then any SIT_NO_CIRCUIT tone reports immediately before it in the log file (the Line ID of which line the log entry is for is just after the timestamp)

 

I wonder if the No Circuit is because VG is picking up the line to make the next call too quickly.

Looks like VGDialer waits 3 seconds after end of previous call before sending another call on the same line. This should be sufficient, but you can always increase this setting by editing VG.INI file. See section [VGDialer], entry "AfterIdleWait".

 

You can confirm the time between end of call and next dial by just looking at the log file.

[MannyTC]

Ok, you identified another problem for me then. Our calls all go out on ONE line. I guess that is why I was really confused at the way the logged looked. The only thing I changed was to put in the new executable you sent. That further explains to me why I all of a sudden got SIT NO CIRCUIT results. Here is the XML from the OutDial_New.xml for the one phone number that you looked at.

 

<OutDialEntry>

<PhoneNumber>*82,955-1716</PhoneNumber>

<DayTimeStart>1800</DayTimeStart>

<DayTimeStop>2030</DayTimeStop>

<DaysCallAllowed>MoTuWeThFrSaSu</DaysCallAllowed>

<LineSelection>dxxxB1C1</LineSelection>

<OnAnswer>C:\RemPlus\Human.vgs</OnAnswer>

<OnAnswerMachine>C:\RemPlus\Ans_Mach.vgs</OnAnswerMachine>

<CallRetries>2</CallRetries>

<RetryDelay>30</RetryDelay>

<RV>[RecordID]{20041020091538010381MARIBEL103104}[PatFirstName]{Alana}[Appt_Date]

Wednesday, November 3}[Appt_Time]{9:30 AM}[Dr_LastName]{Davey}</RV>

<OnNotConnected>C:\RemPlus\No_Ans.vbs $RV[RecordID] $RV[OutDial_Result]</OnNotConnected>

</OutDialEntry>

 

Another problem you will notice is that the retry is set for 2 for all the numbers in the XML file so how is it that the number was dialed 4 times in the log you checked? Something is very wrong.

[SupportTeam]

Our calls all go out on ONE line.

The trace shows VG is sending calls on 4 lines in the system.

Just look at the VG screen when dialing is happening and you'll see which lines it's using...

[MannyTC]

I don't think you understood my post. I have and always have been specifying the line numbers for dialing out. Your new version has ignored that.

 

Also my entries in the OutDial_New.xml specify 2 (TWO) retries and you say that the log says those numbers were dialed a total of 4 (FOUR) times. That would be 1 more than it is supposed to do.

 

Please advise.

[MannyTC]

To add to my above post. I have all 4 lines set in VG to allow dialing out. I set which lines to use in the OutDial_New.xml file because I have different lines available at different times of day. So when I specify a dial time window and line I can be sure that VG will dial on the proper lines at the proper time of day. When I installed the newest exectuable (5.2.3039), VG apparently stopped using the <LineSelection> tag as it should only have dialed on line dxxxB1C1 but it dialed on all four lines. Please check into this. Thank You.

[SupportTeam]

OK, will look into both points above.

 

In the meantime is it possible for you to just disable outbound dialing on other lines by going to "View"->"Line Device Config" menu and unchecking the "Allow to dial out on this line" check box?

[MannyTC]

I can disable the outbound dialing on the lines but I won't be around tomorrow to re-enable them to use all the lines again.

 

Let me know what you find out please.

 

Thanks

[MannyTC]

I disabled the outbound dialing on the other lines and all worked fine. Please let me know if you find out why VG is ignoring my line selection in the OutDial_New.xml. I will have to go back to the 5.2.3035 soon as I cannot continue to manually change VG to handle the change in available lines.

[MannyTC]

Any updates to the Line Selection issue?

[SupportTeam]

We've got the Line Selection bug fix.

 

Please update your v5.2.3 installation with the attached .exe and try again.

VgMulti_5.2.3046.zip

[MannyTC]

I just installed the new version and so far things look good. Thanks for the fix.