Planning and Provisioning

1. Identify the 32 bit Linux distribution that you will use. 2. Identify each location that will support SS7 inter-machine trunks and PRIs 3. For each location, count the number of E1/T1 ports needed 4. Select Sangoma AFT series cards to support decisions above 5. Fill out the ss7box Installation Questionnaire 6. Get CIC Mapping for each SS7 inter-machine trunk 7. Get PRI Provisioning information for each PRI (optional) 8. Get ambnalog interface provisioning information (optional)

System Installation and Configuration

1. Disable Hotplug services for wanpipe drivers. http://sangoma.editme.com/wanpipe-linux-asterisk-appendix#hotplug 2. Configure zaptel interfaces used for PRI and analog plain-old-telephone-service (POTS) lines. * Asterisk PRI Configuration? * Asterisk A200 Analog POTS Configuration * TDMV_SPAN in wanpipeX.conf are in the range 1..n. Values are used only once. The range applies to both PRI and analog wanpipes. TDMV_SPAN is also the zaptel span number. The range does not apply to the SS7 IMT wanpipes. 3. Configure SS7 IMT interfaces * Perform CIC Mapping * Wanpipe Configuration for SS7 IMT Voice and F-Link * Wanpipe Configuration for SS7 IMT Voice-only? * Wanpipe Configuration for SS7 A-link? * TDMV_SPAN in wanpipeX.conf are in the range 1..n. Values are used only once. The range applies only to SS7 IMT wanpipes. The range does not apply to zaptel PRI or analog wanpipes. * Adjust the TDM API Interrupt Rate Control 4. Configure Echo Cancellation. 5. Specify order in which wanpipes are started in wanrouter.rc. * Wanpipes that have SS7 links in them must be omitted from wanrouter.rc. ss7box controls these wanpipe interfaces to adhere to the MTP2 protocol. These are the wanpipes whose numbers are specified in ss7box.conf. * TDMV_SPAN numbers for zaptel interfaces and the TDMV_SPAN numbers for SS7 IMTs are different instances of the same variable. This means that TDMV_SPAN = 0 in a zaptel wanpipeX.conf is different from TDMV_SPAN = 0 in an SS7 IMT wanpipeX.conf. * The following order for starting wanpipes is recommended: 1. zaptel wanpipe interfaces are started in the order of their zaptel TDMV_SPAN number assignment. 2. SS7 inter-machine trunk wanpipe interfaces that have no SS7 links in them can be started without regard to order. 6. ss7box.conf 7. ss7boost.conf 8. sangoma_mgd.conf 9. woomera.conf 10. Asterisk/Callweaver configuration

	exten => _X.,n,Dial(WOOMERA/g1/${EXTEN}|60|o,30)
	

      PREFIX-RDN-RDNA-RDPR-RDNP-OCDN-I-O-R-C-N
	

[ss7-imt]
exten => _1X.,1,noop
exten => _1X.,2,noop(${CALLERID(rdnis)})
exten => _1X.,3,Set(CALLERID(rdnis)=SMGRev-1234-003-2-1-4321-1-2-3-4-1)
exten => _1X.,4,noop(${CALLERID(rdnis)})
exten => _1X.,5,Dial(WOOMERA/g1/${EXTEN:1}|60)
	

[d10-analog-lines]
exten => _616XXXXXXX,1,noop(${CALLERID(rdnis)})
exten => _616XXXXXXX,2,Goto(d7-analog-lines,${EXTEN:3},1)
	

System Operation

This section describes how to start, stop, and verify operation, and troubleshoot SMG.

Sample Section

This is a sample section.

Configuration

The ss7box configuration file is /etc/ss7box/ss7box.conf. An example of this file follows:

 
# This is the configuration file for Xygnada ss7box release 0.1 and 0.3
# Copyright 2004, Michael J. Mueller

# This a comment line

# The order of elements, the bracketed elements, and the order and type
# of information elements must adhere to the pattern specified.

# All index values must be sequential with a skip value of one (1).

[GLOBAL]
#
# SS7 Protocol: ITU/ANSI
#
# Self Point Code:
#       ITU format is 14 bit unsigned integer
#       ANSI format is (network) (cluster) (member)
#               network is an 8 bit unsigned integer
#               cluster is an 8 bit unsigned integer
#               network is an 8 bit unsigned integer
#
# SS7 Prot.  Self Point Code Serial No. Authorization Code            Verbose Group
  ITU           201           xlb3      86d74c6041412a16250670152b74750b 2

[CLI]
#       Local
#       address                 port
        127.0.0.104             55063
#       Remote
#       address                 port
        127.0.0.105             55063

[CROSSLINK]
# Mode (SIMPLEX | DUPLEX)       Local IP Addr   Local Port      Remote IP Addr  Remote Port
  SIMPLEX                       na              na              na              na
# DUPLEX                        192.168.1.21    54030           192.168.1.22    54020

[FACILITIES]
#
# Card Name:
#       wanpipeX where X is 1..n; see Sangoma documentation for more information;
#       don't care for UDP facilities
## Index Card Name Numeral       Frame/Packet    Clear Chan.
  0     1                       80              y
  end
# No more than four facilities supported at this time.

[MTP2LINKS]
# Index Fac  Slot LSet Link T1    T2    T3    T4e   T4n   T5    T6    T7
  0     0    15   0    0    13.00 11.50 11.50 0.60  2.30  0.12  3.00  1.00
  end
# Up to 93 links may be configured.

[MTP3TIMERS]
#
# Timer Value
  1     0.80
  2     1.40
  3     0.80
  4     0.80
  5     0.80
  6     0.80
  7     1.50
  8     1.20
  9     0.00
  10    30.00
  11    30.00
  12    1.50
  13    1.50
  14    3.00
  15    3.00
  16    2.00
  17    1.50
  18    20.00
  19    600.00
  20    120.00
  21    120.00
  22    15.00
  23    15.00
  24    15.00
  25    35.00
  26    15.00
  27    5.00
  28    35.00
  29    65.00
  30    35.00
  31    120.00
  32    120.00
  33    600.00
  34    120.00
