vicidial.org

Having trouble with the timecheck feature in a callmenu. I have a callmenu (lets call it menuA) setup to have two possible outcomes: 1. Route call to another callmenu (lets call this menuB) where the caller is given options to select. This should happen as a result of a prompt timeout and should occur during the time specified in the calltime schedule. 2. Route call to in-group. This should occur as a result of the timecheck feature. It should occur when not in hours of operation.

The hours of operation are from 7:30 to 16:29. Whether I call within this time period or not, the result is always the same, the call is routed to menuB.

Thanks in advance for any and all help.

Thank you for posting your specs!

I will, however, point out that "VicidialNOW 2.2.1-237 build 100510-2015" is impossible, as VicidialNOW is the INSTALLER software, not the actual software being run (although it does appear to have VICIdial and other software bundled nicely).

VICIdial is the actual software being run. VicidialNOW is actually (apparently) becoming goautodial so there will likely never be a VicidialNOW 2.X since the 2.X version is actually Goautodial instead (but STILL installs VICIdial, which is the actual dailer software)

Have you downloaded and read the VICIdial manual for version 2.2.X? (from the EFLO.net site ... free of charge ... but I recommend the paid version as it has much more depth and tutorials?)

Thanks for pointing that out. Did some further digging and found the correct info on my configuration. In regards to the callmenu, I guess I must have missed that detail in the manual. I will check it again.

The manual (paid) didn't help at all...experimentation did the trick. I have a better understanding of how the call menu options work. I am curious to know, though, how a call menu prompt could result in A, B, C or D. There is nothing from pages 97 to 99 (the call menu section in the paid manual) that explains this. Thanks again for your help.

A, B, C and D are valid DTMF keys, that's why they are in there. We have used these in the past to allow for routing of calls from AGIs to specific paths in the call menu they came from.

Have you downloaded and read the VICIdial manual for version 2.2.X? (from the EFLO.net site ... free of charge ... but I recommend the paid version as it has much more depth and tutorials?)

I checked between pages 97 and 99 (section on callmenus) of the paid manual but couldn't find anything that would shed light on my problem. I have a second, identical setup and this one does behave as expected. I can't find any differences between my two systems, as far as setup is concerned. Is there any log I can check out to see what is going on?

1) Asterisk CLI

2) /var/log/asterisk (controlled by /etc/asterisk/logger.conf)

3) /var/log/astguiclient (controlled by Admin->Servers log settings)

Here is the info I have been able to gather on the matter from /var/log/asterisk/messages. I have also provided an address to screenshots with my calltime and callmenu configurations. Telephone numbers have been changed for privacy. Certain lines have been removed since they were repetitive.

http://s1192.photobucket.com/albums/aa334/AlSam1/

