UK PSTN Span 1: WCTDM/4 "Wildcard TDM400P REV I Board 5"

Asterisk Asterisk Support
1

G’day all,

Problem:
I have two BT PSTN line plugged into a tdm400p.
Line on Chan 3 works OK
Line on Chan 4 does not pick up and I can’t dial out.
This setup has been working for about two years and failed about a week ago,

Asterisk 1.6.2.7
DAHDI Version: 2.3.0 Echo Canceller: MG2

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

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

I have the above which has just worked for ever with out a problem.
Last week one of the PSTN lines has failed.

I have swapped the lines over and the problem moves, as you can see above I have an error on chan if I swap chan 3 and 4 the problem moves to chan 3. So I think I rule out the tdm400p and daughter cards that are on it.

If I do dahdi show channel 3 and 4 the one thing I see different it…
chan 3 = Hookstate (FXS only): Offhook
chan 4 = Hookstate (FXS only): Onhook

So why are those different?
I also enabled debug and set debug to 5 and had a look at the output for the two pstn lines
chan 4 (fails) output looked like…

[Oct 13 14:39:53] DEBUG[12600] chan_dahdi.c: Monitor doohicky got event Polarity Reversal on channel 4 [Oct 13 14:39:53] VERBOSE[12600] chan_dahdi.c: == Starting post polarity CID detection on channel 4 [Oct 13 14:39:53] DEBUG[12600] dsp.c: Setup tone 1100 Hz, 500 ms, block_size=160, hits_required=21 [Oct 13 14:39:53] DEBUG[12600] dsp.c: Setup tone 2100 Hz, 2600 ms, block_size=160, hits_required=116 [Oct 13 14:39:53] DEBUG[12600] dsp.c: dsp busy pattern set to 0,0 [Oct 13 14:39:53] DEBUG[12600] devicestate.c: device 'DAHDI/4-1' state '6' [Oct 13 14:39:53] DEBUG[12598] app_queue.c: Device 'DAHDI/4-1' changed to state '6' (Ringing) but we don't care because they're not a member of any queue. [Oct 13 14:39:53] VERBOSE[13062] chan_dahdi.c: -- Starting simple switch on 'DAHDI/4-1' [Oct 13 14:39:53] NOTICE[13062] chan_dahdi.c: Got event 17 (Polarity Reversal)... [Oct 13 14:39:55] WARNING[13062] chan_dahdi.c: CID timed out waiting for ring. Exiting simple switch [Oct 13 14:39:55] DEBUG[13062] channel.c: Hanging up channel 'DAHDI/4-1' [Oct 13 14:39:55] DEBUG[13062] chan_dahdi.c: dahdi_hangup(DAHDI/4-1) [Oct 13 14:39:55] DEBUG[13062] chan_dahdi.c: Hangup: channel: 4 index = 0, normal = 14, callwait = -1, thirdcall = -1 [Oct 13 14:39:55] DEBUG[13062] chan_dahdi.c: Set option TDD MODE, value: OFF(0) on DAHDI/4-1 [Oct 13 14:39:55] DEBUG[13062] chan_dahdi.c: Updated conferencing on 4, with 0 conference users [Oct 13 14:39:55] VERBOSE[13062] chan_dahdi.c: -- Hungup 'DAHDI/4-1' [Oct 13 14:39:55] DEBUG[12592] devicestate.c: No provider found, checking channel drivers for DAHDI - 4 [Oct 13 14:39:55] DEBUG[12592] devicestate.c: Changing state for DAHDI/4 - state 0 (Unknown) [Oct 13 14:39:55] DEBUG[12592] devicestate.c: device 'DAHDI/4' state '0' [Oct 13 14:39:55] DEBUG[12598] app_queue.c: Device 'DAHDI/4' changed to state '0' (Unknown) but we don't care because they're not a member of any queue.

and chan 3 (works)

