UK POTS - Hang up on answer of outbound call


I have a clean new build of Asterisk from source. I use 2 TDM400P cards. One contains fxs and the other fxo cards.

I am in the UK and have 4 BT pots lines. 1 of them is a normal stand alone line (???888) and works perfectly on any of the fxs ports. The other 3 all share a common number (???444) and receive incoming calls without a problem.

My problem is that recently, I have started having difficulty making outbound calls over the 444 lines. The line picks up and Asterisk dials, the called party answers and asterisk immediatelly shows the call as hung up, although the called party has not done so. At first this was happening on just one of the 3 combined lines, but now it is happening on all of the lines all of the time.

If I swap the 888 line into one of the ports used for a 444 line, it works perfectly.

I’m at a loss to know where to start debugging this, even with a very verbose console setting, asterisk doesnt report anything other than that the called party hung up.

The reason this is a clean new build is that I tried the same setup with both trixbox and *now packages. The behavior has been virtually identical.

Any suggestions of where to go now greatly appreciated.

Happy to post whatever logs and configs may be required, but haven’t so far as this is wordy enough already.


Turn on low leve channel tracing. It sounds like you have started getting answer supervision, when your configuration only expects disconnect supervision.

I’m not sure how to do any of that! I’ve tried putting this line

options wctdm opermode=UK debug=3

into /etc/modprobe.d/dahdi
but all I get in dmesg are these 4 lines:-
357791 Polarity reversed (1 -> -1)
RING on 1/1!
358927 Polarity reversed (-1 -> 1)
NO RING on 1/1!

which mean nothing much to me. I certainly don’t see how they relate to answer supervision.

However if I try with the 888 line that works correctly I get:-

NO BATTERY on 1/4!
BATTERY on 1/4 (-)!

After the call has been answered succesfully and then manually hung up.
Maybe that is significant?

Answer and disconnect supervision are normally sent using polarity reversals.

Without knowing the timing, I would suggest that the first reversal is so that the answer reversal leaves the line in normal polarity, and the second reversal is the actual answer.

Thanks for the prompt response David.

So are you saying that Asterisk may be seeing the initial reversal as a hangup? If so, why only on my shared number lines? and more importantly, what do I do about it. I’m sure you have gathered by now, this is all well beyond my level of knowledge.

What you do about it is to configure dahdi (or if you have an ancient system, zaptel) to match the supervision that you are actually receiving, or disable supervision entirely (in which case only Asterisk will be able to clear).

Alternatively, you ask BT to turn off supervision (which may have a similar effect to ignoring it).

Note that most PABX users want both answer and disconnect supervision turned on, as answer supervision makes internal call billing work better and disconnect supervision enables lines to be freed more quickly, especially if you are using automated responders.

I got the dahdi debugging to work properly and got this in my asterisk/full log

[Sep 28 16:50:42] VERBOSE[5183] logger.c: – Called 1/078???
[Sep 28 16:50:42] DEBUG[5183] chan_dahdi.c: Sent deferred digit string: T078???
[Sep 28 16:50:44] DEBUG[5183] chan_dahdi.c: Engaged echo training on channel 1
[Sep 28 16:50:47] DEBUG[5183] chan_dahdi.c: Echo cancellation already on
[Sep 28 16:50:47] VERBOSE[5183] logger.c: – DAHDI/1-1 answered SIP/21-0a433bc0
[Sep 28 16:50:57] DEBUG[5183] chan_dahdi.c: Polarity Reversal event occured - DEBUG 1: channel 1, state 6, pol= 1, aonp= 0, honp= 1, pdelay= 600, tv= 3500389
[Sep 28 16:50:57] DEBUG[5183] chan_dahdi.c: Polarity Reversal detected and now Hanging up on channel 1
[Sep 28 16:50:57] DEBUG[5183] chan_dahdi.c: Polarity Reversal event occured - DEBUG 2: channel 1, state 6, pol= 0, aonp= 0, honp= 1, pdelay= 600, tv= 3500389

So it is the polarity reversal that is causing the disconnect. How do I tell dahdi to ignore it - or handle it properly. I’ve tried looking through the dahdi docs, but can’t see the answer.

Is there some documentation for this sort of thing that a pleb like me can follow?

I don’t know what sort of pleb you are, but you are dealing with a technically complex system for which there are several options you need to understand and agree with your supplier. Unless you let the supplier do the configuration for you, you need to understand them.

From chan_dahdi.conf:

; Use a polarity reversal to mark when a outgoing call is answered by the ; remote party. ; ;answeronpolarityswitch=yes ; ; In some countries, a polarity reversal is used to signal the disconnect of a ; phone line. If the hanguponpolarityswitch option is selected, the call will ; be considered "hung up" on a polarity reversal. ; ;hanguponpolarityswitch=yes ;

You can probably search for typical UK configurations, or maybe Ian can give you the most likely settings, as he has systems which use dahdi with BT.

Thank you David, that was the clue I needed.

My chan_dahdi.conf was from a sample I found whilst trawling for UK configs. Consequently, I didn’t have that documentation from the original file. I’ve found it now in a template.

My installed one included the hanguponpolarityswitch=yes. After experimenting for a while, it seems that it works fine in the UK with a simple pots line, but BT signalling is different for a multiline PSTN and it was that switch which caused my problem. Also, I found that the ‘answeronpolarityswitch=yes’ works for the multiline, but broke the single pots line. So, my resolution was to comment out and ignore both.

Thanks once again for your input, this has been driving me nuts for weeks.