| Summary: | ASTERISK-18746: RFC2833 stops responding | ||||
| Reporter: | dcitelecom (dcitelecom) | Labels: | |||
| Date Opened: | 2011-10-23 19:09:34 | Date Closed: | 2011-11-03 10:41:20 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Core/RTP | ||
| Versions: | 1.8.7.1 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | centos 5.5, FreePBX distro 1.87.29.55-2 with Asterisk 1.8.7.1-1 and Dahdi 2.5.0.1-1 | Attachments: | |||
| Description: | if inband provider with transport=tcp uses dtmfmode=RFC2833 and outbound trunk (transport=udp or tcp) also uses RFC2833 and 7-10 digits are entered very fast, the trunk stops transmitting dtmf tones after the first set of digits is entered. So 10 digits can be entered no problem but once you stop and enter a second set of digits that second set is no longer transmitted. This behaviour can be duplicated every single time. and seems to be related to https://issues.asterisk.org/view.php?id=13209 which is also caused by two trunks using RFC2833 dtmfmode. | ||||
| Comments: | By: Leif Madsen (lmadsen) 2011-11-01 07:48:59.606-0500 You're going to need to provide some information and debug logs to go on here. Please describe the topology (what end points are involved) and also we'll need to know what channel modules are in use (chan_sip? chan_iax2?), along with console debug information from the channel, and the DTMF logs. Once you can reproduce the problem, getting a backtrace and 'core show locks' output may also be useful. Additional messages will follow this one pointing out how to get that information. By: Leif Madsen (lmadsen) 2011-11-01 07:49:14.914-0500 Thank you for your bug report. In order to move your issue forward, we require a backtrace[1] from the core file produced after the crash. Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then: make install After enabling, reproduce the crash, and then execute the backtrace[1] instructions. When complete, attach that file to this issue report. [1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace By: Leif Madsen (lmadsen) 2011-11-01 07:49:24.109-0500 Debugging deadlocks: Please select DEBUG_THREADS and DONT_OPTIMIZE in the Compiler Flags section of menuselect. Recompile and install Asterisk (i.e. make install). This will then give you the console command "core show locks." When the symptoms of the deadlock present themselves again, please provide output of the deadlock via: # asterisk -rx "core show locks" | tee /tmp/core-show-locks.txt # gdb -se "asterisk" <pid of asterisk> | tee /tmp/backtrace.txt gdb> bt gdb> bt full gdb> thread apply all bt Then attach the core-show-locks.txt and backtrace.txt files to this issue. Thanks! By: Leif Madsen (lmadsen) 2011-11-01 07:49:32.757-0500 We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: dcitelecom (dcitelecom) 2011-11-01 20:06:45.979-0500 I am sorry but that's beyond my capabilities. We use a pre-compiled system (FreePBX distro) and I can't recompile asterisk or change settings. I can attach log files if that helps. We resolved the issue by switching the outbound trunk to info so the two trunks don't conflict. | ||||