[asterisk-ss7] ss7 with ewsd
Konrad Hammel
konrad at sangoma.com
Tue Jul 7 09:02:17 CDT 2009
Hello All,
Whether CRC4 or NCRC4 is used should have NOTHING to do with a layer
2 or higher (OSI model) protocols...if it does then there is serious
problem, please let us know.
You should look at all your communication problems with the OSI
model in mind....start at the lowest layer and work your way up
confirming that each layer has a proper, error free connection.
For an SS7 connection layer 1 is the E1/T1 connection which is
controlled by the interface card....in this case an A108 card by the
looks of it.
Start the port up using "wanrouter start wanpipeX" where X is
wanpipe number which on a single card system should be the port number.
Give it a second to stabilize and then run "wanpipemon -i wXg1 -c
Ta"...this command will report the T1/E1 line framer alarms, LIU alarms,
errors counters, and signal strength.
Are any alarms on ? No...then run "tail -f /var/log/messages" and
confirm that they are bouncing on and off. If there are alarms reported
then you need to resolve them now before moving on to the next layer.
With E1's the most common alarm you will see is the OOF alarm being
on in the framer alarms right from the start...this means the incoming
bit stream does not decode as it should most likely because you are
using the wrong line framing. If you see these alarms coming on after
the line has been running fine for a while you have a noise or error
problem...telco support is vital to finding the problem in this case.
Now...once layer 1 is up and running consistently move on the next
layer...MTP2. MTP2 does it's own HDLC framing so you should never have
hardware HDLC framing set on in the hardware....and here is the first
problem with this install. TDMV_DCHAN tells our hardware to perform
HDLC framing on the specified channel...in this case it is set to 16.
Set this option to TDMV_DHCAN=0 so that the hardware is doing straight
pass-through of all layer 2 traffic on all channels.
The second problem I saw....and a big give away is when you do a
MTP2 trace and say " but there wasn't any output"....this would mean
that there is no data coming to the MTP2 part of the SS7 stack. Now
since there are so many installs of chan_ss7 that work just fine don't
start questioning the stack. If you have a physical layer that is in a
connected state but are seeing no data then the data is being
intercepted along the way. In this case the problem is most likely
because you are running an echo canceler on an HDLC channel.
An echo canceler works by recording a certain constant amount of
outgoing data (the "tail" length) and listening for identical data on
the incoming data. If there is a match the data is dropped out of the
incoming stream. In a normal audio stream this only happens when the
incoming data is an echo of the outgoing. In data (aka HDLC streams)
there is a good chance that within the tail there is a repeat of data
causing the echo canceler to drop the data. So the echo canceler needs
to be turned off on the signalling channel.
The easiest way to turn off a signalling channel is to use the
"wan_ec_client" application in our drivers which can be used to talk
directly to the HWEC. After the startup of the card but before starting
the MTP2 stack you should run "wan_ec_client wanpipeX bd Y" where X is
the port number and Y is the channel number. To do this automatically
add this command to the file /etc/wanpipe/scripts/start ... this script
is run after our drivers start and is normally used to run "ztcfg"
automatically.
Give this a try and let the list know if you continue to have problems.
*Thank-you,**
***
*Konrad Hammel, **B.ENG, **Software Engineer/Field Applications Engineer**
*Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON
L3R 9T3 Canada
t. 1 905 474 1990 x 118 | e. konrad at sangoma.com
<mailto:konrad at sangoma.com>_
_www.sangoma.com <http://www.sangoma.com/> | wiki.sangoma.com
<http://wiki.sangoma.com/>
*
*Lifetime Warranty.*** Because it must work!*
<http://www.tmcnet.com/voip/conference/>
Lakshmi Narasimhan .R wrote:
> Wanpipe with crc4 enabled is known to cause problem with chan_ss7
> signalling no matter what you are trying, so first change the below
> setting
>
> FE_FRAME = CRC4
>
> to
>
> FE_FRAME = NCRC4
>
> this will help in finding the actual problem, you might get hints of
> the problem in logs.
>
> 2009/7/6 chamo <chamo4 at darksun.sk>:
>
>> hi
>>
>> i have problems with chan_ss7 to work with EWSD .
>> i have tried many configuration with and without crc4, with different
>> clock sources
>> without success, i always get NOT_ALIGNED message
>>
>> i have also tried ss7 dump, but there wasn't any output
>>
>> many thanks for any help, and sorry for my english ;)
>>
>> ############status
>> dmesg
>>
>> ADDRCONF(NETDEV_CHANGE): w1g1: link becomes ready
>> wanpipe1: Global TDM Ring Resync
>> wanpipe1: Card TDM Rsync Rx=0 Tx=2
>> wanpipe1: RAI alarm is OFF
>> wanpipe1: OOF alarm is OFF
>> mtrr: type mismatch for f9000000,800000 old: write-back new: write-combining
>>
>>
>> voicegw*CLI> ss7 link status
>> linkset siuc, link l1, schannel 1, sls 0, NOT_ALIGNED, rx: 0, tx: 4/4,
>> sentseq/lastack: 127/127, total 4754816, 4754912v
>>
>> i am also getting this message
>>
>> WARNING[4390]: mtp.c:513 t2_timeout: MTP2 timer T2 timeout (failed to
>> receive 'O', 'N', or 'E' after sending 'O'), initial alignment failed on
>> link 'l1'.
>>
>>
>>
>> here are my configs
>>
>> #dahdi system.conf
>> #autogenerated by /usr/sbin/wancfg_dahdi do not hand edit
>> #autogenrated on 2009-06-03
>> #Dahdi Channels Configurations
>> #For detailed Dahdi options, view /etc/dahdi/system.conf.bak
>> loadzone=us
>> defaultzone=us
>>
>> #Sangoma A108 port 1 [slot:4 bus:3 span:1] <wanpipe1>
>> span=1,1,0,ccs,hdb3,crc4
>> #span=1,0,0,ccs,hdb3
>> bchan=1-31
>>
>> wanpipe1.conf
>> #================================================
>> # 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 = NO
>> PCISLOT = 4
>> PCIBUS = 3
>> FE_MEDIA = E1
>> FE_LCODE = HDB3
>> FE_FRAME = CRC4
>> FE_LINE = 1
>> TE_CLOCK = NORMAL
>> TE_REF_CLOCK = 0
>> TE_SIG_MODE = CCS
>> TE_HIGHIMPEDANCE = NO
>> LBO = 120OH
>> FE_TXTRISTATE = NO
>> MTU = 1500
>> UDPPORT = 9000
>> TTL = 255
>> IGNORE_FRONT_END = NO
>> TDMV_SPAN = 1
>> TDMV_DCHAN = 16
>> TDMV_HW_DTMF = YES
>> TDMV_HW_FAX_DETECT = NO
>>
>> [w1g1]
>> ACTIVE_CH = ALL
>> TDMV_HWEC = YES
>>
>>
>>
>> ss7.conf
>>
>> [linkset-siuc]
>>
>> ; The linkset is enabled
>> enabled => yes
>>
>> ; The end-of-pulsing (ST) is not used to determine when incoming address
>> is complete
>> enable_st => no
>>
>> ; Reply incoming call with CON rather than ACM and ANM
>> use_connect => yes
>>
>> ; The CIC hunting policy (even_mru, odd_lru, seq_lth, seq_htl) is even
>> CIC numbers, most recently used
>> hunting_policy => even_mru
>>
>> ; Incoming calls are placed in the ss7 context in the asterisk dialplan
>> context => ss7
>>
>> ; The language for this context is da
>> language => da
>>
>> ; The value and action for t35. Value is in msec, action is either st or
>> timeout
>> ; If you use overlapped dialling dial plan, you might choose: t35 => 4000,st
>> t35 => 15000,timeout
>>
>> ; The subservice field: national (8), international (0), auto or
>> decimal/hex value
>> ; The auto means that the subservice is obtained from first received SLTM
>> subservice => auto
>>
>> ; The host running the mtp3 service
>> ; mtp3server => localhost
>>
>> [link-l1]
>>
>> ; This link belongs to linkset siuc
>> linkset => siuc
>>
>> ; The speech/audio circuit channels on this link
>> channels => 2-31
>>
>> ; The signalling channel
>> schannel => 1 ;yes i have signalling on channel 1, with libss7 was
>> working (configs for libss7 are included lower))
>> ; To use the remote mtp3 service, use 'schannel => remote,16'
>> ; The first CIC
>> firstcic => 1 ;;i have also tried start with firstcic =>2
>>
>> ; The link is enabled
>> enabled => yes
>>
>> ; Echo cancellation
>> ; echocancel can be one of: no, 31speech (enable only when transmission
>> medium is 3.1Khz speech), allways
>> echocancel => no
>> ; echocan_train specifies training period, between 10 to 100 msec
>> echocan_train => 350
>> ; echocan_taps specifies number of taps, 32, 64, 128 or 256
>> echocan_taps => 128
>>
>>
>> [host-voicegw]
>> ; chan_ss7 auto-configures by matching the machines host name with the
>> host-<name>
>> ; section in the configuration file, in this case 'gentoo1'. The same
>> ; configuration file can thus be used on several hosts.
>>
>> ; The host is enabled
>> enabled => yes
>>
>> ; The point code for this SS7 signalling point is 0x8e0
>> ;opc => 0x8e0
>> ; 15389 dec
>> opc => 0x3c1d
>>
>> ; The destination point (peer) code is 0x3fff for linkset siuc
>> ;dpc => siuc:0x3fff
>> ; 15880
>> dpc => siuc:0x3e08
>>
>> ; Syntax: links => link-name:digium-connector-no
>> ; The links on the host is 'l1', connected to span/connector #1
>> links => l1:1
>>
>> ; The SCCP global title: translation-type, nature-of-address,
>> numbering-plan, address
>> globaltitle => 0x00, 0x04, 0x01, 4546931411
>> ssn => 7
>>
>> ##
>> [root at voicegw ~]# uname -a
>> Linux voicegw 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64
>> x86_64 x86_64 GNU/Linux
>>
>>
>> ###################################
>> this is working configuration for linss7, it was good, but there were
>> some problems with ss7 stack
>> ##chan_dahdi.conf
>>
>> trunkgroup => 1,1
>> spanmap => 1,1
>> language=en
>> context=ss7
>> switchtype=euroisdn
>> pridialplan=unknown
>> prilocaldialplan=national
>> usecallerid=yes
>> callwaiting=yes
>> usecallingpres=yes
>> callwaitingcallerid=yes
>> threewaycalling=yes
>> transfer=yes
>> canpark=yes
>> cancallforward=yes
>> callreturn=yes
>> echocancel=yes
>> echocancelwhenbridged=yes
>> group=1
>> callgroup=1
>> pickupgroup=1
>> ss7_called_nai=dynamic
>> ss7_calling_nai=dynamic
>> ss7_internationalprefix = 00
>> ss7_nationalprefix = 0
>> ss7_subscriberprefix =
>> ss7_unknownprefix =
>> networkindicator=national_spare
>> signalling = ss7
>> ss7type = itu
>> linkset = 1
>> pointcode = 15389
>> adjpointcode = 15880
>> defaultdpc = 15880
>> cicbeginswith = 2
>> channel=2-31
>> sigchan = 1
>>
>>
>> ##system.conf
>>
>> span=1,1,0,ccs,hdb3,crc4
>> bchan=2-31
>> #echocanceller=mg2,2-31
>> mtp2=1
>>
>>
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-ss7 mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-ss7
>>
>>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-ss7
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-ss7/attachments/20090707/bdf83db1/attachment-0001.htm
More information about the asterisk-ss7
mailing list