Since net-misc/asterisk-1.8.7.1 specifying signalling=bri_net_ptmp in chan_dahdi.conf prevents chan_dahdi.so from loading. Doing so manually produces the following output: *CLI> module load chan_dahdi.so Unable to load module chan_dahdi.so Command 'module load chan_dahdi.so ' failed. [Oct 23 08:18:06] WARNING[6667]: pbx.c:5658 ast_register_application2: Already have an application 'DAHDISendKeypadFacility' == Parsing '/etc/asterisk/chan_dahdi.conf': == Found == Parsing '/etc/asterisk/users.conf': == Found [Oct 23 08:18:06] WARNING[6667]: chan_dahdi.c:17143 process_dahdi: How cool would it be if someone implemented this mode! For now, sucks for you. (line 1423) [Oct 23 08:18:06] ERROR[6667]: chan_dahdi.c:16595 build_channels: Signalling must be specified before any channels are. Line 1423 in chan_dahdi.conf is "signalling=bri_net_ptmp". This works well with net-misc/asterisk-1.8.6.0 and unfortunately keeps me from upgrading to the SIP-fixed version as per security bug #387453 since non-working DAHDI channels render asterisk completely unusable for me.
Jaco, I do believe that's one of your code comments?
No. That was the comment I got, in return I backported the net_ptmp support - from asterisk 1.8 - did my patch perhaps get applied in reverse or something? Busy downloading the ast 1.8.7.1 source in order to check what's going on. Thanks for the report.
} else if (!strcasecmp(v->value, "bri_net_ptmp")) { #if defined(HAVE_PRI_CALL_HOLD) confp->chan.sig = SIG_BRI_PTMP; confp->pri.pri.nodetype = PRI_NETWORK; #else ast_log(LOG_WARNING, "How cool would it be if someone implemented this mode! For now, sucks for you. (line %d)\n", v->lineno); #endif /* !defined(HAVE_PRI_CALL_HOLD) */ What's your version of libpri?
The oldest version of libpri in the tree is 1.4.12-r1; so I am rather surprised at this failure. It seems to me like out-of-tree ebuilds are in use, which as I'm sure you'll understand is not a situation I'm able to support.
I am using libpri-1.4.12-r1 and asterisk-1.8.7.1, both from main portage tree as distributed via rsync.europe.gentoo.org - except for my current asterisk-1.8.6.0 (which doesn't show this bug) is out-of-tree, because it is no longer in-tree ;) Only my dahdi-drivers (dahdi-2.5.0.1) are "out-of-tree" for as much as I needed to patch the ebuild to compile with a dedicated kernel build directory (see bug #388085).
Tony, Could be that some header or another or something in the build process missing that #define and as a result breaks. Will require some investigation as to whether it should check a different definition, or whether there is a missing #include, or simply whether the ./configure process broke.
(In reply to comment #6) > Could be that some header or another or something in the build process missing > that #define and as a result breaks. Which is why it is concerning that the build system on DAHDI has been modified by the user.
I get the same results when compiling using dahdi 2.5.0.2. I'm not using the patch in bug #388085. I don't have any BRI hardware to test it with, but I do get the "How cool would it be if someone..." compiled into chan_dahdi.o. Seems to be something wrong with autoconfigure. HAVE_PRI is defined in include/asterisk/autoconfig.h, but not HAVE_PRI_CALL_HOLD, although pri_hold_enable exists, and configure says it was found: ... checking for pri_hold_enable in -lpri... yes ... Same thing with other HAVE_PRI_XXX, such as HAVE_PRI_CALL_WAITING. I got worried that I screwed it up with the patch for configure.ac, but the results are the same without that patch. Does anyone know when this last was working?
This works in 1.8.5.0. Same setup. I don't think it has to do with dahdi. It seems a hole section of configure.ac has been removed between 1.8.5.0 and 1.8.7.1. asterisk-1.8.5.0 # diff configure.ac ../../../asterisk-1.8.7.1/work/asterisk-1.8.7.1/configure.ac 23c23 < AC_REVISION($Revision: 320573 $) --- > AC_REVISION($Revision: 336635 $) 411,429d410 .... < AST_EXT_LIB_SETUP_DEPENDENT([PRI_CALL_HOLD], [ISDN PRI call hold], [PRI], [pri]) ... 1806a1788 > AST_EXT_LIB_CHECK([PRI_L2_PERSISTENCE], [pri], [pri_persistent_layer2_option], [libpri.h])
Created attachment 290813 [details, diff] pri-optional-autoconfigure.patch Fix regression of pri options in configure.ac This issue was resolved in 1.8.8.0-rc2. I've backported only the fix for the regression. There are other changes to configure.ac, but they don't seem urgent (or even relevant for gentoo).
Hm... This doesn't seem to work. Let me get back in a minute.
Created attachment 290819 [details, diff] Updated version of pri-optional-autoconfigure.patch that actually works. Sorry about that. I didn't test properly before uploading. Turns out there were some changes required in autoconf/ast_ext_lib.m4 to make this work. It's a bit difficult for me to test this out, but it compiles, and the resulting asterisk binary is working.
(In reply to comment #12) > Created attachment 290819 [details, diff] Felix, could you test this patch on top of 1.8.7.1 please? I plan to release 1.8.7.1-r1 together with DAHDI 2.5.0.2 and ask for fast-track stabilisation. But it would be nice to fix everything at once.
(In reply to comment #13) > (In reply to comment #12) > > Created attachment 290819 [details, diff] > > Felix, could you test this patch on top of 1.8.7.1 please? I plan to release > 1.8.7.1-r1 together with DAHDI 2.5.0.2 and ask for fast-track stabilisation. > But it would be nice to fix everything at once. This patch works for me. Applies and compiles cleanly after gentoo-patchset, DAHDI channels (using net-misc/dahdi-2.5.0.1 with patch from bug #388085 and junghanns.net's just published version 1.0.12) are up as expected and as seen in asterisk-1.8.6.0.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > Created attachment 290819 [details, diff] > > > > Felix, could you test this patch on top of 1.8.7.1 please? I plan to release > > 1.8.7.1-r1 together with DAHDI 2.5.0.2 and ask for fast-track stabilisation. > > But it would be nice to fix everything at once. > > This patch works for me. Applies and compiles cleanly after gentoo-patchset, > DAHDI channels (using net-misc/dahdi-2.5.0.1 with patch from bug #388085 and > junghanns.net's just published version 1.0.12) are up as expected and as seen > in asterisk-1.8.6.0. Confirmed after reboot, using hardened-sources-3.0.4-r4, libpri-1.4.12-r1, dahdi-2.5.0.1 (with junghanns.net drivers 1.0.13(!) and bug #388085) and asterisk-1.8.7.1 with attachment 290819 [details, diff] - works for me now.
+*asterisk-1.8.7.1-r1 (26 Oct 2011) + + 26 Oct 2011; Tony Vroon <chainsaw@gentoo.org> +asterisk-1.8.7.1-r1.ebuild: + Patch by Erik Wallin to restore PRI symbols solves lack of working BRI PTMP + signalling in DAHDI. Closes bug #388179 by Felix Tiede.
This bug is fixed in upstream Asterisk 1.8.8.0-rc2, see ASTERISK-18687 also.