# Periodic Facility Check Timer
  35    10.00
# Periodic Signaling Link Test Message Timer
  36    120.00
# Crosslink Test Acknowledge Timer (must be less the timer 35 Periodic Facility Check Timer
# that controls the Crosslink Test Message)
  37    5.00


  In the MTP3LINKSETS section the linkset are defined. A linkset is a collection of links 
  between ss7box and its adjacent nodes. Each entry in the table is a different linkset.

    * Index - identifies the linkset in the configuration; sequential, no skips, 0..15
    * APC - adjacent point code, point code of node on remote end of linkset
    * slt - signal link test pattern size: 0 - off, no SLT; 1..15 - on, pattern size  
    * slt - deprecated: y - on, size compiled in; n - off
    * prio: SIO priority value in SNM and SLT
    * ni: SIO networking indicator value in SNM and SLT
    * Links in Linkset: listed in order of SLC (0..15), entry is MTP2LINKS index, the 
         Link value in MTP2LINKS for selected entry must match the SLC column selected; 
	 if index 0 has link value 3 then insert '0' in the SLC 3 column of the table 

[MTP3LINKSETS]
#                              Links in Linkset (associated MTP2 link indices)
# Index APC   slt prio ni SLC: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
  0     4000  4   0    2       0 na na na na na na na na na na na na na na na
  end


In the PATHS section, linksets are grouped so that one or two linksets will be used as a single equivalent and load-balanced path to a destination. This is how the ANSI combined linkset in implemented. The PATH concept allows the combined linkset idea to be used in both ANSI and ITU implementations. ss7box routes messages to paths instead of linksets.

    * Index - identifies the path in the configuration, sequential, no skips, 0..15
    * Linkset-A - mandatory, index of linkset in MTP3LINKSETS section; linkset index may be used only once in the PATHS section.
    * Linkset-B - optional, index of linkset in MTP3LINKSETS section; linkset index may be used only once in the PATHS section. 

[PATHS]
# best practice for linksets to STP configurations:
# the first path associated with a linkset should be a path to the adjacent
# node with that linkset in the Linkset-A position; this is not enforced and
# is put into effect through careful attention to the construction of this
# section

# Index     Linkset-A     Linkset-B (optional)
  0         0             na
  end


In the ROUTES section the destination point codes recognized by a particular ss7box are defined. It is mandatory that all adjacent point codes be entered in the table. Non-adjacent destinations are accessible by going through the adjacent point codes.

    * Index - identifies the route in the configuration, sequential, no skips, 0..63
    * DPC - destination point code
    * Protocol - MTP3 or M3UA; MTP3 is the SS7 network; M3UA is a SIGTRAN IP network that is under development (experimental)
    * P/Path - Primary Path, index from PATHS section, the path this used normally for reaching the DPC
    * A/Path - Alternate Path, index from PATHS section, the path that is used if the Primary Path is not available
    * Crosslink - y/n, use link connecting two ss7boxes in a duplex/redundant configuration, used when the Primary Path is not available and before trying the Alternate Path 

[ROUTES]
#
# Must enter routes for adjacent and non-adjacent nodes.
#
# Index         DPC             Protocol  P/Path  A/Path  Crosslink
  0             4000            MTP3      0       na      N
  end

[M3UA]
# Two ports actually used; port and port+1
# local  ipv4 addr and port
   127.0.0.44           50220
# remote ipv4 addr and port
   127.0.0.43           50220

	 

working Section

Installation The first step for all installations is to complete the ss7box Installation Questionnaire.

1. Specify the transmission media 1. E1 or T1 2. Line encoding scheme 3. Framing scheme 4. Sangoma card clock (supplier or consumer) 2. Specify the transmission path 1. How many segments? 2. Identify the connection point of each segement. 3. Can you loopback each segement connection point in both directions? 3. Specify the protocol flavor: ITU or ANSI 4. Specify the SS7 link configuration: F-link or A-link (F-links are used everywhere. A-links are most common when connecting SS7 links to a signal transfer point (STP)). 5. What is the self point code (SPC) - the point code assigned to ss7box? See the discussion on Point Code Structure. 6. How many linksets will be defined? 7. For each linkset specify 1. Adjacent point code (APC) - the point code of the node on the other end of the linkset? 2. Equipment vendor and model of node on adjacent end 8. For each link in a linkset, indicate 1. Sangoma card (if more than one) 2. Sangoma card port (1..n) 3. channel number (E1: 1..31, T1: 1..24) 4. signal link code (SLC) 9. Do you want direct support? If so, how do we log in as a root-priviledged user to the ss7box platform? 10. Identify the installation/operation contacts 1. name 2. location (city/country) 3. email 4. instant messanger service and id 5. voice contact info 6. working hours

