On 2009-06-19, at 10:33, Damian Dowling wrote: > Scott Lawrence wrote: >> On Thu, 2009-06-18 at 15:16 +0100, Damian Dowling wrote: >> >> >>> This limit, which seems extremely low to me, makes the ACD Server >>> useless to us. Is there a way to take Agent's calls and transfers >>> out of >>> the count and have the 30 just apply to queued? In other words >>> stop the >>> ACD Server from bridging the media stream? >>> >> >> Not at present. >> >> The issue to watch/vote-for is >> http://track.sipfoundry.org/browse/XX-4884 >> >> which, I'm sorry to say, is not currently in the queue to be >> addressed >> in 4.2. >> >> I agree that the limit is way too low. It was set to this based on >> performance testing we did a couple of years ago - it's possible >> that on >> better hardware available now it could be increased. If someone is >> interested in doing the testing/development work on this, here's your >> chance to be a hero... >> > Scott, > > This is a deal breaker for us, we don't really have the expertise in > house to start altering code. Is this 30 call limit configurable? > > Also is there anyway to increase the priority on getting a permanent > fix, like a bounty or something. I am not exactly familiar with how > things work with SipXecs in these matters, so I hope I haven't said > anything inappropriate. >
I can build a custom RPMs for You with this limit increased to like 600 calls + other tweaks that allow the sipXecs internal message queue to survive increased number of calls/agents in ACD. But : - this will not make the ACD any more stable - You'll have to wait 3 seconds times number of agents before the server becomes operational each time You activate a new config - All Your agents will still have to logout/login after each config activation - Also I am getting errors with port allocation for RTP streams that results in one way audio. This is with 300 agents talking. Had no time to do bisecting to see when the problems start to show up. Pawel, _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