[Oct 2 06:24:53] VERBOSE[2905]: [Oct 2 06:24:53] -- Accepting call from '787xxxxxxx' to '787xxxxxxx' on channel 0/1, span 1
[Oct 2 06:24:53] DEBUG[2905]: Enabled echo cancellation on channel 1
[Oct 2 06:24:53] VERBOSE[9634]: [Oct 2 06:24:53] -- Executing AGI("Zap/1-1", "agi-DID_route.agi") in new stack
[Oct 2 06:24:53] VERBOSE[9634]: [Oct 2 06:24:53] -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-DID_route.agi
[Oct 2 06:24:53] DEBUG[2905]: Echo cancellation already on
[Oct 2 06:24:53] VERBOSE[9634]: [Oct 2 06:24:53] -- AGI Script agi-DID_route.agi completed, returning 0
[Oct 2 06:24:53] VERBOSE[9634]: [Oct 2 06:24:53] -- Executing AGI("Zap/1-1", "agi-VDAD_inbound_calltime_check.agi|CALLMENU-----YES-----InitCallMenu-----730am430pm-----INGROUP-----AftHrsVM-----CID|LB|998|Inbound|1") in new stack
[Oct 2 06:24:53] VERBOSE[9634]: [Oct 2 06:24:53] -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-VDAD_inbound_calltime_check.agi
[Oct 2 06:24:53] DEBUG[9634]: Scheduling timer at 160 sample intervals
[Oct 2 06:24:53] DEBUG[9634]: Scheduling timer at 0 sample intervals
[Oct 2 06:24:53] DEBUG[9634]: Scheduling timer at 0 sample intervals
[Oct 2 06:24:53] DEBUG[9634]: Scheduling timer at 160 sample intervals
[Oct 2 06:24:53] DEBUG[9634]: Scheduling timer at 0 sample intervals
[Oct 2 06:24:53] DEBUG[9634]: Scheduling timer at 0 sample intervals
[Oct 2 06:24:53] VERBOSE[9634]: [Oct 2 06:24:53] -- AGI Script agi-VDAD_inbound_calltime_check.agi completed, returning 0
[Oct 2 06:24:53] VERBOSE[9634]: [Oct 2 06:24:53] -- Executing BackGround("Zap/1-1", "SaludoNew") in new stack
[Oct 2 06:24:53] DEBUG[2852]: Avoiding initial deadlock for 'Zap/1-1'
[Oct 2 06:24:53] DEBUG[9634]: Scheduling timer at 160 sample intervals
[Oct 2 06:24:53] VERBOSE[9634]: [Oct 2 06:24:53] -- Playing 'SaludoNew' (language 'en')
[Oct 2 06:24:53] DEBUG[2972]: Manager received command 'Command'
[Oct 2 06:24:57] DEBUG[9634]: Scheduling timer at 66 sample intervals
[Oct 2 06:24:57] DEBUG[9634]: Scheduling timer at 0 sample intervals
[Oct 2 06:24:57] DEBUG[9634]: Scheduling timer at 0 sample intervals
[Oct 2 06:24:57] VERBOSE[9634]: [Oct 2 06:24:57] -- Executing WaitExten("Zap/1-1", "1") in new stack
[Oct 2 06:24:57] DEBUG[2972]: Manager received command 'Command'
[Oct 2 06:24:58] DEBUG[2972]: Manager received command 'Command'
[Oct 2 06:24:58] VERBOSE[9634]: [Oct 2 06:24:58] -- Timeout on Zap/1-1, going to 't'
[Oct 2 06:24:58] VERBOSE[9634]: [Oct 2 06:24:58] -- Executing Goto("Zap/1-1", "CallCenter|s|1") in new stack
[Oct 2 06:24:58] VERBOSE[9634]: [Oct 2 06:24:58] -- Goto (CallCenter,s,1)
[Oct 2 06:24:58] VERBOSE[9634]: [Oct 2 06:24:58] -- Executing AGI("Zap/1-1", "agi-VDAD_inbound_calltime_check.agi|CALLMENU-----YES-----CallCenter--------------------") in new stack
[Oct 2 06:24:58] VERBOSE[9634]: [Oct 2 06:24:58] -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-VDAD_inbound_calltime_check.agi
[Oct 2 06:24:58] DEBUG[9634]: Scheduling timer at 160 sample intervals
[Oct 2 06:24:58] DEBUG[9634]: Scheduling timer at 0 sample intervals
[Oct 2 06:24:58] DEBUG[9634]: Scheduling timer at 0 sample intervals
[Oct 2 06:24:58] DEBUG[9634]: Scheduling timer at 160 sample intervals
[Oct 2 06:24:58] DEBUG[9634]: Scheduling timer at 0 sample intervals
[Oct 2 06:24:58] DEBUG[9634]: Scheduling timer at 0 sample intervals
[Oct 2 06:24:58] VERBOSE[9634]: [Oct 2 06:24:58] -- AGI Script agi-VDAD_inbound_calltime_check.agi completed, returning 0
[Oct 2 06:24:58] VERBOSE[9634]: [Oct 2 06:24:58] -- Executing BackGround("Zap/1-1", "MainMenuNew") in new stack
[Oct 2 06:24:58] DEBUG[9634]: Scheduling timer at 160 sample intervals
[Oct 2 06:24:58] VERBOSE[9634]: [Oct 2 06:24:58] -- Playing 'MainMenuNew' (language 'en')
[Oct 2 06:24:58] DEBUG[2972]: Manager received command 'Command'
[Oct 2 06:25:01] DEBUG[9682]: Manager received command 'Login'
[Oct 2 06:25:01] VERBOSE[9682]: [Oct 2 06:25:01] == Parsing '/etc/asterisk/manager.conf': [Oct 2 06:25:01] VERBOSE[9682]: [Oct 2 06:25:01] == Parsing '/etc/asterisk/manager.conf': [Oct 2 06:25:01] Found
[Oct 2 06:25:01] VERBOSE[9682]: [Oct 2 06:25:01] == Manager 'sendcron' logged on from 127.0.0.1
[Oct 2 06:25:01] DEBUG[9682]: Manager received command 'Command'
[Oct 2 06:25:01] DEBUG[9682]: Manager received command 'Ping'
[Oct 2 06:25:01] DEBUG[9686]: Manager received command 'Login'
[Oct 2 06:25:01] VERBOSE[9686]: [Oct 2 06:25:01] == Parsing '/etc/asterisk/manager.conf': [Oct 2 06:25:01] VERBOSE[9686]: [Oct 2 06:25:01] == Parsing '/etc/asterisk/manager.conf': [Oct 2 06:25:01] Found
[Oct 2 06:25:01] VERBOSE[9686]: [Oct 2 06:25:01] == Manager 'sendcron' logged on from 127.0.0.1
[Oct 2 06:25:01] DEBUG[9686]: Manager received command 'MailboxCount'
[Oct 2 06:25:01] DEBUG[9686]: Manager received command 'Ping'
[Oct 2 06:25:01] DEBUG[2972]: Manager received command 'Command'
[Oct 2 06:25:01] DEBUG[9686]: Manager received command 'MailboxCount'
[Oct 2 06:25:01] DEBUG[9686]: Manager received command 'Ping'
[Oct 2 06:25:01] DEBUG[9682]: Manager received command 'Logoff'
[Oct 2 06:25:01] VERBOSE[9682]: [Oct 2 06:25:01] == Manager 'sendcron' logged off from 127.0.0.1
[Oct 2 06:25:06] DEBUG[9686]: Manager received command 'MailboxCount'
[Oct 2 06:25:06] DEBUG[9686]: Manager received command 'Ping'
[Oct 2 06:25:06] DEBUG[9697]: Manager received command 'Login'
[Oct 2 06:25:06] VERBOSE[9697]: [Oct 2 06:25:06] == Parsing '/etc/asterisk/manager.conf': [Oct 2 06:25:06] VERBOSE[9697]: [Oct 2 06:25:06] == Parsing '/etc/asterisk/manager.conf': [Oct 2 06:25:06] Found
[Oct 2 06:25:06] VERBOSE[9697]: [Oct 2 06:25:06] == Manager 'sendcron' logged on from 127.0.0.1
[Oct 2 06:25:06] DEBUG[9697]: Manager received command 'Command'
[Oct 2 06:25:06] DEBUG[9697]: Manager received command 'Ping'
[Oct 2 06:25:06] DEBUG[9686]: Manager received command 'MailboxCount'
[Oct 2 06:25:06] DEBUG[9686]: Manager received command 'Ping'
[Oct 2 06:25:06] DEBUG[9686]: Manager received command 'MailboxCount'
[Oct 2 06:25:06] DEBUG[9686]: Manager received command 'Ping'
[Oct 2 06:25:06] DEBUG[9697]: Manager received command 'Logoff'
[Oct 2 06:25:06] VERBOSE[9697]: [Oct 2 06:25:06] == Manager 'sendcron' logged off from 127.0.0.1
[Oct 2 06:25:06] DEBUG[9686]: Manager received command 'MailboxCount'
[Oct 2 06:25:06] DEBUG[9686]: Manager received command 'Ping'
[Oct 2 06:25:07] VERBOSE[2905]: [Oct 2 06:25:07] -- Channel 0/1, span 1 got hangup request, cause 16