Installing ss7box requires: 1. Installing the Sangoma driver 2. Creating and populating /etc/ss7box 3. Creating and populating /usr/local/ss7box You should determine if you are installing ss7box as part of Sangoma Signal Media Gateway (SMG), SCP, STP, or some combination. If SMG functionality is needed then install with the standard SMG installation procedure; otherwise follow the instructions below. ALERT: Only works with 32 bit Linux kernels. GCC Rev 3.x compilers are recommended. 1. installation instructions go here...... Configuration All configuration files are found in /etc/ss7box. ss7box Wanpipe Configuration File ss7box.conf Operation Reading ss7box Output to /var/log/messages All messages have a text explanation and optional parameters that follow in a colon-separated format. Each message describes its own parameters. * "I:" messages are informational and exposed if the verbose options are used; ss7box now generates far too much information to be useful in a live system; this is an area in need of improvement. * "W:" messages are warnings that indicate events that should be noted and possibly remedied. * "F:" are fatal exceptions that cause ss7box to cease running. These exceptions require the attention of ss7box developers. Starting ss7box 1. cd /usr/local/ss7box 2. ./Tail 3. ./ss7boxd_(revision) 4. Watch output of /var/log/messages for indications of configuration problems and links coming up or not. The output is complex and not easy to decipher. Eventually you will become accustomed on how to read the output. Stopping ss7box You should stop ss7box only to change configuration or revisions of ss7box or xmtp2km. These events do not occur frequently. Stopping ss7box drops all SS7 links. Adjacent point codes will generate lots of alarms when SS7 links are down. In this case, the node technicians at the adjacent point codes will most likely put the offending links into a manually disabled state. You will need to coordinate manual enabling of the SS7 link to get it back in service. Once your links are up, leave them up unless you need to reconfigure or upgrade ss7box/xmtp2km. Any outages should be planned with the adjacent node operators and durations minimized. 1. ps axj | grep ss7 2. kill (pid of ss7box) 3. wanrouter stop all wanpipes to force removal of xmtp2km kernel module Are The Links Up? Refer to SS7 Link Status. Finding the SS7 Links In a E1/T1 This procedure samples the raw bitstream flow of the the entire E1/T1 as presented by the Sangoma Bitstream API which is channels 1-31 for E1 and 1-24 for T1. The wanpipeX.conf file is modified, so be sure to save existing wanpipeX.conf files if appropriate. * Find the SS7 Links E1 Procedure * Find the SS7 Links T1 Procedure? Checking Level 1 While ss7box is running you can do the following: * To check E1/T1 alarms use: # wanpipemon -i w1g1 -c Ta * To see if data is moving through the Sangoma drivers: # ifconfig > output.ifconfig; sleep 5; ifconfig >> output.ifconfig * To see a bit-level sample of what is being sent and received by the SS7 link driver: # wanpipemon -i w1g16 -c tr > bscap OUTGOING Len=80 TimeStamp= 1692 Oct 21 11:52:23 542222 [1/100s] Raw (HEX) 00 9C 98 FB 7D DF 37 00 E0 C4 DC EF FB BE 01 00 27 E6 7E DF F7 0D 00 38 31 F7 FB BE 6F 00 C0 89 B9 DF F7 7D 03 00 4E CC FD BE EF 1B 00 70 62 EE F7 7D DF 00 80 13 73 BF EF FB 06 00 9C 98 FB 7D DF 37 00 E0 C4 DC EF FB BE 01 00 27 E6 7E DF F7 Stop operation with ctl-c. A functioning SS7 link that is trying to align or is aligned and idle, a non-trival pattern of data will be evident by looking diagonally across the output. This is true for both INCOMING and OUTGOING data samples. This pattern exists because a long sequence of repeated small packets are being sent in both directions. The pattern complexity is increased by HDLC-style bit-stuffing. Note the pattern in the OUTGOING sample output shown above. If there is a trivial pattern or no pattern, and the SS7 link is not aligned, then mostly likely there is a configuration or transmission problem. Checking Level 2 This is a brand new tool that runs the bitstreams through and HDLC decoder so the LSSU and FISU patterns can be seen. Here's how to install and use it. It will be included in new Sangoma driver releases. 1. ftp.sangoma.com/tmp 2. untar the wanpipe_hdlc.tgz into 3. 2.3.4 release wanpipe/ directory 4. copy wanpipe_hdlc.tgz into wanpipe/ 5. untar 6. then go to utils/wanpipemon 7. make clean 8. make 9. make install 10. start ss7boxd 11. wanpipemon -i w1g16 -c trh (w1g16 must be set according to your configuration) Output: telco->ss7box, FISUs INCOMING Len=80 TimeStamp=59136 Mar 06 00:04:17 831279 [1/100s] Raw (HEX) FF FF 00 FF FF Raw (HEX) FF FF 00 FF FF Raw (HEX) FF FF 00 FF FF Raw (HEX) FF FF 00 FF FF Raw (HEX) FF FF 00 FF FF Raw (HEX) FF FF 00 FF FF Raw (HEX) FF FF 00 FF FF Raw (HEX) FF FF 00 FF FF Raw (HEX) FF FF 00 FF FF ss7box->telco, FISUs OUTGOING Len=80 TimeStamp=59143 Mar 06 00:04:17 837884 [1/100s] Raw (HEX) FF 83 00 9B A6 Raw (HEX) FF 83 00 9B A6 Raw (HEX) FF 83 00 9B A6 Command Line Interface More to come....

ss7box Conformance

The compliance information is given with respect to the ITU conformance test specification in the tables in this section.

NOTES C means comply. NC - does not comply, no plans to comply at this time command line interface link stop/start supported; CLI linkset stop/start not supported yet worked in past; needs testing in lab; used only as F-link access device in last two years; if not working, fix date will be provided n/a; not testing STP function only emergency changeover supported; normal changeover will be supported in the future; date not known at this time; link failures are infrequent; traffic volume on signal link not above 1%; not essential for small systems link inhibiting not supported; its absence has caused no inconvenience in any SMG installation so far; If a link is not to be used, then the telco or the ss7box side can simply stop the link; Inhibiting stops a link from being used but keeps the link aligned; Inhibiting has complicated rules for automatic uninhibiting in distress situations; the link inhibit procedure offers little value in operations, it is a complex implementation, and link stopping is a reasonable and simple alternative; comments to the contrary are welcome MTP restart not supported; systems have low link count signal low traffic; opposite end of linksets have restart procedure and throttle linkset operation during restart

Product Plan

This section describes the xmtp2km and ss7box product plans.

Installation

ss7boost is installed automatically in the smginstall process. An ss7boost installation consists of putting the ss7boost and ss7boost_cli binaries in /ss7box (a symlink) and putting ss7boost.conf and ss7boost_cli.conf in /etc/ss7box.

Configuration

 
# This is the ss7boost.conf file used by ss7boost.
# Copyright (c) 2005 Xygnada Technology, Inc.

[SS7BOOST]


