[Home]

Summary:DAHLIN-00058: TDM400P FXO when configured for alaw fails to dialout
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2008-11-09 19:44:14.000-0600Date Closed:2019-05-31 09:48:16
Priority:MajorRegression?No
Status:Closed/CompleteComponents:
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:In /etc/dahdi/system.conf selecting alaw=35 causes the FXO to fail dialout.

All that is heard is constant ~1000Hz square wave, this estimated.

Using mulaw=35 the line works fine.

This is not new, also happens on our production box which is Asterisk 1.6.0-rc6 with DAHDI-2.0.0-rc2

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

asterisk trunk version 155671
DAHDI Version: SVN-trunk-r5270

Channels 1-31 are TE110P
Channel 32 is TDM400P-FXS
Channel 35 is TDM400P-FX0
Comments:By: Alec Davis (alecdavis) 2008-11-13 02:52:35.000-0600

User configuration issue, but console indications of 'Default law: alaw' appears incorrect in the misconfigured senario.

file /etc/modprode.d/dahdi requires the following line
'options wctdm alawoverride=1'

Setting alaw=35 /etc/dahdi/system.conf then seemed to make no difference.

Both console outputs below indicate "Default law: alaw"

================================================
CONSOLE output below with correct working alaw configuration:
'options wctdm alawoverride=1' in /etc/modprode.d/dahdi
================================================

Asterisk*CLI> dahdi show channel 35
Channel: 35I>
File Descriptor: 47
Span: 2
Extension:
Dialing: no
Context: auckland-el
Caller ID:
Calling TON: 0
Caller ID name:
Mailbox: none
Destroy: 0
InAlarm: 0
Signalling Type: FXS Loopstart
Radio: 0
Owner: <None>
Real: <None>
Callwait: <None>
Threeway: <None>
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Busy Detection: no
TDD: no
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: alaw
Fax Handled: no
Pulse phone: no
DND: no
Echo Cancellation:
       128 taps
       currently OFF
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Onhook
Asterisk*CLI>

================================================
CONSOLE Output below with incorrect alaw configuration
'alaw=35' in /etc/dahdi/system.conf
'options wctdm alawoverride=1' missing /etc/modprode.d/dahdi
================================================

Asterisk*CLI> dahdi show channel 35
Channel: 35I>
File Descriptor: 47
Span: 2
Extension:
Dialing: no
Context: auckland-el
Caller ID:
Calling TON: 0
Caller ID name:
Mailbox: none
Destroy: 0
InAlarm: 0
Signalling Type: FXS Loopstart
Radio: 0
Owner: <None>
Real: <None>
Callwait: <None>
Threeway: <None>
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Busy Detection: no
TDD: no
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: alaw
Fax Handled: no
Pulse phone: no
DND: no
Echo Cancellation:
       128 taps
       currently OFF
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Onhook
Asterisk*CLI>
By: Leif Madsen (lmadsen) 2008-11-24 21:13:25.000-0600

I'm going to assign this issue to sruffell for now in the hopes he can take a look at it and determine what to do with this issue. Please reassign as you see fit. Unfortunately I don't exactly have a goto guy to assign these issues to, so sruffell got to be the lucky one this time :)
By: Mike Tucker (mtucker) 2008-11-28 07:20:47.000-0600

We have the same issue on both of our boxes.  Debian running 4.14.  Thanks for assist.
By: Mike Tucker (mtucker) 2009-01-09 06:59:46.000-0600

We are still working on this.  There definitely appears to be a problem at the card.  One point we noticed was that we need A-Law inside Asterisk but U-Law on the POTS line.  Is it possible that the card cant cross the codec types?  We note that the tone heard in reports above is actually dial tone at very high audio that cant be broken to dial.

Many folks need to cross A and U Law so an answer would be useful.  Thanks in advance.
By: Leif Madsen (lmadsen) 2009-01-09 07:10:38.000-0600

