Page 1 of 1
Echo problem: Lead hears themself and lost calls
Posted:
Fri Jul 21, 2006 1:17 am
by gschaller
Hello,
I have an echo problem. The agent side is ok, but the lead/customer hears themself. I played around with echocancel in zapata.conf, but it doesn't help. Anyone had this issue?
Another problem are lost calls. Agent speaks to lead/customer. Sometimes the customer is away then, it seems the channel is hang up. One time I tried dial level 1.0. After 40 minutes 5 agents where kicked off, the customers where away. After relogin it worked as before.
System: latest vicidial, dialing ratio 0, agents on idefisk, Digium TE210P, Xeon Server with Asterisk, Dual Core P4 with apache/mysql, 10 - 12 agents
Posted:
Fri Jul 21, 2006 5:51 am
by mflorell
Can you post some Asterisk CLI output?
What is the loadavg of the server when this happens?
Posted:
Fri Jul 21, 2006 9:39 am
by enjay
This is pretty much what I am experiencing I continually have my agents log out and log back in to clear up their static/customer echo etc..
Posted:
Fri Jul 21, 2006 10:25 am
by mflorell
What version of Asterisk are you using?
Have you tried the 1.4 SVN trunk? I think they do some different things with VOIP call handling in Meetmes.
Posted:
Sat Jul 22, 2006 5:31 am
by gschaller
Asterisk 1.2.8, but I will try the latest 1.2.10 next week. It is difficult to post CLI output, because I monitor the system remotely. After an agent lost his customer they call me and tell about that. So I only can search in screenlog, but that would be difficult. All of my 10 agents lost at minimum 1 customer per day.
System load is maximum 1.81, 1.26, 0.94 (output from top, no recording of calls).
Posted:
Sat Jul 22, 2006 7:36 am
by mflorell
Are these agents remote from the server or on the same local network as it?
Posted:
Sat Jul 22, 2006 8:24 pm
by enjay
What kind of line are you on? Are you on the Qwest network, because they have had a few outages in the last few days and I experienced the same thing. The lines appear to have cleared up significantly over the last 36 hours.
I also had to call the carrier and have them check the circuits (errors on the echo cancellers).
-enjay
Posted:
Sun Jul 23, 2006 6:09 am
by gschaller
Local agents on same network as vicidial/Asterisk servers. We are on lines of COLT Telecom.
Let's see how it works tomorrow. I upgraded to Asterisk 1.2.10 and patched zaptel with mg2 echo canceller patch (
http://www.rmdir.de/~michael/mg2ec-limit-coeff-1.2.diff).
Posted:
Mon Jul 24, 2006 6:38 am
by gschaller
Today the system is running with Asterisk 1.2.10. Works fine with the new echo canceller (very rarely a small echo now - so much better than last week). But there are still lost customers. One agent tried to call with a SIP phone manually (without vicidial) today. There are also lost customers! So it is not a vicidial failure absolutly, I think there is something wrong with Asterisk itself. We called the carrier (COLT), but they told us there are no errors on the lines.
Any hints?
Posted:
Mon Jul 24, 2006 7:25 am
by gschaller
I have a screenlog file with a customer lost. There are other calls in this file. Can I send it attached to an email? I don't want to post here because of the telephone numbers in it. I see a normal hangup, the agi shows minutes the agent was speaking to customer and so on. Nothing noticeable ...
Posted:
Mon Jul 24, 2006 7:55 am
by mflorell
We have run into that before. It's the carrier in our experience. On four of our systems we have one T1 from each of two separate carriers on each of them and when researching phantom hangups that happened one day they only occured on the T1s of a single carrier, the otheer T1s had none of these hangups. They show up as normal hangups with a normal PRI Hangup code. We have sent specific examples to our carrier of hangups and they said they would "look into it". We are getting new T1s through our new fiber connection in the next couple of weeks so hopefully tis problem will go away when we switch.
Posted:
Mon Jul 24, 2006 3:12 pm
by gschaller
Thanks for your reply. I will check it with our carrier.