This section defines some global attributes of a particular instance of ss7boost.

* SS7 Protocol
   o ITU
   o ANSI 
* Self Point Code
   o 14 bit unsigned integer for ITU
o Three 8 bit unsigned integers separated by spaces (network cluster member) 
* System ID
o unsigned integer
o identifies this system in CDR log report 
* Verbose Group (see Verbose Group Indicators) 

#       SS7 Protocol    Self Point Code   System Id      Verbose Group
	ITU             200               1              1


The SS7BOX section describe the connection to ss7box. The assignments must be the 
reverse of what is found in the [M3UA] section of ss7box.conf.

Two ports are used. One each for the normal and high priority queues.

[SS7BOX]
#       local address   local port
	127.0.0.43      50220
#       remote address  remote port
	127.0.0.44      50220

The SANGOMA_MGD section defines the connection to sangoma_mgd. The assignments must 
be the reverse of the boost_XXXXX assignments in sangoma_mgd.conf.

Two ports are used. One each for the normal and high priority queues.

[SANGOMA_MGD]
#       local address           port
	127.0.0.66              53000

#       remote address          port
	127.0.0.65              53000

The CLI  section defines the connection to the ss7boost command line interface system. The
assignments must be the reverse of what is found in the [APPSERVER] section of ss7boost_cli.conf.

[CLI]
#       Local 
#       address                 port
	127.0.0.92              55000
	
#       Remote (CLI script)
#       address                 port
	127.0.0.93              55000

[CDR]
# Automatic CDR Logging at Startup (y/n)
	n
#       Local
#       address                 port
	127.0.0.92              55011
#       Remote (CDR Collector)
#       address                 port
	127.0.0.93              55011

[SYSTEM_TIMERS]
# index  timer
  0       0.00 	# base, unused
  1       1.00	# heartbeat rate
  2      45.00	# call stop
  3       1.00	# circuit maintenance gap timer
  4      20.00	# automatic call gap timer
  5       0.00	# last, unused

The TRUNK section describes parameters for individual E1 or T1 trunks (also
called spans).  
  
* index - must match TDMV_SPAN-1 value in wanpipeX.conf of E1/T1 of this trunk
* wanrouter number - X in the filename found in /etc/wanpipe/wanpipeX.conf
	this value is needed to monitor trunk status and maintain the circuits
	in the trunk timeslots; derive this information as follows:
	1. get a list of wanpipes that are used as SMG controlled voice trunks
		grep TDM_VOICE_API /etc/wanpipe/wanpipe*.conf > smg-ctl-wp.txt
	2. for each smg controlled wanpipe in smg-ctl-wp.txt do
		a. grep TDMV_SPAN /etc/wanpipe/wanpipeX.conf where X is the
		   wanpipe number
		b. subtract 1 from the TDMV_SPAN value to get the TRUNK section
		   index value
	3. enter the wanpipe number value in the entry with the index value 
	   derived in step 2.b above
* facility type
	o T1 - 24 channels
	o E1 - 31 channels 
* CIC base
	o the CIC assigned to ss7boost channel 0
	o see Channel Numbering for more details
	o see CIC Mapping for more details 
* non-voice channels
	o any channel not used for voice, for example the SS7 signaling channels
	o use the ss7boost channel number 
	
[TRUNK]
#        wanpipe    fac   CIC    non-voice
# index  number     type  base   channels
  0      1          E1    1      15 end
  1      2          E1    65     end
end

[TRUNK_GROUP]
* A - tg_index
	o must be in order [0..99]
	o early termination of list with keyword "end" 
* B - remote p/c
	o point code of SSP on remote end of span 
* C - ISUP SIO PRIO
	o value to assign to MTP3 header SIO priority field in ISUP messages 
* D - ISUP SIO NI
	o value to assign to MTP3 header SIO network indicator field in ISUP messages 
* E - CIC descend
	o the direction of hunting for an available CIC
	o n - CIC hunting starts low and increments
	o y - CIC hunting starts high and decrements 
* F - overlap signalling
	o use of overlap vs en bloc call setup method
	o n - en bloc
	o y - overlap 
* G - NADI In Prefix
	o n - no prefix added to numbers
	o y - NADI value in prefix digit in all calling/called numbers 
	      passed between the dialplan and ISUP; disables the next 
	      option - clg num NADI; also makes the Structured Trunk 
	      Group Value dialplan feature unecessary 
* H - clg num NADI
	o integer value placed in the Calling Party Address - Nature of Address field for all outbound calls per Q.763 
* I - Tranmission Media Requirement 3.1 KHz allowed
	o n - not allowed
	o y - allowed 
* J - Tranmission Media Requirement Speech allowed
	o n - not allowed
	o y - allowed 
* K - Calling Party Category
	o 10 - ordinary subscriber (should be kept as default value)
o Refer to Q.763 for more values 
* L - outbound Transmission Medium Requirement value (0..3)
	o Refer to Q.763 
* Z - span_list
	o space separated list of span indices from the [TRUNK] section above
	o numerical order not required
	o a span may be used in only one trunk group
	o a span list may contain up to 20 spans
	o a span list is delimited with the keywords "begin" and "end" 

# A    B  C  D  E  F  G  H  I  J  K  L  Z
  0  201  1  2  n  y  n  3  y  y 10  0  begin 0 1 end
end

[GTT_TYPE]

This section associates a GTT type with a ss7boost defined value assigned to each GTT function. This is necessary because there is no industry consensus on the GTT functions associated with each of the possible values in the GTT Type field (0..255) of the SCCP Calling/Called Party Address parameter. It is possible, though unlikely, to have more functions than available GTT Type values (256).

The format of each entry is two decimal integers:
(gtt type value) (ss7boost gtt function id)
where:
* gtt type value is in the range 0..255
* ss7boost gtt function id is one of the following:
	o 5 (CNAM)
	o 6 (LNP)
	o 7 (TFS)
	o 8 (LIDB)
	o 9 (MAP)
	o 10 (HLR)
	o 11 (VLR)
	o more values added as needed by ss7boost maintainers 

