[Home]

Summary:ASTERISK-12696: rc5: chan_dahdi doesn't recognize TDM400P channels
Reporter:Sean Darcy (seandarcy)Labels:
Date Opened:2008-09-08 19:47:02Date Closed:2008-10-27 12:14:56
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_dahdi.conf
( 1) dahdichan_patch_v2
( 2) system.conf
( 3) users.conf
Description:using dahdi-linux-rc4 and 1.6.0-rc5, no dial tone or answer on TDM400P channels. Nothing on CLI.

dahdi-linux seems to work, but chan_dahdi sees only the card not the channels.

****** ADDITIONAL INFORMATION ******

dahdi_cfg -vv
DAHDI Tools Version - 2.0.0-rc2

DAHDI Version: 2.0.0-rc4
Echo Canceller(s): MG2
Configuration
======================


Channel map:

Channel 01: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 01)
Channel 02: FXO Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 02)
Channel 04: FXS Kewlstart (Default) (Echo Canceler: mg2) (Slaves: 04)

3 channels to configure.

Setting echocan for channel 1 to mg2
Setting echocan for channel 2 to mg2
Setting echocan for channel 4 to mg2

cat /proc/dahdi/1
Span 1: WCTDM/4 "Wildcard TDM400P REV I Board 5" (MASTER)

  1 WCTDM/4/0 FXOKS  (EC: MG2)
  2 WCTDM/4/1 FXOKS  (EC: MG2)
  3 WCTDM/4/2
  4 WCTDM/4/3 FXSKS  (EC: MG2)

dahdi_scan
[1]
active=yes
alarms=OK
description=Wildcard TDM400P REV I Board 5
name=WCTDM/4
manufacturer=Digium
devicetype=Wildcard TDM400P REV I
location=PCI Bus 01 Slot 06
basechan=1
totchans=4
irq=16
type=analog
port=1,FXS
port=2,FXS
port=3,none
port=4,FXO


so the driver works. But:

*CLI> dahdi show status
Description                              Alarms  IRQ    bpviol CRC4   Fra Codi Options  LBO
Wildcard TDM400P REV I Board 5           OK      0      0      0      CAS Unk  YEL      0 db (CSU)/0-133 feet (DSX-1)
*CLI> dahdi show channels
  Chan Extension  Context         Language   MOH Interpret        Blocked    State    
pseudo            default                    default                         In Service
*CLI> dahdi show channel 1
Unable to find given channel 1
Command 'dahdi show channel 1' failed.
*CLI> dahdi restart
Destroying channels and reloading DAHDI configuration.
      > Initial softhangup of all DAHDI channels complete.
      > Final softhangup of all DAHDI channels complete.
 == Unregistered channel -2
 == Parsing '/etc/asterisk/chan_dahdi.conf':   == Found
 == Parsing '/etc/asterisk/users.conf':   == Found

cat /etc/asterisk/chan_dahdi.conf


[trunkgroups]

[channels]
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=yes

group=1
callgroup=1
pickupgroup=1

callprogress=yes
progzone=us
tonezone = 0 ; 0 is US
jbenable = yes

[home-phones]
context=internal      ; Uses the [internal] context in extensions.conf
signalling=auto     ; fxo_ks Use FXO signalling for an FXS channel - as set in sytem.conf.conf
;channel => 1          ; Telephone attached to port 1
;channel => 2          ; Telephone attached to port 2
dahdichan => 1,2

[pstn]
context=incoming-pstn-line  ; Incoming calls go to [incoming-pstn-line] in extensions.conf
signalling=auto     ; fxs_ks Use FXS signalling for an FXO channel - use as set in system.conf
faxdetect=incoming
busydetect=yes
;channel => 4
dahdichan => 4          ; PSTN attached to port 4
Comments:By: Sean Darcy (seandarcy) 2008-09-09 21:01:37

same result with rc6
By: Sean Darcy (seandarcy) 2008-09-12 14:23:30

got your note. Revised chan_dahdi.conf

cat chan_dahdi.conf
[trunkgroups]

[channels]
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=yes

group=1
callgroup=1
pickupgroup=1

callprogress=yes
progzone=us
tonezone = 0 ; 0 is US
jbenable = yes              ; Enables the use of a jitterbuffer on the receiving side of a
                             ; DAHDI channel. Defaults to "no".

;;; home-phones
context=internal      ; Uses the [internal] context in extensions.conf
signalling=auto     ; fxo_ks Use FXO signalling for an FXS channel - as set in sytem.conf.conf
;channel => 1          ; Telephone attached to port 1
;channel => 2          ; Telephone attached to port 2
dahdichan => 1,2

;;; pstn
context=incoming-pstn-line  ; Incoming calls go to [incoming-pstn-line] in extensions.conf
signalling=auto     ; fxs_ks Use FXS signalling for an FXO channel - use as set in system.conf
faxdetect=incoming
busydetect=yes
;channel => 4
dahdichan => 4          ; PSTN attached to port 4

