[Home]

Summary:DAHLIN-00119: [patch] Click heard 6 seconds after answer on FXS ports.
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2009-06-18 04:12:12Date Closed:2009-08-08 18:43:25
Priority:MinorRegression?No
Status:Closed/CompleteComponents:wctdm
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) wctdm_prevent_ohttimer_click.diff2.txt
( 1) wctdm_prevent_ohttimer_click.diff3.txt
Description:Continuation of https://issues.asterisk.org/view.php?id=15311 which is specifically related AsteriskNOW 1.5

This is for SVN trunk.

If a call to a FXS port on a TDM400P is picked up while ringing (not silent period), after 6 seconds of the pickup a click is heard, and it's reported that sometimes this causes a hangup.



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

The cause is the states which the lasthook goes through

1). ringing lasthook = 4 (which is ringing)
2). ring quiet period lasthook = 2 (which is Forward On Hook Transfer) needed for FSk signalling
3). Off hook. lasthook = 2 (still Forward On Hook Transfer).
4). 6 seconds later CLICK. lasthook = 1 (which is Forward Active).

This patch corrects step 3.
.
.
3). Off hook. lasthook = 1 (Forward Active)
4). no click, as the port isn't in On Hook Transfer.


Comments:By: Alec Davis (alecdavis) 2009-06-18 06:00:26

Please remove wctdm_avoid_ohttimer_click.diff.txt it only covered an OnHook->OffHook during Ringing.

Further testing revealed that the click is also present just by lifting the handset repeatably, this is because every time the handset is put down the Message Waiting FSK is sent out, so the linefeed may be in OnHookTransfer when you pick it up.

uploaded wctdm_prevent_ohttimer_click.diff.txt
If an OnHook->OffHook transistion is detected during a Ring or OnHookTransfer, this patch sets the idletxhookstate to be 'Active', instead of OnHookTransfer.
By: Alec Davis (alecdavis) 2009-06-18 07:42:45

Please remove wctdm_prevent_ohttimer_click.diff.txt
Please change the reproducability to sometimes or always, I am experiencing this problem on multiple boxes.

Uploaded wctdm_prevent_ohttimer_click.diff2.txt
The reason for the click when just going OffHook and then OnHook. It was the OnHookTransfer Idle state should have been 'Active' but was left at OnHookTransfer.


By: Alec Davis (alecdavis) 2009-06-21 02:53:52

Seems harder with trunk to get to VMWI FSK OnHookTransfer to happen to hear the click, just by going OffHook to OnHook.

Previously it was sent on every OnHook, and the click is easily heard, now it only OnHookTransfer MWI updates only happens if the extension's messages changes from 'some' to 'none' or the other way around.

So this needs to verified as a fix on an older system, which of course will be correct in trunk.

Ready for testing.
Please report back so we can get this simple patch committed.
By: Alec Davis (alecdavis) 2009-07-04 03:14:41

Once patch from bug ASTERISK-14355 is applied, the click can be heard by going OnHook->OffHook
By: Alec Davis (alecdavis) 2009-07-14 05:30:24

dbailey: Doug, I believe this is in your field.
By: Vladimir Mikhelson (vmikhelson) 2009-07-30 22:52:15

Alec,

Tested the patch on TDM400P using DAHDI 2.2 branch code.

DAHDI Version: SVN-branch-2.2-r6864M

All worked as expected after the patch was applied. Initially experienced the same disconnect as with DAHDI 2.1.0.4, the timing was different, 9 sec. vs. 8 sec.

Thank you,
Vladimir

PS Do you happen to know if the patch to reverse polarity to normal exists for DAHDI 2.2? I am still using "options wctdm reversepolarity=1" you suggested in the very beginnig.


By: Alec Davis (alecdavis) 2009-07-31 00:04:30

Good news.

Vladimir:
ignore reversepolarity=1 it was only an idea for you to test, before I actually had tested the problem myself. I guess you missed https://issues.asterisk.org/view.php?id=15311#106453
By: Vladimir Mikhelson (vmikhelson) 2009-07-31 00:29:38

Alec,

It is a different issue as you stated in 15311/106521.

I have just retested to make sure.

1. Polarity was reversed on all FXS lines if the "reversepolarity=1" was commented out, checked by a Telephone Line Tester GTT-200;
2. After reversepolarity=1 switch was re-applied polarity became normal.

