Damian Dowling writes: > 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?
Looking at the code briefly, it looks as though the ACD itself has an optional configuration parameter that could be used to override it (I'm not 100% sure on this point - I'm far from the expert on this component), but sipXconfig doesn't generate that parameter at all, so it defaults to the hardcoded 30. > 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. Never any harm in asking, and Pawel has been exploring various alternatives to the current implementation... Paweł Pierścionek wrote: > Good question. RPMs will be 4.0.0-15824 or newer compiled directly > from the urtho_4.0 branch I am about to update with the "fixes" for ACD. > If You are willing to risk the custom build than downloading all RPMs > from the URL (to be posted on Monday) and doing rpm -Uvh sipx*rpm > while sipXecs is NOT running should do the trick. If you do a custom build like this, please set the environment variable SIPX_BUILD_LABEL to some identifiable string. If it works right, that value will be appended to the version string in both the RPM names and the internal version stamps so that the build will be identifiable as different from the standard project builds. Setting a label should not interfere with upgrades, I think. _______________________________________________ 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/