Now rc6 sees channel 4 , pstn, but _not_ 1 or 2:

Parsing '/etc/asterisk/chan_dahdi.conf':   == Found
 == Parsing '/etc/asterisk/users.conf':   == Found
   -- Registered channel 4, FXS Kewlstart signalling
   -- Automatically generated pseudo channel
 == Registered channel type 'DAHDI' (DAHDI Telephony Driver)
 == Manager registered action DAHDITransfer
 == Manager registered action DAHDIHangup
 == Manager registered action DAHDIDialOffhook
 == Manager registered action DAHDIDNDon
 == Manager registered action DAHDIDNDoff
 == Manager registered action DAHDIShowChannels
 == Manager registered action DAHDIRestart
chan_dahdi.so => (DAHDI Telephony)

dahdi show status
Description                              Alarms  IRQ    bpviol CRC4   Fra Codi Options  LBO
Wildcard TDM400P REV I Board 5           OK      0      0      0      CAS Unk  YEL      0 db (CSU)/0-133 feet (DSX-1)
*CLI> dahdi show channels
  Chan Extension  Context         Language   MOH Interpret        Blocked    State    
pseudo            incoming-pstn-l            default                         In Service
     4            incoming-pstn-l            default                         In Service

But then I ;'d out the pstn stanza, that is everthing after dahdichan => 1,2
and:

Parsing '/etc/asterisk/chan_dahdi.conf':   == Found
 == Parsing '/etc/asterisk/users.conf':   == Found
   -- Registered channel 1, FXO Kewlstart signalling
   -- Registered channel 2, FXO Kewlstart signalling
   -- Automatically generated pseudo channel
 == Registered channel type 'DAHDI' (DAHDI Telephony Driver)
 == Manager registered action DAHDITransfer
 == Manager registered action DAHDIHangup
 == Manager registered action DAHDIDialOffhook
 == Manager registered action DAHDIDNDon
 == Manager registered action DAHDIDNDoff
 == Manager registered action DAHDIShowChannels
 == Manager registered action DAHDIRestart
chan_dahdi.so => (DAHDI Telephony)
dahdi show channels
  Chan Extension  Context         Language   MOH Interpret        Blocked    State    
pseudo            internal                   default                         In Service
     1            internal                   default                         In Service
     2            internal                   default                         In Service

so it looks like chan_dahdi is only parsing the last dahdichan it finds.
By: John Bigelow (jbigelow) 2008-09-12 14:54:30

I had removed the note since I saw you're using Asterisk 1.6 which is capable of using user defined context/sections. If you use channel => X under the '[channel]' section it shows up fine. It looks to be a problem within user defined sections.
By: Sean Darcy (seandarcy) 2008-09-12 22:53:32

I don't understand. Do you mean I should use 'channel => x' instead of dahdichan?

In any event, ;'d out the context/sections _did_ mean that dahdi_chan saw at least one channel. So your note did do something.

I'm confused. Is there a way this will work? Or is there a bug?
By: Sean Darcy (seandarcy) 2008-09-13 10:56:15

Here's what happens:

1. If you use dahdichan=>  chan_dahdi only parses the _last_ dahdichan statement.

2. If you use dahdichan=> , you can use section headings , i.e., [pstn], but still only the last dahdichan statment is parsed.

3. channels=> works, just like in zapata.conf.

4. If you use channels=>  , you cannot use section headings. If you do no channels are parsed.

So there's at least one bug in dahdi_chan - No. 1 above.

Also chan_dahdi.conf.sample is very confusing. At the very least, the references to "dahdi.conf" should be dropped or clarified ( is it referring to dahdi/system.conf ? )

So now with channels=>,  rc6 and my tdm400p work. But now no dialtone, for which I'll file another bug.
By: John Bigelow (jbigelow) 2008-09-15 11:48:17

Give the patch I attached a try. I know very little C but the patch seems to work for me.
By: John Bigelow (jbigelow) 2008-09-17 17:39:58

New patch uploaded. The original would not have compiled.
By: Sean Darcy (seandarcy) 2008-09-28 20:13:36

Nope. The patch compiled.

If I used the working chan_dahdi, it still worked.

However, changing channel=> to dahdichan => meant only the last dahdichan was parsed.

sdahdi show channels
  Chan Extension  Context         Language   MOH Interpret        Blocked    State    
pseudo            incoming-pstn-l            default                         In Service
     4            incoming-pstn-l            default                         In Service


Here's bottom of chan_dahdi:

;;;[home-phones]
context=internal      ; Uses the [internal] context in extensions.conf
signalling=auto     ; fxo_ks Use FXO signalling for an FXS channel - as set in sytem.conf.conf
;channel => 1          ; Telephone attached to port 1
;channel => 2          ; Telephone attached to port 2
dahdichan => 1,2

