My asterisk plight.

My system :

There is no voip mixed in, asterisk is used to provide a menu for incomming calls regarding which member(s) of the household are to be contacted and to provide voicemail, as a side effect, it automatically blocks all telemarketers.
My system may or may not flush the toilet, control the furnace, and or operate a message waiting board at the front door, that is beyond the scope of this excersize.

Origionally my system ran asterisk-1.2.15 with zaptel-1.2.13. My gains were adjusted by ear as best I could come up with at the time. Today I started by straightened out the gains to achive 0db across

In a typical call, there are 4 gains in each direction of the audio path, the system uses native bridging on the t1 card to connect paths:

FXO card
[M04-01- channel 7]
T100P card
"FXO Side"
"FXS Side"
FXS card
[M01-02- channel 2]
Mic ->
TX gain 0db ->
RX gain 0db ->
TX gain 3db ->
RX gain -3db (device limit) ->
 -> Speaker
Speaker <-
RX gain 0db <-
TX gain 0db <-
RX gain 0db <-
TX gain 0db <-
 <- Mic

The nifty advantage here is that, because the system is analog, I can hook on a meter and see the actual signal strengths. (dbm)

My goals:

  1. Update to drivers with a working channel monitor (just can't find zaptools anymore)
  2. Confirm system passes audio without significant positive or negitive gain
  3. Confirm proper operation of asterisks milliwatt() signal
  4. Get a proper reading out of dahdi_monitor for a confirmed milliwatt signal.

My measurements (linux-2.6.15  asterisk-1.2.15  zaptel-1.2.13):

  - Standard phone hooked solely into pots line, 1mw signal from CO (604 958 2011):    -4.55dbm
This isn't bad, its just line loss, its to be expected, thats fine.

  - Channelbank hooked solely into pots line, 1mw signal from CO (604 958 2011):  -5.78dbm
This is a combination of the line loss and a screwy impedence on my channelbank that I'm quite aware of, this is a control number, so this is ok.

  - Gains as mentioned above.

  - Phone set, via channelbank to 1mw from CO:  -5.61dbm
So the system has a slight gain, this is ok, I'm not really worried about being out by even so much as +-1.5db

  - Phone set, via channelbank to 1mw from asterisk:  -00.14 dbm
Excellent! this is exactly one of the things that I wanted to know! however, as I didn't origionally install zaptools, I can't get a reading for the level.

OK, so with that I upgrade (rather painfully), The measurements to redo after this are the thruput gain to the CO 1mw, and the asterisk internal 1mw signal. Then I can watch the dahdi monitor and get a number for a true 1mw level.

 My measurements (linux-2.6.28  asterisk-  dahdi-linux-complete- ):

  - Channelbank hooked solely into pots line, 1mw signal from CO (604 958 2011):  -6.50 dbm

  - Phone set, via channelbank to 1mw from CO:  -6.14 dbm
Again, this isn't out by enough to concern me.

  - Phone set, via channelbank to 1mw from asterisk:  -11.5 dbm
!!!! NO! this shouldn't be  !!!!

  -  dahdi_monitor -vv shows the following for what its worth

Current Configs:



rxwink=300              ; Atlas seems to use long (250ms) winks


;First 6 channels are the FXS modular cards


;Next 2 channels are the FXO card

# Autogenerated by /usr/sbin/dahdi_genconf on Sat Jun 20 00:45:29 2009 -- do not hand edit
# Dahdi Configuration File
# This file is parsed by the Dahdi Configurator, dahdi_cfg
# Span 1: WCT1/0 "Digium Wildcard T100P T1/PRI Card 0" (MASTER) B8ZS/ESF YELLOWClockSource
# termtype: te


# Global data

loadzone        = us
defaultzone     = us

Old Configs:

# Zaptel Configuration File
# This file is parsed by the Zaptel Configurator, ztcfg
# First come the span definitions, in the format
# span=<span num>,<timing source>,<line build out (LBO)>,<framing>,<coding>[,yellow]
# All T1/E1 spans generate a clock signal on their transmit side. The
# <timing source> parameter determines whether the clock signal from the far
# end of the T1/E1 is used as the master source of clock timing. If it is, our
# own clock will synchronise to it. T1/E1's connected directly or indirectly to
# a PSTN provider (telco) should generally be the first choice to sync to. The
# PSTN will never be a slave to you. You must be a slave to it.
# Choose 1 to make the equipment at the far end of the E1/T1 link the preferred
# source of the master clock. Choose 2 to make it the second choice for the master
# clock, if the first choice port fails (the far end dies, a cable breaks, or
# whatever). Choose 3 to make a port the third choice, and so on. If you have, say,
# 2 ports connected to the PSTN, mark those as 1 and 2. The number used for each
# port should be different.
# If you choose 0, the port will never be used as a source of timing. This is
# appropriate when you know the far end should always be a slave to you. If the
# port is connected to a channel bank, for example, you should always be its
# master. Any number of ports can be marked as 0.
# Incorrect timing sync may cause clicks/noise in the audio, poor quality or failed
# faxes, unreliable modem operation, and is a general all round bad thing.
# The line build-out (or LBO) is an integer, from the following table:
# 0: 0 db (CSU) / 0-133 feet (DSX-1)
# 1: 133-266 feet (DSX-1)
# 2: 266-399 feet (DSX-1)
# 3: 399-533 feet (DSX-1)
# 4: 533-655 feet (DSX-1)
# 5: -7.5db (CSU)
# 6: -15db (CSU)
# 7: -22.5db (CSU)
# The framing is one of "d4" or "esf" for T1 or "cas" or "ccs" for E1
# Note: "d4" could be referred to as "sf" or "superframe"
# The coding is one of "ami" or "b8zs" for T1 or "ami" or "hdb3" for E1
# E1's may have the additional keyword "crc4" to enable CRC4 checking
# If the keyword "yellow" follows, yellow alarm is transmitted when no
# channels are open.


# Next come the dynamic span definitions, in the form:
# dynamic=<driver>,<address>,<numchans>,<timing>
# Where <driver> is the name of the driver (e.g. eth), <address> is the
# driver specific address (like a MAC for eth), <numchans> is the number
# of channels, and <timing> is a timing priority, like for a normal span.
# use "0" to not use this as a timing source, or prioritize them as
# primary, secondard, etc.  Note that you MUST have a REAL zaptel device
# if you are not using external timing.
# dynamic=eth,eth0/00:02:b3:35:43:9c,24,0

# Next come the definitions for using the channels.  The format is:
# <device>=<channel list>
# Valid devices are:
# "e&m"     : Channel(s) are signalled using E&M signalling (specific
#             implementation, such as Immediate, Wink, or Feature Group D
#             are handled by the userspace library).
# "fxsls"   : Channel(s) are signalled using FXS Loopstart protocol.
# "fxsgs"   : Channel(s) are signalled using FXS Groundstart protocol.
# "fxsks"   : Channel(s) are signalled using FXS Koolstart protocol.
# "fxols"   : Channel(s) are signalled using FXO Loopstart protocol.
# "fxogs"   : Channel(s) are signalled using FXO Groundstart protocol.
# "fxoks"   : Channel(s) are signalled using FXO Koolstart protocol.
# "sf"        : Channel(s) are signalled using in-band single freq tone.
#        Syntax as follows:
#         channel# => sf:<rxfreq>,<rxbw>,<rxflag>,<txfreq>,<txlevel>,<txflag>
#        rxfreq is rx tone freq in hz, rxbw is rx notch (and decode)
#        bandwith in hz (typically 10.0), rxflag is either 'normal' or
#        'inverted', txfreq is tx tone freq in hz, txlevel is tx tone
#        level in dbm, txflag is either 'normal' or 'inverted'. Set
#        rxfreq or txfreq to 0.0 if that tone is not desired.
# "unused"  : No signalling is performed, each channel in the list remains idle
# "clear"   : Channel(s) are bundled into a single span.  No conversion or
#             signalling is performed, and raw data is available on the master.
# "indclear": Like "clear" except all channels are treated individually and
#             are not bundled.  "bchan" is an alias for this.
# "rawhdlc" : The zaptel driver performs HDLC encoding and decoding on the
#             bundle, and the resulting data is communicated via the master
#             device.
# "fcshdlc" : The zapdel driver performs HDLC encoding and decoding on the
#             bundle and also performs incoming and outgoing FCS insertion
#             and verification.  "dchan" is an alias for this.
# "nethdlc" : The zaptel driver bundles the channels together into an
#             hdlc network device, which in turn can be configured with
#             sethdlc (available separately).
# "dacs"    : The zaptel driver cross connects the channels starting at
#             the channel number listed at the end, after a colon
# "dacsrbs" : The zaptel driver cross connects the channels starting at
#             the channel number listed at the end, after a colon and
#             also performs the DACSing of RBS bits
# The channel list is a comma-separated list of channels or ranges, for
# example:
#   1,3,5 (channels one, three, and five)
#   16-23, 29 (channels 16 through 23, as well as channel 29
# So, some complete examples are:
#   e&m=1-12
#   nethdlc=13-24
#   fxsls=25,26,27,28
#   fxols=29-32





# Finally, you can preload some tone zones, to prevent them from getting
# overwritten by other users (if you allow non-root users to open /dev/zap/*
# interfaces anyway.  Also this means they won't have to be loaded at runtime.
# The format is "loadzone=<zone>" where the zone is a two letter country code.
# You may also specify a default zone with "defaultzone=<zone>" where zone
# is a two letter country code.
# An up-to-date list of the zones can be found in the file zaptel/zonedata.c
loadzone = us
#loadzone = us-old
# Section for PCI Radio Interface
# (see
# The PCI Radio Interface card interfaces up to 4 two-way radios (either
# a base/mobile radio or repeater system) to Zaptel channels. The driver
# may work either independent of an application, or with it, through
# the driver;s ioctl() interface. This file gives you access to specify
# load-time parameters for Radio channels, so that the driver may run
# by itself, and just act like a generic Zaptel radio interface.
# Unlike the rest of this file, you specify a block of parameters, and
# then the channel(s) to which they apply. CTCSS is specified as a frequency
# in tenths of hertz, for example 131.8 HZ is specified as 1318. DCS
# for receive is specified as the code directly, for example 223. DCS for
# transmit is specified as D and then the code, for example D223.
# The hardware supports a "community" CTCSS decoder system that has
# arbitrary transmit CTCSS or DCS codes associated with them, unlike
# traditional "community" systems that encode the same tone they decode.
# this example is a single tone DCS transmit and receive
# # specify the transmit tone (in DCS mode this stays constant)
# tx=D371
# # specify the receive DCS code
# dcsrx=223
# this example is a "community" CTCSS (if you only want a single tone, then
# only specify 1 in the ctcss list)
# # specify the default transmit tone (when not receiving)
# tx=1000
# # Specify the receive freq, the tag (use 0 if none), and the transmit code.
# # The tag may be used by applications to determine classification of tones.
# # The tones are to be specified in order of presedence, most important first.
# # Currently, 15 tones may be specified..
# ctcss=1318,1,1318
# ctcss=1862,1,1862
# The following parameters may be omitted if their default value is acceptible
# # set the receive debounce time in milliseconds
# debouncetime=123
# # set the transmit quiet dropoff burst time in milliseconds
# bursttime=234
# # set the COR level threshold (specified in tenths of millivolts)
# # valid values are {3125,6250,9375,12500,15625,18750,21875,25000}
# corthresh=12500
# # Invert COR signal {y,n}
# invertcor=y
# # set the external tone mode; yes, no, internal {y,n,i}
# exttone=y
# Now apply the configuration to the specified channels:
# # We are all done with our channel parameters, so now we specify what
# # channels they apply to
# channels=1-4



; once we have an incoming call what context does it start off in the state machine?

; Specify whether the channel should be answered immediately or if the simple
; switch should provide dialtone, read digits, etc.

; Enable echo cancellation
; Use either "yes", "no", or a power of two from 32 to 256 if you wish to
; actually set the number of taps of cancellation.
; Note that if any of your Zaptel cards have hardware echo cancellers,
; then this setting only turns them on and off; numeric settings will
; be treated as "yes". There are no special settings required for
; hardware echo cancellers; when present and enabled in their kernel
; modules, they take precedence over the software echo canceller compiled
; into Zaptel automatically.
; Generally, it is not necessary (and in fact undesirable) to echo cancel when
; the circuit path is entirely TDM.  You may, however, change this behavior
; by enabling the echo cancel during pure TDM bridging below.
; In some cases, the echo canceller doesn't train quickly enough and there
; is echo at the beginning of the call.  Enabling echo training will cause
; asterisk to briefly mute the channel, send an impulse, and use the impulse
; response to pre-train the echo canceller so it can start out with a much
; closer idea of the actual echo.  Value may be "yes", "no", or a number of
; milliseconds to delay before training (default = 400)
; Note that these parameters do not apply to hardware echo cancellers.

; Support three-way calling

; Support flash-hook call transfer (requires three way calling)
; Also enables call parking (overrides the 'canpark' parameter)

; Allow call parking
; ('canpark=no' is overridden by 'transfer=yes')

; Specify whether flash-hook transfers to 'busy' channels should complete or
; return to the caller performing the transfer (default is yes).

; In some countries, a polarity reversal is used to signal the disconnect of a
; phone line.  If the hanguponpolarityswitch option is selected, the call will
; be considered "hung up" on a polarity reversal.

; You may also set the default receive and transmit gains (in dB)

;First 6 channels are the FXS modular cards
context = house
signalling = fxo_ls
;group = 1


;Next 2 channels are the FXO card
context = telus
signalling = fxs_ks
;group = 2