DAHLIN-00116: [patch] Call to a FXS DAHDI channel with Panasonic KX-TG4000 connected drops in 8 seconds randomly

[Home]

Summary: DAHLIN-00116: [patch] Call to a FXS DAHDI channel with Panasonic KX-TG4000 connected drops in 8 seconds randomly

Reporter: Vladimir Mikhelson (vmikhelson) Labels:

Date Opened: 2009-06-11 00:49:35 Date Closed: 2009-08-05 09:46:23

Priority: Major Regression? No

Status: Closed/Complete Components: dahdi (the module)

Versions: 2.1.0.4 Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) dahdi_wctdm_click.diff.txt
( 1) dahdi_wctdm_click.diff2.txt

Description: More often than not a call placed to a DAHDI channel with Panasonic KX-TG4000 connected would drop on its own in exactly 8 seconds after being answered. Before being disconnected two (2) clicks are being heard in succession. The second click kills the connection.

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

Configuration:
Asterisk: 1.6.0.9. DAHDI 2.1.0.4 Echo Canceler: MG2
AsteriskNOW 1.5 FreePBX 2.5.1.5

The portion of the debug log is below. HAHDI/7 is the Panasonic channel. The call was originated from the DAHDI/8 channel.

[Jun 4 01:13:56] DEBUG[1856]: dsp.c:497 tone_detect: tone 1100, Ew=90004.000000, Et=2304000.000000, s/n= 0.04
[Jun 4 01:13:56] DEBUG[1856]: dsp.c:497 tone_detect: tone 1100, Ew=172884.000000, Et=2519040.000000, s/n= 0.07
[Jun 4 01:13:56] DEBUG[1856]: dsp.c:497 tone_detect: tone 1100, Ew=91810.000000, Et=2693120.000000, s/n= 0.04
[Jun 4 01:13:56] DEBUG[1856]: dsp.c:497 tone_detect: tone 1100, Ew=45512.000000, Et=2795520.000000, s/n= 0.02
[Jun 4 01:13:56] DEBUG[1856]: chan_dahdi.c:5603 __dahdi_exception: Exception on 22, channel 7
[Jun 4 01:13:56] DEBUG[1856]: chan_dahdi.c:4703 dahdi_handle_event: Got event On hook(1) on channel 7 (index 0)
[Jun 4 01:13:56] DEBUG[1856]: chan_dahdi.c:2048 dahdi_disable_ec: Disabled echo cancellation on channel 7
<< [ HANGUP (NULL) ] [DAHDI/7-1]
[Jun 4 01:13:56] DEBUG[1856]: channel.c:4486 ast_generic_bridge: Didn't get a frame from channel: DAHDI/7-1
[Jun 4 01:13:56] DEBUG[1856]: chan_dahdi.c:6025 dahdi_indicate: Requested indication 20 on channel DAHDI/8-1
[Jun 4 01:13:56] DEBUG[1856]: channel.c:4878 ast_channel_bridge: Bridge stops bridging channels DAHDI/8-1 and DAHDI/7-1
[Jun 4 01:13:56] DEBUG[1856]: pbx.c:3092 pbx_extension_helper: Launching 'Macro'
-- Executing [h@macro-dial:1] Macro("DAHDI/8-1", "hangupcall") in new stack

Comments: By: Tzafrir Cohen (tzafrir) 2009-06-13 09:55:08

Does the problem go away if you change configuration of the channel from ks to ls?

Can you provide some more details of your configuration? (what device you use, configuration files involved, etc.)
By: Alec Davis (alecdavis) 2009-06-13 18:57:48

Which card, older TDM400P or the newer TDM800P/TDM2400 series?

I've noticed the TDM400P clicks after 6 seconds of call being answered.
TDM800P ot TDM2400 doesn't.

In other work I've done when I discovered this https://issues.asterisk.org/view.php?id=14261 I've a patch for the TDM400P if it's related try https://issues.asterisk.org/file_download.php?file_id=21559&type=bug

Alec
By: Vladimir Mikhelson (vmikhelson) 2009-06-13 23:17:16

In reply to tzafrir's note.

If the channel is configured to "ls" the problem goes away but the channel stays on indefinitely after an incoming call is hung up by a caller.

Device used:
Generic Wildcard TDM400p REV I
lspci identifies it as a "Communication controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN interface"