you said it works on one but not the other. perhaps you should post the differences between the two so we can see where they contrast and find out why.

have you tried this with a SIP trunk to be sure the issues is not related to your OpenVox card?

Let me clarify. On my tests with my second install I did not have a timeout option, only the timecheck. The calltime definition is not the same, but it shouldn't matter since I called after hours. The OpenVox card got added recently since we are having a different problem and believed changing from SIP to PRI would solve it. This timecheck issued has been around since day 1 on this system. Is there anything you can gather from the sequence of events displayed on my previous post that would indicate there actually is a problem? I will post the output to /var/log/asterisk/messages from this second setup as well as callmenu and calltime.

my process of troubleshooting would require that you start with the closest to "working" that you have available and then only change one variable at a time. if something breaks, you have only changed one variable and can find out HOW/WHY that change broke something.

so, since i have no time right now ... can you clarify with a simpler posting with only ONE item changed that breaks something that used to work?

if this requires going back to sip for this one test call, that's fine.

I was able to make it work by having the call routed directly to voicemail instead of an in-group. For call tracking purposes, the way I currently have it setup is that calls are routed to an in-group with no agents. This group has the "No agents no queue" option activated and the associated action is to go to voicemail. Any thoughts on why it would work with the voicemail and not with the ingroup? Current config for the callmenu can be seen at: http://s1192.photobucket.com/albums/aa334/AlSam1/