;;;[pstn]
context=incoming-pstn-line  ; Incoming calls go to [incoming-pstn-line] in extensions.conf
signalling=auto     ; fxs_ks Use FXS signalling for an FXO channel - use as set in system.conf
faxdetect=incoming
busydetect=yes
;;channel => 4
dahdichan => 4          ; PSTN attached to port 4
By: John Bigelow (jbigelow) 2008-09-29 01:26:59

1. Did the patch resolve the issue?
2. If not, what is the behavior after applying it?
3. Also what version of Asterisk did you apply it to?

My setup:
-Used Asterisk 1.6 RC6 and Asterisk 1.6 branch (rev 142954)
-1 FXS
-1 FXO

Using defaults of chan_dahdi.conf and my created sections being this:
[home-phones]
context= mycontext
signalling=fxo_ks
dahdichan= 1
group=3
callerid="bob2"

[outgoing]
context= myoutcontext
signalling=fxs_ks
group=6
dahdichan= 4
callerid="billy bob2"

When I run 'dahdi show channels' it correctly shows both channel 1 and 4. Before the patch it would not show any channels.
By: Sean Darcy (seandarcy) 2008-09-29 18:59:49

1. No

2. Same as before

3. 1.6 rc6
By: John Bigelow (jbigelow) 2008-10-03 16:17:49

Something is not correct. I only can reproduce what you originally reported "dahdi-linux seems to work, but chan_dahdi sees only the card not the channels". I just updated to DAHDI-2.0 and Asterisk-1.6.0 and it behaves the same with not showing ANY channels when using 'dahdichan' in my defined sections of chan_dahdi.conf. Applying the patch correctly shows my 3 channels(I added another FXS module to match your config exactly).

1. Did you use the 'dahdichan_patch_v1' or the 'dahdichan_patch_v2' patch?
2. Did applying the patch fail?
3. Are you sure you restarted Asterisk("dahdi restart" isn't enough)?
4. Please attach your system.conf, chan_dahdi.conf, and users.conf files to this bug. (Remove any passwords, etc.)


By: Sean Darcy (seandarcy) 2008-10-05 18:21:16

1. The v2 patch which compiled cleanly.

2. the patch applied cleanly

3. restarted asterisk.

Now using 1.6.0, 2.0.0 dahdi-linux & tools.

I switch back and forth between channels-> and dahdichan-> in the attached chan_dahdi.conf by commenting and uncommenting the lines. If I restart asterisk with dahdichan uncommented, i.e.,

;;;[home-phones]
context=internal      ; Uses the [internal] context in extensions.conf
signalling=auto     ; fxo_ks Use FXO signalling for an FXS channel - as set in $
;;channel => 1          ; Telephone attached to port 1
;;
channel => 2          ; Telephone attached to port 2
dahdichan => 1,2

;;;[pstn]
context=incoming-pstn-line  ; Incoming calls go to [incoming-pstn-line] in exte$
signalling=auto     ; fxs_ks Use FXS signalling for an FXO channel - use as set$
faxdetect=incoming
busydetect=yes
;;channel => 4
dahdichan => 4          ; PSTN attached to port 4

asterisk*CLI> dahdi show channels
  Chan Extension  Context         Language   MOH Interpret        Blocked    State    
pseudo            incoming-pstn-l            default                         In Service
     4            incoming-pstn-l            default                         In Service


But if I uncomment the channels=> lines, comment out the dahdican=> lines and restart asterisk, I get:



asterisk*CLI> dahdi show channels
  Chan Extension  Context         Language   MOH Interpret        Blocked    State    
     1            internal                   default                         In Service
     2            internal                   default                         In Service
     4            incoming-pstn-l            default                         In Service


BTW, I get the same behavior if I use dahdi restart. Changing chan_dahdi.conf gives the same results.
By: John Bigelow (jbigelow) 2008-10-06 16:57:29

I took a look at Asterisk 1.6.1 branch and tested it. It appears to correctly work for me without patching it.
By: Jason Parker (jparker) 2008-10-15 15:47:25

Does anything need to be done here, now that 1.6.0.1 was released?
By: Sean Darcy (seandarcy) 2008-10-18 11:17:39

I don't know. I've gone back to 1.4.22.

If the only difference is the patch. then 1.6.0.1 wouldn't make any difference.

But I thought that the only diff in 1.6.0.1 is removing the references to dahdichan in the chan_dahdi.conf file. So we've solved it by definition, since channels worked for me.
By: Leif Madsen (lmadsen) 2008-10-20 08:19:04

seandarcy: any chance of you testing the latest version to see if this is still an issue for you? Since angler doesn't seem to be able to reproduce in the latest version, then it'd be nice for confirmation.

If that is not possible, we'll have to close this bug as suspended, and can reopen if necessary in the future should you move back to 1.6 and still have this issue.

Thanks!
By: Leif Madsen (lmadsen) 2008-10-27 12:14:53

It appears the issue has been resolved in later versions of 1.6. If this is not the case, please reopen the issue with new information. Thanks!