Hi list!<br><br>We are facing some issues with asterisk using Digium TE420 cards for Argentina Telco frames.<br>Asterisk is generating a coredump periodically, so we went ahead and raised up a bug on Jira platform: https://issues.asterisk.org/jira/browse/ASTERISK-22353<br><br>They are pointing us to the libopenr2 libraries, according to the backtrace generated thru gdb.<br>The environment we are experiencing the incident from has the following details:<br><br>CentOS release 5.7 (Final)
<br>
Kernel 2.6.18-238.12.1.el5 #1 SMP Tue May 31 13:23:01 EDT 2011 i686 i686 i386 GNU/Linux
<br>
Asterisk 1.8.23.0
<br>
DAHDI Version: 2.6.1 Echo Canceller: HWEC, OSLEC
<br>
libpri-1.4.14-0
<br>
libpri-devel-1.4.14-0
<br>
libopenr2-1.3.2-1
<br>
libopenr2-devel-1.3.2-1
<br>
Cards Installed: 03:08.0 Communication controller: Digium, Inc. Wildcard
 TE420 quad-span T1/E1/J1 card 3.3V (PCI-Express) (5th gen) (rev 02)
<br><br>A piece of GDB has the following output after the backtrace analysis:<br><pre>Core was generated by `/usr/sbin/asterisk -f -U asterisk -G asterisk -vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0  0x0014c4e5 in vfprintf () from /lib/libc.so.6
#0  0x0014c4e5 in vfprintf () from /lib/libc.so.6
No symbol table info available.
#1  0x00156742 in fprintf () from /lib/libc.so.6
No symbol table info available.
#2  0x00949d59 in ?? () from /usr/lib/libopenr2.so.3
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.<br><br>I have just the mfcr2 logging flag in true as the example of one of the telco frames below:
</pre><p>usecallerid=yes<br>
hidecallerid=no<br>
callwaiting=no<br>
usecallingpres=yes<br>
callwaitingcallerid=no<br>
threewaycalling=yes<br>
transfer=yes<br>
canpark=yes<br>
cancallforward=yes<br>
callreturn=yes<br>
relaxdtmf=yes<br>
rxgain=1.0<br>
txgain=0.0<br>
signalling=mfcr2<br>
mfcr2_variant=ar<br>
mfcr2_get_ani_first=no<br>
mfcr2_max_ani=13<br>
mfcr2_max_dnis=14<br>
mfcr2_category=national_subscriber<br>
mfcr2_call_files=yes<br>
mfcr2_logdir=span1<br>
mfcr2_logging=all<br>
mfcr2_mfback_timeout=-1<br>
mfcr2_metering_pulse_timeout=-1<br>
group=0<br>
faxdetect=both<br>
faxbuffers=&gt;12,half<br>
context=from-pstn<br>
channel =&gt; 1-15,17-31</p><pre>System.conf from dahdi perspective looks good from our side:<br><br># Frame 1 *****************************<br>span=1,1,0,cas,hdb3<br>cas=1-15,17-31:1101<br>echocanceller=oslec,1-15,17-31<br># Frame 2 *****************************<br>span=2,0,0,cas,hdb3<br>cas=32-46,48-62:1101<br>echocanceller=oslec,32-46,48-62<br># Frame 3 ****************************<br>span=3,3,0,cas,hdb3<br>cas=63-77:1101<br>echocanceller=oslec,63-77<br><br>Cannot find any related issue with libopenr2, nor r2 configuration symtons.<br><br>Is there a bug that we need to be aware of?<br><br>Thank you! <br></pre><br>