Other rules:
* This section may have up to 256 entries.
* No order is enforced.
* Duplicate entries are allowed with later entries overriding previous ones.
* Early termination of the section with "end" is allowed. 
# GTT Type      SSN     Function ID
11           210     5 # CNAM
end
[CNAM_SERVER_2]
# describes parameters of relationship with the media_gw
#       Local (app server)
#       address                 port
	127.0.0.76              53040

#       Remote (media_gw)
#       address                 port
	127.0.0.75              53040
	
[CNAM_SERVER_3]
# describes parameters of relationship with the media_gw

#       Local (app server)
#       address                 port
	127.0.0.86              53040

#       Remote (media_gw)
#       address                 port
	127.0.0.85              53040
	 

Trunk Group Timers Configuration

There is a separate timer file for each trunk group. The value of N in the file name corresponds to the trunk group index found in the TRUNK_GROUP section of ss7boost.conf.

A sample of the contents of the ISUP timer file is shown below:

 
[ISUPTIMERS]
1      20.00
2      180.00
3      120.00
4      300.00
5      300.00
6      20.00
7      25.00
8      12.00
9      180.00
10      5.00
11      17.00
12      30.00
13      300.00
14      30.00
15      300.00
16      10.00
17      300.00
18      30.00
19      300.00
20      30.00
21      300.00
22      30.00
23      300.00
24      1.00
25      2.00
26      60.00
27      240.00
28      10.00
29      0.60
30      5.00
31      365.00
32      3.00
	 

Operation

This section describes how to operate ss7boost. All commands are executed from /usr/local/ss7box unless otherwise noted.

	[root@ana3 smg]# cd /ss7box/
	[root@ana3 ss7box]# ./ss7boost --ver
	Xyganda Technology, Inc. ss7boost Revision 1.0.2.137
	

Command Line Interface

The CLI is used to control ss7boost operation while it is running as a daemon. The CLI is composed of the ss7boost_cli program and ss7boost. ss7box_cli provides the human interface and sends and receives packetized information to ss7boost to execute the commands specified on the human interface.

The ss7boost_cli program provides the human, or command line interface for interacting with ss7boost. There is a packet interface between ss7boost_cli and ss7boost. This arrangment allows ss7boost to run in a higher priority than the ss7boost_cli program which a typical sytems engineering practice.

The ss7boost_cli program is copied to /usr/local/ss7box during normal SMG installation or upgrade.

 
[APPSERVER]

#       Local 
#       address                 port
        127.0.0.103             55033

#       Remote 
#       address                 port
	127.0.0.102             55033
	 

   cd /ss7box
   ./Tail
   ./ss7boost_cli --log-verbose on (vgi)
	

   ./ss7boost_cli --log-verbose off
	

	./ss7boost_cli --log-cdr on
	./ss7boost_cli --log-cdr off 
	

	./ss7boost_cli --ckt-block --chan Y --span X
	./ss7boost_cli --ckt-unblock --chan Y --span X
	

	./ss7boost_cli --ckt-report --span 0 --chan 3
	

	./ss7boost_cli --ckt-report --span all --chan all
	

	./ss7boost_cli --ckt-report --span 1 --chan all
	

 
[root@localhost ss7box]# ./ss7boost_cli --ckt-report --chan all --span all
ckt-report begin
   span:  0  chan cfg inuse inrst rhb lhbs lhbm lhbc lhbr rmb lmb
              0   n   -     -     -   -    -    -    -    -   -
	      1   Y   n     n     n   n    n    n    n    Y   n
	      2   Y   n     n     n   n    n    n    n    Y   n
	      3   Y   n     n     n   n    n    n    n    Y   n
	 

Conformance

Product Plan