Behavior is different in DAHDI 2.2 in the following way. If "reversepolarity=1" is specified polarity is normal upon startup whereas in 2.1.0.4 it was necessary to trigger it by placing a call. See my note 15311/106525.

Thank you,
Vladimir
By: Doug Bailey (dbailey) 2009-07-31 13:48:29

I will need to modify the wctdm24xxp driver for the same behaviour.
By: Doug Bailey (dbailey) 2009-08-03 15:24:18

wctdm_prevent_ohttimer_click.diff3.txt includes the changes for wctdm24xxp that Alec Davis had done for the wctdm.c.  In addition, the magic numbers for values that are written to the slic's linefeed register have been changed to manifest constants.  

I tested both units out with dahdi_monitor recordings of FSK spills with no discernible problems.
By: Vladimir Mikhelson (vmikhelson) 2009-08-03 15:34:51

Doug,

"Wget patch" for ...diff3 is missing.

-Vladimir
By: Alec Davis (alecdavis) 2009-08-03 16:31:02

Doug:
With these changes, now a 'broad shoulders' (or other approriate term) question.

Does the 3 second 'ohtimer' in the IRQ now need to be there?

I see no harm in leaving the LF control in OHT (On Hook Transfer) mode.
The only concern I had was DTMF reception, but that is now done in the DSP code in Asterisk not onboard the Proslic, As the 3215 doesn't have it DTMF detection anymore.. the 3210 did.

We do need to consider if call waiting CallerId is enable and sent, then the  line needs to be in OHT mode, so after ringing leave it in OHT mode. If we take this stance, this fix is obsolete (but tidies up code) and we only need to remove the OHTTIMER code.
By: Doug Bailey (dbailey) 2009-08-03 16:49:38

Looking through the SLIC data sheet, OHT does require more power than nominal on-hook by a factor of 1.4:1 so taking it out of OHT mode does have some benefits.  
I am not sure if this is substantial enough reason for doing this.  Let me ask teh question and see what kind of response I get.
By: Alec Davis (alecdavis) 2009-08-03 17:05:13

Sure while OnHook try to save power, and go out of OHT mode.
But while OffHook while talking, stay in OHT mode.
By: Alec Davis (alecdavis) 2009-08-03 17:37:13

Patch for 2.1.0.4 for TDM400P, is at https://issues.asterisk.org/file_download.php?file_id=23002&type=bug

When OHTTIMER expires (6 seconds after ringing);
  if OffHook this patch avoids the switch to ActiveMode.
  if OnHoook will back switch to ActiveMmode.

Thus, saving power while OnHook, but no clicks while OffHook.
By: Doug Bailey (dbailey) 2009-08-04 16:37:03

Alec,

I'm not sure what you are looking for in addition to what the last patch
included.  Could you give me more of an idea as to what you would like to see?

I don't think we can get rid of the OHT timer as we need a means of getting out
of OHT mode if the transfer data is sent but there is no hook event to clear the
OHT mode.  (Though it certainly would be nice to get it out of the ISR.)

I can agree that we do not change the state of the Linefeed register while we
are off-hook.  I'm not sure what benefit we see when we put the linefeed
register back into OHT mode when we go back on-hook.  (Or am I missing
something?)

If we could always set the state back to Active when going on-hook, we could
then get rid of idletxhookstate.  I think doing so would make the code easier to
follow.

Doug
By: Alec Davis (alecdavis) 2009-08-04 16:47:12

Doug,
I'm happy with it what has been done, it's working for all of us, so ready to go.

Re OHTTIMER suggestions, these are for another day.
By: Alec Davis (alecdavis) 2009-08-04 16:52:35

Doug
Did you try ringing into an FXO port, and abort the call before answering.
Notice that the extensions keep ringing - forever, unless you have a Dial Timeout.

This is not related to this bug fix, but I'm trying to get some attention to it.
By: Digium Subversion (svnbot) 2009-08-05 09:41:03

Repository: dahdi
Revision: 6941

U   linux/trunk/drivers/dahdi/proslic.h
U   linux/trunk/drivers/dahdi/wctdm.c
U   linux/trunk/drivers/dahdi/wctdm24xxp/base.c

------------------------------------------------------------------------
r6941 | dbailey | 2009-08-05 09:41:03 -0500 (Wed, 05 Aug 2009) | 14 lines

