[asterisk-ss7] my chan_ss7 status is going up and down

Anton anton.vazir at gmail.com
Sat Mar 18 12:44:02 MST 2006


ADEGOKE,

Are you shure that you NEED crc4 enabled on spans? It's 
rarely used and improper settings causes E1 link to be 
down. When you get link into the operation you should first 
receive message that channels have been allocated from 
asterisk debug messages. Until then there is no SS7 link

I do use sangoma A102 - and it's working. 

My advice to try simple way first. Configure single SS7 link 
- when you succeed with it - process furher configuring 
more links.

See my working configs below, hopy it can help

I have empty zapata.conf

SS7.conf

[linkset-siuc]
enabled => yes
enable_st => no
use_connect => no
hunting_policy => even_mru
context => ss7
language => en
subservice => auto

[link-l1]
linkset => siuc
channels => 1-15,17-31
schannel => 16
firstcic => 1
enabled => yes

[link-l2]
linkset => siuc
channels => 1-15,17-31
schannel => 16
firstcic => 1
enabled => yes

[host-ss7-1]
enabled => yes
opc => 9000
dpc => siuc:4065
links => l1:1


ZAPTEL.CONF

#
# 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.
#

span=1,0,0,ccs,hdb3
bchan=1-31
span=2,0,0,ccs,hdb3
bchan=32-62

#span=1,0,0,esf,b8zs
#span=2,1,0,esf,b8zs
#span=3,0,0,ccs,hdb3,crc4
#
# 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
#
#fxoks=1-24
#bchan=25-47
#dchan=48
#fxols=1-12
#fxols=13-24
#e&m=25-29
#nethdlc=30-33
#clear=44
#clear=45
#clear=46
#clear=47
#fcshdlc=48
#dacs=1-24:48
#dacsrbs=1-24:48
#
# 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
#loadzone=gr
#loadzone=it
#loadzone=fr
#loadzone=de
#loadzone=uk
#loadzone=fi
#loadzone=jp
#loadzone=sp
#loadzone=no
#loadzone=hu
#loadzone=lt
#loadzone=pl
defaultzone=us
#
# Section for PCI Radio Interface 
# (see http://www.zapatatelephony.org/app_rpt.html)
#
# 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