Overview ss7boost is Xygnada Technology's implementation of an M3UA application server (AS). This application server hosts an ISUP engine that is part of the Sangoma Signal Media Gateway. The application server also hosts SCCP applications like the CNAM Proxy Server and an SMS router. The ISUP engine is currently managed as an basic and integral part of ss7boost. The SCCP applications are managed as separate plug-ins under their own product plan. In the future, ISUP and SCCP applications will both be managed as plug-ins. The features in each release stream are documented below: Contents * Overview * Plan for Future Releases * Plan and Release Notes for 1.0 o 1.0 Plan o 1.0.1 Release Notes + Patch 00 (2007-10-02 Tu) + Patch 03 (2007-10-03 We) + Patch 04 (2007-10-10 We) + Patch 08 (2007-10-11 Th) + Patch 09 (2007-10-12 Fr) + Patch 12 (2007-10-15 Mo) + Patch 15 (2007-10-19 Fr) + Patch 18 (2007-10-27 Sa) o 1.0.0 Release Notes + Patch 00 + Patch 10 + Patch 11 + Patch 13 + Patch 14 + Patch 16 (2007-09-18 Tu) + Patch 17 (2007-09-18 Tu) * Plan for 0.2.x * Release Notes for 0.2.x o 0.2.95 + Patch 02 + Patch 03 o 0.2.94 o 0.2.92 o 0.2.91 o 0.2.90 o 0.2.89 o 0.2.88 * Plan for Future Releases * Past Releases 0.1.x * Omitted Features Plan for Future Releases * Automatic restart * Clustering * Operation with redundant ss7box configuration * Expanded SMS support (may become separate wireless product) Plan and Release Notes for 1.0 1.0 Plan * gcc 4 support * Call Redirection * Hardware Blocking * Group Circuit Blocking/Unblocking reception * Group Circuit Reset reception * CLI circuit reset * Suspend/Resume 1.0.1 Release Notes Patch 00 (2007-10-02 Tu) * some cgxx DEBUG messages replaced with log warnings * all ckts busy local vs remote distinguished Patch 03 (2007-10-03 We) * add suspend/resume procedure; T6 in /etc/ss7box/tgX_isup_timers.conf is used Patch 04 (2007-10-10 We) * change BCI charge and access values to chraging and isdn respectivelyh Patch 08 (2007-10-11 Th) * add Redirecting Number NADI, Presentation, and Number Plan info to RDNIS string; see Call Redirection for more information Patch 09 (2007-10-12 Fr) * catch and ignore suspend and resume message during T6 expiry processing Patch 12 (2007-10-15 Mo) * Warning for call entering middle stop process * Catch and process call stop from MG in call suspend state * Warning for MG event arrival for call in middle_stop_2 state Patch 15 (2007-10-19 Fr) * INR/INF processing for calling party address Patch 18 (2007-10-27 Sa) * local hw block route set/clear - code added not tested * ISUP call redirection bug fixes * house-cleaned some debug clutter * per t/g configurable tranmission medium requirement for outbound calls * spare field in redirection info set to zero 1.0.0 Release Notes Patch 00 * ss7boost has been fielded tested long enough to change revision level to 1.0.0 * redirection work still underway * adapted to gcc 4.1.1 * per trunk group calling party category configuration Patch 10 * redirection without transparent parm passing field tested; works as designed; more requirements found Patch 11 * comm port to ss7box is SCTP protocol Patch 13 * redirection kludge; change redirection_indicator from "no_redirection" to "unused" so that a non-zero value appear in the field, thus forcing the redirection procedure to run even though the telco has indicated no redirection is occurring; it satisfies a odd situation in HK * SCTP port to ss7box Patch 14 * removed release cause translation; release cause in sigboost messages is a Q.850 value now Patch 16 (2007-09-18 Tu) * hw block development * CGxx development; CGB/CGU reception works; CGxx sending works for unit testing Patch 17 (2007-09-18 Tu) * remove sangoma_mgd stop control from ss7boost init Plan for 0.2.x * automatic installation * automatic start/restart * CIC gap support * support for n E1/T1 per platform * ISUP timers * Per trunk group configuration of SIO priority and network indicator * high call volume robustness * International Gateway Switching o Method 1 + Specify called number NADI using a Structured Trunk Group Value + Specify calling number NADI statically with user configuration per trunk group o Method 2 + Add/remove NADI in dialplan as prefix to calling/called numbers on all inbound/outbound ISUP calls * Per Trunk Group Configurations o Calling Party Address NADI o MTP3 SIO Priority and Network Indicator for ISUP MSU * reset circuit on abnormal conditions * ISUP CON message support * SUS/REL o Q.764 handling of reception o option to treat SUSpend as RELease * Remote CDR Event Logging * Circuit Blocking Support o Maintenance Local/Remote o Circuit Status Reports + Static Information + Dynamic Information * Continuity Testing o Circuit Continutiy Request (CCR) Reception o IAM, Nature of Connections, CC on Previous Circuit * Calling Number Presentation and Screening Pass-Through * Command Line Interface ss7boost_cli o verbose logging on/off o CDR on/off o block/unblock ckt o ckt status report * ITU GSM support o SMS support * Automatic Call Gapping * Calling Party Number Presentation/Screening support * Network/User Calling Number support * Call Redirection Support Release Notes for 0.2.x 0.2.95 Patch 02 * added per t/g options to allow/disallow TMR 3.1 KHz and TMR Speech Patch 03 * clean up isup_decode code 0.2.94 * CCR support * static calling NADI per trunk group fixed * cdr logger has option to output to stdout from the daemon * France Telecom ITX/TXA * 3 digit NADI prefix feature for international gateway applications * support for 16 trunks, 16 trunk groups, 16 trunks/tg * support for hex digits A-F in dialed digit strings * CDR logger supplied with span/chan for every message except call start outbound * ss7boost sets its own nice to -15 internally during init * hearbeat to mgd function fixed * mgd is sole controller of all-ckt-reset now * SCTP used to communicate with mg * mg communication congestion monitored * single channel block/unblock fixed * automatic call gapping * ACM BCI called party status set to subscriber free * ITU: reject calls with TMR != SPEECH * controls for continuity indication and tmr added to IAM building API; still using hard-coded values for these controls, however * ISUP timer 17 fixed * calling number presentation/screening fixed 0.2.93 * CPG call progress being decoded * glare bug on outbound abandon fixed * SMS o SMS dev for collecting actual message text o msg string sent out UDP port o conf ready o accepting DCS of 0x00, 0xf0, 0xf1, 0xf2, 0xf3 * CDR call stop entries are made now * BLO/BLA/UBL/UBA unit testing fixes * CLI ckt-block and ckt-unblock now accept "--chan all" * added number prefix option to pass NADI info for clg/cld for inb/outb using a prefix digit on all cld and clg digit strings; prefix digit is NADI value 0.2.92 * ckt-block command is recognized; handling code is being written * manual decode of SMS samples in msu_workbench.c * decoding SMS in 09 mobile app in sccp_scrc.c * print_sccp decode debug aid built in * special app, filtering, decoding SMS SUBMIT and sending ack 0.2.91 * SCCP enhancements for processing ANSI/ITU called party address * SCCP improved handling of GTT for ITU * msu_workbench pokes 3 SMS submit MSUs * applied new functions for extracting packed BCD digit strings from ISUP and SCCP parameters * blocking doc. additions 0.2.90 * t/g span list now requires the string "begin" at the beginning of the span list in each trunk group entry 0.2.89 * toss out IAM with too many digits in calling/called party address * toss out SAM with too many digits in subsequent digits parm 0.2.88 * bci changes from 09mobile testing * ckt-report * warning if COT is required on inb call * specific warning on receipt of continuity messages * handling for NATURE OF CONNECTION, CONTINUITY = 2 (wait until upstream COT is finished) * t/g calling number NADI config Plan for Future Releases * Hardware ckt blocking * Media gateway cluster support * Redundant ss7box support * number translation services o select t/g from config. subscriber carrier choice o select t/g from prefix digits o config patterns for national, international numbers * call forwarding support: pass through of these parms in the IAM: Redirecting number, redirecting reason, original called number, called party address, calling party address * CLI ISUP timer change * configuration tools * additional ISUP message support as needed * CNAM support * LNP support * Free call support Past Releases 0.1.x * SS7 link configuration o F-link (1 link, done) * ss7boost ISUP state machine o basic call + inbound # ANSI # ITU + outbound # ANSI # ITU o suspend msg reception, action not implemented o call progress reception, action not implemented o reset ckt + reception + sending o reset ckt group + reception - message rcvd, action not implemented o boost restart + stop all sangoma_mgd calls + RSC all ckt o sangoma_mgd restart + RSC all ckts o ckt blocking/unblocking + blocking reception - message rcvd and ackd, action not implemented + unblocking reception - message rcvd and ackd, action not implemented o ckt group blocking/unblocking + ckt group blocking reception - message rcvd, action not implemented + ckt group unblocking reception - message rcvd and ackd, action not implemented Omitted Features * Sending Circuit Group Reset * Sending Circuit Group Block * Sending SUSpend/RESume * Continuity Test Sending

