HowTos
- Dahdi/Zaptel Adjustable Chunk Size/Interrupt Frequency
- RTP TAP Call Recording Feature
- Asterisk Hardware DTMF
- Sample Zaptel Config Files ( /etc/zaptel.conf )
- Sample Zapata Config files ( /etc/asterisk/zapata.conf )
- HOTPLUG Conflicts with WANPIPE (Linux only)
- Exec "ztcfg" after wanrouter startover
- Updating FLASH on AFT Cards
- Multiple ZAPTEL Releases AND Wanpipe Crashing
- Multiple ZTCFG executions on bootup
- UDEV Conflicts with ZAPTEL
- A101/2/4/8 TE1 Clock Synchronization
- Cable Pin Outs
- Firmware Version
- Asterisk PRI Fails to Come Up or Oscillates up and down
- PRI got event: HDLC Bad FCS, D-Channels oscillates up and down
- Noise on A104D when running Voice & Data Channels
- Everything loads, but Asterisk does not see incoming call or off-hook state on analog cards.
- Installing Wanpipe on Suse
- Using PRI and T1/E1: Incoming calls work fine, but cannot dial out
- Cannot Load Zaptel module because crc_ccitt table not found
- Patlooptest
- Ouch ... error while writing audio data: : Broken pipe
- Compile Warning on 2.4 kernels: DEVFS HWEC not supported
- Failed to start echo canceller after improper shutdown
- Zaptel not compiling on Trixbox, RedHat and CentOs
- Is my hardware echo canceller running?
- Wanpipe crashes the system on Trixbox 1.2
- DTMF detection
- Script to get notified when your T1/E1 PRI lines are down by Paul Norris
- System load simulation using SIPp
- MFC/R2 Configuration
- Install wanpipe driver on AsteriskNOW or Asterisk Business Edition
- Woomera configuration using FreePBX
- Sample Configuration files for a J1 implementation
- Configuring A500 BRI as Timing source for Asterisk
- Creating a Binary recording of DTMF/ECHO Issues
- Debugging Asterisk/Wanpipe RBS
- WANPIPE® Echo Spike Generation
- Configuring NFAS
- Chunk size 80 with A108 under big load
- Asterisk Now 1.5 or Greater Installation Guide
- Activating loopback line mode
- Asterisk Logrotate Configuration
- How To Troubleshoot Overruns
- How To Enable DTMF CID (Caller ID)
Linux paths:
Wanpipe configuration directory: /etc/wanpipe
Wanpipe executable/script directory: /usr/sbin
Asterisk configuration directory: /etc/asterisk
Zaptel configuration file: /etc/zaptel.conf
FreeBSD paths:
Wanpipe configuration directory: /usr/local/etc/wanpipe
Wanpipe executable/script directory: /usr/local/sbin
Asterisk configuration directory: /usr/local/etc/asterisk
Zaptel configuration file /usr/local/etc/zaptel.conf
Sample Zaptel Config files ( zaptel.conf )
For additional information, you can find the original zaptel.conf file here.
Your zaptel.conf and zapata.conf should match your wanpipe configurations. The syntax for the span definitions are as follows:
span=<span num>,<timing source>,
<line build out (LBO)>,<framing>,<coding>[,yellow]
Note: If you are using wanpipe-beta2-2.3.4 or later, you can automatically configure our hardware based on your zaptel.conf file. Please refer to: http://sangoma.editme.com/wanpipe-asterisk-configure#auto for additional information.
2 PRI T1 spans with B8ZS line decoding, ESF framing
(A101/2/3/4/4D Cards)
for example: 2 PRI telco lines in North America
---------cut here---------------------------
loadzone = us
defaultzone = us
#span definitions
span = 1,1,0,esf,b8zs
span = 2,2,0,esf,b8zs
#channel definitions
#span 1
bchan = 1-23
dchan = 24
#span 2
bchan = 25-47
dchan = 48
---------cut here---------------------------
2 RBS T1 spans with B8ZS line decoding, ESF framing
(A101/2/3/4/4D Cards)
for example: 2 E & M telco lines in North America
---------cut here---------------------------
loadzone = us
defaultzone = us
#span definitions
span = 1,1,0,esf,b8zs
span = 2,2,0,esf,b8zs
#channel definitions
#span 1
e&m = 1-24
#span 2
e&m = 25-48
---------cut here---------------------------
2 PRI E1 spans with HDB3 line decoding, CCS framing, CRC4
(A101/2/3/4/4D Cards)
for example: 2 PRI telco lines outside of North America
---------cut here---------------------------
loadzone = uk
defaultzone = uk
#span definitions
span = 1,1,0,ccs,hdb3,crc4,yellow
span = 2,2,0,ccs,hdb3,crc4
#channel definitions
#span 1
bchan = 1-15,17-31
dchan = 16
#span 2
bchan = 32-46,48-62
dchan = 47
---------cut here---------------------------
T1 span with FXS kewlstart signalling
(A101/2/3/4/4D Cards)
For example: connection to a channel bank
---------cut here---------------------------
loadzone = us
defaultzone = us
span = 1,1,0,esf,b8zs
fxsks = 1-24
---------cut here---------------------------
FXO/FXS signalling with analog card
(A20x Cards)
for example: using analog fxo/fxs card (A204 with 1 fxo + 1 fxs modules)
Note: FXO ports use FXS signalling and FXS ports use FXO signalling.
Note: Analog Cards will register 24 channels, even if less ports are used.
Note: No span definitions.
---------cut here---------------------------
loadzone = us
defaultzone = us
fxsks = 1-2
fxoks = 3-4
---------cut here---------------------------
Using a combination of Analog Cards and T1/E1 Cards
Analog Cards register 24 channels, even if less ports are used, so the first T1/E1 channel will start at 25.
Note: in this example, the analog card is loaded first, and therefore takes the first span.
Note: No span definitions for analog card.
---------cut here---------------------------
loadzone = us
defaultzone = us
# ports for analog card
fxsks = 1-2
fxoks = 3-4
#ports and span definitions for T1 card
#note: span number is 2
span = 2,1,0,esf,b8zs
bchan = 25-47
dchan = 48
---------cut here---------------------------
Top
Sample Zapata Config files ( zapata.conf )
For original zapata.conf, click here
Zapata.conf section with detailed explanation from voip-info.org, click here
Your zaptel.conf and zapata.conf should match your wanpipe configurations.
Note: If you are using Asterisk@Home/Trixbox, copy the following configurations to zapata_additional.conf and omit the [channels] because zapata_additional.conf is already in the [channels] section.
2 PRI T1 spans with B8ZS line decoding, ESF framing (A10x/A10xD Cards)
---------cut here---------------------------
[channels] ;omit this line if you are including these lines in zapata_additional.conf
context = from-pstn
switchtype = national
usecallerid = yes
callerid=asreceived
echocancel = yes
echocancelwhenbridged = yes
;add the is option if you are problems with DTMF detection
relaxdtmf = yes
rxgain = 0.0
txgain = 0.0
signalling = pri_cpe
group = 1
channel => 1-23, 25-47
---------cut here---------------------------
2 RBS T1 spans with B8ZS line decoding, ESF framing (A10x/A10xD Cards)
---------cut here---------------------------
[channels] ;omit this line if you are including these lines in zapata_additional.conf
context = from-pstn
switchtype = national
usecallerid = yes
callerid=asreceived
echocancel = yes
echocancelwhenbridged = yes
;add the is option if you are problems with DTMF detection
relaxdtmf = yes
rxgain = 0.0
txgain = 0.0
signalling = em
group = 1
channel => 1-48
---------cut here---------------------------
2 PRI E1 spans with HDB3 line decoding, CCS framing, CRC4 (A10x/A10xD Cards)
---------cut here---------------------------
[channels] ;omit this line if you are including these lines in zapata_additional.conf
context = default
switchtype = Euroisdn
usecallerid = yes
callerid=asreceived
echocancel = yes
echocancelwhenbridged = yes
;add the is option if you are problems with DTMF detection
relaxdtmf = yes
rxgain = 0.0
txgain = 0.0
signalling = pri_cpe
group =1
channel => 1-15,17-31
channel => 32-46,48-62
;Note: Customers in the UK connected to BT might require this parameter:
pridialplan=local
---------cut here---------------------------
T1 span with FXS kewlstart signalling
(A10x/A10xD Cards)
---------cut here---------------------------
[channels]
context = from-pstn
switchtype = national
usecallerid = yes
echocancel = yes
echocancelwhenbridged = yes
;add the is option if you are problems with DTMF detection
relaxdtmf = yes
rxgain = 0.0
txgain = 0.0
signalling = fxs_ks
group = 1
channel => 1-24
---------cut here---------------------------
FXO/FXS signalling with analog card
(A20x/A20xD Cards)
---------cut here---------------------------
[channels] ;omit this line if you are including these lines in zapata_additional.conf
context = from-pstn
switchtype = national
usecallerid = yes
callerid=asreceived
echocancel = yes
echocancelwhenbridged = yes
;add the is option if you are problems with DTMF detection
relaxdtmf = yes
rxgain = 0.0
txgain = 0.0
signalling = fxs_ks
group = 1
channel => 1-2
signalling = fxo_ks
group = 2
channel => 3-4
;Note: Customers in the UK may require these additional parameters for callerID.
cidsignalling=v23
cidstart=polarity
---------cut here---------------------------
Top
HOTPLUG Conflicts with WANPIPE (Linux only)
On systems that use HOTPLUG note that HOTPLUG can conflict with startup of TDMV drivers.
Important:
Hotplug issues only affect old A101 and A102 cards.
The Hotplug issues have been resolved for A101d/2d/4d/8d and analog cards.
Solution:
Insert wanpipe interface name into the hotplug interface list, and restart hotplug.
#>vi /etc/hotplug/net.agent (if you are using a redhat style distro)
#>vi /etc/sysconfig/network-scripts/net.hotplug (if you are using newer redhat style distro)
#>vi /etc/hotplug.d/net/50-ifup.hotplug (if you are running Suse)
Insert wanpipe interface name into the ignore list:
Look for:
add|register)
case $INTERFACE in
(dsl*|ppp*|....................|tun*|tap*|wifi*)
And add w* to the list
(dsl*|ppp*|....................|tun*|tap*|wifi*|w*)
Where w* relates to all wanpipe interfaces starting with letter "w".
On some systems, there is also a list of interfaces to be ignored when unregistering, and the w* interfaces must be added to this list also.
Look for:
remove|unregister)
case $INTERFACE in
(dsl*|ppp*|....................|tun*|tap*|wifi*)
and add w*
On some systems, you need to restart hotplug agent to apply changes:
/etc/init.d/hotplug restart
Top
Exec "ztcfg" after wanrouter start
The "ztcfg" tool must be executed before starting asterisk. WANPIPE's "wanrouter" script has the capability to execute an external script after "wanrouter start" command is competed.
The wanrouter looks to /etc/wanpipe/scripts directory for any configured bash scripts.
1) Create a file called "start" (lower case)
#>vi start
----------Cut Here----------------
#!/bin/sh
#Make sure that udev/devfs zaptel device
#has come up.
cnt=0
max_delay=30
for ((i=0;i<$max_delay;i++))
do
if [ -e /dev/zap ]; then
break;
fi
echo "Waiting for zaptel device /dev/zap ($i/$max_delay)..."
sleep 2
done
if [ ! -e /dev/zap ]; then
echo
echo "Error: Zaptel device failed to come up";
echo "Possible Cause: UDEV not installed!";
echo
exit 1
fi
sleep 1
ztcfg -vvvv
exit 0
----------Cut Here----------------
2) Copy the file "start" into /etc/wanpipe/scripts directory (Note: the file doesn't have to have exec privileges) .
The script "start" will execute each time the "wanrouter start" command executes.
Please Refer to README.external_scripts for more info about wanrouter and external scripts.
Top
Updating FLASH on AFT Cards
Please check here for instructions on flash update.
Top
Multiple ZAPTEL Releases AND Wanpipe Crashing
On systems, where ZAPTEL has been upgraded from old releases, it is possible for a kernel module directory to contain MULTIPLE ZAPTEL drivers.
Old Zaptel install dir: /lib/modules/$(uname -r)/zaptel
New Zaptel install dir: /lib/modules/$(uname -r)/misc
If the old zaptel installation was NOT removed, the new installation would NOT overwrite the old kernel modules. In this case the OLD modules would continue to be loaded, even though the new ones were installed.
Check:
The check if this condition exists on your machine run:
#>modprobe -l | grep zaptel.*o
IMPORTANT: If multiple zaptel modules are found, the problem must be fixed before starting WANPIPE!
In this scenario, if a customer starts WANPIPE drivers based on NEW ZAPTEL sources, the WANPIPE will crash. The WANPIPE driver shares structures with ZAPTEL, thus, a result of mismatched structures is a kernel panic.
Solution:
The solution in this case is to REMOVE the old zaptel modules.
#>modprobe -l | grep zaptel | xargs rm
#>depmod -a
Top
Multiple ZTCFG executions on bootup
On systems that have zaptel and digium drivers installed, one must be careful to synchronize wanpipe, digium and zaptel ztcfg on boot up.
Therefore, wanpipe and digium MUST start before ztcfg is executed.
Check your /etc/rcS.d startup scripts. Make sure that the startup numbers S## for zaptel are higher than those of wanpipe and digium.
Top
UDEV Conflicts with ZAPTEL
UDEV is a user space daemon, which handles all /dev devices. On startup ZAPTEL schedules creation of /dev/zap device. It takes about 10 seconds for the UDEV daemon to create /dev/zap and all its devices after zaptel has been started (wanrouter start).
On shutdown, ZAPTEL schedules deletion of /dev/zap device. Again it takes about 1-5 seconds for UDEV daemon to delete /dev/zap device from user space.
A conflict can occur if one quickly starts and then stops wanpipe/zaptel . In this case UDEV daemon might be in process of creating /dev/zap devices, while zaptel kernel driver tries to remove them.
To prevent this please install the wanpipe external start script referenced in ITEM #2 of the APPENDIX above. This script will delay wanpipe start until UDEV has created the /dev/zap devices.
On some systems, UDEV has to be configured to configure zap channels, please read README.udev from the zaptel source directory (/usr/src/zaptel) for instructions on how to do this.
Top
A101/2/4/8 TE1 Clock Synchronization:
TE1 Clock synchronization is used to propagate a single clock source over the T1/E1 ports on a single card.
Before configuring your system you must identify which ports should be in NORMAL (slave) clock mode and which should be in MASTER clock mode.
All ports connected to TELCO MUST be in NORMAL mode, because Telco is ALWAYS MASTER clock (unless telco tells you otherwise).
Network Example:
wanpipe1->Port 1 connected to TELCO
wanpipe2->Port 2 connected to channel bank or back to back to another T1/E1 device.
In this scenario Port2 must be configured as CLOCK MASTER.
Settings for wanpipe1, Port 1:
Port 1 must be configured for NORMAL (slave) clock mode, because TELCO is always clock MASTER.
Using wancfg, configure port1 as clock slave with TE_CLOCK=NORMAL
So that port1 receives its clock from the TELCO.
All ports connected to TELCO MUST be in NORMAL mode, because Telco is ALWAYS MASTER clock!
(unless telco tells you otherwise).
Settings for wanpipe2, Port 2:
Port 2 must be configured for MASTER clock mode, in order to drive the channel bank or back to back T1/E1 device. However, in order to synchronize the port2 to port1 we use the TE_REF_CLOCK option to take the clock from port1 and pass it through to port2. By synchronizing port 1 and port2 together with a single clock that is derived from TELCO, we will be guaranteed that FAX and VOICE calls work perfectly without any interrupt or frame slips.
Using wancfg, configure as master with
TE_CLOCK=MASTER #configure port as MASTER clock
TE_REF_CLOCK=1 #use the incoming clock from port1 as the MASTER clock
The TE_REF_CLOCK parameter refers to the source of the MASTER clock for this port.
The TE_REF_CLOCK value can be set to any port that is ALREADY configured/started!
Note: Setting TE_REF_CLOCK=0 sets the MASTER clock source as the on-board oscillator.
IMPORTANT:
- When starting and stopping wanpipe devices make sure that the wanpipe T1/E1 port that provides the synchronized clock source is started first and stopped last. This is normally done automatically by the wanrouter startup script.
- If wanpipe T1/E1 port that provides the synchronized clock source is stopped, the other devices using the clock source will behave unpredictably.
- If the wanpipe T1/E1 port looses connection to the TELCO, it will automatically switch to its internal oscillator. In this case all slave ports will still be synchronized.
- If there is no clock coming from Telco (Port 1 in example), then the port using the referenced clock (Port 2 in example) will start using the internal oscillator. If your port 1 clock is unstable, this can cause noise and cracklings on the line as the clock source is being switched continuously between the referenced port and the internal oscillator.
Firmware Version
To find the current firmware version for your AFT card,
Drivers beta7-2.3.4 and higher
#>wanrouter hwprobe
The hardware probe output will display the card info as well as version number.
Drivers pre beta7-2.3.4
#>wanrouter start
#>wanpipemon -g
<local system debugging>
<select a wanpipe interface>
<Card status>
<Read Code Version<
it should say:
Code version : HDLC rev.XX
where XX is the current firmware version of the card.
Instruction for firmware update: Firmware update instructions
Top
Asterisk PRI Fails to Come UP or Oscillates Up and Down
PRI does not come up on the span, or it comes up and goes down again cyclically.
Running “pri intense debug spanX”, in Asterisk CLI, shows a sequence where only incoming frames are the "Unnumbered Frames".
< [ 02 01 7f ]
< Unnumbered frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< M3: 3 P/F: 1 M2: 3 11: 3 [ SABMEhere (set asynchronous balanced mode extended) ]
< 0 bytes of data
-- Got SABME from network peer.
Sending Unnumbered Acknowledgement
Also when running wanpipemon DCHAN Trace
#>wanpipemon –i w1g1 -c trd
Notice that all the data is INCOMING, there are no OUTGOING packets.
The problem is that zaptel driver has not been recompiled after Wanpipe installation. During Wanpipe installation, zaptel sources were patched with Wanpipe HW DCHAN patch, that enables zaptel to transmit HDLC frames to Wanpipe drivers. If zaptel driver is not re-compiled and re-installed HW DCHAN option will not work properly.
To fix this problem:
Recompile and Reinstall Zaptel Sources
#>cd /usr/src/zaptel
#>make clean
#>make
#>make install
OR
Disable TDMV_DCHAN=16 or 24 option and set it to 0 in /etc/wanpipe/wanpipe1.conf file.
This will disable Wanpipe HW DCHAN option and DCHAN HDLC encoding/decoding will be done by zaptel HDLC engine.
Note: With wanpipe-3.2.2 and later (and wanpipe-3.3.x beta driver) doesn't require to zaptel patch with zaptel-1.4.x . Therefore there is no need to recompile zaptel. (In /etc/zaptel.conf d-channels are defined as 'hardhdlc' instead of 'dchan')
Asterisk displays this error: PRI got event: HDLC Bad FCS
This could be because you are using the wrong coding/framing mode in /etc/zaptel.conf. Try to change your coding and framing modes and see it if makes a difference.
Everything loads, but Asterisk does not see incoming call or off-hook state on analog cards.
This could be a hotplug issue, try to configure hotplug settings so that wanpipe interfaces are ignored. (See HOTPLUG fix).
Installing Wanpipe on SuSe (Only for the version before 10.1)
The wanpipe drivers assume the kernel source is located in /lib/modules/$(uname -r)/build. and in SuSe, this symbolic link points to the headers only. There is a symbolic link in /lib/modules/$(uname -r)/source that points to the kernel source.
To compile on SuSe:
1. Apply the current kernel configuration.
Copy .config file from headers to source
#>cp /lib/modules/$(uname -r)/build/.config /lib/modules/$(uname -r)/source/.config
Set the symbolic link in /lib/modules/$(uname -r)/build to point to the kernel source
#>cd /lib/modules/$(uname -r)
#>mv build build_old
Find the location of your source:
#>ls -al source
It will look like this: source -> /usr/src/linux-2.6.11.4-20a (adjust for your current kernel version)
Create a symbolic link toyour kernel source with name build
#>ln -s /usr/src/linux-2.6.11.4-20a build
Update current configurations from the .config file
#>cd build
#>make menuconfig
#>make prepare-all
2. Install Zaptel, Libpri and Asterisk. Click here
3. Install wanpipe drivers.
5. Configure Hotplug to ignore wanpipe interfaces. Click here .
6. Configure Asterisk. Click here .
Using PRI and T1/E1: Incoming calls work fine, but cannot dial out
On some PRI with E1
We saw that these two settings must be added in /etc/asterisk/zapata.confpridialplan=local
pridialplan: Sets an option required for some (rare) switches that require a dialplan parameter to be passed. This option is ignored by most PRI switches. It may be necessary on a few pieces of hardware. Valid options are: unknown, local, private, national, and international. This option can almost always be left unchanged from the default. Default: national.
priindication=inband
priindication: Tells how Asterisk should indicate Busy() and Congestion() to the switch/user. Default: inband. Accepted values are:
inband: Asterisk plays indication tones without answering; not available on all PRI/BRI subscription linesoutofband: Asterisk disconnects with busy/congestion information code so the switch will play the indication tones to the caller.
prilocaldialplan=unknown
You may also set the prilocaldialplan in the same way (as pridialplan) , but by prefixing the Caller*ID Number, rather than the dialled number. Please note that telcos which require this kind of additional manipulation of the TON/NPI are *rare*. Most telco PRIs will work fine simply by setting pridialplan to unknown or dynamic.
On some PRI with T1
We saw that some providers (CMC Telecom for example) checks for the caller's callerID so make sure your callerID is within the list of one of the DIDs or phone numbers provided by your Telco.
Cannot Load Zaptel module because crc_ccitt table not found
This is because you are missing the crc_ccitt library routine.
Go to /lib/modules/$(uname -r)/build
type:
#>make menuconfig
In the ncurses utility,
Go to Library routines
Include:
<M> CRC-CCITT functions
<save> and <exit>
to build modules, type:
make modules
This will rebuild all your modules, including crc-ccitt. After you are done, the crc-ccitt module will be located in ./lib
copy the crc-ccitt.ko (for 2.6 kernels) or crc-ccitt.o (for 2.4 kernels)to /lib/modules/$(uname -r)/kernel/lib/
Ouch ... error while writing audio data: : Broken pipe
This error can be caused by misconfigured asterisk config file.
For example check that all comments are properly comented out in /etc/asterisk/zapata.conf.
Top
Compile Warning on 2.4 kernels: DEVFS HWEC not supported
This is just a warning.
Your 2.4 kernel doesn't have DEVFS support and our Hardware Echo Cancellatoin on A104d needs DEVFS on 2.4 kernels in order to configure HWEC Chip.
Please enable DEVFS support on your kernel in order to use Hardware EC support.
Otherwise, you will be forced to use software echo cancellation.
The use of DEVFS on 2.4 kernels and UDEV on 2.6 kernels was added in wanpipe-beta2-2.3.4 release.
Failure to start echo canceller after improper shutdown
If you are using wanpipe-beta4-2.3.4 drivers and you get an error loading wanpipe with hardware echo cancelling, this is probably because you have invalid wan_ec_socket and wan_ec.pid files in /var/run. Delete these 2 files and try to restart wanpipe.
note: if you are using wanpipe-beta2-3.4. and wanpipe-beta3-2.3.4 drivers, these files will be in /etc/wanpipe/wan_ec
Zaptel not compiling on some RedHat, CentOs and Trixbox systems.
If you are getting these errors when compiling zaptel:
/usr/src/zaptel/zaptel.c:384: error: syntax error before "zone_lock"
/usr/src/zaptel/zaptel.c:384: warning: type defaults to `int' in declaration of `zone_lock'
/usr/src/zaptel/zaptel.c:384: error: incompatible types in initialization
/usr/src/zaptel/zaptel.c:384: error: initializer element is not constant
:
:
There is a typo in your kernel headers.
View a file called spinlock.h in your kernel source directory:
#>vi /lib/modules/$(uname -r)/build/include/linux/spinlock.h
look for this line:
#define DEFINE_RWLOCK(x) rw_lock_t x = RW_LOCK_UNLOCK
(it is around line 407)
and change it to:
#define DEFINE_RWLOCK(x) rwlock_t x = RW_LOCK_UNLOCK
then try to recompile Zaptel again.
Is my hardware echo canceller running?
How to confirm that your hardware echo canceller is running and active on your Zap calls.
1. Confirm that you have a hardware echo canceller:
After the Wanpipe drivers are installed, type:
#>wanrouter hwprobe
It should say:
1. AFT-AXX-SH : SLOT=X : BUS=X : IRQ=X CPU=A: PORT=X : HWEC= 32 : V=X
HWEC values should be:
A200d : 32
A101d : 32
A102d : 64
A104d : 128
A108d : 256
A500d : 64
If it says HWEC=0, and you ordered a "d" model card,
If you purchased this card from a reseller, contact your reseller.
If you purchased this card directly from Sangoma, contact Sangoma RMA department.
2. If you have a hardware echo canceller, confirm that:
1. You have a 2.3.4 / 3.2 series driver.
2. You have the parameter "TDMV_HWEC = YES" in your /etc/wanpipe/wanpipe*.conf
3. You have the parameter "echocancel=yes" in your /etc/asterisk/zapata.conf
3. After you start wanrouter start, type:
#> wan_ec_client wanpipe1 stats
If you do not see any output, contact Sangoma Tech Support and attach your system log file to the email (/var/log/messages).
You should see:
wanpipe1: Running Get stats command to Echo Canceller device... Done!
***** Echo Canceller Chip Get Stats wanpipe1 *****
wanpipe1: Number of channels currently open 32
:
:
This confirms that the WANPIPE drivers can communicate with the hardware echo canceller chip properly.
4. Make a call through Asterisk. While the call is active,
1. In the Asterisk CLI, type:
CLI> zap show channel N
where N is your active channel. It should say:
:
:
echocancel: 128 TAPS, currently ON
:
if it does not say "currently ON", check your /etc/asterisk/zapata.conf, if you are bridging TDM to TDM, and you want echo cancelling to be performed, then you should also have "echocancelwhenbridged=yes"
2. if it says "currently ON"
To check if hardware EC is enabled or not , use wanpipemon -i <interface name> -c ehw
For example:
#> wanpipemon -i w1g1 -c ehw
Sangoma HW echo canceller active on channel N
where N is your active channel.
With wanpipe-3.2.x and wanpipe-2.3.4-5 or later, we have persistent hardware EC means hardware EC is enabled all the times, there fore you should see following for all the voice channels
#> wanpipemon -i w1g1 -c ehw
Sangoma HW Echo Canceller is enabled for channel N ( N: is your channel number)
Wanpipe crashes the system on Trixbox 1.2
Wanpipe driver crashes the system on Trixbox 1.2 if you compiled new Zaptel modules, but your older Zaptel module are still loaded in the kernel. To replace your existing Zaptel module:
1. Unload the Zaptel module from the kernel.
#> rmmod zaptel
Note: Sometimes the zaptel module is used by other modules (wctdm, wct4xxp etc....), you will need to unload those modules before unloading zaptel.
2. Remove current Zaptel module
modprobe -l | grep zaptel | xargs rm
depmod -a
3. Change directory to Zaptel source and run
make
make install
4. Reconfirm that new zaptel module is there
modprobe -l | grep Zaptel
5. Install Wanpipe driver
DTMF detection can be solved in the following ways:
1. Enable relaxdtmf=yes in zapata.conf. Relaxing them may make the DTMF detector more likely to have "talkoff" where DTMF is detected when it shouldn't be.
2. Increase rxgain in zapata.conf as well
3. If the above two steps don't help at all and you have hardware echo canceller enable on Sangoma cards(A102d/A104d/A108d), please try to disable it by setting TDMV_HWEC=NO in wanpipe#.conf
4. If disabling HWEC solves the problem, this means hardware echo canceller may corrupt DTMF data. You need to reenable HWEC and continue the debugging in the following link: http://wiki.sangoma.com/wanpipe-linux-asterisk-debugging#a104d_echo_debug
Installation of Sangoma Wanpipe driver on AsteriskNOW or Asterisk Business Edtion
1. Download the kernel source XXX (e.g 2.6.17.11) from kernel.org to /usr/src
You need to check your kernel version first(uname -r).
2. Make a symbolic link from /usr/src/linux-2.6.17.11 to /lib/modules/$(uname -r)/build
#> ln -s /usr/src/linux-2.6.17.11 /lib/modules/$(uname -r)/build
3. Go to /lib/modules/$(uname -r)/build, open Makefile and change the kernel
naming parameters such as VERSION, PATCHLEVEL,SUBLEVEL and EXTRAVERSION
to match the output of "uname -r"
For example:
uname -r ===> "2.6.17.11-1.smp.x86.i686.cmov"
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 17
EXTRAVERSION = .11-1.smp.x86.i686.cmov
4. Copy kernel configuration file from /boot to /lib/modules/$(uname -r)/build
#> cp /boot/config-2.6.17.11-1.smp.x86.i686.cmov /lib/modules/$(uname -r)/build/.config
5. Go to /lib/modules/$(uname -r)/build, run "make menuconfig", exit and save the config file
6. Install byacc and flex
a. untar yacc tar ball
b. run "make"
c. manually copy "yacc" to /usr/local/bin directory
#> cp yacc /usr/bin
d. untarflex tar ball
e. run "./configure"
f. run "make"
g. run "make install"
h. change directory to /usr/local/bin and make a symbolic link from flex to lex
#> ln -s flex lex
7. Install Zaptel from source
Download zaptel into arbitrary directory (/usr/src) and untar it.
#>tar xvfz zaptel(version)
Make a symbolic link /usr/src/zaptel to the actual zaptel directory.
#>ln -s zaptel(version) zaptel
#>make
#>make install
8. Install Wanpipe driver from source
Wanpipe TDM Installation
- Download the appropriate WANPIPE® Release based on the Sangoma Hardware. Refer to Wanpipe Drivers section.
- Untar wanpipe release in arbitrary directory (/usr/src/).
#>tar xvfz wanpipe(version)
After untarring WANPIPE®, the wanpipe/ directory will be created. - Run ./Setup install
Proceed with installation Select "Y" for each option.
Under compilation mode: Select "TDM Only drivers" (Option #2).
Setup will ask you for location of zaptel sources?
[By default Setup will look in /usr/src/zaptel]
Setup will ask you if you would like to add support for Sangoma HW HDLC DCHAN PRI to Zaptel.
"Enable TDMV DCHAN Native HDLC Support & Patch Zaptel ? (y/n)"
Select "Y" to Enable HW HDLC on DCHAN PRI in Zaptel.
Setup will ask you if you would like to recompile/reinstall Zaptel.
"Recompile/reinstall zaptel (recommended) ? (y/n) "
Select "Y" to recompile/reistall Zaptel
Proceed to compile wanpipe drivers. - Proceed with Defaults for the rest of the compilation.
If any errors are encountered during the compilation of the utilities, click here for assistance.
9. Once the driver are installed, use "wancfg" utility to manually configure the card.
10. Restart the computer and then go to your web interface and go ahead with your configuration.
Zaptel/Dahdi with Adjustable Chunk Size
By default Zaptel/Dahdi runs with 8 byte chunk size. This equates to 1ms interrupt on TDM hardware! This causes congestion on the PCI bus and overal creates a bottle neck.
Sangomas hardware is able to automatically detect Zaptel/Dahdi chunk size and adjust accordingly. One can configure Zaptel/Dahdi for 8bytes (1ms - default)- 16bytes (2ms) - 40byte (5ms) or 80byte (10ms) chunk size. This would drastically reduce number of interrutps on your system and allow you to scale better with large number of ports.
To configure Zaptel/Dahdi for higher chunk size
Zaptel ==> ./Setup install --zap-chunk=<CHUNK SIZE>
Dahdi ==> ./Setup install --dahdi-chunk=<CHUNK SIZE>
Where CHUNK SIZE: 8, 16 , 40 or 80
Setup will patch Zaptel/Dahdi source for selected chunk size and will remove wct4xxx (digium) driver out of zaptel Makefile. Reason for this is that digium wct4xxx driver does not support any chunk size other than 8bytes (1ms).
Once Setup recompiles Zaptel/Dahdi and wanpipe drivers. There are no other configuration needed! Just start wanpipe and Zaptel/Dahdi and Asterisk:
- wanrouter start
- ztcfg -vvv / dahdi_cfg -vvv
- asterisk
- asterisk -c -r
In order to confirm that you are running with new Zaptel/Dahdi chunk size. run:
- ifconfig w1g1
-> confirm that MTU = configured chunk size.
IMPORTANT:
This option has been tested in production and is SAFE for T1/E1 PRI Mode.
If running meetme chunk size of 40 is suggested.
Otherwise chunk size of 80 is most efficient..
Software echo cancelers are made for a chunk size of 8, so they may not function correctly.
This option does not work very well for ANALOG and T1/E1 E&M wink!
because zaptel hard codes the chunk size to 8 in some of the Analog/RBS
timing code. Sangoma is working on this problem.
If you are having trobule with this configuraiton please contact Sangoma Support.
Asterisk & Sangoma Hardware DTMF
Sangoma hardware DTMF is now supported starting from 3.3.0 wanpipe release. The Hardware DTMF is supported by the Octasic Hardware Echo/DTMF DSP. Therefore in order to take advantage of hardware DTMF you must have one of Sangomas AFT A200/A400,101/2/4/8 D cards (with onboard hardware echo cancelation)
Requirements:
- Download latest 3.3.X release or greater: Latest Drivers
- Install above wanpipe release:
-> follow standard wanpipe installation instructions - Configure wanpipe devices using wancfg_zaptel script.
-> run: /usr/sbin/wancfg_zaptel
-> follow standard wanpipe config instructions
-> select hardware dtmf option - Start wanpipe
-> wanrouter start - Configure zaptel
-> ztcfg - Start Asterisk
-> asterisk
Sample Configuration files for a J1 implementation
Configuring your Sangoma A10x card for J1 is qute simple but it does require making some manul changes:
- First use the "wancfg_zaptel" script to quickly create a base wanpipeX.conf, zaptel.conf, and zapata.conf files. For now select the T1 line media and take the default line configuration options (B8ZS and ESF). Select the type of clocking to use; NORMAL, and the card will take the clocking from the line (select this for a telco connection) and MASTER if the card needs to act like the telco and generate the clocking for the line. Next select either PRI_NET (telco/master side of a PRI connection) or PRI_CPE (slave side of a PRI connection). Lastly direct the call to the Asterisk context of your choice.
- Once the configuration script has created all the files, the wanpipeX.conf files need to be modified so the driver correctly encodes the line. Open the file "/etc/wanpipe/wanpipeX.conf", where X is the port number. Add the line "FE_SUBMEDIA=J1" as per the following sample wanpipeX.conf file:
#================================================
#WANPIPE1 Configuration File
#================================================
#
# Date: Wed Dec 6 20:29:03 UTC 2006
#
# Note: This file was generated automatically
# by /usr/local/sbin/setup-sangoma program.
#
# If you want to edit this file, it is
# recommended that you use wancfg program
# to do so.
#================================================
# Sangoma Technologies Inc.
#================================================
[devices]
wanpipe1 = WAN_AFT_TE1, Comment
[interfaces]
w1g1 = wanpipe1, , TDM_VOICE, Comment
[wanpipe1]
CARD_TYPE = AFT
S514CPU = A
CommPort = PRI
AUTO_PCISLOT = YES
PCISLOT = 2
PCIBUS = 7
FE_MEDIA = T1
FE_SUBMEDIA = J1
FE_LCODE = B8ZS
FE_FRAME = ESF
FE_LINE = 1
TE_CLOCK = NORMAL
TE_REF_CLOCK = 0
TE_HIGHIMPEDANCE = NO
LBO = 0DB
FE_TXTRISTATE = NO
MTU = 1500
UDPPORT = 9000
TTL = 255
IGNORE_FRONT_END = NO
TDMV_SPAN = 1
TDMV_DCHAN = 24
TDMV_HW_DTMF = NO
[w1g1]
ACTIVE_CH = ALL
TDMV_ECHO_OFF = NO
TDMV_HWEC = YES- Save the file and confirm that Wanpipe, Zaptel, and Asterisk start properly. If you have any problems please following the debugging instructions at the following link: PRI Debugging
# Autogenerated by /usr/local/sbin/sangoma/setup-sangoma -- do not hand edit
# Zaptel Channels Configurations (zaptel.conf)
#
loadzone=us
defaultzone=us
#Sangoma A102 port 1 [slot:2 bus:7 span:1] <wanpipe1>
span=1,0,0,esf,b8zs
bchan=1-23
hardhdlc=24
;autogenerated by /usr/local/sbin/config-zaptel do not hand edit
;Zaptel Channels Configurations (zapata.conf)
;
;For detailed zapata options, view /etc/asterisk/zapata.conf.orig
[trunkgroups]
[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no
;Sangoma A102 port 1 [slot:2 bus:7 span:1] <wanpipe1>
switchtype=national
context=from-pstn
group=0
signalling=pri_cpe
channel =>1-23
Configuring A500 BRI as Timing source for Asterisk
A500 BRI card can be used as Timing source for Asterisk , by adding following paramater in /etc/wanpipe/wanpipe1.conf .Note: This is the case when you have only A500 BRI card on the system.
Add TDMV_DUMMY_REF =YES inside [wanpipe1] section:
[trixbox1.localdomain ~]# cat /etc/wanpipe//wanpipe1.conf
#================================================
# WANPIPE1 Configuration File
#================================================
#
# Note: This file was generated automatically
# by /usr/local/sbin/setup-sangoma program.
#
# If you want to edit this file, it is
# recommended that you use wancfg program
# to do so.
#================================================
# Sangoma Technologies Inc.
#================================================
[devices]
wanpipe1 = WAN_AFT_ISDN_BRI, Comment
[interfaces]
w1g1 = wanpipe1, , TDM_VOICE_API, Comment
[wanpipe1]
CARD_TYPE = AFT
S514CPU = A
CommPort = PRI
AUTO_PCISLOT = NO
PCISLOT = 9
PCIBUS = 1
FE_MEDIA = BRI
FE_LINE = 1
TDMV_LAW = ALAW
TDMV_DUMMY_REF =YES
MTU = 1500
UDPPORT = 9000
TTL = 255
IGNORE_FRONT_END = NO
TDMV_SPAN = 1
[w1g1]
ACTIVE_CH = ALL
TDMV_ECHO_OFF = NO
TDMV_HWEC = YES
MTU = 80
Note:
Make sure zaptel is installed before and also make sure to choose "SMG(BRI)+Zaptel Support" during the installation of the driver.
Hardware echo canceler Fax/DTMF Debugging (AFT A101/2/3/8/Analog)
For Instructions for A500 BRI card (click here)
If you are experiencing ECHO or DTMF/Fax problems on your system using a card only when the hardware echo canceler is enabled, please follow the instructions below on how to capture an echo debug file.
The hardware echo canceler chip has a debug feature where a DEBUG Monitor will capture chip debug data during active calls. The captured debug binary file can be sent to Sangoma for further processing and analysis.
Before proceeding you should also confirm that Is my Hardware echo canceller running?
- Establish a call that has an echo problem noise or DTMF problem
- Determine the call channel number by running "show channels" on Asterisk CLI:
CLI> show channels - Run a echo canceler debug utility on that channel (15 sec recording)
#>wan_ec_client wanpipe1 monitor <channel number>
Where <channel number> is a channel number obtained in step 2.
The above command will record for 15 seconds and then stop.
The wan_ec_client will write a binary file in your local directory. - To record for 2 mintues run
#> wan_ec_client wanpipe1 monitor120 <channel number>
Where <channel number> is a channel number obtained in step 2.
The above command will record for 120 seconds and then stop.
The wan_ec_client will write a binary file in your local directory.
6. Send the binary file back to techdesk@sangoma.com
Hardware echo canceler Fax/DTMF Debugging for A500
- Determine which Wanpipe number and channel number the call is using with the aid of the following link:
HOW TO DETERMINE SPAN AND CHANNEL on A500 - Start the echo canceler monitoring tool by executing
#> wan_ec_client wanpipeX monitor Y
(where X is the wanpipe number and Y is the channel number found in step 1) from the Linux Command prompt. - Keep the call active for at least 1 minute (2 minutes is better) by having a normal conversation (the weather is always a fun topic). You should here echo on the local phone.
- Stop the monitoring tool and create a binary file of the audio by running the command
#> wan_ec_client wanpipeX monitor
(where X is the wanpipe number found in step 1). This will take a second or so. - The binary recording will be saved to the current working directory with the date and channel number in the title.
- Send the binary file back to techdesk@sangoma.com
To activate loopback line mode use the commands below. Now note that w1g1 is the interface as found in ifconfig or the /etc/wanpipe/wanpipe*.conf file. So to apply this command to different interfaces simply change the interface name.
Activate - wanpipemon -i w1g1 -c Taldlb
Deactivate - wanpipemon -i w1g1 -c Tdldlb

Debugging Asterisk/Wanpipe RBS
The wanpipemon utility provides the ability to debug RBS bits. The following command enables/disables WANPIPE RBS debugging and prints all debugging message into the /var/log/messages file. This feature is supported for all Sangoma digital AFT-series cards.
* To enable RBS debugging on reciever side (this command will print only changes to the RBS bit settings):
wanpipemon -i <interface name> -c derr
* To disable RBS debugging on reciever side:
wanpipemon -i <interface name> -c ddrr
* To enable RBS debugging on transmit side (this command will print only changes to the RBS bit settings):
wanpipemon -i <interface name> -c dert
* To disable RBS debugging on transmit side:
wanpipemon -i <interface name> -c ddrt
* Read the current RBS status bits from AFT-series cards:
wanpipemon -i <interface name> -c drr
* Read the current RBS status from the Wanpipe driver:
wanpipemon -i <interface name> -c dpr
In order to verify the RBS operations, you can run ./zttool utility and enable Sangoma RBS debugging at the same time. Zttoll shows what zaptel thinks is the RBS setting and the wanpipe utilities show what the sangoma driver thinks is the RBS setting. The two have to match at all times.
- In one window run: zttool
- In another window run: tail -f /var/log/messages
- Enable RBS debugging as stated above:
wanpipemon -i <interface name> -c derr #Enable rx rbs debugging
wanpipemon -i <interface name> -c dert #Enable tx rbs debugging - Place a call on Asterisk with reproducable bad behaviour
- Compare zttool output versus the /var/log/messages
If driver rbs changes are identical to zttool rbs changes problem is with the telco.
If driver rbs changes differ from zttool rbs changes there could be a problem with the drivers. - If zttool output doesnt match wanpipe rbs output please contact Sangoma Support.
NFAS or rather Non-Facilities Associated Signaling allows you to share a single D channel across multiple spans. The benefit of doing this allows you to use the other span's D channels as B channels, therefore you gain extra voice channels. If you use a signaling D channel for 4 spans then you will gain 3 voice channels.
1) Please see http://www.voip-info.org/wiki/view/NFAS for more information about configuring this feature.
2) For sample configuration files please download NFAS.zip.
NOTE: On a smaller installation with only 2 PRI's we have noticed you need to have the following in your zapata.conf, now note the change below is just the last digit in the spanmap starts at 0 instead of 1.
trunkgroup => 1,24,48
spanmap => 1,1,0
spanmap => 2,1,1
WANPIPE® Echo Spike Generation: Debugging (Linux)
When a system suffers from an intractable echo, it is often very difficult to diagnose the origins and possible solutions to the echo problem. WANPIPE® has a utility that allows the echo from a unit impulse to be examined and analyzed.
Important:
If you have Sangoma Card with Hardware echo canceller, the echo spike is not very important or useful.
In this case we suggest using hardware echo canceller tools to determine the echo problem:
Please read the Sangoma Hardware Echo canceler debugging howto .
To debug Echo problem during the phone call:
1. Install WANPIPE version beta1w-2.3.4 or later, use the following command when installing:
./Setup install --echo-debug
The Setup script will patch Zaptel driver, so it will have to be recompiled/reinstalled after WANPIPE installation is complete. Software Echo canceller should be enabled on the span, where the test will be done (or on all spans).
2. Make the phone call and check if there is echo.
Find a number that shows consistent echo for this test. The test should be done from the side where the echo is heard. Ideally, mute the phone on the remote side during the test. Note the Zap channel number on which the test call is done, for example channel 12. The rest of this document assumes the test call is active on Zap channel 12.
3. Run the following command:
#>wanpipemon -zap -c ses -zapchan 12
A test impulse is sent on zap channel 12. The Finite Impulse Response (FIR) is saved to the file: /etc/wanpipe/span_1_chan_12_before_ec.spike as a set of linear samples taken 8000 times per second.
4. Copy the data from /etc/wanpipe/span_1_chan_12_before_ec.spike into a spreadsheet.
Create a line chart of the data. The result should look similar to this picture:The graph shows the response to a unit impulse (FIR). Note that the start of the FIR is at 55 taps (7ms) after the impulse, and the echo was attenuated by 80 taps (10 ms). If the echo canceller had been configured for 128 taps, the echo would have been properly cancelled. If the Echo Canceller had been set to 64 taps, much of the echo would have survived the echo cancellation, and there would have been audible echo on this call.
If you are getting like a distorted noise on an A108 being under great load and you have a chunk size of 80, lowering the chunk size might help to eliminate the noise.
Nenad
Asterisk Logrotate Configuration
File:
/etc/logrotate.d/asterisk
---- cut-----
/var/log/asterisk/messages /var/log/asterisk/full /var/log/asterisk/*log {
missingok
rotate 30
daily
create 0640 root root
postrotate
/usr/sbin/asterisk -rx 'logger reload' > /dev/null 2> /dev/null
endscript
}
/var/log/asterisk/cdr-csv/*csv {
missingok
rotate 5
monthly
create 0640 root root
}
--cut-----
~
What Are Overruns?
Our cards generate an interrupt at a set interval and when the interrupt is handled the driver reads data from the card. So there can be a few factors which can cause the driver not to be able to read data from the card. The reasons this occurs is because of a clocking problem, ACPI needs to be disabled/enabled or DMA is not working correctly.
Do I Have Them?
It is important to note that to see if you have overruns just run "ifconfig" and there is a counter on each of our interfaces which shows how many overruns have occurred. Now when starting the driver or plugging in a line this can cause a few overruns. So it is important to determine if the overruns are increasing over time; so after the port has been connected for some time. So best idea is check twice with about 2 seconds delay between checks. Now overruns can also occur very slow; so in some extreme cases it may be necessary to check over a larger time such as 30minutes.
Trouble Shooting
Now once you have verified if you have overruns please follow the steps below to correct them.
1) Clocking
Only for E1/T1 cards
- To insure your clocking is setup correct please go to http://wiki.sangoma.com/Asterisk-FAQ#clocking and go through the per port configuration and the per card configuration sections. If you needed to make changes to your clocking then please do so and restart our driver and check for overruns. If the overruns occur even after clocking issues have been resolved then proceed to the next step.
Per Port
- In Master mode you don't know if the other side is providing a clock as well on the line. So example #3 at http://wiki.sangoma.com/Asterisk-FAQ#per_port can be occurring, so place the port into NORMAL clocking and see if the link connects. If it does then the other side is providing a clock, if not then MASTER mode is the correct mode to be in.
- In Normal mode if the link is in the "connected" state then this means the other side is providing a clock and this is the correct setup.
Per Card
- The DMA engine uses a single clock per card to pull data from the ports, so this is why having as single clock is very important as shown at http://wiki.sangoma.com/Asterisk-FAQ#per_card in the per card section. The different clocks will cause the DMA engine to be out of sync for some ports (ports with the second clock) and therefore cause overruns.
2) Checking DMA Engine
- Use the hdparm command to check your hard drive read speed as shown below; now the important thing here is the speed is over 40MB/sec. If the speed is below then this means you will need to upgrade your kernel with the latest chipset drivers. You can contact your motherboard manufacture for this information.
SATA
# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 240 MB in 3.01 seconds = 79.73 MB/sec
IDE
# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 240 MB in 3.01 seconds = 79.73 MB/sec
#hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on) Ensure this is set to "1 (on)"
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 80026361856, start = 0
3) Toggling ACPI
- On some systems ACPI needs to be disabled and others it needs to be enabled. So if all other steps above have not corrected the issue the last step is to toggle ACPI. Below is how to check if ACPI is enabled or disabled.
cat /proc/interrupts | grep -c acpi
- 0 - disabled
- 1 - enabled
- Now edit the /etc/grub.conf file and add "acpi=on" to enable acpi and "acpi=off to disable acpi. This line needs to be added to the end of the kernel line as shown below. Insure this option is toggled so if acpi was found to be enabled then insure you set "acpi=off" to disable it. Now once the grub.conf file is edited then the system will require a reboot to apply the change. Once it comes up just check if your overrun issue has been resolved. If not then please contact techdesk@sangoma.com.
title CentOS-4 i386 (2.6.9-34.0.2.ELsmp)
root (hd0,0)
kernel /vmlinuz-2.6.9-34.0.2.ELsmp ro root=LABEL=/1 acpi=on
initrd /initrd-2.6.9-34.0.2.ELsmp.img
How To Enable DTMF CID (Caller ID)
The average analog line uses what is called FSK caller ID. This sends the CID info via the FSK format. Now in some areas the CID info is sent through DTMF tones; these are the same tones you use to navigate an IVR.
Below is the steps to enable DTMF CID in Asterisk and Wanpipe.
- Add the line "RM_FAKE_POLARITY = YES" into /etc/wanpipe/wanpipe*.conf in the wanpipeX section.
- Add "cidsignalling=dtmf" and "cidstart=polarity" into /etc/asterisk/chan_dahdi.conf
- Or in some regions the following needs to be done, the difference is "polarity_IN" for details on this see http://www.voip-info.org/wiki/view/Asterisk+Documentation+1.6.1+India-CID.txt
- Add the line "RM_FAKE_POLARITY = YES" into /etc/wanpipe/wanpipe*.conf in the wanpipeX section.
- Add "cidsignalling=dtmf" and "cidstart=polarity_IN" into /etc/asterisk/chan_dahdi.conf
#> yum install lksctp-tools-devel
(sctp tools are very important otherwise openzap will not build properly)