[Oct 13 14:41:53] DEBUG[12600] chan_dahdi.c: Monitor doohicky got event Polarity Reversal on channel 3 [Oct 13 14:41:53] VERBOSE[12600] chan_dahdi.c: == Starting post polarity CID detection on channel 3 [Oct 13 14:41:53] DEBUG[12600] dsp.c: Setup tone 1100 Hz, 500 ms, block_size=160, hits_required=21 [Oct 13 14:41:53] DEBUG[12600] dsp.c: Setup tone 2100 Hz, 2600 ms, block_size=160, hits_required=116 [Oct 13 14:41:53] DEBUG[12600] dsp.c: dsp busy pattern set to 0,0 [Oct 13 14:41:53] DEBUG[12600] devicestate.c: device 'DAHDI/3-1' state '6' [Oct 13 14:41:53] DEBUG[12598] app_queue.c: Device 'DAHDI/3-1' changed to state '6' (Ringing) but we don't care because they're not a member of any queue. [Oct 13 14:41:53] VERBOSE[13078] chan_dahdi.c: -- Starting simple switch on 'DAHDI/3-1' [Oct 13 14:41:54] NOTICE[13078] chan_dahdi.c: CallerID number: 907785......, name: (null), flags=4 [Oct 13 14:41:54] DEBUG[13078] chan_dahdi.c: Exception on 13, channel 3 [Oct 13 14:41:54] DEBUG[13078] chan_dahdi.c: Got event Ring Begin(18) on channel 3 (index 0) [Oct 13 14:41:55] DEBUG[13078] chan_dahdi.c: Exception on 13, channel 3 [Oct 13 14:41:55] DEBUG[13078] chan_dahdi.c: Got event Ring/Answered(2) on channel 3 (index 0) [Oct 13 14:41:55] DEBUG[13078] chan_dahdi.c: Setting IDLE polarity due to ring. Old polarity was 1 [Oct 13 14:41:55] DEBUG[13078] chan_dahdi.c: Ring detected [Oct 13 14:41:55] DEBUG[13078] pbx.c: Launching 'Set' [Oct 13 14:41:55] VERBOSE[13078] pbx.c: -- Executing [s@indial-01736788279:1] Set("DAHDI/3-1", "incoming=01736......") in new stack [Oct 13 14:41:55] DEBUG[13078] pbx.c: Function result is '907785......'

I have tried a few things, but not sure where to go from here.

Have tried
1.
issues.asterisk.org/view.php?id=14577
2.
If I turn usecallerid=no in chan_dahdi.conf
I get phantom calls…
3.
Replaced various bit of the BT wiring and internal, I need to prove the wiring from the master socket to the card just to ensure there is no issue, but since I swapped the wires around I think it proves the fault is not with me.

I have a ‘normal’ phone and that works and displays callerid OK.
I do have a DACS unit on this line and I am wondering if that might be the problem.

Edit 1
I compiled and ran fxstest on chan 3/4 and got…
chan3 (works)

[root@pbx tools]# ./fxstest /dev/dahdi/3 stats TIP: -50.0000 Volts RING: -50.0000 Volts VBAT: -50.0000 Volts
chan 4 (fails)

[root@pbx tools]# ./fxstest /dev/dahdi/4 stats TIP: 1.0000 Volts RING: 1.0000 Volts VBAT: 1.0000 Volts

2

Ok before we start.
can you clearly explain what the problem is, not expect us to look through output to find an error.

secondly post your config files for these lines so we can look at those.

a dacs could be a problem as thse do reduce line voltage.

Ian

3

Edited original post to add the problem and added output of fxstest as well.

I also plugged both chan 3 and 4 into the same pstn line and got the same readings on each.
I think I have ruled out the hardware as being an issue.

configs for dahdi

chan_dahdi.conf

[code]signalling=fxs_ks
immediate=yes ; will take the line on the first ring
callerid=asreceived ; propagate the CID received from BT
context=indial-01736…
usecallerid=yes
group=2
channel => 3

signalling=fxs_ks
immediate=yes ; will take the line on the first ring
callerid=asreceived ; propagate the CID received from BT
context=indial-01736…
usecallerid=yes
txgain=2.5
rxgain=1
channel => 4
[/code]

system.conf

[code]fxoks=1
echocanceller=mg2,1
fxoks=2
echocanceller=mg2,2
fxsks=3
echocanceller=mg2,3
fxsks=4
echocanceller=mg2,4

Global data

loadzone = uk
defaultzone = uk[/code]

Is this what is required? Or are other config files needed?

4

G’day all,

Turns out the master socket was faulty.
I took it apart and found break in the ring wire which explains the sysntoms.

Polarity Reversal, dectect CID, wait for ring, time out because ring never arrives.
Of course modern phones work due to having a ring capacitor in the phone itself.
Could have saved a load of time if BT engineer had actually done some testing rather than just plugging his phone in.

The very useful fxstest was what helped me solve it.

5

The bell wire and ring capacitor are basically UK things. Most modern phones do not connect to the bell wire, because they are designed for the world market. The bell wire was intended to prevent tinkling on mechanical bells, especially with pulse dialing, when there was more than one phone on the line.

I would have expected the Openreach technician to use a test handset, not an ordinary phone.

6

Yes so would I, but he did not. He just plugged in a grubby looking plastic phone and said. My phone works yours does not, it must be you your phone and left.
Most unsatisfactory, saying that I had never seen him before and was not the ‘usual’ BT man I see around. So he has probably come in to soak up some of the work load or something.
I can see his logic about the phone though just that it was wrong in this case. Of course in most cases it would not be an issue since phones brought from argos would just work.
Now I need to wait and see if I get charged and if I do have a think about what I need to do.