[Home]

Summary:ASTERISK-16078: [patch] FXS Polarity Reversal on Hangup or Answer
Reporter:armeniki (armeniki)Labels:
Date Opened:2010-05-11 06:12:18Date Closed:2011-06-07 14:00:23
Priority:MajorRegression?No
Status:Closed/CompleteComponents:
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug17318_debug_output.diff.txt
( 1) fxs_linepolarity.diff.txt
( 2) fxs_linepolarity.diff5.txt
Description:FXS lines normally connect to a telephone.  However, when FXS lines are routed to an external PBX or Key System to act as "external" or "CO" lines, it is extremely difficult, if not impossible for the external PBX to know when the call has been disconnected without receiving a polarity reversal on the line.

DAHDI/Asterisk should have a feature to allow a setting someplace, perhaps in chan_dahdi.conf, to allow a FXS channel to provide a polarity reversal on channel hangup.
Comments:By: Alec Davis (alecdavis) 2010-05-11 18:39:32

but also need to consider:
  reverse polarity on seizure.
  reverse polarity on answer.

The TDM400P already has the lowlevel ioctl to tell it to reverse line polarity, it already can do it for VMWI (check mwisendtype in chan_dahdi.conf).

edit:
What is the normal behaviour of a CO line that has 'Line Reversal' features enabled, when the called number is busy?


By: armeniki (armeniki) 2010-05-11 22:42:44

Hi Alec,

The behaviour of a CO line with Line Reversal, is as follows.  Note that the phone company offers this service in two different flavours, one is called ROA (reverse on answer) and the other is ROD (reverse on disconnect).  You can also choose to have both if you needed but that's extremely rare. It's basically a manner of what event causes the reversal.

In the case of this particular ticket, ROD (reverse on disconnect) would be the feature, as it's a type of disconnect supervision.

ROD works likes this:
1) Telephone is Onhook - polarity FWD
2) Telephone goes Offhook - polarity FWD
3) User dials number - polarity FWD
4) Call is answered - polarity FWD
5) Call is disconnected - polarity **REV**
6) Telephone goes back Onhook - polarity resets back to FWD

The important thing to note is that for any of these scenarios, the polarity never changes if the call is not completed (answered or hangup).  So if the number dialed is BUSY, etc. it will not change.

So for example, where we have SIP trunks going out and I'm using one of the FXS ports to call out on, the time for this reversal would occur when the far end disconnects, and the usual "Spawn extension exited non-zero on 'DAHDI/1-1'...." message appears on the Console followed by congestion tone.

Cheers,
Armen


By: armeniki (armeniki) 2010-06-16 21:36:48

Just an additional note - this is also causing a new problem on incoming calls that are transferred.

Example:  A call comes in from a customer, then they are transferred to another extension, they decide to hangup after waiting a while, but since there is no ROD, the system still rings the other extension until eternity thinking that someone is still there (although a reorder signal can be heard on the line when it's picked up).
By: Alec Davis (alecdavis) 2010-06-17 02:44:21

armeniki: I believe your note ~123513 is specifically related to the FXO port, and already supported.

If you have ROD support on your lines from your telco, in chan_dahdi.conf you need hanguponpolarityswitch=yes for the ports connected to the incoming lines.

Or in chan_dahdi.conf busycount=4 for the FXO ports.
By: David Woolley (davidw) 2010-06-17 06:03:09

Note ##121763 seems to be limited to phones for the North American market.  The UK PSTN uses a line reversal at the start of calling to phones with caller id presentation.
By: armeniki (armeniki) 2010-06-17 09:18:48

alecdavis: I'm afraid there's a misunderstanding someplace, as I am completely aware of that feature/functionality.

As described, this issue is happening on a FXS channel, there are no FXO channels involves in this situation.

Let me go through this again in more detail:

This is how the system is setup:

1) Linux box running Asterisk with a TDM400P and 4 *FXS* ports... not FXO.
2) Several SIP trunks are connected to this box via Ethernet for various lines in/out.
3) These FXS ports are then connected to the INPUT (or CO LINE CONNECTION) to a large PBX system.

4) Normally, telco lines would be going to this PBX which would provide ROD/ROI, however this is not the case as the Asterisk box is used to serve the PBX with trunks/lines.