/etc/dahdi/system.conf
# Autogenerated by /usr/sbin/dahdi_genconf on Sat Nov 8 15:13:08 2008 -- do not hand edit
# Dahdi Configuration File
#
# This file is parsed by the Dahdi Configurator, dahdi_cfg
#
# Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
fxsks=1
echocanceller=mg2,1
fxsks=2
echocanceller=mg2,2
fxsks=3
echocanceller=mg2,3
# channel 4, WCTDM/0/3, no module.

# Span 2: WCTDM/4 "Wildcard TDM400P REV I Board 5"
fxoks=5
echocanceller=mg2,5
fxoks=6
echocanceller=mg2,6
fxoks=7
echocanceller=mg2,7
fxoks=8
echocanceller=mg2,8

# Global data

loadzone = us
defaultzone = us

/etc/asterisk/chan_dahdi.conf
;# Flash Operator Panel will parse this file for dahdi trunk buttons
;# AMPLABEL will be used for the display labels on the buttons

;# %c Dahdi Channel number
;# %n Line number
;# %N Line number, but restart counter
;# Example:
;# ;AMPLABEL:Channel %c - Button %n

;# For Dahdi/* buttons use the following
;# (where x=number of buttons to dislpay)
;# ;AMPWILDCARDLABEL(x):MyLabel

[channels]
language=en

; include dahdi-cahnnels.conf generated by dahdi_genconfig
#include dahdi-channels.conf

; include dahdi extensions defined in FreePBX
#include chan_dahdi_additional.conf
#include chan_dahdi_custom.conf

/etc/asterisk/dahdi-channels.conf
; Autogenerated by /usr/sbin/dahdi_genconf on Sat Nov 8 15:13:08 2008 -- do not hand edit
; Dahdi Channels Configurations (chan_dahdi.conf)
;
; This is not intended to be a complete chan_dahdi.conf. Rather, it is intended
; to be #include-d by /etc/asterisk/chan_dahdi.conf that will include the global settings
;

; Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
;;; line="1 WCTDM/0/0 FXSKS (In use) (EC: MG2)"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
faxdetect=incoming
channel => 1

;;; line="2 WCTDM/0/1 FXSKS (In use) (EC: MG2)"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
faxdetect=incoming
channel => 2

;;; line="3 WCTDM/0/2 FXSKS (In use) (EC: MG2)"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
faxdetect=incoming
channel => 3

; Span 2: WCTDM/4 "Wildcard TDM400P REV I Board 5"
;;; line="5 WCTDM/4/0 FXOKS (In use) (EC: MG2)"
signalling=fxo_ks
callerid="Channel 5" <4005>
mailbox=4005
group=5
context=from-internal
channel => 5

;;; line="6 WCTDM/4/1 FXOKS (In use) (EC: MG2)"
signalling=fxo_ks
callerid="Channel 6" <4006>
mailbox=4006
group=5
context=from-internal
channel => 6

;;; line="7 WCTDM/4/2 FXOKS (In use) (EC: MG2)"
signalling=fxo_ks
callerid="Channel 7" <4007>
mailbox=4007
group=5
context=from-internal
channel => 7

;;; line="8 WCTDM/4/3"
signalling=fxo_ks
callerid="Channel 8" <4008>
mailbox=4008
group=5
context=from-internal
channel => 8

/etc/asterisk/chan_dahdi_additional.conf
;--------------------------------------------------------------------------------;
; Do NOT edit this file as it is auto-generated by FreePBX. All modifications to ;
; this file must be done via the web gui. There are alternative files to make ;
; custom modifications, details at: http://freepbx.org/configuration_files ;
;--------------------------------------------------------------------------------;
;

;;;;;;[21]
signalling=fxo_ks
pickupgroup=
mailbox=21@default
immediate=no
echotraining=4000
echocancelwhenbridged=yes
echocancel=32
context=from-internal
callprogress=no
callgroup=
callerid=device <21>
busydetect=no
busycount=7
accountcode=
channel=>5

;;;;;;[22]
signalling=fxo_ks
pickupgroup=
mailbox=22@default
immediate=no
echotraining=4000
echocancelwhenbridged=yes
echocancel=32
context=from-internal
callprogress=no
callgroup=
callerid=device <22>
busydetect=no
busycount=7
accountcode=
channel=>6