Change proslic linefeed register setting

Insure that proslic linefeed register is not transitioned from Active to
On-Hook Transmission while the channel is off-hook.
Replaced magic numbers assigned to linefeed associated variables with more
descriptive constants.

(issue DAHLIN-119)
Reported by: alecdavis
Patches:
     wctdm_prevent_ohttimer_click.diff3.txt uploaded by dbailey (license 819)
Tested by: alecdavis, dbailey, vmikhelson


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

http://svn.digium.com/view/dahdi?view=rev&revision=6941
By: Doug Bailey (dbailey) 2009-08-05 11:13:05

Alec,

I was able to reproduce the following on the wctdm and wctdm24xxp drivers.

Here is my scenario

My fxo line is configured so that it waits 4 seconds, answers, then loops through a playback.
I have two FXS lines in which FXS2 is looped back the FXO line.

I have fxs1 (dahdi/9) call fxs2 (dahdi/10) which connects to the fxo (dahdi/1).
Before the call is answered by the fxo (i.e. it is executing wait), I hangup fxs1 which hangs up both fxs1 and fxs2
The fxo diaplan continues to execute with a simple switch thread started on fxs2

   -- Starting simple switch on 'DAHDI/9-1'
   -- Executing [7770@default:1] NoOp("DAHDI/9-1", ""Call dahdi10"") in new stack
   -- Executing [7770@default:2] Dial("DAHDI/9-1", "dahdi/10") in new stack
   -- Called 10
   -- DAHDI/10-1 is ringing
   -- DAHDI/10-1 is ringing
   -- Starting simple switch on 'DAHDI/1-1'
   -- Executing [s@dougfxo:1] NoOp("DAHDI/1-1", ""Doug's test context"") in new stack
   -- Executing [s@dougfxo:2] Wait("DAHDI/1-1", "4") in new stack
   -- Hanging up on 'DAHDI/10-1'
   -- Hungup 'DAHDI/10-1'
 == Spawn extension (default, 7770, 2) exited non-zero on 'DAHDI/9-1'
   -- Hanging up on 'DAHDI/9-1'
   -- Hungup 'DAHDI/9-1'
   -- Starting simple switch on 'DAHDI/9-1'
   -- Executing [s@dougfxo:3] Answer("DAHDI/1-1", "") in new stack
   -- Executing [s@dougfxo:4] Playback("DAHDI/1-1", "tt-weasels") in new stack
   -- <DAHDI/1-1> Playing 'tt-weasels.gsm' (language 'en')
   -- Starting simple switch on 'DAHDI/10-1'
   -- Hanging up on 'DAHDI/9-1'
   -- Hungup 'DAHDI/9-1'
   -- Executing [s@dougfxo:5] Wait("DAHDI/1-1", "10") in new stack
   -- Executing [s@dougfxo:6] Goto("DAHDI/1-1", "looper") in new stack
   -- Goto (dougfxo,s,4)

Is this the scenario you are talking about?
By: Alec Davis (alecdavis) 2009-08-05 13:24:23

The ringing forever only occurs if the FXO wasn't answered.

In your case, your answering it 4 seconds after it starts ringing, causing the caller to be charged but no-one is home.

I'll only bridge the call when an FXS is answered.

My FXO is port 5 which starts in context 'incoming'

[incoming]
exten => s,1,Dial(DAHDI/2&DAHDI/3&DAHDI/4)

This is working fine in SVN Branch 1.6.1, but TRUNK has introduced the problem.
By: Alec Davis (alecdavis) 2009-08-05 17:27:27

Doug or Leif:
Please don't forget karma, I need some ;)
By: Alec Davis (alecdavis) 2009-08-06 15:49:27

Doug:
Did you manage to get the ringforever to happen?
If not I'll try trunk again over the weekend, to see if I can reproduce.
By: Alec Davis (alecdavis) 2009-08-07 18:00:48

This current bug relating to 'the 6 second click' can be closed.

Doug:
The ringforever bug is caused by 'analog_p->ringt' timer is not being updated by dahdi_read like 'p->ringt' is.

The ringforever bug is covered in https://issues.asterisk.org/view.php?id=15288
By: Doug Bailey (dbailey) 2009-08-08 18:43:25

Fix added to trunk.