5) Since these FXS lines are being used as incoming/outgoing lines to the PBX, they require to provide ROD/ROI so that the PBX knows when calls have been disconnected.

I hope this makes it clearer.  

If anyone has played with a Linksys PAP2 ATA, this feature is also included in that little box and is called either "reverse on hangup or reverse on connect".

davidw: We're in Australia and it has nothing to do with the phones, but the PBX which happens to be manufactured by Nortel and has its region set to Australia.

So, in conclusion, what needs to happen is that when a call is disconnected and the "Hangup" message appears in the Asterisk CLI - a reorder tone is played AND a temporary reversal of the line is made.

Cheers,
Armen
By: David Woolley (davidw) 2010-06-17 09:22:47

I'm expecting this to get closed as it is a feature request without a supporting patch, but if you do implement line reversals on FXS, you need to consider all the cases where they might be needed.
By: armeniki (armeniki) 2010-06-17 09:26:27

Hi Davidw - when you say closed does that mean resolved?  

At least for now, they can implement the reversal on "Hangup"... when I first encountered this problem I searched for a long time and all I found was issues relating to FXO ports, except for few people with my issue.

This will definitely help those of us who use Asterisk's SIP trunking capabilities with an existing PBX.  Cheers.
By: armeniki (armeniki) 2010-07-14 23:24:41

Any activity on this?
By: David Woolley (davidw) 2010-07-16 05:50:39

As I tried to suggest before, according to the submission rules for this bug tracker, this should be closed:

Status: closed
Resolution: won't fix

because it involves a request for a new feature, but no code to implement that request.  Although I don't believe it to be the case, there may be slightly different rules for Dahdi issues, but even then there will be no promises for when or if anything will be done, up to the point where someone starts actively working on it.
By: Alec Davis (alecdavis) 2010-07-20 05:26:05

armeniki: In DAHLIN-68 between dbailey and myself the basics for FXS line reversal per channel was implemented, which allowed for a VMWI indicator, This is implemented in the TDM400P and the TDM800P/24.

The intention was to later develop for other uses of line reversal.
The implementation your suggesting isn't too hard, just finding time and motivation.
By: Alec Davis (alecdavis) 2010-07-21 06:26:12

uploaded fxs_linepolarity.diff.txt

Work in progress:

Just forces a line reversal on FXS port when remote side answers, and again when hungup.

No configuration options yet.

Tested with TDM800P:
Outgoing calls line reversal worked fine, not so when the FXS port is being rung.


By: armeniki (armeniki) 2010-07-21 06:39:25

Hi Alec,

Good on you mate, I'm glad to see you're taking the initiative on this, it's really much appreciated.

Please let me know if you want me to test anything out for you.

Cheers,
Armen
By: Alec Davis (alecdavis) 2010-07-22 04:27:09

uploaded fxs_linepolarity.diff5.txt

In chan_dahdi.conf, uses the same keywords as for the FXO modules.

answeronpolarityswitch=yes
hanguponpolarityswitch=yes


By: Alec Davis (alecdavis) 2010-07-22 06:14:19

armeniki: Other than the verbose debug statements prefixed with ALEC, this works for me.

Please test and feedback.

Tested inbound and outbound, with various combinations of the XXXXXXonpolarityswitch keywords.
By: Alec Davis (alecdavis) 2010-07-22 07:07:13

reviewboard link: https://reviewboard.asterisk.org/r/797/
By: Alec Davis (alecdavis) 2010-07-22 14:48:29

Doug, as promised a few months ago, finally got it done.
Possibly too late for 1.8 branch.


By: Alec Davis (alecdavis) 2010-07-22 18:02:47

Changed Description to reflect additional functionality
By: Digium Subversion (svnbot) 2010-07-22 18:14:49

Repository: asterisk
Revision: 278809

U   trunk/channels/chan_dahdi.c
U   trunk/channels/sig_analog.c
U   trunk/channels/sig_analog.h
U   trunk/configs/chan_dahdi.conf.sample

------------------------------------------------------------------------
r278809 | alecdavis | 2010-07-22 18:14:49 -0500 (Thu, 22 Jul 2010) | 20 lines

Support FXS module Polarity Reversal on remote party Answer and Hangup