;;;;;;[23]
signalling=fxo_ks
pickupgroup=
mailbox=23@device
immediate=no
echotraining=yes
echocancelwhenbridged=yes
echocancel=yes
context=from-internal
callprogress=no
callgroup=
callerid=device <23>
busydetect=no
busycount=7
accountcode=
channel=>7

;;;;;;[30]
signalling=fxo_ks
pickupgroup=
mailbox=30@default
immediate=no
echotraining=yes
echocancelwhenbridged=yes
echocancel=yes
context=from-internal
callprogress=no
callgroup=
callerid=device <30>
busydetect=no
busycount=7
accountcode=
channel=>8

/etc/asterisk/chan_dahdi_custom.conf
<empty>
By: Vladimir Mikhelson (vmikhelson) 2009-06-13 23:44:18

Alec,

It is an old generic TDM400P. I believe the 6 second click you noticed is in fact my click #1, then in 2 seconds it happens again and DAHDI interprets the sequence or whatever signaling is behind what we hear as clicks as a hangup request or something of that nature.

The version of DAHDI I use is 2.1.0.4, all modules are dated May 11, 2009, came through yum on AsteriskNOW 1.5/CentOS release 5.3 (Final). Do you think the patch you mentioned is included?

If you can provide me with another version of relevant binaries compatible with my installation I will gladly test them in relationship to the symptom discussed.

Thank you,
Vladimir
By: Alec Davis (alecdavis) 2009-06-14 05:23:45

Vladimir:

I believe this will fix the 'CLICK' for DAHDI 2.1.x
(untested as I don't have an AsteriskNOW box):

On Debian in /etc/modprobe.d/dahdi you need to add the following line
options wctdm reversepolarity=1

Summary:
I believe the key to fixing this is the 'reversepolarity=1' module option for the wctdm, how it's achieved in Centos I'm not sure.

Detail:
As I understand it, on the FXS module (Si3215), the line voltage is reversed while ringing, and when you answer the line, it stays reversed for 6 seconds (ohttimer), then is switched back to normal polarity, hence the click.

The workaround, operates the FXS line in reversepolarity, so ringing doesn't have to reverse it, thus after 6 seconds of it being answered it doesn't have to switch back to 'normal' polarity.

DAHDI trunk, also exhibits this problem with the TDM400P, the click is heard if the handset is picked up while the phone is ringing (not during the silent period).

By: Vladimir Mikhelson (vmikhelson) 2009-06-14 22:34:43

Alec,

Good news, modprobe.d is organized the same way in CentOS as in Debian. Bad news, the fix did not work. The "bad" behavior did not change a bit.

Here is what I did:

1. Modified /etc/modprobe.d/dahdi

# You should place any module parameters for your DAHDI modules here
# Example:
#
# options wctdm24xxp latency=6
options wctdm reversepolarity=1 boostringer=1

2. Unloaded Asterisk, modprobe -r wctdm, modprobe wctdm, dahdi_cfg, loaded Asterisk.

3. Tested. Observed no changes in behavior.

4. Shut down the server. Started. Observed the following in /var/log/messages:
Jun 14 21:34:08 localhost kernel: ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKD] -> G
SI 9 (level, low) -> IRQ 9
Jun 14 21:34:10 localhost kernel: Port 1: Installed -- AUTO FXO (FCC mode)
Jun 14 21:34:10 localhost kernel: Port 2: Installed -- AUTO FXO (FCC mode)
Jun 14 21:34:11 localhost kernel: Port 3: Installed -- AUTO FXO (FCC mode)
Jun 14 21:34:11 localhost kernel: Port 4: Not installed
Jun 14 21:34:11 localhost kernel: Found a Wildcard TDM: Wildcard TDM410P (4 modules)
Jun 14 21:34:11 localhost kernel: PCI: Enabling device 0000:00:0e.0 (0104 -> 0107)
Jun 14 21:34:11 localhost kernel: ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
Jun 14 21:34:11 localhost kernel: ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LNKB] -> G
SI 10 (level, low) -> IRQ 10
Jun 14 21:34:16 localhost kernel: Freshmaker version: 73
Jun 14 21:34:16 localhost kernel: Freshmaker passed register test
Jun 14 21:34:16 localhost kernel: Boosting ringer on slot 1 (89V peak)
Jun 14 21:34:16 localhost kernel: Module 0: Installed -- AUTO FXS/DPO
Jun 14 21:34:16 localhost kernel: Boosting ringer on slot 2 (89V peak)
Jun 14 21:34:16 localhost kernel: Module 1: Installed -- AUTO FXS/DPO
Jun 14 21:34:16 localhost kernel: Boosting ringer on slot 3 (89V peak)
Jun 14 21:34:16 localhost kernel: Module 2: Installed -- AUTO FXS/DPO
Jun 14 21:34:16 localhost kernel: Boosting ringer on slot 4 (89V peak)
Jun 14 21:34:16 localhost kernel: Module 3: Installed -- AUTO FXS/DPO
Jun 14 21:34:16 localhost kernel: Found a Wildcard TDM: Wildcard TDM400P REV I (4 modules
)
Jun 14 21:34:16 localhost kernel: dahdi_transcode: Loaded.
Jun 14 21:34:16 localhost kernel: dahdi_echocan_mg2: Registered echo canceler 'MG2'
Jun 14 21:34:16 localhost kernel: dahdi: Registered tone zone 0 (United States / North America)
Jun 14 21:34:16 localhost kernel: -- Setting echo registers:
Jun 14 21:34:16 localhost kernel: -- Set echo registers successfully
Jun 14 21:34:16 localhost kernel: -- Setting echo registers:
Jun 14 21:34:16 localhost kernel: -- Set echo registers successfully
Jun 14 21:34:16 localhost kernel: -- Setting echo registers:
Jun 14 21:34:16 localhost kernel: -- Set echo registers successfully