On 19 March 2006 00:28, ADEGOKE ARUNA wrote:
> Thank you for the past responses,
>
> Can someone please help me point out my flaws again?
>
> I am working on fedora core 3 with sangoma a104d and
> lastest stable asterisk and libs.
>
> I have disabled my chan_zap.so
>
> After compiling my chan_ss7-0.8.3
>
> WIRELESS2*CLI> load chan_ss7.so
>  Loaded /usr/lib/asterisk/modules/chan_ss7.so => (SS7
> Protocol Support) Mar 18 19:10:08 NOTICE[11525]:
> config.c:320 load_config_linkset: Using default language
> '' for linkset 'siuc'
> Mar 18 19:10:08 NOTICE[11525]: config.c:463
> load_config_link: Configured link 'l1' on linkset 'siuc',
> firstcic=1
> Mar 18 19:10:08 NOTICE[11525]: config.c:463
> load_config_link: Configured link 'l2' on linkset 'siuc',
> firstcic=33
> Mar 18 19:10:08 NOTICE[11525]: config.c:463
> load_config_link: Configured link 'l3' on linkset 'siuc',
> firstcic=65
> Mar 18 19:10:08 NOTICE[11525]: config.c:463
> load_config_link: Configured link 'l4' on linkset 'siuc',
> firstcic=97
> Mar 18 19:10:08 WARNING[11525]: config.c:622
> load_config_host: Missing interface entries for host
> 'WIRELESS2'.
> Mar 18 19:10:08 NOTICE[11525]: config.c:772 load_config:
> Configuring DPC 60 for linkset 'siuc'.
>     -- Starting cluster thread, pid=3976.
> Mar 18 19:10:09 NOTICE[11525]: mtp.c:1934 mtp_init:
> Initialising 1 signalling links
>     -- Starting MTP thread, pid=3976.
>     -- Starting continuity check thread, pid=3976.
>   == Registered channel type 'SS7' (SS7 Protocol Driver)
>     -- SS7 channel loaded successfully.
>     -- Starting monitor thread, pid=3976.
> Mar 18 19:10:09 WARNING[14785]: mtp.c:1539
> mtp_thread_main: Empty Zaptel output buffer detected,
> outgoing packets may have been lost on link 'l1'.
> WIRELESS2*CLI> ss7
> block     cluster   dump      linestat  link      reset  
>   unblock WIRELESS2*CLI> ss7 li
> linestat  link
> WIRELESS2*CLI> ss7 linestat
> Linkset: siuc>
> Mar 18 19:11:24 WARNING[14785]: mtp.c:393 t2_timeout:
> MTP2 timer T2 timeout (failed to receive 'O', 'N', or 'E'
> after sending 'O'), initial alignment failed on link
> 'l1'.
>
>
> when I dialed 6210006
> i get this:
>
>  -- Executing Dial("IAX2/marko-2", "ss7/6210010|60") in
> new stack -- SS7 request (ss7/6210010) format = 0x8.
> Mar 18 20:15:59 WARNING[5495]: chan_ss7.c:425
> cic_hunt_even_mru: No idle circuit found.
> Mar 18 20:15:59 WARNING[5495]: chan_ss7.c:646
> ss7_requester: SS7 requester: No idle circuit available.
> Mar 18 20:15:59 NOTICE[5495]: app_dial.c:1011
> dial_exec_full: Unable to create channel of type 'ss7'
> (cause 17 - User busy) == Everyone is busy/congested at
> this time (1:1/0/0) == Auto fallthrough, channel
> 'IAX2/marko-2' status is 'BUSY'
>
> :22:37 WARNING[14785]: mtp.c:1438 mtp_thread_main:
> : Excessive poll delay
>
> 20978!
> Mar 18 19:22:37 WARNING[14785]: mtp.c:1438
> mtp_thread_main: Excessive poll delay 20979!
> Mar 18 19:22:37 WARNING[14785]: mtp.c:1438
> mtp_thread_main: Excessive poll delay 20977!
> Mar 18 19:22:37 WARNING[14785]: mtp.c:1438
> mtp_thread_main: Excessive poll delay 20978!
> Mar 18 19:22:37 WARNING[14785]: mtp.c:1438
> mtp_thread_main: Excessive poll delay 20978!
> Mar 18 19:22:38 WARNING[14785]: mtp.c:1438
> mtp_thread_main: Excessive poll delay 20979!
>
>
>
> Mar 18 19:25:20 WARNING[15612] mtp.c: Excessive poll
> delay 20979! Mar 18 19:25:20 WARNING[15624] chan_ss7.c:
> No idle circuit found. Mar 18 19:25:20 WARNING[15624]
> chan_ss7.c: SS7 requester: No idle circuit available.
> Mar 18 19:25:20 NOTICE[15624] app_dial.c: Unable to
> create channel of type 'SS7' (cause 17 - User busy)
>
>
> Extensions.conf
> [default]
> Exten => _621XXXX,1,Dial(ss7/${EXTEN},60)
>
> zaptel.conf
>
> loadzone = uk
> defaultzone = uk
>
> #span definitions
> span = 1,1,0,ccs,hdb3,crc4,yellow
> span = 2,2,0,ccs,hdb3,crc4,yellow
> span = 3,3,0,ccs,hdb3,crc4,yellow
> span = 4,4,0,ccs,hdb3,crc4,yellow
>
> #channel definitions
> #bchan = 1-124
> #bchan = 1-15,17-124
> #dchan = 16
>
>
>
> zapata.conf
>
> ;[trunkgroups]
> ;trunkgroup => 1, 16
>
> ;spanmap
> ;spanmap => 1,1,1
> ;spanmap => 2,1,2
> ;spanmap => 3,1,3
> ;spanmap => 4,1,4
>
>
> [channels]
> ;context = default
> ;switchtype = Euroisdn
> ;usecallerid = yes
> ;echocancel = yes
> ;echocancelwhenbridged = yes
> ;rxgain = 0.0
> ;txgain = 0.0
>
> ;signalling = pri_cpe
> ;group = 1
> ;channel = 1-15,17-31
>
>
> one of the wanpipe#.conf that controls sangoma interface
>
> #================================================
> # 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    = NO
> PCISLOT         = 13
> PCIBUS          = 6
> FE_MEDIA        = E1
> FE_LCODE        = HDB3
> FE_FRAME        = CRC4
> FE_LINE         = 1
> TE_CLOCK        = NORMAL
> TE_REF_CLOCK    = 0
> TE_HIGHIMPEDANCE        = NO
> LBO             = 120OH
> FE_TXTRISTATE   = NO
> MTU             = 1500
> UDPPORT         = 9000
> TTL             = 255
> IGNORE_FRONT_END = NO
> TDMV_SPAN       = 1
> TDMV_DCHAN      = 0
>
> [w1g1]
> ACTIVE_CH       = ALL
> TDMV_ECHO_OFF   = NO
> TDMV_HWEC       = YES
>
>
> ss7.conf is as below
> [linkset-siuc]
> enabled => yes
> enable_st => no
> use_connect => no #bcos am connect to alcatel s12 which
> doesn't lik con hunting_policy => even_mru
> subservice => auto
>
> [link-l1]
> linkset => siuc
> channels => 1-15,17-31
> schannel => 16
> firstcic => 1
> enabled => yes
>
> [link-l2]
> linkset => siuc
> channels => 1-31
> schannel =>
> firstcic => 33
> enabled => yes
>
> [link-l3]
> linkset => siuc
> channels => 1-31
> schannel =>
> firstcic => 65
> enabled => yes
>
> [link-l4]
> linkset => siuc
> channels => 1-31
> schannel =>
> firstcic => 97
> enabled => yes
>
> [host-WIRELESS2]
> enabled => yes
> opc => 900
> dpc => siuc:60
> links => l1:1,l2:2,l3:3,l4:4
>
>
>
>
> The following output is produced
> Mar 18 19:25:24 WARNING[15612] mtp.c: Excessive poll
> delay 20979! Mar 18 19:25:25 WARNING[15612] mtp.c:
> Excessive poll delay 20978! Mar 18 19:25:25
> WARNING[15612] mtp.c: Excessive poll delay 20979! Mar 18
> 19:25:25 WARNING[15612] mtp.c: Excessive poll delay
> 20979! Mar 18 19:25:25 WARNING[15612] mtp.c: Excessive
> poll delay 20979! Mar 18 19:25:25 WARNING[15612] mtp.c:
> Excessive poll delay 20979! Mar 18 19:25:25
> WARNING[15612] mtp.c: Excessive poll delay 20980!
>
>
> and its just to much and that the log growths in MB per
> minute
>
>
> after I rebooted my pc and applying the kai Militzer's
> patch I got the following error
> Verbosity is at least 3
> Mar 18 20:13:30 WARNING[5478]: mtp.c:414 t3_timeout: MTP2
> timer T3 timeout (failed to receive 'N', or 'E' after
> sending 'O'), initial alignment failed on link 'l1'.
> Mar 18 20:13:33 WARNING[5478]: mtp.c:414 t3_timeout: MTP2
> timer T3 timeout (failed to receive 'N', or 'E' after
> sending 'O'), initial alignment failed on link 'l1'.
> Mar 18 20:13:36 WARNING[5478]: mtp.c:414 t3_timeout: MTP2
> timer T3 timeout (failed to receive 'N', or 'E' after
> sending 'O'), initial alignment failed on link 'l1'.
> Mar 18 20:13:38 WARNING[5478]: mtp.c:414 t3_timeout: MTP2
> timer T3 timeout (failed to receive 'N', or 'E' after
> sending 'O'), initial alignment failed on link 'l1'.
> Mar 18 20:13:41 WARNING[5478]: mtp.c:414 t3_timeout: MTP2
> timer T3 timeout (failed to receive 'N', or 'E' after
> sending 'O'), initial alignment failed on link 'l1'.
> Mar 18 20:13:44 NOTICE[5478]: mtp.c:1197 mtp2_read_su:
> MTP2 bitstream frame format error, entering octet
> counting mode on link 'l1'. Mar 18 20:13:46
> WARNING[5478]: mtp.c:414 t3_timeout: MTP2 timer T3
> timeout (failed to receive 'N', or 'E' after sending
> 'O'), initial alignment failed on link 'l1'.
> Mar 18 20:13:49 WARNING[5478]: mtp.c:414 t3_timeout: MTP2
> timer T3 timeout (failed to receive 'N', or 'E' after
> sending 'O'), initial alignment failed on link 'l1'.
> Mar 18 20:13:52 WARNING[5478]: mtp.c:414 t3_timeout: MTP2
> timer T3 timeout (failed to receive 'N', or 'E' after
> sending 'O'), initial alignment failed on link 'l1'.
>
>
>
>
>
>
> ss7 link status
> linkset siuc, link l1, schannel 16, ALIGNED, rx: 3, tx:
> 0/4, sentseq/lastack: 127/127, total     73792,     73856
>
>
> WIRELESS2*CLI> ss7 linestat
> Linkset: siuc>
> CIC   1 Idle Reset pending
> CIC   2 Idle Reset pending
> CIC   3 Idle Reset pending
>
>
>
> CIC 125 Idle Reset pending
> CIC 126 Idle Reset pending
> CIC 127 Idle Reset pending
>
>
>
>
> -----Original Message-----
> From: Kai Militzer [mailto:km at westend.com]
> Sent: Friday, March 17, 2006 4:39 PM
> To: ADEGOKE ARUNA
> Subject: Re: chan_ss7.c: Failure in ZT_SPECIFY for
> circuit 1: Device or resource busy
>
> Hi Goksie,
>
> ADEGOKE ARUNA wrote:
> > What do you ask to disable?
>
> If you had this system at first running with ISDN E1s (no
> SS7) you have to disable your config for that at first.
>
> And did you tell your Telco that they have to configure
> the S12 to talk SS7 instead of ISDN to you? For me it
> doesn't look that way. Nevertheless it's not that easy to
> find your problem without more information.
>
> I am off into the weekend now, if you need more help send
> me an email, i will answer you on monday.
>
> Regards,
> Kai


More information about the asterisk-ss7 mailing list