<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 6, 2016 at 2:20 PM, Michael Petruzzello <span dir="ltr"><<a href="mailto:michael.petruzzello@civi.com" target="_blank">michael.petruzzello@civi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><pre>On Tue, Jul 5, 2016 at 4:03 PM, Jonathan Rose <jonathan.rose at <a href="http://motorolasolutions.com" target="_blank">motorolasolutions.com</a>> wrote:</pre><pre>> If you don't need all of your participants actually to be speaking at a<br>> time (and I hope not with that kind of volume), you could use holding<br>> bridges for the vast majority of the partipants. Link the bridges using a<br>> local channel with the Hold bridge side being set to use the 'announcer'<br>> bridge role and the hold bridge will effectively just be voiceless<br>> conference participants. If you want, you can listen for DTMF events to<br>> move the participants back and forth between the different bridges.<br></pre></span><div>Doing the conference this way results in the same kind of long voice queue warnings/errors as before and eventually the DNS lookup for the server fails. All 5,000 callers were able to get in though, which is a bit better than before.<span class=""><br><br><pre>On Tue, Jul 5, 2016 at 5:09 PM, <i>Richard Mudgett <rmudgett at <a href="http://digium.com" target="_blank">digium.com</a></i>> wrote:</pre>> The exceptionally long voice queue length messages can be a symptom of<br>> thread<br>> starvation as the Local channels frame queue has developed an excessive<br>> backlog.<br>> <br>> The forthcoming v13.10.0 release should indirectly take care of the EEXISTS<br>> messages<br>> as part of the <a href="https://issues.asterisk.org/jira/browse/ASTERISK-26088" target="_blank">https://issues.asterisk.org/jira/browse/ASTERISK-26088</a> fix.<br>> Working on<br>> that issue I saw the EEXISTS messages for REGISTER and SUBSCRIBE message<br>> processing.  The issue was a result of the original message and<br>> retransmissions getting<br>> backlogged in the serializer/taskprocessor and responses sent using another<br>> serializer.<br>> <br>> Looks like your system's DNS resolver has gotten overwhelmed.<br><br></span></div><div>Is there any configuration changes I can make to help alleviate the thread starvation on the Local channels frame queue?<br><br></div><div>It does not make sense to me that the system's DNS resolver is getting overwhelmed. When I have 10,000 calls in one bridge, this does not occur. When I have multiple bridges with locally originated channels bridging them then the DNS errors occur.<span class=""><br><br>> Wow.  Thanks Jonathan.  I hadn't thought of doing it that way.  That should<br>> really drop the mixing load.<br>> Probably should allow only ulaw or alaw (pick one) for all participants to<br>> minimize translation costs.<br>> One additional thing I should add is that those linking Local channel<br>> bridges should just allow the<br>> chosen alaw/ulaw to reduce translation to each participant in the holding<br>> bridge.  The forthcoming<br>> v13.10.0 adds the ability to specify formats when ARI originates a channel<br>> (Local in this case) and<br>> an originator channel is not available.  (See CHANGES file)<br><br></span></div><div>I have only been allowing ulaw. That is very interesting to note about the Local channels. I'll keep that in mind.<br><br></div><div>Well, thank you Jonathan, Richard, and Matthew. You have all been really helpful. This has been really interesting trying to get 10,000 callers on one Asterisk server. As Asterisk is not capable on one server for what I am trying to do, I am going to design a scalable, multi-server architecture instead. <br></div><span class=""><div><div><div data-smartmail="gmail_signature"><div dir="ltr"></div></div></div></div></span></div></blockquote><div><br></div><div> While that's definitely a more sustainable approach, it has been awfully entertaining/interesting to see how far you were able to take it. I think everyone was pretty impressed when you hit 5000 channels in a single bridge. Thanks for giving it a shot!</div><div><br></div><div>As an aside, what were you using to simulate the callers? SIPp + a pcap file, or something else?</div><div><br></div><div>Matt</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Matthew Jordan<br>Digium, Inc. | CTO<br>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div></div>