FXS lines normally connect to a telephone. However, when FXS lines are routed
to an external PBX or Key System to act as "external" or "CO" lines, it is
extremely difficult, if not impossible for the external PBX to know when
the call has been disconnected without receiving a polarity reversal on the line.

Now using answeronpolarityswitch and hanguponpolarityswitch keywords that
previously were used only for FXO ports, now applies like functionality for
an FXS port, but from the connected equipment's point of view.

(closes issue ASTERISK-16078)
Reported by: armeniki
Patches:
     fxs_linepolarity.diff5.txt uploaded by alecdavis (license 585)
Tested by: alecdavis

Review: https://reviewboard.asterisk.org/r/797/


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=278809
By: Alec Davis (alecdavis) 2010-07-23 05:36:54

Additional note of implemented conditions:

with answeronpolarityswitch=yes and hanguponpolarityswitch=no
Incoming/Outgoing setup
on answer: Polarity reversed

Remote party hangups first
remote hangup: no change
local hangup: Polarity normal

Local party hangups first
local hangup: Polarity normal

with answeronpolarityswitch=no and hanguponpolarityswitch=yes
Incoming/Outgoing setup
on answer: no change

Remote party hangups first
remote hangup: Polarity reversed
local hangup: Polarity normal

Local party hangups first
local hangup: Polarity normal

with answeronpolarityswitch=yes and hanguponpolarityswitch=yes
Incoming/Outgoing setup
on answer: Polarity reversed

Remote party hangups first
remote hangup: Polarity normal
local hangup: no change

Local party hangups first
remote hangup: Polarity normal
By: Digium Subversion (svnbot) 2010-07-23 06:01:13

Repository: asterisk
Revision: 278841

U   trunk/channels/chan_dahdi.c
U   trunk/channels/sig_analog.c

------------------------------------------------------------------------
r278841 | alecdavis | 2010-07-23 06:01:12 -0500 (Fri, 23 Jul 2010) | 5 lines

missed FXS kewl start polarityswitch when finally on hook.

(issue ASTERISK-16078)


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=278841
By: armeniki (armeniki) 2010-08-05 21:24:47

Hi guys,

There seems to be a bug someplace which appears out of nowhere after sometime...

I have the following settings in chan_dahdi.conf
answeronpolarityswitch=yes
hanguponpolarityswitch=yes

This results in polarity reversal on answer and then on hangup.

In the CLI the polarity reversals take place when the following DEBUG messages appear respectively:

DEBUG[13225]: sig_analog.c:1347 analog_answer: analog_answer 1
and
DEBUG[13225]: sig_analog.c:1161 analog_hangup: analog_hangup 1