Overview

The CDR logger collects signaling event reports from multiple instances of ss7boost. The events are stored in a flat file in the order in which they are received. The information in the flat files can be read into an RDBMS for report generation and long term storage. CDR Logger and the RDBMS should run on a machine that is physically different from any of the the SMG feeding it information so that logging, sorting, and reporting does not impact the real-time performance of the SMG.

Features include:

• Built in configurable periodic file rotation.

• Collects information from multiple SMG.

• CSV format output files are compatible with spreadsheets and databases.

• Configurable location and file name prefix for CDR files.

• Fine grained epoch-based time-stamps

Installation

The CDR Logger is installed in the /ss7box directory as part of the SMG installation process. Verify that the cdr_logger binary file is in /ss7box and the the cdr_logger.conf file is in /etc/ss7box.

CDR Logger may run on a separate machine and collect information from a multiple ss7boost instances. To do this, you must create /usr/src/ss7box directory on the new machine and copy cdr_logger to this directory. You must then create /etc/ss7box on the new machine and copy cdr_logger.conf to this directory on the new machine.

Configuration

The contents of the CDR Logger configuration file is as follows:

 
# This is the cdr_logger.conf file used by cdr_logger.
# Copyright (c) 2006 Xygnada Technology, Inc.

[CONNECT]
# Opposite config should be used by CDR event pushers like ss7boost and
# sangoma_mgd
#
#       Local
#       address                 port
192.168.1.141           55011
#       Remote (don't care, not used)
#       address                 port
192.168.1.202           55011

[OUTPUT]
# CDR file path and prefix              file rotate period (minutes)
/usr/local/ss7box/cdr/cdrfile-          30
	 

The ss7boost.conf CDR section is related to this application.

Operation

1. Start the CDR Logging daemon.

   	# cd /ss7box
   	# ./cdr_logger
   			

2. Start CDR ouput on ss7boost

   • Manually using the CDR Logging control CLI command described in the CLI section of the ss7boost User Manual.

   • Automatically using the auto-start control in the [CDR] section of ss7boost.conf as described in the ss7boost User Manual.

3. Verify functioning

   1. Examine the contents of /var/log/messages on the CDR Logger machine to see the report on opening the CDR file.

   2. Verify calls are being made through SMG. Place some tracer test calls.

   3. List the detailed contents of the subdirectory for CDR files; ensure the CDR file is growing as calls are being made.

   4. Edit the current CDR file to review the contents. Search for evidence of test calls that might have been made.

CDR Log File Format

The CDR log file is a sequence of lines where each line is a set of comma separated values. Each lines corresponds to a call event in ss7boost. There are four line types:

• Callstart

• IAM

• Common

• Release

Call Event Field Reference mt - message type md - message direction sy - system id y - year mn - month d - day h - hour m - minute s - second sn - call serial number es - epoch timestamp seconds esu - epoch timestamp micro-seconds cs - call state cd - call direction su - csupid, call setup id tg - trunk group sp - span ch - chan ci - circuit id code dc - called number digit count dd - called number digits gc - calling number digit count gd - calling number digits gpi - calling number presentation indicator rc - release cause Call Event Record: Callstart Message Type: 128 mt md sy sn y mn d h mi s es esu cs cd 128 1 1 0 2006 09 29 10 23 17 1159420 54085 0 1 Call Event Record: IAM Message Type: 1001 mt md sy sn y mn d h mi s es esu cs cd su tg sp ch ci dc dd gc gd gpi 1001 0 1 0 2006 09 29 10 23 17 1159420 5414 0 0 1 0 0 0 1 4 1111 4 2222 0 Call Event Record: Common Message Type Value a 130 d 131 b 1012 c 501 mt md sy sn es esu cs 130 1 1 0 1159467526 590026 2002 501 1 1 0 1159467531 593045 1009 1016 1 1 0 1159467532 158290 1009 131 0 1 0 1159467532 158398 1009 Call Event Record: Release Message Type: 1012 mt md sy sn es esu cs rc 1012 0 1 0 1159467531 593128 1009 16 Creating Call Records The CDR Logger files are designed to be imported to a spreadsheet or database for storage, sorting, and reporting. A call report is created by first sorting on the system id (sy), then by the epoch time (es/esu), and then by the call serial number (sn). This will group the calls by system, time, and call. The call start time, end time, and duration are derived by using the calendar date/time and epoch times. Schema Example The call event records can be parsed in to a dB using a schema as shown in this section. mt md sy sn y mn d h mi s es esu cs cd su tg sp ch ci dc dd gc gd rc 128 1 1 0 2006 09 29 10 23 17 1159467520 54085 0 1 - - - - - - - - - 1001 0 1 0 2006 09 29 10 23 17 1159467520 54124 0 0 1 0 0 0 1 4 1111 4 2222 130 1 1 0 - - - - - - 1159467526 590026 2002 1012 0 1 0 - - - - - - 1159467526 590064 2002 501 1 1 0 - - - - - - 1159467531 593045 1009 1012 0 1 0 - - - - - - 1159467531 593128 1009 1016 1 1 0 - - - - - - 1159467532 158290 1009 131 0 1 0 - - - - - - 1159467532 158398 1009

