<br><br><div class="gmail_quote">On Tue, Jul 21, 2009 at 10:15 AM, James Green <span dir="ltr"><<a href="mailto:james.green@mjog.com">james.green@mjog.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div><font size="2" face="Arial"><span>Hi,</span></font></div>
<div><font size="2" face="Arial"><span></span></font> </div>
<div><font size="2" face="Arial"><span>We currently fire
multiple HTTP requests (via multi-curl) to the AJAM interface in order to place
calls. We are finding Asterisk has it's limits however, and I've found
astmanproxy recommended for helping maintain the connections. This would prove
particularly useful with multiple servers of course.</span></font></div>
<div><font size="2" face="Arial"><span></span></font> </div>
<div><font size="2" face="Arial"><span>However, in testing
astmanproxy crashes with buffer overflows.</span></font></div>
<div><font size="2" face="Arial"><span></span></font> </div>
<div><font size="2" face="Arial"><span>This leads to the
inevitable question: Is astmanproxy still recommended for use or are we missing
some knowledge here?</span></font></div>
<div><font size="2" face="Arial"><span></span></font> </div>
<div><font size="2" face="Arial"><span>Platform is 64 bit
Intel, Ubuntu 9.04, Asterisk 1.6 with latest trunk of astmanproxy from
github.</span></font></div>
<div><font size="2" face="Arial"><span></span></font> </div>
<div><font size="2" face="Arial"><span>Thanks,</span></font></div>
<div><font size="2" face="Arial"><span></span></font> </div>
<div><font size="2" face="Arial"><span>James</span></font></div>
<div><font size="2" face="Arial"><span></span></font> <br></div></div>
</blockquote></div><br>When faced with this same problem, creating and FTPing .call files to the outgoing spool directory freed up the AMI for other functions.<br><br>Plain, simple, and "Just Worked" I looked at, but never tried AstManProxy because I prefer to eliminate levels of complexity and points of failure rather than add, whenever possible.<br>
<br>Not saying that this is your best solution, just what I found to be much more reliable than pounding the AMI.<br clear="all"><br>-- <br>Thanks,<br>Steve Totaro <br>+18887771888 (Toll Free)<br>+12409381212 (Cell)<br>+12024369784 (Skype)<br>