Firstly let me thank everyone for doing what Digium won't, fix bugs! :) I have only been using CallWeaver for a few days now, but have seen a few issues that you guys may want to look at, my experiences relate to the 1.2.0 RC4 release and I've tried to see if they've been fixed in SVN where possible.
The Debian packages you link to on your wiki are somewhat broken, they require callweaver-sounds, but I can't find any debian packages for callweaver-sounds. Also this appears to have been fixed, but RC4 app_echo doesn't echo :) The Debian package linked to also fails to come with a core lib or update library paths properly etc. /usr/sbin/callweaver: error while loading shared libraries: libcwresample.so.0: cannot open shared object file: No such file or directory Also the instructions for building deb packages claim to have everything needed to build without using bootstrap.sh, however there is no configure file in SVN and the only way I could easily get one was to run bootstrap.sh, and then the configure option datarootdir disappears or is replaced with datadir and the rules file needs to be altered. Since I'm on the subject, it "would be nice" to have multiple debian packages, or perhaps different common sets of modules split over packages, for example with php if you want mysql support, you install php5-mysql or php5-odbc or php5-pgsql etc etc etc, since most people don't want all options all the time, and most of the time only want a fairly basic set of options. This would also cover the situation with encryption not being able to be exported or re-exported from the US without all the paper work, yet having packages available for it somewhere. I've since resorted to building both packages by hand. Due to re-coding of enum functions, enum.conf is never used for anything as far as I can tell, and apart from giving us a little free publicity, it seems pointless and may lead to confusing people. It might be worth removing app_enumlookup along with a number of other apps that have been made depreciated by functions, either that or remove the warnings, not sure which is better etc haven't studied the present code in depth. In func_enum.c there is code for txtcidname, which we coded originally for asterisk before they expanded the enum functionality to support all types. After about 1.2 I think, it became redundant and we stopped publishing txt records and as far as I know no one else ever published txt records for this, or even uses this as far as I know. At the time we switched to publishing NAPTR E2U+X-ADDRESS which contains a lot more information, and in the case of non-7bit ascii text we convert base64 encode it. We have a number of records in the database where due to a combination of base64 encoding, and some very long names and/or street addresses exceeded the 256 byte field in func_enum.c. I'm guessing this will probably cause asterisk to crash if they still aren't parsing input properly. This doesn't seem to be an issue in CallWeaver SVN as far as I can tell. One final bug, although I haven't confirmed if it's still a problem in CallWeaver code or not. http://bugs.digium.com/view.php?id=9581 One final feature request, in func_enum.c there is the option "ALL" I'm not sure if this should be either changed or augmented with a "VOIP" option, we publish 20 or so different types, 15 or so of these types are non-voip related and perhaps this could be made a little "smart" by checking what channel modules are loaded and only including them in any data returned. I would have posted these as tickets but there is no registration link on the website, Steve said something about site update and it being there about a week ago. -- Best regards, Duane http://www.freeauth.org - Enterprise Two Factor Authentication http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ Callweaver-dev mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-dev
