Summary: | ASTERISK-22279: when fxs(fxs is callee) is ring, dialing is set to 1,and so frametype = AST_FRAME_NULL in chan_dahdi.c/dahdi_read() , so will not invoke ast_dsp_busydetect() | ||||
Reporter: | wangpeng (voipwangpeng) | Labels: | |||
Date Opened: | 2013-08-12 04:09:59 | Date Closed: | |||
Priority: | Major | Regression? | |||
Status: | Open/New | Components: | |||
Versions: | 1.8.22.0 13.18.4 | Frequency of Occurrence | |||
Related Issues: |
| ||||
Environment: | ubuntu 12.04 | Attachments: | ( 0) issue_busydetectnotwork_full_log_first ( 1) issue_busydetectnotwork_full_log_second | ||
Description: | dialplan is :
[from-pstn] exten => s,1,Answer() same => n,Background(welcome) same => n,WaitExten(100) exten => 8003,1,Dial(${FXSPORT_3}) same => n,Goto(S_${DIALSTATUS},1) in chan_dahdi.conf is: busydetect=yes busycount=3 busypattern=350,350 first: an incoming call(will via fxo port),and when run WaitExten(100),outbound call hungup, but see log(by asterisk -rvvvv) "Perform busy detection etc on the dahdi line", fxo port not hungup. second: i modify WaitExten(100) to WaitExten(10). an incoming call(will via fxo port and then dial exten of asterisk),and dial 8003,will run Dial(${FXSPORT_3}), outbound call hungup, but exten 8003 is still ring. i found p->dialing is 1 when fxs(8003) is ring,this will led to "frametype = AST_FRAME_NULL" in chan_dahdi.c/dahdi_read() , so will not invoke ast_dsp_busydetect() (ref ast_dsp_process,and fxo will invoke ast_dsp_busydetect,but not return 1). fxs is callee,why set dialing to 1??is this led to busydetect not work?? how to resolve it?? thanks | ||||
Comments: | By: Rusty Newton (rnewton) 2013-08-15 15:21:46.572-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 Please follow the instructions on the wiki page indicated. * Specifically attach (More Actions > Attach Files) logs of both scenarios you describe, where busydetect works and where it doesn't. * Be sure the log includes DEBUG messages. If capturing from the CLI be sure you set it to level 5 and VERBOSE to 5 as well. What hardware are you using with DAHDI? By: wangpeng (voipwangpeng) 2013-08-15 20:47:55.965-0500 scencs of first log file is after WaitExten(15), fxo hungup itself. scencs of second log file is after outbound call hungup, i hungup 8003(after it ring a while). dahdi info: Loading DAHDI hardware modules: wctdm24xxp: done dahdi_echocan_oslec: done root@ubuntu:~# dahdi_cfg -vv DAHDI Tools Version - 2.7.0 DAHDI Version: 2.7.0 Echo Canceller(s): OSLEC Configuration ====================== Channel map: Channel 01: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 01) Channel 02: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 02) Channel 03: FXO Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 03) Channel 04: FXO Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 04) 4 channels to configure. Setting echocan for channel 1 to oslec Setting echocan for channel 2 to oslec Setting echocan for channel 3 to oslec Setting echocan for channel 4 to oslec By: Rusty Newton (rnewton) 2013-09-03 19:26:01.578-0500 Please attach your *complete* dahdi/system.conf and chan_dahdi.conf files to the issue. Please also use the dahdi_monitor application to record the audio on the line for both of your call scenarios. You can use it like "dahdi_monitor <channel number> -f <filename.raw>". Be sure to gather DEBUG like you did before, but for each recording. Attach the resulting files to the issue and indicate which *new* debug log they belong to. By: Rusty Newton (rnewton) 2013-09-04 19:34:24.477-0500 Don't worry about the recordings so much, but please attach the complete configuration files mentioned. Richard Mudgett has looked into the issue and determined that there is an issue as you have described, but the configuration files will still help out for understanding the behaviour in your scenario. |