This might be something I fixed several months ago in SVN/trunk(2.4)

AlSam wrote:I was able to make it work by having the call routed directly to voicemail instead of an in-group. For call tracking purposes, the way I currently have it setup is that calls are routed to an in-group with no agents. This group has the "No agents no queue" option activated and the associated action is to go to voicemail. Any thoughts on why it would work with the voicemail and not with the ingroup? Current config for the callmenu can be seen at: http://s1192.photobucket.com/albums/aa334/AlSam1/

but you said you got it to work THROUGH the ingroup to get to the voicemail. so the ingroup worked. what was NOT working again?

Just to confirm, I was able to recreate the problem in my other setup. If I route to an ingroup the timecheck does not function properly. Thanks for the info. Where can I find info on updating my system?

Method one: at the top of this page Matt has kindly placed a "VICIDIAL Wiki" link. Inside this Wiki is the link "SVN:howto - How To use the SVN server".

Method two: download from sourceforget.net (the project source code).

Either way, you will end up with "the new version" ready to install. The new version will have (in it) the "UPGRADE.txt" file with specific instructions how to update.

So regardless of whether you use SVN to download the new source, or just download it manually, the UPGRADE.txt will tell you what to do next (which is basically to run a sql script and then "install" again right on top of your old install). It is generally around 10 lines of command line typing to upgrade.

Please back up first! (look at /usr/share/astguiclient/ADMIN_backup.pl, instructions are IN the file )

Thanks again for the info and your quick responses. I will check out the wiki.

williamconley wrote:

AlSam wrote:I was able to make it work by having the call routed directly to voicemail instead of an in-group. For call tracking purposes, the way I currently have it setup is that calls are routed to an in-group with no agents. This group has the "No agents no queue" option activated and the associated action is to go to voicemail. Any thoughts on why it would work with the voicemail and not with the ingroup? Current config for the callmenu can be seen at: http://s1192.photobucket.com/albums/aa334/AlSam1/

but you said you got it to work THROUGH the ingroup to get to the voicemail. so the ingroup worked. what was NOT working again?

william, if i configure the call in the callmenu to be routed directly to voicemail, the call is properly routed. If i have it routed to the ingroup, which in turn routes it to the voicemail, it does not work. I am never able to get to the voicemail. In other words, the only way I can get to the voicemail when calling after hours is if I route the call directly to the voicemail as a result of the timecheck feature.

Call -> Callmenu -> Ingroup (calltime: match=Agents, no match=VM) FAIL

Call -> Callmenu -> Ingroup (no agents = VM, agents available = agents get call) SUCCESS

?Is this the correct flow?

Success or failure, in this particular case, can be determined well before the call ever reaches an agent. The problem is in the very first callmenu. The call flow should be:

call -> callmenuA (calltime:match = callmenuB, no match=ingroup with no agents using no agents no queue feature)

callmenuB (selection is made by caller)-> ingroup (calltime:match=agent, no match=ingroup with no agents using no agents no queue feature)

ingroup with no agents -> vm box 5000

mflorell wrote:This might be something I fixed several months ago in SVN/trunk(2.4)

I was able to confirm, through a test setup, that the issue is corrected in version 2.4.

Thank you very much for following up on this.