5. Tested. Observed no changes in behavior, i.e. the same 2 (two) clicks and line drop by Asterisk.

Observations:
1. The problem became better reproducible;
2. Polarity was initially reversed on all FXS lines, checked by a Telephone Line Tester GTT-200;
3. After reversepolarity=1 switch was applied polarity became normal.
4. Panasonic KX-TG4000 never exhibited the same problem while working with a PSTN line.
5. Replaced "ks" with "gs." Observed the same 8-second line hangup.

Thank you,
Vladimir

By: Tzafrir Cohen (tzafrir) 2009-06-15 01:14:41

vmikhelson, there are reports that the issue has been resolved in 2.2 . I'd like to first check that.

Can you copy wctdm from 2.2 to your tree? http://svn.digium.com/svn/dahdi/linux/trunk/drivers/dahdi/wctdm.c
By: Alec Davis (alecdavis) 2009-06-15 05:36:12

I'd need to install AsteriskNOW 1.5.0 to help any further.
Downloaded, but out of time here tonight in NZ.
By: Vladimir Mikhelson (vmikhelson) 2009-06-15 17:49:13

In reply to tzafrir's note.

I would need some instructions on how to compile the driver. Can I leave all over DAHDI modules from v2.1.0.4?
By: Vladimir Mikhelson (vmikhelson) 2009-06-15 17:52:23

Alec,

I am not sure that the problem we are working with is AsteriskNOW specific. Although it would be nice if you are on the same platform as I am.

Wasn't that strange to you that initially the polarity on FXS lines was reverted and "reversepolarity=1" returned it to normal?

Thank you,
Vladimir
By: Alec Davis (alecdavis) 2009-06-16 06:20:57

Uploaded dahdi_wctdm_click.diff.txt patch for DAHDI 2.1.0.4 in AsteriskNOW 1.5
This patch avoids the line reversal that happens on a TDM400P FXS port 6 seconds after call is answered.

Don't need /etc/modprobe.d/dahdi module option reversepolarity=1, sounds like it didn't work as expected, I didn't check.

What I had to do after a fresh install of AsteriskNOW 1.5.0

yum install kernel-devel
cd /usr/src
svn checkout http://svn.digium.com/svn/dahdi/linux/tags/2.1.0.4 dahdi-linux
cd dahdi-linux
wget "https://issues.asterisk.org/file_download.php?file_id=23002&type=bug"
patch -p0 < dahdi_wctdm_click.diff.txt
make
make install

shutdown -r now

Debug testing still in patch:
tail -f /var/log/messages
Jun 16 22:47:15 localhost kernel: wctdm: ohttimer expire avoided after OffHook
Jun 16 22:47:35 localhost kernel: wctdm: ohttimer expired while OnHook
Jun 16 22:47:47 localhost kernel: wctdm: ohttimer expire avoided after OffHook
Jun 16 22:48:04 localhost kernel: wctdm: ohttimer expired while OnHook

