Topic: No Dial tone on FXS ports

[compsos]

Hi S
Not sure if this only started after upgrading to 2.3.1-20 or it was just going to start at the same time.

Basically a TDM422B card seems to be only working a single FXO port on port 1. The 2nd FXO deflects all incoming calls as busy, a internal call to any analogue phone on the FXS ports goes straight to message bank. The phones have no dial tone.

The only clue I have found is in the console

Code: [Select]

[Jul 13 22:35:00] WARNING[31878]: channel.c:3210 ast_request: No channel type registered for 'DAHDI'
[Jul 13 22:35:00] WARNING[31878]: app_dial.c:1272 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 66 - Channel not implemented)
  == Everyone is busy/congested at this time (1:0/0/1)
The dahdi_cfg -vv did throw

Code: [Select]

DAHDI Tools Version - 2.1.0.2
Notice: Configuration file is /etc/dahdi/system.conf
line 15: Syntax error. Should be <keyword>=<value>
line 17: Syntax error. Should be <keyword>=<value>
But issuing /usr/bin/dos2unix /etc/dahdi/system.conf seems to have fixed that and dahdi loads OK. How can I test/prove the 3 (1 FXO & 2 FXS) modules that now seem suspect?
Thanks

Details
asterisk-1.4.25.1-78.el4
asterisk-addons-1.4.8-22.el4
dahdi-linux-kmdl-2.6.9-78.0.22.ELsmp-2.1.0.4-60.el4
dahdi-tools-2.1.0.2-59.el4
dahdi-linux-2.1.0.4-60.el4
kernel-2.6.9-78.0.22.ELsmp

[compsos]

OK Got the extension FXS Ports back but still the 1 FXO port reports busy. The module is a X100M card. Is there a way to reset this card? I have shut down and removed the module card and reseated but made no difference.

[SARK devs]

with the card fitted and running, at the asterisk console do

dahdi show channels


also - at the linux console 

cat /proc/dahdi/1

should show the card channels

Usually its the FXS channels which give trouble, not the FXO

Best

S

[compsos]

Thanks S
I was unable to see any difference between the working one and the one rejecting all calls

Code: [Select]

   Chan Extension  Context         Language   MOH Interpret
 pseudo            default                    default
      1            mainmenu                   default
      2            mainmenu                   default
      3            internal                   default
      4            internal                   default

Failing Card
Channel: 2*CLI>
File Descriptor: 22
Span: 1
Extension:
Dialing: no
Context: mainmenu
Caller ID:
Calling TON: 0
Caller ID name:
Destroy: 0
InAlarm: 0
Signalling Type: FXS Kewlstart
Radio: 0
Owner: <None>
Real: <None>
Callwait: <None>
Threeway: <None>
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Relax DTMF: yes
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
Echo Cancellation: 128 taps unless TDM bridged, currently OFF
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Onhook

Working Card
File Descriptor: 21
Span: 1
Extension: CLI>
Dialing: no
Context: mainmenu
Caller ID:
Calling TON: 0>
Caller ID name:
Destroy: 0*CLI>
InAlarm: 0
Signalling Type: FXS Kewlstart
Radio: 0
Owner: <None>I>
Real: <None>
Callwait: <None>
Threeway: <None>
Confno: -1*CLI>
Propagated Conference: -1
Real in conference: 0
DSP: no
Relax DTMF: yes
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
Echo Cancellation: 128 taps unless TDM bridged, currently OFF
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Onhook

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

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

Both say they are "Onhook" but all calls on card 2 are instantly rejected as busy with no activity on the console. This is the 2nd time a card in this position has failed with no warnings or messages. It would be great to be able to pin point the cause.
Thanks

[SARK devs]

Hard to know what to suggest.  You could try swapping the daughterboards around to see if the fault follows the board.  If it does then you probabaly need a new daughterboard.

Over the years we have had quite a few TDM FXO modules blow, usually as a result of some kind of surge on the phone line (we've had a few go during thunder storms).

Best

S
   

[compsos]

Thanks Jeff
I have ordered new daughterboard. Just strange how the last one to fail was in the same position.