Has anyone called Digium support on this? If this is really a hardware issue, then that is really the most appropriate place for this, and not the bug tracker.
By: Alec Davis (alecdavis) 2009-01-09 12:56:12.000-0600

Digium support would have been able to assist, to get the system working, but the fact remains, this should still be in bug tracker.

A user shouldn't need to set a module parameter to get the hardware to use alaw, when there is a channel configuration parameter that can be set.

Even worse that misleads the user, 'dahdi show channel 35' shows 'Default law: alaw' when the module parameter 'alawoverride=1' has been missed, when infact it's 'ulaw'.
By: Alec Davis (alecdavis) 2009-01-09 13:01:48.000-0600

mtucker: I think this is your answer.
The file /etc/modprobe.d/dahdi should look similar to below;

# You should place any module parameters for your DAHDI modules here
# Example:
#
# options wctdm24xxp latency=6
options wctdm alawoverride=1 boostringer=1
By: Leif Madsen (lmadsen) 2009-01-09 13:07:12.000-0600

Thanks for the information. Digium support also has access to another bug system that would probably be better for hardware support issues, which is really what I meant, not that it shouldn't be this bug tracker; just that going through Digium support would probably get this closed out sooner.
By: Mike Tucker (mtucker) 2009-01-13 12:27:55.000-0600

Gone to Digium, awaiting advice.  Alecdavis, many thanks.  We will try this route when we have moved all our platforms to dahdi. In the meantime we will be patient.
By: Shaun Ruffell (sruffell) 2009-01-15 11:54:20.000-0600

As written, there is not currently a way at runtime for the wctdm24xxp driver to be notified when the DAHDI_SETLAW ioctl is called on the channel.  That ioctl is used to tell DAHDI how to control conversion to and from signed linear.  For digital cards, the board driver and framer do not actually perform any companding and therefore do not care about that information.

In the case of the analog cards, they do actually need that information as part of digital<->analog conversion.  So the board drivers would need some hook into the ioctl in order to have the option of changing the companding.  

But I agree that it would be helpful that even if the drivers are not changed to make the switch from ulaw to alaw in response to the ioctl, then maybe there is a way to report that not only do they have a default companding method (dahdi_span.deflaw) but that it is locked and can not be changed so that you do not get into a situation where your converting samples in ulaw to signed linear as if they were alaw.

As an aside, you can edit /etc/sysconfig/zaptel (or /etc/default/zaptel depending on your distribution) and add a module parameter for the alawoverride.  i.e.

wctdm24xxp_ARGS="alawoverride=1"


By: Alec Davis (alecdavis) 2009-06-13 03:45:48

With a TDM800P using Asterisk SVN-branch-1.6.1-r199300 and DAHDI SVN-trunk-r6675 on Debian Lenny in /etc/modprobe.d/dahdi had to add the following line;

options wctdm24xxp alawoverride=1

The symptom on the TDM800P FXS port is extremely loud dialtone, and will not recognise any dialling.

I'm kicking myself, I wasted about 2 hours trying to 're-find' this.
I'd tarred up /etc/dahdi and /etc/asterisk and moved to new box, forgot about /etc/modprobe.d/dahdi, copying it wouldn't have helped, different card but same problem, moved from TDM400P to TDM800P.

edit:
also found that enabling 'deflaw=35' with 'alaw=35' then 'dahdi show channel 35' is in sync with the module parameter alawoverride.
Remove alawoverride and 'dahdi show channel 35' .. shows "Default law: mulaw"
Enable alawoverride=1 and 'dahdi show channel 35' .. shows "Default law: alaw"

in /etc/dahdi/system.conf
alaw=35
deflaw=35


By: Shaun Ruffell (sruffell) 2012-03-11 14:27:09.774-0500

This came up again recently on the mailing list:
http://thread.gmane.org/gmane.comp.telephony.pbx.asterisk.user/267896