Previous to patch: fresh AsteriskNow 1.5.0 download, I can confirm that the clicks were present.
After the patch: No clicks are heard.

By: Vladimir Mikhelson (vmikhelson) 2009-06-16 11:13:01

Alec,

Thank you for posting the detailed procedure. I was able to follow it almost exactly with minor modifications. Please confirm my deviations.

1. The patch name was dahdi_wctdm_click.diff.txt
2. cd dahdi-linux/2.1.0.4 before wget

The "[^]" syntax was not familiar to me, but I still used it per your instructions. I have received the following warnings:

svn: [^] does not appear to be a URL
wget: http://[^]: Invalid IPv6 Numeric address.

The hangup problem seems to be resolved by your patch. I now hear the click immediately after the extension is dialed, but it does not cause any adverse effects.

Here are the relevant lines from the /var/log/messages.

On the first call after reboot:
Jun 16 10:57:50 localhost kernel: wctdm: ohttimer expired while OnHook
Jun 16 10:57:53 localhost last message repeated 3 times
Jun 16 10:58:10 localhost kernel: wctdm: ohttimer expire avoided after OffHook

On subsequent calls:
Jun 16 11:00:28 localhost kernel: wctdm: ohttimer expire avoided after OffHook

Sorry for the persistence, I still have the same question, "Wasn't that strange to you that initially the polarity on FXS lines was reverted and "reversepolarity=1" returned it to normal?"

Thank you for all your help.

-Vladimir
By: Alec Davis (alecdavis) 2009-06-16 16:24:07

oops, sorry about the patch filename error, I'll correct the instructions above.

Notice the "[^]" that is in you bug note, they don't appear when typing up the note, but after being submitted there they are.

regarding your question about polarity reversal.
Just after startup I saw the line was reversed, then after the first call the line had reverted to normal, I think it only happens when the module option "reversepolarity=1" is present.

Somewhere there is another patch for wctdm.c that I think would have fixed the reversepolarity issue, but I couldn't find it lastnight.

Oh for svn.digium.com/view to be working (Anyone listening).
By: Vladimir Mikhelson (vmikhelson) 2009-06-16 17:55:20

Alec,

Thank you for clarifications. I bet [^] has something to do with hyper-links.

You may want to change "cd dahdi-linux" to "cd dahdi-linux/2.1.0.4" in your instructions otherwise 'patch' command has trouble accessing sub-directories.

Now regarding the 'reversepolarity' issue. As I understand, it is a known issue and polarity on TDM400p FXS lines is normally reversed unless the 'reversepolarity=1' parameter is passed to wctdm at startup which sets it to normal. Is my understanding correct? This is what I observe with my hardware.

I also confirm that the first call is needed after reboot to reset the polarity back to normal. Return to normal only occurs if 'reversepolarity=1' parameter is passed to wctdm at startup, otherwise the polarity stays reverted all the time.

Should I keep the 'boostringer=1'?

Do you think your patch will be included in future versions of wctdm or will I need to re-compile all future versions of the module?

Thank you,
Vladimir

By: Alec Davis (alecdavis) 2009-06-16 19:44:56

I'll have to remove the printk's in it as this is an interrupt routine, I left them there for debug.

A variation for DAHDI 2.2 may make it (as mentioned in my first note above), but will only get commited if bugs marshals are made aware that it and more users report or comment on the problem.

If AsteriskNOW maintainers see this, they may be able to make an update package available...

Alec

By: Alec Davis (alecdavis) 2009-06-17 07:02:02

Uploaded dahdi_wctdm_click.diff2.txt for DAHDI 2.1.0.4 AsteriskNOW 1.5

This forces the idletxhookstate to FORWARD ACTIVE or REVERSE ACTIVE as soon as off hook is detect on an FXS port.

The initial patch dahdi_wctdm_click.diff.txt leaves the FXS module in 'On Hook Transmission' or 'Active' mode during the call, Depends on when OffHook happened. There maybe merit in this, as CallWaiting ID can be sent over the line, without any clicks, and perhaps not dropping the line.

The click isn't the change in line polarity as I initially thought.

The click that is heard at 6 seconds, is the OHT-TIMER (On Hook Transfer) timing out and changing from 'Forward/Reverse On-Hook Transmission' to 'Forward/Reverse Active'.

