Enable debugging for only chan_dahdi?

I’m currently trying to locate the source of a odd problem we are having.

Occasianally when we answer the phone, it emits a couple clicks, and the line goes dead (or to dialtone).

We have four FXO lines running straight into Asterisk (Elastix), and two SIP phones. The regular log shows nothing with verbose 3. The disconnect also sometimes happens when the calls come in one FXO port and out another FXO port. When the person receives the call on their cell picks it up, they hear a couple clicks, then the line goes dead or they hear a dialtone.

I think it has to do with how DAHDI is detecting the hangup. In order to trace it, I’d like to set verbosity to 100 and debug to 1 for ONLY chan_dahdi.c.

I did ‘core set debug 1’ and ‘core set verbose 100’. I know that WILL show what I want, but because I don’t know WHEN the call will come in that will disconnect, I’m getting a ton of other information in the log.

Is there a way to enable verbose 100 debugging for ONLY chan_dahdi.c?

Thanks!
-Nathan w/ Cutting Edge

[edit] added ‘sometimes’ to call forwarding section [/edit]

ok, I need help. Would someone kindly look over the following log? I can’t figure out why the call was dropped.

Call route: Incoming port is dahdi 1. From there it goes to ext 329, then queue 150. Finally, someone at extension 204 answers it, hears a couple clicks, and the line goes dead.

I’ve put the log up on pastebin:
http://pastebin.com/JqtQ5Kfz

Lines of interest:

  • 573: Extension 204 answers picks up the phone
  • 672: Exception on 11, Channel 1
  • 673: Got event On hook(1) on channel 1 (index 0)

Any ideas? I’ve been scratching my head on this one for quite a while now.

Here’s my chan_dahdi.conf

[code];autogenerated by /usr/sbin/wancfg_dahdi do not hand edit
;autogenrated on 2009-11-05
;Dahdi Channels Configurations
;For detailed Dahdi options, view /etc/asterisk/chan_dahdi.conf.bak

[trunkgroups]

[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=2
txgain=3
group=1
callgroup=1
pickupgroup=1
immediate=yes
faxdetect=no

;Uncomment these if you have hanup trouble
callprogress=yes
busydetect=yes

;Sangoma AFT-B600 [slot:0 bus:4 span:1]
context=from-zaptel
group=0
echocancel=yes
signalling = fxs_ks
channel => 1

context=from-zaptel
group=0
echocancel=yes
signalling = fxs_ks
channel => 2

context=from-zaptel
group=0
echocancel=yes
signalling = fxs_ks
channel => 3

context=from-zaptel
group=0
echocancel=yes
signalling = fxs_ks
channel => 4

context=from-internal
group=1
echocancel=yes
signalling = fxo_ks
channel => 5[/code]
I’ve got both callprogress=yes and busydetect=yes because I originally had trouble with the lines staying open, even after the other person hung up. I’m playing around with various combinations right now. It takes time because I don’t know if it’s right until NO calls are dropped, and at 6 calls an hour, that can take a while (and none of my test calls from various locations get dropped. aarg!)

It looks like incoming calls from 800*, and 866* get dropped more often than local calls. I’m not sure if that is related or not. Anyone have an idea on what I should take a closer look at?