vicidial.org

hello
I installed theINSTALL_FROM.... Evering seems to be running correct except two things:

The remote agents: The inbound calls never go through the remote agents.
The xls reports: Fronter_reports and closer_reports are allways empty with a fixed size 5,632.


Thanks.

There is a bug with remote agents that is fixed in both SVN branches. As for the Excel report, that was a contributed report that is not supported by the contributor anymore.

I used the svn version.
The remote agents are not functioning yet. don´t know wich one may be my error.

This is the message I have got for asterisk -vvvvgc

Manager 'sendcron' logged off from 127.0.0.1
-- Executing Answer("SIP/109-081b1150", "") in new stack
-- Executing BackGround("SIP/109-081b1150", "foo-out") in new stack
-- Playing 'foo-out' (language 'en')
== CDR updated on SIP/109-081b1150
-- Executing Answer("SIP/109-081b1150", "") in new stack
-- Executing AGI("SIP/109-081b1150", "agi-VDAD_ALL_inbound.agi|CIDLOOKUP-----LB-----ventas-----63400033-----Closer-----park----------101-----") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/agi-VDAD_ALL_inbound.agi
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
Feb 22 15:34:47 NOTICE[6017]: chan_local.c:523 local_alloc: No such extension/context 192*168*000*190*72573137591275@default creating local channel
Feb 22 15:34:47 NOTICE[6017]: channel.c:2496 __ast_request_and_dial: Unable to request channel Local/192*168*000*190*72573137591275@default
-- AGI Script agi-VDAD_ALL_inbound.agi completed, returning 0
-- Sent into invalid extension '192*168*000*190*2573137591275' in context 'default' on SIP/109-081b1150
-- Executing Playback("SIP/109-081b1150", "invalid") in new stack
-- Playing 'invalid' (language 'en')
== Manager 'sendcron' logged off from 127.0.0.1

I have got the remote agent in the number 2573137591275. If I dial directly from the phone(ext) the call is going out well.


Furthermore in this version, I had to edit the databse the field closer_campaigns cause the agent couln´t receive calls. there were no groups for the campaign.

Thanks again for your replies.

Looks like you found a bug in remote agent when using inbound groups. Could you post this information to the Issue Tracker?

mflorell wrote:Looks like you found a bug in remote agent when using inbound groups. Could you post this information to the Issue Tracker?

I searched for this in the tracker, but could not find it. Anyway, I have a problem with remote agents for inbound groups that maybe its related.

I have a group of agents that now work with a Nortel Meridian, you dial an extension to reach any of the logged in ones. I am slowly migrating them to vicidial, and in the meantime configuring the campaing with a drop time and the drop extension calls the meridian queue. So far good.

I tried today to make remote agents, all calling this extension, so I can visualize the queue in vicidial and it works perfectly to deliver the calls. Problem is, seemingly at random hanged up calls dont get erased from the live calls table, so after a couple of hours I have to reset the table to clean it. Yes, I have a working h extension (actually more than one, as I have had to put one for each incoming context to make asterisk call them).

Can you help me debug it? Do you have a newer vdremote script that works better with incoming?

thanks.

Try adding this to your extensions.conf if it isn't there already:

exten => _192*168*000*190*.,1,Goto(default,${EXTEN:16},1)

As for vdremote, that script has been neglacted for quite a while since hardly anyone uses it. I will make a note to work on it, but I'm not sure when that will happen.

As for the non-clearing calls, can you turn on full logging and trace the call in the Asterisk CLI output and see what happened with it?

mflorell wrote:
As for vdremote, that script has been neglacted for quite a while since hardly anyone uses it. I will make a note to work on it, but I'm not sure when that will happen.

As for the non-clearing calls, can you turn on full logging and trace the call in the Asterisk CLI output and see what happened with it?

Where can I turn on full loging? I'll try to debug it tonight.In the day there is too much going on to be able to see whats happening.

The VICIDIAL Issue Tracker:
http://www.eflo.net/VICIDIALmantis

There is a link to it at the top of every page in the forums.

Thanks!

hi matt,

I put the line you wrote. everithing appears to be funciotning ok now.

Thanks again

Wonderful! Thanks for the feedback.

ekaftan wrote:

mflorell wrote:
As for vdremote, that script has been neglacted for quite a while since hardly anyone uses it. I will make a note to work on it, but I'm not sure when that will happen.

As for the non-clearing calls, can you turn on full logging and trace the call in the Asterisk CLI output and see what happened with it?

Where can I turn on full loging? I'll try to debug it tonight.In the day there is too much going on to be able to see whats happening.

Good news... I now know why it does not work and its not a vicidial bug (although maybe it could work around it, I dont know)

