Hello all, I?m not sure if this is the right venue for this question, so please let me know if there is a better place to ask. We have been experimenting with using ConfBridge to reduce connect time for agents on an outbound dialer (reminder calls, in case you?re wondering). In a simulation, we parked 80 idle agents into 80 idle ConfBridge channels. This is to say, 80 channels were sitting alone in separate rooms with no mixing going on. Since this is PSTN, all of the calls are ulaw, so there should be no need to transcode. In this situation, Asterisk was consuming 72% of the CPU steady. Since our goal is to get well above 80 agents, we realized we had a problem. I have several questions around this scenario: 1) I had thought that ConfBridge optimizes media paths where it can. In our use-case, the number of participants in ConfBridge will always be exactly 1 or 2 - both of which are highly optimizable. Is my understanding wrong? 2) Why is ConfBridge eating so much CPU with only 1 channel per bridge? Is it transcoding? Is it mixing? 3) Is there a way to generally reduce ConfBridge overhead? Can we specify the codec up front? All of my calls should be ulaw so there should be no need to transcode before mixing. 4) We are now looking at moving to the AMI Bridge command - should we expect better performance as a result? Additional technical details: ConfBridge with timerfd Asterisk version 11.3.0 Linux 3.8.0-29-generic (Ubuntu Precise) confbridge.conf: [general] [default_user] type=user admin=no music_on_hold_when_empty=no quiet=yes announce_user_count=no announce_only_user=no announce_user_count_all=no [default_bridge] type=bridge max_members=2 [agent_menu] type=menu *3=admin_kick_last ; only applied to admin users 3=admin_kick_last ; only applied to admin users Thanks! /BAK/ -- Ben Klang Principal/Technology Strategist, Mojo Lingo bklang at mojolingo.com +1.404.475.4841 Mojo Lingo -- Voice applications that work like magic http://mojolingo.com Twitter: @MojoLingo -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131223/830a8a84/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131223/830a8a84/attachment.pgp>