The issue is that after some time (not sure if it's minutes, hours, or days) the polarity reversal on answers stops functioning.  

The DEBUG message appears still in the CLI but there is no reversal.

The funny thing is that the Hangup Reversal still works.

I have noticed that if I do a restart of the Asterisk service, everything works again but as I mentioned not sure for how long... or perhaps there's something else which triggers it to stop working.

Cheers,
Armen

By: Alec Davis (alecdavis) 2010-08-10 16:33:57

armeniki:
What TDM hardware is this being used with, The TDM800P/TDM2400P (wctdm24xxp driver) have an issue, fixed in DAHDI DAHLIN-204

The TDM400 (wctdm driver) based never failed me in testing.

Also, if you enable debugging for the TDM400 and TDM800 you should see the reversals being triggered.

edit: What signalling do you use for the FXS ports, Loop, Kewl etc?


By: Alec Davis (alecdavis) 2010-08-11 02:11:53

debug output with bug17318_debug_output.diff.txt patch applied.

channel 35 is an FXS port
channel 36 is an FXO port

asterix:/var/log/asterisk# tail -f full | grep pol
[Aug 11 19:20:43] DEBUG[27113] sig_analog.c: Ignore possible polarity reversal on line seizure
[Aug 11 19:20:47] DEBUG[27113] sig_analog.c: Answering on polarity switch! channel 36
[Aug 11 19:20:47] DEBUG[27113] sig_analog.c: Polarity Reversal event occured - DEBUG 2: channel 36, state 6, pol= 1, aonp= 1, honp= 1, pdelay= 600, tv= 0
[Aug 11 19:20:47] DEBUG[27113] sig_analog.c: analog_answer chan=35 pol(a=1 h=1)
[Aug 11 19:20:47] DEBUG[27113] chan_dahdi.c: my_answer_polarityswitch: Reversed channel 35
[Aug 11 19:21:12] DEBUG[27113] sig_analog.c: HangingUp on polarity switch! channel 36
[Aug 11 19:21:12] DEBUG[27113] sig_analog.c: Polarity Reversal event occured - DEBUG 2: channel 36, state 6, pol= 0, aonp= 1, honp= 1, pdelay= 600, tv= 24996
[Aug 11 19:21:12] DEBUG[27113] sig_analog.c: analog_hangup chan=36 pol(a=1 h=1)
[Aug 11 19:21:12] DEBUG[27113] sig_analog.c: analog_hangup chan=35 pol(a=1 h=1)
[Aug 11 19:21:12] DEBUG[27113] chan_dahdi.c: my_hangup_polarityswitch: Normal channel 35
[Aug 11 19:21:19] DEBUG[27084] chan_dahdi.c: my_start_polarityswitch: Normal channel 35


By: Alec Davis (alecdavis) 2010-08-11 15:00:40

armeniki:
What I forgot to say above, is to look for the consistant a=1 and h=1 in the analog_answer and analog_hangup.

If they are not both '=1' for you FXS port, you won't get a polarity reversal at each event.
a=1 on the FXS port indicates "Polarity will be reversed when remote party answers"
h=1 on the FXS port indicates "Polarity will be reversed when remote party hangs up"
By: armeniki (armeniki) 2010-08-11 22:40:54

Hi Alec,

I'll check this out and get back to you.

Cheers,
Armen
By: armeniki (armeniki) 2010-08-11 22:41:56

Oh sorry, I'm using loop start on TDM400P.
By: Alec Davis (alecdavis) 2010-08-12 00:14:08

Loop Start should be fine on a TDM400P

Apply the patch bug17318_debug_output.diff.txt and start monitoring /var/log/full.

note: /etc/asterisk/logger.conf requires
[logfiles]
.....
full => notice,warning,error,debug,verbose
By: Alec Davis (alecdavis) 2010-08-18 17:42:58

armeniki:
Are you still having the issue where the polarity switch on answer stops working after a period of time?

Did you get a chance to apply the patch that outputs additional debug.
By: armeniki (armeniki) 2010-08-18 19:30:26

Hi Alec,

I apologise but I haven't had a chance to do it yet.  I'm still have that issue (seems to happen almost always during the "answer" part and not the "hangup" part).  

I will test this out for you hopefully in the next few days and post results.

Cheers
By: armeniki (armeniki) 2010-08-21 02:38:29

Hi Alec,

I did the patch but got one error at the end.. not sure if this will change things:

patching file channels/chan_dahdi.c
Hunk #1 succeeded at 2753 (offset -5 lines).
Hunk #2 succeeded at 2766 (offset -5 lines).
Hunk #3 succeeded at 2779 (offset -5 lines).
patch: **** Can't rename file channels/chan_dahdi.c to channels/chan_dahdi.c.orig : Permission denied

Will recompile and post "full" soon...
By: Alec Davis (alecdavis) 2010-09-07 02:16:22

Additional Note: In a setup where an FXO port is connected to a Telco, and an inbound call to an IVR where a message may be taken.

In testing, we have found that our telco only reverses the line polarity on the outbound call's 'answer' and 'hangup' events, not an inbound call.
So when your called, and answer the call, you cannot rely on a polarity reversal if the remote party hangs up first, as is the case when a message is being taken by voicemail.

chan_dahdi.conf required on the Telco connected FXO port
busydetect=yes
busycount=4
busypattern=250,250
By: Alec Davis (alecdavis) 2010-09-07 02:20:20

armeniki: Still having any weird issues? Can I close this?
By: armeniki (armeniki) 2010-09-07 02:31:29

Hi Alec, please close. Thanks.
By: Alec Davis (alecdavis) 2010-09-07 03:41:38

armeniki:
Are we closing this as you have it working to your satisfaction, or is it due to no further interest?
By: Alec Davis (alecdavis) 2010-09-09 01:30:51

No apparent problem with implementation. Problem assumed to be elsewhere.