Page 1 of 1
single recording of multiple calls.
Posted:
Wed Mar 31, 2010 5:59 am
by shivkumar
Hi
i am using 2.2.0
i found the single recording of multiple calls.
one of my agent doing manual call using vicidial agent screen
when i saw the recording it was of 2 hr recording have all the calls talk of 7 -8 customer
what is the problem.
what is wrong with me.
please help me.
Regards:
shiv kumar
Posted:
Wed Mar 31, 2010 7:35 am
by mflorell
How did you install ViciDial?
and please do not double-post.
Re: single recording of multiple calls.
Posted:
Wed Mar 31, 2010 11:54 pm
by shivkumar
mflorell wrote:How did you install ViciDial?
.
i screech install VicidDial 2.2.0rc4 on opensuse
this is a mult server setup i use
opensuse 11.2 for database mysql5.0.90,and webserver
and use ununtu OS for dialer.
regards:
shivkumar
Posted:
Thu Apr 01, 2010 7:51 am
by mflorell
How exactly was your agent doing these calls?
Posted:
Fri Apr 02, 2010 12:22 am
by shivkumar
mflorell wrote:How exatly was your agent doing these calls?
login vicidial agent screen 192.168.3.10/agc/vicidial.php.
show Active Callback, Manual Dial, fast Dial at the bottom of the screen
click on the manual dial
we see the green screen enter the Dial Code and Phone Number and click on the Dial Now
Posted:
Fri Apr 02, 2010 12:58 am
by mflorell
Is this repeatable?
Posted:
Fri Apr 02, 2010 2:36 am
by shivkumar
mflorell wrote:Is this repeatable?
agent do login and start to calling he do 8 calls
click on
1. manual dial
2. Enter Dial Code and phone Number.
3.talk with customer
4.Hangup
5.select dispositon and submit
and again fellow the same procedure 1--5
he take 8 calls and then logout agent
now when i download the recording its have talk of all 8 customer for that this agent talk.
regards:
shiv kumar
Posted:
Fri Apr 02, 2010 8:02 am
by mflorell
I cannot duplicate this issue, what is campaign recording option set to?
Posted:
Mon Sep 20, 2010 10:19 am
by jamestaylor
When I have had this same problem I always found it to be because the ASTlisten script had stopped. Connecting to, then ending that screen would fix the problem for all newly placed calls after the screen re-launches.
Re:
Posted:
Wed Feb 27, 2013 5:26 pm
by AlSam
jamestaylor wrote:When I have had this same problem I always found it to be because the ASTlisten script had stopped. Connecting to, then ending that screen would fix the problem for all newly placed calls after the screen re-launches.
James,
I am facing the same issue. Could you give me a bit more detail as to the process you followed to resolve this matter? I am not too skilled at these matters dealing with Asterisk.
Thanks,
Re: single recording of multiple calls.
Posted:
Wed Feb 27, 2013 9:03 pm
by williamconley
You would probably do well to upgrade. Is your problem recent? or ongoing?
Re: single recording of multiple calls.
Posted:
Wed Feb 27, 2013 9:07 pm
by AlSam
williamconley wrote:You would probably do well to upgrade. Is your problem recent? or ongoing?
It was recently brought to my attention, however I do not know for how long it has been happening, if at all.
Re: single recording of multiple calls.
Posted:
Wed Feb 27, 2013 10:07 pm
by williamconley
If intermittent, and unpredictable, it is more likely Overload. Check out your server load when it happens.
Re: single recording of multiple calls.
Posted:
Fri Mar 01, 2013 6:55 am
by AlSam
williamconley wrote:If intermittent, and unpredictable, it is more likely Overload. Check out your server load when it happens.
Could running out of disk space be a cause for this instead of server load? I have often checked them during peak hours and rarely do they exceed 1.0; they all have quad-core processors.
Re: single recording of multiple calls.
Posted:
Fri Mar 01, 2013 9:53 pm
by williamconley
have a look at htop when the average is at 1.0 and see if they "peak" at their top end. Nice thing about htop is that it will show you the "NOW" values in addition to the 1,5,10 minute averages. If you are not ever hitting top end, then you are not likely overloaded.
running out of disk space does not provide "irregularities", it provides system crash. LOL However: If you are experiencing hard drive "backlogs" it can cause system irregularities. However, this will usually manfiest itself in heavy server load as the system tries to cache requests and begins to overload ... but checking i/o throughput with an appropriate tool is never a bad idea.
I've also found on a few occasions that "well, we don't actually have a log ... and can't point to any specific instances ..." results in a final diagnoses of the problem being somewhere between the keyboard and the seat. Quite a bit, actually. It often turns out that they "thought" they had a problem and found later it was a different problem, but that original thought remained and they eventually forgot the resolution. LOL
Insist on a log being created, the Lead_ID, Agent_ID, and date/time of the affected call be logged ... otherwise you'll never be able to troubleshoot anything. Chasing your tail is only cool in a facility with deep pockets.