Repeatablity:
This click can be easily heard 6 seconds after the pickup of the called extension only if the pickup was while it's ringing, not during a silent period. That is where the randomness comes in.

I had to setup loadzone=US, as the ringcadence is long, I had trouble initally here in NZ as we have a ring-ring-pause cadence.

This patch, doesn't have any printk's, so no debug can be seen.
This patch is applies to an unpatched DAHDI 2.1.0.4

By: Tzafrir Cohen (tzafrir) 2009-06-17 07:21:22

alecdavis, I'm confused. Are still patches needed to trunk?
By: Alec Davis (alecdavis) 2009-06-17 07:30:58

Tzafrir: Yes, trunk needs the patches, but which method is better should perhaps be put up for debate.

The DAHDI 2.1.0.4 patches above for AsteriskNOW are tested.

Just uploaded for SVN trunk for the TDM400P (wctdm.c):
dadhi_wctdm_click.trunk.diff.txt
wctdm.c_ohttimer_click.diff.txt

dadhi_wctdm_click.trunk.diff.txt:
This forces the idletxhookstate to FORWARD ACTIVE or REVERSE ACTIVE as soon as ringing off hook is detected on an FXS port. Description as above.

wctdm.c_ohttimer_click.diff.txt:
This forces the ohttimer to be expired, thus ignoring the switch from 'On-Hook Transmission' to 'ACTIVE' if the FXS port is OffHook.

This trunk patch is untested, at this stage.
What may be broken, needs to be checked:
whether CallWaiting ID is still functional, as this is sent while OffHook.

By: Alec Davis (alecdavis) 2009-06-17 16:19:00

Please remove files below, I'll redo them with POLARITY_XOR macro.
dadhi_wctdm_click.trunk.diff.txt
wctdm.c_ohttimer_click.diff.txt

The patches that will remain are approriate for AsteriskNOW 1.5 users wishing to patch their systems.

I should also open new bug for DAHDI TRUNK, as I feel I have highjacked Vladimir's bug. Which I understand is working for him.

By: Alec Davis (alecdavis) 2009-06-18 18:43:32

For SVN Trunk opened new bug https://issues.asterisk.org/view.php?id=15352

Please remove files below:
dadhi_wctdm_click.trunk.diff.txt
wctdm.c_ohttimer_click.diff.txt
By: Vladimir Mikhelson (vmikhelson) 2009-06-18 23:50:03

Alec,

Tested diff2, works great. Thank you.

Should I keep the 'boostringer=1' you advised me to add to the wctdm options in /etc/modprobe.d/dahdi?

Thank you,
Vladimir
By: Alec Davis (alecdavis) 2009-06-19 03:35:27

Vladimir:
I just copied a line from our config, which had boostringer=1. If you didn't have it, then remove it.

It doesn't come into play with this bug.

Sorry to misguide you on that one.

Tzafrir:
If your around, can you remove the requested files, thanks.
By: Vladimir Mikhelson (vmikhelson) 2009-06-29 13:16:18

Alec,

Maybe my question is completely irrelevant, but let me ask.

Do you think that the wctdm patch, second edition, i.e. diff2, could introduce a problem with DTMF when a call comes in on a SIP trunk?

This is what I see. A call comes in from PSTN via SIP Broker, terminates on my AsteriskNOW via Gizmo5 SIP trunk, caller dials a Panasonic KX-TG4000 extension (so far so good, DTMF works fine that far), call gets connected to the Panasonic (patch works fine, the line does not drop in 8 seconds), caller tries to dial a Panasonic extension with no luck, DTMFs are not recognized at all.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2009-07-29 22:16:36

Hi,

It looks like it will take quite some time while the patch will be included in a DAHDI build.

In a mean time I need to manually overwrite the wctdm.ko every time I receive DAHDI update. Today it would not load after the kernel update so I needed to run make, make install. I did not update the DAHDI source since I am cautious not to get a version which the patch will not be applicable to. As a result I am forced not to apply any DAHDI updates.

Is it possible to apply the posted patch to the current DAHDI 2.1.0.4 source? Is there an easy way to compile just the specific module?

Thank you,
Vladimir
By: Alec Davis (alecdavis) 2009-07-29 22:32:15

Vladimir
It's normal to have to recompile DAHDI after a kernel update, and as you have found, DAHDI will not load.

Regarding inclusion of patch in source tree, I'll leave that for the bug marshals to consider.
By: Vladimir Mikhelson (vmikhelson) 2009-07-29 23:02:55