bad news, there is no way I know how to fix it....

Problem is, in Asterisk if a Dial never gets aswered, and the caller hangs up, no further processing takes place, and the h extension never gets called. I tried a lot of different dialplans and never could get DeadAgi executed for a non answered call to a remote agent.

There is a non-official patch to enable a new option -F- to force a transfer via an explicit goto if the caller hangs up, but its only for 1.4.x. There is no space in 1.2 for more options in app_dial.c (32 bit limit reached).

Any ideas?

Depending on your load you might want to try Asterisk 1.4.18. I have tested it with VICIDIAL and it does work and is a lot more stable than previous 1.4.X releases, although not as stable as the latest 1.2.X releases. I was able to crash 1.4.18 twice over the course of 5 days running it at a call rate of 10,000 calls per hour. Less call volume and you might not see any crashes at all.

mflorell wrote:Depending on your load you might want to try Asterisk 1.4.18. I have tested it with VICIDIAL and it does work and is a lot more stable than previous 1.4.X releases, although not as stable as the latest 1.2.X releases. I was able to crash 1.4.18 twice over the course of 5 days running it at a call rate of 10,000 calls per hour. Less call volume and you might not see any crashes at all.

Will the dial plan work with no or little change? (I've never used 1.4.x)

Also, could the remote agent script check to see if the remote agent never answered when the calls originator hangs up (dial would exit with CANCEL) and then erase the call from the table?

There are a few changes you need to make for 1.4 compatibility, take a look at the extensions.conf.sample.1.4 file that is included with the release. You need to change anything that references callerID variables like call recording extensions.

As for Remote Agent CANCEL of calls, I haven't really worked on that in a long time, is the call eventually deleted?

mflorell wrote:
As for Remote Agent CANCEL of calls, I haven't really worked on that in a long time, is the call eventually deleted?

The calls eventually (hours later) go away. Probably gets erased after another one comes in with the same channel data.

When the calls are placed, do they go through a call_log entry in extensions.conf?

If they are in vicidial_auto_calls they should be hung up within 2 minutes of getting hung up.

mflorell wrote:When the calls are placed, do they go through a call_log entry in extensions.conf?

If they are in vicidial_auto_calls they should be hung up within 2 minutes of getting hung up.

Incoming calls come through this exten:

exten => 8991253,1,Ringing ; call ringing
exten => 8991253,n,Wait(1) ; Wait 1 second for CID delivery from PRI
exten => 8991253,n,Answer ; Answer the line
exten => 8991253,n,SetCDRUserField('in-telmex')
exten => 8991253,n,MixMonitor(/var/spool/asterisk/monitor/zap/tmp/zap-${STRFTIME(${EPOCH},America/Santiago,%Y%m%d-%H%M%S)}-${CALLERID(num)}.gsm|V(2))
exten => 8991253,n,AGI(agi-VDAD_ALL_inbound.agi,CIDLOOKUPRC-----SO-----InTelmex90-----8991253-----Closer-----park----------8000-----56-----TelmexIN)
exten => 8991253,n,Hangup

Remote agents are in exten 8990, although for some reason I had to add this hack to make it work:

exten => _${VDADSERVERIP}*7899X,1,Goto(tomeridian,${EXTEN:17},1)
exten => _${VDADSERVERIP}*899X,1,Goto(tomeridian,${EXTEN:16},1)

Then, 8990 is defined in the tomeridian context:

[tomeridian]

exten => h,1,DeadAGI(agi://127.0.0.1:4577/call_log--HVcauses ... EBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME}))

exten => 8990,1,AGI(agi://127.0.0.1:4577/call_log)
exten => 8990,n,SetCDRUserField('in-telmex')
exten => 8990,n,Dial(${MERIDIAN}/8990,,m(dmt))

Do I need another call_log entry?

Do you have an "exten => h" entry in the context where your incoming calls come in to?

mflorell wrote:Do you have an "exten => h" entry in the context where your incoming calls come in to?

Yes. I have three h extensions, one in the intelmex context (where the zapata.conf sends the incoming calls) one in the tomeridian context, where the calls get Dialed to the outgoing E1 and one in the vicidial context where all the vicidial specific extensions are...

vicidial and tomeridian are also included by the default context.

what exten and context do calls go through when they get transferred to remote agents?

mflorell wrote:what exten and context do calls go through when they get transferred to remote agents?

I fixed it! well sort of call and agents no longer get stuck after I added a DeadAgi call just after the inbound AGI call on the incoming number.

All call gets marked as drop, even though and agent actually spoke to them, but at least the remote agents relase. I've been running all afternoon (around 1000 calls) and no stucks.

No to debug the marked as drop