Installation

Hardware Installation 1. Install a Sangoma A102 or A104 card in a Linux box. A box that has a faster CPU and a lot of memory is better since ss7mon is a user space application. A 1 GHz CPU and 512 MB RAM box is sufficient. 2. Build a Monitor Tap Cable. 3. Insert the ss7mon E1/T1 tap cable in the circuit that will be monitored. Do not plug the monitor taps into the ss7mon ports at this time. 4. Ensure the SS7 link is working.

Software Installation 1. Get latest smginstall package and put in /usr/local and untar 2. cd /usr/local/smginstall-(version) 3. ./smginistall ss7mon 4. Verify wanrouter version 5. Verify Sangoma driver installation by asking it to report on cards that it can see using "wanrouter hwprobe".

Configuration

1. Disable Hotplug services for wanpipe drivers. 2. Create configuration for wanpipe1 and wanpipe2 from template files 1. cd /etc/wanpipe 2. cp wanpipe1.conf.mon wanpipe1.conf 3. cp wanpipe2.conf.mon wanpipe2.conf 3. Modify ss7mon Wanpipe Configuration File if needed 4. Edit wanrouter.rc so that WAN_DEVICES="wanpipe1 wanpipe2" 5. Verify wanpipe operation 1. /ss7box/Tail 2. wanrouter start 3. Verify that both wanpipe1 and wanpipe2 started 4. wanrouter stop 5. /ss7box/Tail off 6. Modify ss7mon Configuration File

Operation

Starting ss7mon 1. Ensure tap cables are connected to ports 1 and 2 of the Sangoma card. 2. cd /ss7box 3. Start ss7mon * Console interactive mode with MSU decode and FISU summary reports: # ./ss7mon -i --decode --fisu * Background mode with MSU decode and FISU summary reports: # ./ss7mon --decode --fisu * Help: # ./ss7mon -h * Version: # ./ss7mon --ver

Stopping ss7mon * If operating in console interactive mode, use ctl-c. * If operating in background 1. ps axj | grep ss7mon 2. kill (pid of ss7mon)

Low Impedance Interference Sangoma cards are low impedance devices. When they are used as a passive monitor with the monitor tap cable, they may interfere with normal operation of the circuit under observation. If the observed link will not go into service with the tap cables inserted into ss7mon, then remove the tap cables and get the observed link running. Then reconnect the tap cables to ss7mon and determine if both ss7mon and the observed circuit function simultaneously. For critical applications, consider using powered transformer-based high impedance taps.

Finding the SS7 Channels 1. Turn on option for bitstream capture for full E/T carrier # Card Name Number Frame/Packet Clear Chan. b/s harvest Channels/Frame 1 50 n y 24 # Card Name Number Frame/Packet Clear Chan. b/s harvest Channels/Frame 2 50 n y 24 2. Run ss7mon cts-knpl-ss7:/usr/local/ss7box# ./ss7mon_a_2.1.23_knpl -v -i Two files will be produced: bs_span_0 and bs_span1 where bs_span_0 is from the interface card defined near the top of the conf file (Card 1 in the example above), and bs_span_1 is from the interface card defined near the bottom of the conf file (Card 2 in the example above). 3. hexdump bitstream file cts-knpl-ss7:/usr/local/ss7box# hexdump -f hd.conf bs_span_1 ......... 100f8 ff ff ff ff ff ff ff ff 8d 9f ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10110 ff ff ff ff ff ff ff ff c0 bf ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10128 ff ff ff ff ff ff ff ff 98 e1 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10140 ff ff ff ff ff ff ff ff a6 ed ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10158 ff ff ff ff ff ff ff ff fe 82 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10170 ff ff ff ff ff ff ff ff c8 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10188 ff ff ff ff ff ff ff ff fa b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 101a0 ff ff ff ff ff ff ff ff 8d 9f ff ff ff ff ff ff ff ff ff ff ff ff ff ff 101b8 ff ff ff ff ff ff ff ff c0 bf ff ff ff ff ff ff ff ff ff ff ff ff ff ff 101d0 ff ff ff ff ff ff ff ff 98 fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff 101e8 ff ff ff ff ff ff ff ff a6 c2 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10200 ff ff ff ff ff ff ff ff fe db ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10218 ff ff ff ff ff ff ff ff c8 85 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10230 ff ff ff ff ff ff ff ff fa f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10248 ff ff ff ff ff ff ff ff 8d e1 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10260 ff ff ff ff ff ff ff ff c0 be ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10278 ff ff ff ff ff ff ff ff 98 fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10290 ff ff ff ff ff ff ff ff a6 fc ff ff ff ff ff ff ff ff ff ff ff ff ff ff 102a8 ff ff ff ff ff ff ff ff fe 85 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 102c0 ff ff ff ff ff ff ff ff c8 b7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 102d8 ff ff ff ff ff ff ff ff fa 8b ff ff ff ff ff ff ff ff ff ff ff ff ff ff * Leftmost column is octet offset from beginning of file * Remaining columns each contain the octet streams in each channel; the second column from the left is channel 1 and the rightmost column is channel 24 * There are hexdump format files for T1 and E1 provided # Find a repeating pattern of 7 octets in a column; this corresponds to the stream of FISU on an SS7 link; take the column number and subtract one to get the ss7mon channel number # Repeat procedure for bs_span_0 and bs_span_1 # Edit /etc/ss7box/ss7mon.conf and turn on monitoring for the resulting channels # Turn off bitstream capturing in /etc/ss7box/ss7mon.conf

Interpreting the Output