Alec,

Thank you for the prompt reply.

Can I apply your patch to the current svn of 2.1.0.4, i.e. can I use "svn checkout http://svn.digium.com/svn/dahdi/linux/tags/2.1.0.4 dahdi-linux" now and still be able to apply your patch created more than a month ago?

Thank you,
Vladimir

By: Alec Davis (alecdavis) 2009-07-29 23:22:43

yes. But 'tags' are not updated, they are a snapshot as the code was at the time.

I see DAHDI 2.2 now has a branch, which I presume will contain stable maintained code.

svn checkout http://svn.digium.com/svn/dahdi/linux/branches/2.2 dahdi-linux

Alec
By: Vladimir Mikhelson (vmikhelson) 2009-07-29 23:43:17

Alec,

Can you please explain the issue with "tags," what should be done with it?

Can your ...diff2.txt be applied to 2.2?

Vladimir

PS How do you suppress the [^] in your postings?
By: Alec Davis (alecdavis) 2009-07-30 03:36:00

As I understand it, you previously had done an svn checkout of the 2.1.0.4 tag release. Then applied my patch.

roughly:
'trunk' is the latest and greatest and perhaps buggy.
'branches' are feature frozen, with bus only being fixed.
'tags' are a snapshot of trunk, that has the features and bugs that truck had at the time.

google may give you a better explaination.

Re: How do I suppress [^]
they are the html markup tags that mantis supports, not documented any where
but within '<' and '/>' the following seem to be supported
'i' for italics
'b' for bold
'u' for underline
'pre' for <pre>preformatted text</pre>

I requested further info at https://issues.asterisk.org/view.php?id=15462

edit:
I didn't actually advise how I stop the hyperlink.
after the http: put a '/u' html tag

By: Vladimir Mikhelson (vmikhelson) 2009-07-30 09:58:57

Alec,

Thank you for the information. Unfortunately the original link you posted produced "Access Denied" message for me. Thank you for fixing that.

I will check out the current version of 2.1.0.4 and try to apply your patch.

My understanding is that another patch will be needed for 2.2. Is that correct?

Thank you,
Vladimir

By: Doug Bailey (dbailey) 2009-07-30 14:25:02

Is this only a 2.1.0.4 issue?

Looking in the trunk version of the wctdm_proslic_check_hook function, I do not see the setting of proslic register 64 as implemented in the patch here. If we do add it, it will need to take into account the line reversal MWI that was added in January.
By: Doug Bailey (dbailey) 2009-07-30 14:27:29

Pardon my ignorance, I see that issue 15352 is handling the issue for trunk.
By: Alec Davis (alecdavis) 2009-07-30 15:02:44

Vladimir:
Updated previous note with 'access denied' link.
By: Vladimir Mikhelson (vmikhelson) 2009-07-30 16:20:58

Alec,

Thank you for the update. I have updated my ASTERISK-1040177 to remove the unnecessary [^]. Your trick worked fine.

Back to the original issue. Do you think I should switch to 2.2? Is your fix incorporated in the current branch? Or should I better stick with 2.1.0.4?

Thank you,
Vladimir
By: Alec Davis (alecdavis) 2009-07-30 16:27:01

Vladimir:
DAHDI 2.2.0 patch is at https://issues.asterisk.org/view.php?id=15352

Doug:
The above DAHDI 2.2 patch is ready for testing.
It's been tested only so far by me with both a TDM400P and TDM800P, the TDM800P is being used every day.

Vladimir and I have tested this 2.1.0.4 patch on a TDM400P, I've also tested it with a TDM800P.
By: Vladimir Mikhelson (vmikhelson) 2009-07-30 16:37:45

Doug,

I have a positive daily experience with Alec's patch with TDM400P, DAHDI 2.1.0.4.

My configuration with Panasonic behind Asterisk is inoperable unless the patch has been applied.

Thank you,
Vladimir
By: Doug Bailey (dbailey) 2009-07-31 08:47:39

At this point, I would concentrate on 2.2 and trunk as that is where we are concetrating our development efforts. At present there are no plans for a new release of the 2.1.x branch of Dahdi
By: Doug Bailey (dbailey) 2009-08-05 09:46:21

This will be addressed in trunk via issue 15352.

There are no plans to update the 2.1.0.4 branch.