Many thanks Matt,<br><br>I heard asterisk had some problems with registering over 100 SIP endpoints and I was worried about how much the transcoding load could be for over 100 concurrents calls too. I expect to be over these figures. Regarding the AMI connection, yes, there will be only one, like any third-party cti-link but my concern was about how many commands an events asterisk is able to handle without becoming in a bottleneck.<br>
<br>You said you're using about 8 patches. Are all of them to make sure the stability and scalability of the system? Well, one of them is the AsyncAGI patch, isn't? Is there anyone to mach originate commands with new_channel events?<br>
<br>I'm planning to use asterisk 1.4.18<br><br>Regards<br>Jose<br><br><br><div class="gmail_quote">2009/7/21 Matt Florell <span dir="ltr"><<a href="mailto:astmattf@gmail.com">astmattf@gmail.com</a>></span><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></div><div class="h5">On 7/21/09, Jose Arias <<a href="mailto:cyr2242@gmail.com">cyr2242@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I'm planning to develop a custom autodialer application which will be<br>
> dealing with its own model for agents and queues, therefore it won't use<br>
> neither asterisk agents nor asterisk queues, nor asterisk cdr. The<br>
> application will supply the whole reporting and agent managing features by<br>
> itself.<br>
><br>
> The application will command asterisk through an AMI telnet connection using<br>
> only the originate, redirect and hangup AMI commands plus the stream file<br>
> AGI command (AsyncAGI patch will be required).<br>
><br>
> The application will make outbound calls, then they will be redirected on<br>
> the fly to dynamically defined meetme rooms, then the application will call<br>
> extensions (registered endpoints) where it will know there are available<br>
> agents in order to redirect them to the previous meetme rooms. If the<br>
> application launched more calls than available agents it would play prompts<br>
> while waiting for agents to become available.<br>
><br>
> Since the planned features set from asterisk to be used by the application<br>
> will be very short, but the figures can be very large (in terms of<br>
> concurrent calls, registered endpoints, traffic on the AMI port, etc..) I<br>
> would appreciate if anybody can help me to find out what's the more suitable<br>
> asterisk version to use in terms of scalability and stability:<br>
><br>
> - concurrent registered endpoints (SIP and IAX)<br>
> - concurrent two and tree party meetme rooms (whatever codec can be used)<br>
> - concurrent mixmonitor recordings<br>
> - concurrent playings for prompts<br>
> - commands and events rate on the AMI port<br>
><br>
> It's important to notice the advanced features from asterisk aren't a<br>
> priority.<br>
><br>
> I already looked over some links like<br>
> <a href="http://www.voip-info.org/wiki/view/Asterisk+dimensioning" target="_blank">http://www.voip-info.org/wiki/view/Asterisk+dimensioning</a><br>
> and others but I found more questions than answers there.<br>
><br>
> Thanks in advance<br>
> Jose<br>
><br>
<br>
</div></div>This sounds a lot like ViciDial, which does use meetme instead of<br>
Asterisk Queues/Agents, is already engineered to be multi-server, is<br>
capable of placing 200,000+ outbound calls per server per day, has a<br>
web-based GUI for configuring the system and a web-based agent<br>
interface.<br>
<div class="im"><br>
<br>
- concurrent registered endpoints (SIP and IAX)<br>
<br>
</div>Doesn't really matter, we've done 500+ on a single server before and<br>
it didn't really affect load much. As for number of agents, we are<br>
usually conservative on that front, usually we keep it under 50 agents<br>
per outbound server, but we have done 100 before.<br>
<div class="im"><br>
- concurrent two and tree party meetme rooms (whatever codec can be used)<br>
<br>
</div>Everything is transcoded in a meetme room to slin. ViciDial does<br>
everything in Meetme, and while it does use slightly more resources<br>
than Asterisk Queues, it is more stable and offers more flexibility<br>
<br>
- concurrent mixmonitor recordings<br>
<br>
We do not recommend using mxmonitor. It is better to have a custom<br>
recording handling script. And if you are using Meetme for everything<br>
you don't have to bother mixing recordings anyway.<br>
<br>
- concurrent playings for prompts<br>
<br>
This depends on a lot of different things, if load or playback quality<br>
becomes an issue then you should put prompts on a RAM drive or tmpfs<br>
<div class="im"><br>
- commands and events rate on the AMI port<br>
<br>
</div>Use a single point(or a few limited points) of entry to the AMI to<br>
keep it working well. You should not have an AMI connection for each<br>
agent.<br>
<br>
<br>
We currently use a version of 1.4.21.2 that has about 8 patches<br>
applied to it, and we have found it to be very stable in production.<br>
<br>
MATT---<br>
<br>
_______________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</blockquote></div><br>