<span class="gmail_quote">On 9/22/05, <b class="gmail_sendername">Matt Roth</b> <<a href="mailto:mroth@imminc.com">mroth@imminc.com</a>> wrote:</span><br>
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Matt,<br><br>- Have you tried recording directly to GSM format? It will help reduce the
<br>- bottleneck on disk IO although it will use more CPU cycles(in your case<br>- on a RAM drive this may not help at all)<br>We don't want to do any transcoding on the Asterisk server because of<br>the drain on CPU. The RAM disk seems to be the best solution for our
<br>scenario.</blockquote><div><br>
That's pretty much what I though, wanted to mention it though. <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- (Regarding "Avoided deadlock" warnings and their effects)<br>- There aren't always audio skips but they do happen more when you get more
<br>- ast_channel_walk warnings. The audio gaps are usually less than a quarter<br>- second in our experience but can be upto a second depending on the<br>- severity of the IO problem at that instance. It's very hard to test for
<br>- until you get into production and you have real conversations and real<br>- people listening to them that can hear the audio skips.<br>Thank you for this information. It seems like the warnings won't cause<br>any unacceptable results, but we'll be listening to the audio regularly
<br>after we go into production.</blockquote><div><br>
When we traced the recording skips back to an exact time there is
always a ast_channel_walk warning in the logs, although there is not
always an audio skip if the warning appears, but the more of those
warnings, the more skips we got.<br>
</div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- We mostly do outbound and the volume is split across several servers, and<br>- for inbound we do have forwarding to other servers if the defined
<br>- capacity is exceeded a certain point.<br>How are you calculating this capacity?</blockquote><div><br>
Trial and error, astGUIclient/VICIDIAL has a very detailed
system performance logging utility built into it that tracks open
asterisk channels, ram, CPU use %, system load and a few other things
and we were best able to find a good and safe capacity at which to
limit our systems to ensure reliability:<br>
<a href="http://astguiclient.sourceforge.net/VDreports/performance_new.gif">http://astguiclient.sourceforge.net/VDreports/performance_new.gif</a><br>
</div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- As for phone calls at one time: for inbound we almost never exceed 50<br>- agents on a single server with no more than 72 incoming lines live at
<br>once.<br>- Our average is actually much less than that. For outbound we usually have<br>- about 15-40 agents per server with upto 96 lines dialing out<br>concurrently.<br>- At our main office location we've had over 100 agents on at one time
<br>across<br>- 6 Asterisk servers handling over 350 calls at once with a total of<br>more than<br>- 550 live channels on our Asterisk servers(includes recording, client and<br>- trunk channels).<br>I hope you don't mind answering some questions about your setup.
<br><br>It seems like you have really solid numbers to work with. We're<br>implementing our own reporting (both real-time and next-day) using<br>Asterisk's call detail records (stored in a MySQL database) and<br>information captured from the management interface (via AstManProxy).
<br>Are we reinventing the wheel? Do you have any tips for us in regards to<br>our reporting software?</blockquote><div><br>
We don't use any Asterisk-generated logs, they didn't offer enough
information for us, so we created several of our own MySQL logs for
calls and Manager actions that we use to track every action that
happens across all systems as well as all live calls that are occuring
in real-time on all systems. This allows VICIDIAL to have real-time
status screens and datetime-level statistical performance reports
available any time you want to pull them. As for tips, just log
everything, you may not think you need it now but you will eventually
want just about every little piece of call and action information that
you can get your hands on for reporting.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'm assuming you are using VICIDIAL as a predictive dialer in<br>conjunction with Asterisk for your outbound calling. We are looking for
<br>an outbound dialing solution. Could you please provide a list of the<br>abilities and limitations of VICIDIAL?</blockquote><div><br>
Well, since we wrote VICIDIAL we are a little biased :) it is free and
GPL so you won't get many of the pretty features you get with those
expensive dialer solutions, but you can tinker with it all you like.
We've been using it for about 2 years in production and now have it on
over 200 seats across 4 locations for our company. There are also over
50 production VICIDIAL installations in over a dozen countries that we
know about. It works better for us than any of the dialer systems we
used to use and we have total control over it which makes it easier to
change things on the fly. There are limitations and things that
we have not gotten around to writing yet, but there is an active
community around it and we are developing new features for it all the
time and releasing a new version every 2-8 weeks. One limitation is
Answering Machine detection. We haven't found a good method of doing
this and we don't like the delay that all commercial systems have when
doing AM detection so we just do a dial timeout by default, about 4-5
rings will eliminate 90% of the answering machines you receive without
any delay in the calls that are answered by a human. For other features
see the product page:<br>
<a href="http://astguiclient.sourceforge.net/vicidial.html">http://astguiclient.sourceforge.net/vicidial.html</a><br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">In your experience, how stable is Asterisk at high call volumes? Do you<br>have any issues with dropped calls, call quality, or losing calls in queue?
</blockquote><div><br>
What really matters is the load on your system and the type of channels
you are using. Zap channels are more reliable at extremely high loads
than any VOIP channel. Manager Actions can fail at extremely high
loads. All VOIP channels will suffer quality loss at extremely high
loads. By extremely high loads I mean about 5.00 and higher of system
load(10.00 on dual CPU machine) There are other factors, but this has
proven fairly reliable for us. System Load by channels in use is
different from server to server depending on the CPU/RAM/Motherboard
and other application running on the server.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">How are you calculating the number of live channels on your Asterisk<br>server? For instance, if we have 256 simultaneous calls each being
<br>digitally recorded, how many live channels is that? Is there a number of<br>live channels where Asterisk starts experiencing stability problems?</blockquote><div><br>
With VICIDIAL we have a real-time count of all active channels
(including recordings) on each server so it is easy to limit them. 256
channels being recorded would be 256 recording channels, and 256 agent
channels and at least 256 customer channels(768 channels total) which
is many more than we've ever had going on a single server. The maximum
channels per server really depends on the server, it's hard to
specilate in general without testing first.<br>
<br>
Hope this helps,<br>
</div><br>MATT---</div><br>