On Wed, Jul 6, 2016 at 2:20 PM, Michael Petruzzello < [email protected]> wrote:
> On Tue, Jul 5, 2016 at 4:03 PM, Jonathan Rose <jonathan.rose at > motorolasolutions.com> wrote: > > > If you don't need all of your participants actually to be speaking at a > > time (and I hope not with that kind of volume), you could use holding > > bridges for the vast majority of the partipants. Link the bridges using a > > local channel with the Hold bridge side being set to use the 'announcer' > > bridge role and the hold bridge will effectively just be voiceless > > conference participants. If you want, you can listen for DTMF events to > > move the participants back and forth between the different bridges. > > 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. > > On Tue, Jul 5, 2016 at 5:09 PM, *Richard Mudgett <rmudgett at digium.com > <http://digium.com>*> wrote: > > > The exceptionally long voice queue length messages can be a symptom of > > thread > > starvation as the Local channels frame queue has developed an excessive > > backlog. > > > > The forthcoming v13.10.0 release should indirectly take care of the > EEXISTS > > messages > > as part of the https://issues.asterisk.org/jira/browse/ASTERISK-26088 > fix. > > Working on > > that issue I saw the EEXISTS messages for REGISTER and SUBSCRIBE message > > processing. The issue was a result of the original message and > > retransmissions getting > > backlogged in the serializer/taskprocessor and responses sent using > another > > serializer. > > > > Looks like your system's DNS resolver has gotten overwhelmed. > > Is there any configuration changes I can make to help alleviate the thread > starvation on the Local channels frame queue? > > 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. > > > Wow. Thanks Jonathan. I hadn't thought of doing it that way. That > should > > really drop the mixing load. > > Probably should allow only ulaw or alaw (pick one) for all participants > to > > minimize translation costs. > > One additional thing I should add is that those linking Local channel > > bridges should just allow the > > chosen alaw/ulaw to reduce translation to each participant in the holding > > bridge. The forthcoming > > v13.10.0 adds the ability to specify formats when ARI originates a > channel > > (Local in this case) and > > an originator channel is not available. (See CHANGES file) > > I have only been allowing ulaw. That is very interesting to note about the > Local channels. I'll keep that in mind. > > 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. > 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! As an aside, what were you using to simulate the callers? SIPp + a pcap file, or something else? Matt -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
