ss7box

Wanpipe Install Problem Fixed

2011-12-15T11:17:00.000-05:00

Got this problem. Fixed it. Don't think it's important. It took a lot of time....wasted time....to figure all of this out.

Compiling WANPIPE API Development Utilities ...Failed!

ERROR: Failed to compile WANPIPE API Tools !!!
Please contact support at Sangoma Technologies
email: techdesk@sangoma.com
Please include the file setup_drv_compile.log

Let's see if we can get some detail:

[root@ana64 api]# cd /usr/src/Sangoma/wanpipe/api

[root@ana64 api]# make

make -C tdm_api

make[1]: Entering directory `/usr/src/Sangoma/wanpipe-3.5.12/api/tdm_api'

Ok.

make[1]: Leaving directory `/usr/src/Sangoma/wanpipe-3.5.12/api/tdm_api'

make -C legacy

make[1]: Entering directory `/usr/src/Sangoma/wanpipe-3.5.12/api/legacy'

make -C x25 all APIINC=/usr/include/wanpipe

make[2]: Entering directory `/usr/src/Sangoma/wanpipe-3.5.12/api/legacy/x25'

Ok.

make[2]: Leaving directory `/usr/src/Sangoma/wanpipe-3.5.12/api/legacy/x25'

make -C chdlc all APIINC=/usr/include/wanpipe

make[2]: Entering directory `/usr/src/Sangoma/wanpipe-3.5.12/api/legacy/chdlc'

cc -Wall -O2 -D__LINUX__ -D_DEBUG_=2 -D_GNUC_ -I../lib -I/usr/include/wanpipe -o chdlc_modem_cmd chdlc_modem_cmd.c ../lib/lib_api.c

chdlc_modem_cmd.c: In function 'handle_socket':

chdlc_modem_cmd.c:412: error: 'wp_api_hdr_t' has no member named 'error_flag'

make[2]: *** [chdlc_modem_cmd] Error 1

make[2]: Leaving directory `/usr/src/Sangoma/wanpipe-3.5.12/api/legacy/chdlc'

make[1]: *** [all] Error 2

make[1]: Leaving directory `/usr/src/Sangoma/wanpipe-3.5.12/api/legacy'

make: *** [all] Error 2

Problem is with legacy chdlc - not using it. This is why this problem can most likely be ignored. Nevertheless, the fix follows. First, we look for a replacement for the offending "error_flag" field that's not defined.

[root@ana64 api]# grep -r "wp_api_hdr_t\;" ../* | grep "\.h\:"

grep: warning: ../patches/kdrivers/include/linux: recursive directory loop

../patches/kdrivers/include/wanpipe_api_hdr.h:} wp_api_hdr_t;

grep: warning: ../patches/kdrivers/wanec/linux: recursive directory loop

[root@ana64 api]# vi ../patches/kdrivers/include/wanpipe_api_hdr.h

[root@ana64 api]# vim ../patches/kdrivers/include/wanpipe_api_hdr.h

This looks promising:

/* CHDLC Old backdward comptabile */

#define wp_api_rx_hdr_chdlc_error_flag wp_api_rx_hdr_error_flag

Let's apply a change:

[root@ana64 api]# cd /usr/src/Sangoma/wanpipe/api/legacy/chdlc/
[root@ana64 chdlc]#

Create a file called "patch" and fill it with the following:

--- chdlc_modem_cmd.c 2011-12-15 17:05:20.000000000 -0500
+++ chdlc_modem_cmd.c.chg 2011-12-15 17:16:06.000000000 -0500
@@ -409,7 +409,7 @@
return;
}

- switch (api_rx_el->api_rx_hdr.error_flag){
+ switch (api_rx_el->api_rx_hdr.wp_api_rx_hdr_error_flag){

case 0:
/* Rx packet is good */

Apply the patch:

[root@ana64 chdlc]# patch --ignore-whitespace < patch

patching file chdlc_modem_cmd.c

Now compile the api:

[root@ana64 chdlc]# cd /usr/src/Sangoma/wanpipe/api

[root@ana64 api]# make

Problem should be gone. There will be tons of warnings depending on the gcc version you are using. As long as you don't see "error" in the output it should be fine.

Cluster Configuration Needs To Improve

2011-12-13T10:52:00.000-05:00

Adding a cluster node to the lab this morning. The lab is currently working using older versions of ss7box/SMG. This configuration needs to remain intact. The new cluster being added will be the development tip alpha test site.

It takes a lot of coordinated data to make it work because that's how the protocol works. The smgcfg tool attempted to simplify the task and it did to some extent but plenty of feedback says we can do better.

Using a spreadsheet helps to make things visual and colorful, but downloading .csv and running smgcfgXX against it is kludgy. Two tools and manually pushing files is not good. I'm getting reintroduced to the problem this morning.

A better approach would be to use a single tool that is aware of a group of nodes and a library of configurations. The user interface needs to be efficient for users that want to use vi to edit a source file, a command line for lean systems with no X11 stuff loaded, and a command line IF that accommodates a web interface. A diagramatic interface showing nodes and connections that allows click-to-query-or-modify would be helpful. All of these interfaces should be supported interchangeably, for example, if one person wants to use vi on a source file and another wants to use the CLI or web interface (not at the same time), then it should be possible - because the CLI is a specialized source file editor and the web interface uses the CLI. Of course, using vi to edit the source file could screw things up if the format is disturbed. Ideally the CLI interface will not have this problem. Furthermore, the CLI would have prompts like: add a link to a linkset, or add a trunk to a trunkgroup, or a powerful add a node. These prompts would lead the user through the collection of information needed. Maybe the tool could generate a graphical representation output from input data as a precursor to using a graphical representation as an input.

Here's something interesting. Whatever gets built, most of it is general purpose for all SS7 networks regardless of what equipment or protocol is being used. Distinctions about specific equipment like ss7boxd, isupd, and sccpd are made in the final steps where specific conf files are created and pushed or pulled from specific nodes. Sounds like an open source project.

Lab Expansion Problem and Fix

2011-12-10T17:00:00.001-05:00

The lab is expanding to support cluster configuration testing again. We use old versions of Dahdi, Asterisk and Linux because we only like change in our own code. So when we upgraded a Centos 5 system, we ran into the following problem:

CC [M] /usr/src/dahdi-linux-2.2.0.1/drivers/dahdi/xpp/card_bri.o
In file included from /usr/src/dahdi-linux-2.2.0.1/drivers/dahdi/xpp/xpd.h:31,
from /usr/src/dahdi-linux-2.2.0.1/drivers/dahdi/xpp/card_bri.c:29:
include/linux/device.h:407: error: expected identifier or â(â before âconstâ
make[3]: *** [/usr/src/dahdi-linux-2.2.0.1/drivers/dahdi/xpp/card_bri.o] Error 1
make[2]: *** [/usr/src/dahdi-linux-2.2.0.1/drivers/dahdi/xpp] Error 2
make[1]: *** [_module_/usr/src/dahdi-linux-2.2.0.1/drivers/dahdi] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.18-274.12.1.el5-PAE-i686'
make: *** [modules] Error 2

After trying to solve the problem as though something was missing, we had the insight that maybe something was being redefined. Centos back ports lots of stuff into its 2.6.18 and at the same time, Dahdi does some of its own back porting. We think we found duplicate back porting of the same item. The back ported item in the Dahdi package was eliminated and the problem went away. The patch is as follows:

--- /usr/src/dahdi-linux-2.2.0.1/drivers/dahdi/xpp/xdefs-orig.h 2011-12-10 11:41:12.000000000 -0500
+++ /usr/src/dahdi-linux-2.2.0.1/drivers/dahdi/xpp/xdefs.h 2011-12-10 11:23:25.000000000 -0500
@@ -139,7 +139,7 @@
ssize_t name(struct device_driver *drv, char * buf)

#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,26)
-#define dev_name(dev) (dev)->bus_id
+//#define dev_name(dev) (dev)->bus_id
#define dev_set_name(dev, format, ...) \
snprintf((dev)->bus_id, BUS_ID_SIZE, format, ## __VA_ARGS__);
#endif

Quite a relief. Now on to installing the media and signal gateway applications, drivers, and patches. We are creating a four-box cluster configuration with duplex signal gateways and two media gateways. We'll start with a two-box configuration composed of a signal gateway and a media gateway. We'll suspend system growth so that we can use this new system to establish the current functionality of the call detail recording system in isupd. After this assessment we'll plan to fix any deficiencies in the CDR system. Then we'll add another media gateway to the system. After that, we'll detail the steps needed to convert a in-service simplex signal system cluster to a duplex signal system cluster. Then after that, we'll repeat the process at a live commercial 14-box operation.

Clustering Improvements in ss7box

2011-12-08T15:20:00.001-05:00

ss7box is an end node. It does not perform the transfer function. Let's make that clear.

ss7box clustering allows several CIC ranges to be supported by several call engines. ss7box and the call engines communicate over an IP network. The association of a CIC range to a call engine worked fine as long as a unique local/remote address:port tuple was used. It makes sense to reuse the same address tuple for different CIC ranges handled by the same call engine. Unfortunately, it didn't work. Even more unfortunately, the problem was flagged but the system was allowed to continue operating. It would have been better to halt ss7box and force the problem to be fixed.

While fixing the CIC range association problem, some sloppy coding was identified and fixed in the socket creation tools too.

We're back!

2011-12-07T19:35:00.001-05:00

Work on ss7box is resuming. Found a problem with clustering and circuit group messages. It's possible to receive a circuit group message for a range of CICs that span across multiple cluster nodes. Currently, the code assumes circuit group messages can and will be parochial to a single node. The circuit group message handler must be redesigned to handle any possible range of CICs on any number of nodes.

ISUP Circuits Stay in Quarantine State

2009-11-09T10:44:00.002-05:00

> Dear Mr. ss7box,
>
> Can you give me some insight into what theses messages are telling me:
>
> Nov 9 15:12:45 tele2ss7 sangoma_isupd[21182]:
> W:sb_cmm.c:cmm_quarantine_ckt:CQ_WAIT_TIMER:go back to
> CQ_WAIT_SG:span/chan/event_id/caller follow:10:22:1019:8
> Nov 9 15:12:45 tele2ss7 sangoma_isupd[21182]:
> W:sb_cmm.c:cmm_quarantine_ckt:CQ_WAIT_TIMER:go back to
> CQ_WAIT_SG:span/chan/event_id/caller follow:10:19:1019:8
> Nov 9 15:12:45 tele2ss7 sangoma_isupd[21182]:
>
> Puzzled

Dear Puzzled,

My first guess is that the remote side is not responding to our reset circuit messages. If this goes on long enough the circuit will be quarantined and stay in the quarantined state until the remote side answers our resets.

Sometimes this happens because the NI and PRIO values in MTP3 for ISUP on our side are not matched to those of the remote side. You can check this by using /ss7box/ss7box_cli --show msu on and looking in /ss7box/msu.log. Examine the inbound and outbound messages for a particular point code pair and ensure that the NI and PRIO values are the same.

If the values are the same then you'll most likely need to work with the remote telco to find out why they are not responding to the circuit reset. The telco on the remote side may or may not care about helping you, and it may be a function of their ability to help you.

If the values are different then make necessary changes to the NI and PRIO columsn for this trunk group in the ss7boost section (soon to be renamed the isupd section) of the configuration spreadsheet and use the smgcfg tool to make a new sangoma_isup.conf. Apply the new conf and see if problem is resolved.

Six SMG Project Status

2009-10-30T09:19:00.000-04:00

Since June I've been building a set of six servers to run SMG. A major goal of this project is to deliver 6 SMG servers fully configured and tested so they are ready to run out of the box. Two of the boxes have shipped and presumably are doing well. The four remaining boxes have been a challenge. Two Intel motherboards had to be replaced. One of the two was replaced twice, and the second replacement was to an ASUS board which is now in my warranty replacement inventory.

I specified Intel CPU, fans, and motherboards thinking that a single brand system must have been system tested. My doubts started upon assembling the first system and seeing the Intel fan attachment mechanism causing the motherboard to bow slightly. Then I started getting random kernel oops, panics, and freezes on the 5th box. I had to go through the Intel RMA process to get a replacement but not without a fight. At first, Intel rejected my claim and said that I damaged the board, and offered to sell a new board to me at a reduced cost. After some discussion Intel kindly reversed their position and replaced the board at no cost to me.

As I was waiting for the Intel RMA, I purchased a 7th board to move the project ahead. This board worked for a few days and then began failing with the same random kernel oops, panic, and freeze. Since this purchase was recent I was able to have the board exchanged at Tiger Direct without any problem. I built up box 5 using board 7. It wasn't long before it failed similarly. When I returned to Tiger Direct for yet another replacement I found that they had sold out of this board completely. I exchanged it for an ASUS board and had to buy DDR2 memory because the Intel board used DDR3 memory.

The Intel RMA board arrived and has been working well. The ASUS board is on the shelf because I didn't want to spend time working with an odd board when the project is very late already. I purchased a Thermaltake fan when I bought the ASUS board. This fan causes no board deformation. I will replace the Intel fans in boxes 3-5 with Thermaltake fans on the hunch that fans causing board deformation is the root cause of the board problems, and to simply eliminate the undesirable deformation.

Box 6 has a failed power LED. This is an annoyance. Had I quality checked all components as soon as I received them I wold have been able to get a complete box exchange at the store. My options now are to RMA the box with the manufacterer, fix the LED, or purchase a new box. I will attempt to fix the LED first.

Another unexpected problem became evident after building the first box. The analog cards were long and top heavy and had a PCI-e1 connector. I estimated that these boards might fail during shipping because of stresses on the connector. I also observed the boards sagging under their own weight. To alleviate the stress and sagging during shipping and operation, I devised and constructed a support sytem made of Lexan and aluminum shown here.

Early tests showed noticeable heat build-up in the boxes. Investigation led us to understand that the three analog cards in each box dissapate a lot of heat continuously. All six boxes have case fans added to their specifications.

The original project plan called for placing two patch panels in a desktop rack. When the user received the first two boxes and one of the patch panel racks, he saw that having one patch panel per rack offered more flexibility. The project will now include three additional racks for a total of six desktop racks: three 4U and three 2U.

The project plan has been enahnced to include a 4 box daisy-chain configuration and a 'Y' configuration. The plan was also improved to include bulk call testing using SIPP.

The project documentation will use textual, graphical, and video media.

The current status of the project is:

boxes 1 and 2 are shipped and working on site
boxes 3-6

are built and showing signs of long term stability
analog lines are working
require daisy-chain and Y configuration building and testing
require bulk call testing
require shipping to site

box 6 requires power LED repair
box 3-5 require CPU fan change out
2U patch panel acquisition and preparation
video capture and edit of setup, operation, installation, configuration
.pdf documentation

sangoma_sccpd Passes Heartbeat Test

2009-10-29T16:35:00.003-04:00

The sangoma_sccpd daemon is running and heartbeating with ss7boxd:

[root@ana3 ss7box]# ./xps
10978 -15 ss7boxd
11531 -15 sangoma_isupd
11536 -5 sangoma_mgd
11613 -15 sangoma_sccpd
9891 0 asterisk

It is sending a heartbeat to ss7box. The heartbeats from isupd and sccpd are recognized by ss7boxd who sends a heartbeat ack to each entity. Hearbeats from isupd are ack'd to isupd, and heartbeats from sccpd are ack'd to sccpd. Here are some logs:

First we see the SS7 links are up:

Oct 29 16:38:41 ana3 ss7boxd[10978]: R:link util:ls 0:link 1:msu oc 34:tot oc 162000:util 0
Oct 29 16:38:41 ana3 ss7boxd[10978]: R:link util:ls 0:link 2:msu oc 34:tot oc 162000:util 0
Oct 29 16:38:41 ana3 ss7boxd[10978]: R:link util:ls 1:link 1:msu oc 34:tot oc 162000:util 0
Oct 29 16:38:41 ana3 ss7boxd[10978]: R:link util:ls 1:link 2:msu oc 34:tot oc 162000:util 0

Then we see an inbound heartbeat from isupd (SI=5):

Oct 29 16:38:43 ana3 ss7boxd[10978]: I:mtp3_l4_m3ua.c:handle_asp_state_msg:M3UA_MT_ASPSM_BEAT:si/index/msg-type:5:0:3

Next we see an inbound heartbeat from sccpd (SI=3):

Oct 29 16:38:46 ana3 ss7boxd[10978]: I:mtp3_l4_m3ua.c:handle_asp_state_msg:M3UA_MT_ASPSM_BEAT:si/index/msg-type:3:0:3

We then confirm that the heartbeat ack was sent from ss7boxd to sccpd:

Oct 29 16:38:46 ana3 sangoma_sccpd[11613]: I:core.c:analyse_sg_0_heartbeat_ack:MARK:0

And finally, we see the process repeating continuously:

[root@ana3 ss7box]# Oct 29 16:38:49 ana3 ss7boxd[10978]: I:mtp3_l4_m3ua.c:handle_asp_state_msg:M3UA_MT_ASPSM_BEAT:si/index/msg-type:5:0:3
Oct 29 16:38:51 ana3 ss7boxd[10978]: I:mtp3_l4_m3ua.c:handle_asp_state_msg:M3UA_MT_ASPSM_BEAT:si/index/msg-type:3:0:3
Oct 29 16:38:51 ana3 sangoma_sccpd[11613]: I:core.c:analyse_sg_0_heartbeat_ack:MARK:0
Oct 29 16:38:54 ana3 ss7boxd[10978]: I:mtp3_l4_m3ua.c:handle_asp_state_msg:M3UA_MT_ASPSM_BEAT:si/index/msg-type:5:0:3
Oct 29 16:38:56 ana3 ss7boxd[10978]: I:mtp3_l4_m3ua.c:handle_asp_state_msg:M3UA_MT_ASPSM_BEAT:si/index/msg-type:3:0:3
Oct 29 16:38:56 ana3 sangoma_sccpd[11613]: I:core.c:analyse_sg_0_heartbeat_ack:MARK:0
Oct 29 16:38:59 ana3 ss7boxd[10978]: I:mtp3_l4_m3ua.c:handle_asp_state_msg:M3UA_MT_ASPSM_BEAT:si/index/msg-type:5:0:3

Twick or Tweet

2009-10-27T20:54:00.002-04:00

Twitter has allowed me to return. I suppose I'll continue using it for microblogging the daily stuff.

sccpd and it's sister isupd are the twin daemons that came from splitting ss7boost into two separate functions. This project has been crawling along since May of this year, but it's finally become a top priority. isupd is fully separated operational and is part of the most recent stable SMG release. sccpd will require a new revision of ss7boxd. Anybody wanting to try out the tip development releases of sccpd should expect some updates to ss7boxd along the way. We're planning on getting most of the ss7boxd changes completed soon so that disturbances at the MTP3 levels are minimized.

The four box 48 hours stability test is still running and will be complete in about 12 hours from now. So far, this is the longest run ever for all 4 boxes. Intel motherboards have been a challenge. Intel silicon is fine. My spare motherboard inventory has been converted to ASUS already.

Dead Bird

2009-10-27T11:30:00.003-04:00

Twitter won't let me in. No more tweeted status updates for now. Guess I'll go back to old-fashioned blogging.

The four box, 48 hour stability test passed the 24 hour mark this morning.

I've got a Sony video camera for documenting SMG procedures. I downloaded a video file for the first time this morning and found that Windows Media Player would not play the sound. Then I downloaded VLC Media Player which just worked with the MPEG2-PS files produced by the camera. Now I'm looking at video editing tools starting with CyberLink PowerDirector. I don't want to spend much time with this, so the first tool that just works will be the winner. (Follow up. This was hard and not much fun, but I finally managed to produce a video. I think I know enough now to make a useful video.)

This afternoon I'll complete the lab setup for sccpd testing and hopefully complete the first sccpd tests.

Normalcy Returns

2009-10-15T11:34:00.002-04:00

It's been crazy busy since June. We delivered ss7box redundancy, 32 E1/T1 SMG, and some significant bug fixes. We're also working on a couple of unusual special projects that have resisted efforts to keep them on plan. Mix in several personal catastrophes requiring on-going time demands, and presto: crazy busy.

Thank you to everyone that had to wait longer than expected for promises fulfilled and support.

The good news is that things are settling down. The SMG product is showing itself to be on solid ground and we are now committed and able to support releases without requiring users to jump up to using development tip releases. The special projects are headed toward completion and the long-promised sccpd project is back on track.

What lies ahead? More intuitive configuration methods for networks and nodes. A continuous high volume testing program with more variance and talk path testing. Increased focus on sccp and related applications. Exposure of protocol layers using API's.

Thinking vs. Debugging

2009-07-14T09:35:00.003-04:00

It happened again. I was working on redundant ss7box yesterday. When I launched the second ss7box there were lots of route audit log messages. Odd because ISUP was not running so there should not have been any route audits. How could I have screwed up so badly?

I got up and walked away. I did not return for over twelve hours. In that time I realized that I was not clear on how to configure redundant ss7box yet. Maybe the configuration was screwed up.

This morning I confirmed that the problem appeared as soon as the new redundant ss7box was started. I looked closely at the ss7box configuration and found that the same port number for sockets to the ISUP layer had been used on both ss7boxes. I found a new configuration rule.

This find strengthened the thought I had yesterday that configuration definition is still too complicated and redundant. Getting the configuration correct is difficult for me, so it will be impossible for a normal user.

This experience demonstrates the importance of taking time to think as part of the debugging process. Setting breakpoints and adding print statements are important too. What's more, it's active debugging. It shows that you are doing something. On the other hand, thinking is passive. It's often done while you are doing something else. It looks like goofing off. It's not. It's probably the most powerful debugging technique that I have. I first heard about it in engineering school at the University of South Carolina from Dr. Pettus. I've found my own way to what he was talking about. It takes a while to get there.

Problems are usually not solved on a time line or according to a deadline. If they are, they can be forced and awkward. Taking time to think through a problem and letting the solution come naturally according to function of the brain doing the thinking is valuable. My brain does not arrive at solutions well under high stress. It won't find any solutions when there's a lack of stress. Finding a tolerable balance of stress is the key.

ss7box: New Features, New Lab

2009-06-05T13:26:00.004-04:00

ss7box is getting a lot of attention lately. Three new features are being developed simultaneously: redundancy, sccp routing, and support for a fiber interface. To support this development, significant changes to the Xygnada lab are required. Figure 1 below shows the build plan.

Figure 1

The nodes ana3 and ana62 will host a mated pair of redundant ss7box acting as a single point code. ana3 will host Asterisk, SMG, ISUP, SCCP, and a CNAM application that is capable of being both a client and a server. ana19 will be a clustered ISUP node using SS7 services from ana3 and ana62 with a new twist - it will have a point code that differs from the redundant ss7box pair. It will also host Asterisk and SMG. ana17 will be a single node instance of asterisk/SMG/ss7box. The dt node will be dedicated to SCCP and related applications with CNAM client/server being the lead-off application. This node will also serve as a developer workstation and regression test platform to support integration of a fiber interface into ss7box. In the middle, nodes ana60 and ana61 provide MTP3 transfer services like those found in STPs.

The lab configuration creates quite a few functional interactions and raises the overall lab complexity so that we can get more test coverage and carry out development in several areas simultaneously. Changing the lab is labor intensive and work in other areas stops as a result, so it's not done as often as needed. In this case, we could no longer put off the pain of changing the lab because progress had come to a halt.

The ana3, ana62, ana60, ana61, and ana17 nodes had been working together prior to the change. The dt node has been under construction for a while. It took a while to find the right version of opensuse (10.2) to work with the fiber interface libraries. Then it took more time to figure out that its A102c interfaces are incompatible with the modern SMG/ss7box so an upgrade to A102SH was required. The SS7 linkset between dt and ana60 was put into service today. What remains is to put the dt-ana61 linkset into service, create ana19, and reconfigure ana62 into an SMG/ss7box node from its current status as an SMG-only clustered node.

Configuration Changes

2009-05-27T10:07:00.003-04:00

We are moving away from hand editing SMG configuration files, and moving toward using the smgcfgXX.py tool. XX is the version. We are currently using 01 and working on 02 now.

The tool uses a .csv file as input and the output are the wanpipe, ss7box, and ss7boost conf files. The .csv file comes from the export function in any spreadsheet program.

We support googledocs spreadsheets:
http://spreadsheets.google.com/ccc?key=rzeNA2SoiXKhaKX7Y9t2keg&hl=en

The smgcfgXX.py program is a Python script and is included with each SMG release.

We are working on an improvement where the smgcfg.py script will read the revision number in the .csv file and use the corresponding smgcfgXX.py script to continue processing.

ss7box Redundancy Explained

2009-05-13T14:56:00.011-04:00

Two ss7box are better than one as is usually the case in SS7 networking. If one fails or needs to be worked on, the other carries the load and there's no interruption in operations. The next question is, "How will that work?"

The first thing that's needed is a two-link linkset as shown in Figure 1 below. The links need to be in two separate E1/T1 spans. Each span is connected to Sangoma wanpipe port on a separate Linux box. Each Linux box is running an instance of ss7box. This is the F-Link setup most often found in ITU networks.

Figure 1

In Figure 2 the left hand SSP from Figure 1 is shown as an Sangoma SMG implementation using redundant ss7box. ss7box and SMG communicate using SCTP/IP. SMG communicates with Asterisk using TCP/IP and UDP/IP. SMG can receive from either ss7box at any time. SMG sends to the pair of ss7box using a load balancing scheme. If one of the links to an ss7box is lost, or if an ss7box is lost or is under maintenance, then the full signaling load is handled by the remaining ss7box. When the second ss7box returns to service, load is automatically balanced between both ss7box.

Figure 2

ANSI networks and some ITU networks use redundant signal transfer points (STPs) to interconnect signaling terminations like signal switching points (SSPs) as shown in Figure 3. In this type of network there will be a combined linkset between an SSP and a mated pair of STPs. A combined linkset, in its simplest form, is a pair of single-link linksets. The SSP connects to both linksets. Each STP in the mated pair connects to one of the two linksets. The same rules

Figure 3

In Figure 4 the SSP from Figure 3 is shown as an Sangoma SMG implementation. The same rules regarding load balance, fail-over, and fail-back listed for the F-link configuration above also apply to this A-link (or combined linkset) configuration.

Figure 4

Redundant ss7box; GRS and Configuration Improvements

2009-05-05T09:38:00.006-04:00

ss7box redundancy is the next big feature in the works. Now that SMG clustering is in the field and working, some larger systems are being designed. As predicted, those system designers quickly spot a single ss7box as a single point of failure. The solution is to deploy two ss7box acting as a single entity - so called redundancy. If one ss7box is lost then operations continue without interruption.

A redundant ss7box configuration minimizes interruptions during upgrades because one ss7box can serve on-going operations while the other is off-line and being updated. Then the updated ss7box serves operations and other ss7box is updated. Finally, both updated ss7box are put online and normal redundant operations resume.

We found a flaw in GRS processing in the past two weeks. The fix required enhancing GRS processing so that each trunk group has its own GRS queue. The ehancement is used if GRS processing gets stuck in ss7boost and the remote end keeps repeating requests for GRS. In this scenario, GRS requests are queued and after N queued GRS, the GRS queue overflows. When this happens, the GRS queue is cleared, all circuits in the trunk group associated with the GRS queue are put into quarantine, and subsequent GRS for the trunk group are ignored until all circuits in the trunk group have exited quarantine. The persistent nature of the GRS protocol ensures that a GRS will arrive after the GRS queue clearing protocol has completed. As ss7boost matures, more of these complex, self-healing protocols are being implemented which make SMG more robust and reliable. I makes SMG easier to use and maintain for users and support staff.

The smgcfg.py script is helping users and support staff create, update, and maintain SMG configurations. With the introduction of SMG clustering it became evident that hand editing text configuration files was unwieldy. With smgcfg.py the entire configuration for a node is entered in a single spreadsheet tab. We are using Googledoc spreadsheets to enable editable sharing of SMG configuration spreadsheets on a worldwide basis.

Check out the Twitter feed on this blog. Small increments of progress are reported in that media stream

Transparent IAM Passes Unit Testing

2009-03-13T09:40:00.002-04:00

The transparent IAM feature works in the unit test environment. We are now working on enlarging the ISUPinRDNIS buffer in the sigboost callstart message to 900 octets. This change also demands that we convert to passing dynamically sized callstarts. At the same time we are adding a new field to the sigboost messages to indicate the version of sigboost a particular message adheres to. This is a safety mechanism for when sigboost interfaces are used by parties outside the closely associated original developers (CAOD). More than likely it will serve the CAOD well too.

We're struggling with installing some 3rd party protocol stacks in opensuse 11.1. It appears that the stack maintainers have not kept their products in step with recent major Linux distros. The job of sorting out the mess falls to me and this is not my strong suit. I am happy to learn as I go but others waiting on me would prefer to forego the learning and move directly to the doing part. I agree with them but find myself unable to comply.

CNAM work is bubbling up to the top. This time around we will be able to finish the project. I am refreshing myself on the code and I'm devising what the first step is restart this dormant project.

Some new features are being added to the list. One is providing trunk group and circuit status up to the Asterisk command line. Another is to add a session id to inbound ISUP calls to improve management of callstop and callstopack messages that arrive late and out of context. Comparing the session ids of messages to session ids of circuits will improve identification of messages that are useful, useless and discardable, or nonsense. The improvement will be that some messages are identified as safely discardable instead of confusing. If a message is confusing it can lead to a circuit being quarantined, which means a valid call might be disconnected, and the circuit becomes unavailable for use for several minutes.

Transparent IAM Front and Center

2009-02-26T20:07:00.002-05:00

The transparent IAM project has stepped into the priority 1 position because of a deadline in early March for a test of number portability in France.

March 15 looms large - .us corporate tax returns are due then. Then April 15 follows for .us person tax returns. These are unyielding distractions.

The transparent IAM feature now sends and receives stringified IAMs in the ISUPinRDNIS string that is copied to the the Asterisk RDNIS channel variable. Transparent IAM processing is optional per trunk group. The last big thing to do before releasing the feature to field test is to develop a new outbound transparent IAM parser. This new parser is aware of how to pick apart the outbound transparent IAM and use the harvested parts to assemble a new IAM. Here is the process being considered. The term sIAM is short for "stringified IAM" which is another term for the transparent IAM.

1. CIC value is determined by trunk group specified by dialplan and
the outbound hunt algo. in ss7boost
2. message type is IAM
3. fixed mandatory variables are taken from the sIAM
4. called number taken from dialplan
5. calling number taken from dialplan
6. redirection parms built from RED parms in ISUPinRDNIS from dialplan
if present, else take from sIAM if present
7. generic number parm built from GEN parms in ISUPinRDNIS from
dialplan if present, else take from sIAM if present
8. add on all other optional variable length parms in sIAM that have
not been used or overlayed already

This plan has been reviewed and approved by a reliable partner and user in France so it's a good bet that this will be very close to what's needed.

New SMG Release and Configuration Change Proposal

2009-01-28T13:11:00.005-05:00

There will be a new SMG release today or tomorrow. The follow entry from the release notes summarize what to expect:

Patch 32 (2009-01-28 We)
* call processing, ISUP Transmission Medium Requirement pass to/from
Asterisk CALLTYPE channel variable via the sigboost callstart message
in the bearer.capability field found in sigboost.h
* Sangoma driver 3.3.15.6 required
* CMM, bug fixed, a span was being reported as clear and ready when the logs
indicated the ckt reset requests were being ignored by the telco; fix made
sure the ckt report showed the ckts in reset under this condition
* smgcfg.py, bug fix, numeration of formated wanpipe xmtp2 interface names
corrected
* transparent IAM, new feature work in progress, code added that does not
affect operations yet

As mentioned in a recent post here, the current method of configuring the association of span/chan to CIC and trunk group is too restricted. A new method is needed that allows configuring CIC and trunk group for each individual span/chan. But this approach might mean having to fill out a table for 16 E1s for a total of 496 entries. Since it is rare that individual control of all 496 span/chans is needed, then supporting configuration language that allows table minimization will be useful.

An example of explicit per channel configuration would be as follows:

Span	Chan	CIC	Trunk Group
0	0	1024	0
0	1	1025	0
0	2	1026	0
0	5	1027	0
0	6	1028	0
0	7	1029	0

Here is an example of minimizing language that accomplishes the same thing:

Span	Chan	CIC	Trunk Group
0	0-2.5-7	1024	0

Here's a slightly different example done explicitly:

Span	Chan	CIC	Trunk Group
0	0	1024	0
0	1	1025	0
0	2	1026	0
0	5	1029	0
0	6	1030	0
0	7	1031	0

And the same configuration using minimizing language:

Span	Chan	CIC	Trunk Group
0	0-2	1024	0
0	5-7	1029	0

There will also need to be a similar configuration technique to assign specific span/chans SS7 linkset, link, and SLC (noting that in ss7box, the link is always equal to the SLC value). Any span/chan in the CIC/trunk group table must not appear in the SS7 linkset/link table, and vice-versa.

Span	Chan	linkset	link and SLC
0	15	0	0
2	15	1	0

There will be no table minimization language used with the linkset/link table at this time.

CMM Bug Fixed Tonight

2009-01-21T21:27:00.002-05:00

Found that a span was being reported as clear and ready when the logs indicated the reset requests were being ignored by the telco. Problem found and fixed in the Circuit Maintenance Manager. Confirming tests should be completed tomorrow.

Sangoma SMG Cluster Working

2009-01-20T14:57:00.002-05:00

Multiple Asterisk/SMG using a single ss7box access point is delivered and working. Field trials are now underway.

Working on Transparent IAM for ported number handling in several countries. This feature pushes a copy of an inbound IAM into the dialplan. If the dialplan decides that the next leg of the call is an SS7 outbound call and IAM transparency is needed, then the copy of the inbound IAM is passed down to ss7boost where it will be used to construct an outbound IAM that is very similar to the inbound IAM. This is done to preserve information in the IAM when a call is forwarded, redirected, or ported.

Working on Transmission Media Requirement being mapped to and from the dialplan CALLTYPE per call variable.

ISUP T9 is implemented in ss7boost now. It was being handled with the Dial function timeout but this solution failed to pass several conformance tests where the release cause was expected to be 19. The Dial timeout was consistently delivering 16 as the release cause.

A major rework of the span/chan assignment of CIC and trunk group is planned. Currently simplifying assumptions are made about these assignments in a effort to reduce work done during configuration. The loss of flexibility from the current system is no longer tolerable, so a new system where each span/chan is explicited assigned a CIC and trunk group will be implemented.

A new configuration system is being rolled out where all SMG configuration parameters for wanpipes, MTP2, MTP3, and ISUP are entered into a single spreadsheet. The spreadsheet is then converted into a .csv file and fed into a new tool called smgcfg.py. This tool converts the information in the .csv file into the .conf files expected by the various component programs in SMG. The longer vision is to manage system configuration at a level above the spreadsheet so that engineers are specifying configurations using standard terms and language labels instead of using tables and indexes and coordinating information. Eventually, the tools will decompose humanly understandable configuration terms into the .conf file terms expected by the programs.

Product plans for 2009 for the SS7 part of Sangoma SMG include redundant ss7box, continuous operation upgrades, and SIGTRAN support.

A Second Quarter of Reliability, Performance, and Capacity

2008-07-28T05:54:00.000-04:00

It's been a while since the last entry. Since that time the focus has been on managing 500+ circuits when four critical resources are lost and recovered. Those four resources are: signal gateway (ss7boxd), media gateway (sangoma_mgd), SS7 route, and bearer channel spans (E1 or T1).

Initial designs were found to be flawed when taken to high capacity test and some field trials. Two revisions followed and now the basic design is settled. The system, called Circuit Maintenance Manager (CMM) is now undergoing high capacity test and field trials. It currently supports loss/recovery of signal gateway, media gateway, and SS7 routes. The bearer channel span management function is ready for development now that underlying support is available from the Sangoma device driver as of this past week.

The CDR Logger is under going a change. The points in ss7boost where information is injected to the logger has been reduced and is now coupled tightly to the ss7boost message input/output functions and timer function. This change ensures no loss of info to the logger. The call serial number field is no longer provided because it did not make sense in some situations. Log entries are correlated into circuit event using the call setup id , span/chan and timestamps for outbound calls, and span/chan/timestamps for inbound calls. The reason for the change is that CDR Logger began as a tool for creating call records only but has also been valuable as a protocol analyser. The older logger missed some messages events which were not important to creating CDRs but were important for protocol analysis. The new logger improves the analyser function while retaining the call record creation function.

Another activity this summer has been load testing with 16 E1 loaded fully with 30 second calls. A number of bugs were found and fixed and the overall quality has improved noticeably.

There are now two release versions of SMG: stable and beta. This is more work but the time has come to provide options for SMG users. Stable releases will only receive small fixes and now new features. Beta releases will contain all fixes and new features. Stable releases that are closed will be reproducible. This marks a significant change from the past when development was much faster and installations were smaller and more change tolerant. As SMG has become more stable, users have indicated the SMG must change in a more controlled manner.

SMG ANSI installations are growing and bring new challenges. The circuit continuity test appears to be used more often in these locations. The procedure is slightly different from the ITU method. The final stage of COT reception functionality for four-wire circuits is being completed to comply with requirements from a major western USA service provider.

The third quarter 2008 will see initial development, testing, and field trials of the long awaited clustering function where asterisk boxes are clustered around an SMG box (already available) and SMG boxes are clustered around an ss7box box. Following cluster development will be the re-introduction of ss7box redundancy.

Other features in the works are expanded conformance testing and expanded ISUP parameter decoding. In particular are the calling party category and the generic number parameters. Asterisk does not have a convenient container for the many ISUP parameters so SMG is sneaking the information in and out of Asterisk using a char long string.

New MTP and ISUP Features

2008-04-10T12:11:00.000-04:00

SMG/ss7box has been accepted into a major telecom network in North America.

The ss7boost Circuit Maintenance Manager (CMM) is functional in the field now. It is managing the blocking and resetting of circuits with respect to ss7boost restart, and the presence and absence of the media gateway interface (sangoma_mgd). In the coming weeks CMM will be managing circuits with respect to the presence/absence of SS7 routes, the signaling gateway (ss7box), and trunks (E1/T1 facilities).

ss7box now supports Management Inhibit reception sufficient to pass the limited conformance tests being administered in ITU-land. Management Inhibiting is used in conformance testing and rarely in operations. The procedure is complicated in some configurations. More time is being devoted to developing features for conformance tests lately.

ss7box will be supporting the reception of MTP Restart procedure in the upcoming week.

ss7boost now supports GRS reception fully. The circuits being reset are actually reset. ss7boost also now supports the CQM/CQR procedure and the ANSI CCR process.

Group Reset Reception Processing

2008-03-17T09:47:00.005-04:00

The time has finally come where it is no longer possible to avoid developing the ill-specified Group Reset (GRS). Our siege of the GRS was broken while SMG was undergoing conformance testing in Belgium. We knew this day would come and it's good that we could hold out as long as we did, because the time has allowed the general approach to circuit maintenance in ss7boost to mature and improve to handle many circuits under stressful conditions. We are ready to implement GRS reception. We continue to resist implementing GRS sending for reasons we offer in detail at the end of this article.

The base ss7boost 1.0.2.x is in lab test and has passed calls in both directions. This revision has the first working version of the Circuit Maintenance Manager for queueing and executing requests for circuit reset, block, and unblock. The CMM is required as the base for developing GRS reception processing to ensure compatibility with the new circuit maintenance model in ss7boost.

GRS reception processor decomposes the request into individual circuit reset requests that are each then submitted to the CMM. The CMM queues the requests and manages sending the reset requests to the core circuit reset reception handler (CCRH). The CCRH performs maintenance actions and then passes the request to call processing where the the concerned circuit is handled for reset based on its current state. The final reset action in the CCRH is to acknowledge the completion of the circuit reset. Currently the ackowledgement is a Release Complete (RLC) message sent in response to a Reset Circuit (RSC). ss7boost will be modified to conditionally send an RLC or a completion indication to the GRS processor. This approach will eliminate the need to modify the call processing state machine, which eliminates a significant amount of regression testing to a core function that has approximately 1.1 million hours of field verification time.

Our dislike of the GRS comes from the awkward specification of the Range and Status parameter. The format and coding of the parameter changes if it is being used in a GRS, CGB, or CGU, It also changes if it is being used in ANSI or ITU SS7 flavors. In some instances, it allows up to 30-ish circuits to be affected in a group of up to 256 circuits. This means that it's possible to receive a GRS with a status containing a 256 bit status field with each bit needing to be test for 0 (not affected) or 1 (affected). The Range field assigns meaning to the values 0, 1, and n>1, and if n>1 is used, then the actual count of affected circuits in the Range is n-1. The GRS processor must search of allocate a variable number of octets in the Range. The Range and Status field has a very high degree of variability which drives up the numbers of exceptions and test cases. A great deal of code must be written and tested for the exceptions. The possibility of partial success exists with the GRS, the processing of which is not specified clearly.

The cost versus the benefit of the GRS in a small and distrubuted ISUP implementation like ss7boost is not favorable. Using the RSC for each individual circuit make smuch more sense because the implementation is straightforward. In a large switch with large trunk groups, the GRS makes sense. Most samples of GRS harvested from the field show a restricted and rational use of the GRS in that circuit groups are in the same E1/T1. It is our opinion that the idea of the GRS is good, the specification is too broad and uses tricks to save a bit of space.

Our implementation of the GRS reception will be based on our field samples and a sub-set of the specifications that minimizes the number of exceptions that will be handled. If our GRS reception processor encounters a GRS that is legally forms and yet exceeds the limits we impose, it will rejected and announced. We will consider remedies if this should occur, but we are betting it will never occur.

Merging ss7boost Development Streams

2008-03-05T10:41:00.000-05:00

For a while now there have been two ss7boost code streams: stable and development. The stable stream is a repository branch and the development stream is the repository tip. The development stream insulated users from the difficulties of building the Circuit Maintenance Manager. The development stream has reached functional parity with the stable stream in terms of circuit management, and the development stream needs to be tested in the field. The time has come to merge the stable and dev ss7boost streams.

The merge is complicated because the two streams have been apart for several months. A wholesale "diff -up stable dev > patchfile" followed by a "patch -p0 <>

ss7box and MTP3 Route Management

2008-02-01T12:05:00.000-05:00

ss7box has a partial implementation of MTP3 route management. Route management is needed when ever SS7 linksets are connected to a signal transfer point (STP). The ss7box implementation needs to be advanced for passing network acceptance testing, automatic restart, and improved fault tolerance. Up to this point, ss7box has not been connected to an STP where route management has been a critical issue. STPs tolerate nodes that ignore route management messages which also supports why the implementation is incomplete. As is often the case with ss7box, things changed suddenly this week, and now having a more complete route management is important.

Route management in MTP3 consists of procedures and messages per ITU Q.704 Section 13 Signalling Route Management:

TFA - allow traffic to route
TFP - prohibit
TFR - restrict, don't allow unless no better choice to reach destination
TFC - controlled, for communicating congestion levels
SRST - signal route set test for asking and STP about the status of a route
SRSC - signal route set congestion test for asking an STP about the congestion status of a route

In ss7box, route management is already designed and implemented at the core of the ss7box routing mechanism. The route management values assigned to each linkset are initialized to TFA and are never changed, but the values are checked for every outbound MSU passing through ss7box. Inbound route management messages are being decoded. These functions have been thoroughly tested in the field.

Inbound route management messages need to affect the route table and the values from the route table need to affect the related status of each linkset. If a route becomes completely unreachable, ss7box needs to send out a Destination UNAvailable (DUNA) M3UA message to all connected ss7boost clients. Conversely if a destination becomes reachable, a Destination AVAvailable (DAVA) M3UA message needs to be sent.

A signaling route set test procedure needs to be implemented to periodically query an STP that has prohibited a destination on its linksets to see if the prohibited destination is available.

A tool is needed to inject and receive route management messages for unit testing in the lab. This will most likely take the form of ss7box_cli commands for injection. In the lab two ss7box will be connected back-to-back. One will be the device under test (DUT) and the other will be the tester. The cli commands will be issued on the tester to the DUT. Messages from the DUT will be captured and decoded n the tester using normal ss7box route management procedures with some added debugging code.

The route set congestion messages and procedures will not be supported at this time as they are options in the spec and not frequently encountered.

Bug Found in ss7boost_cli --ckt-block

2008-01-31T16:49:00.000-05:00

A bug was found with the ss7boost CLI commands:

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

The logs for the unblock follow:

Jan 31 22:46:08 acc05 ss7boost[9831]: I:sb_mpc.c:sg_bsm_unblock_sending:MARK:0
Jan 31 22:46:08 acc05 ss7boost[9831]: I:sb_mpc.c:sg_bsm_wait_uba:MARK:0
Jan 31 22:46:08 acc05 ss7boost[9831]: W:sb_mpc.c:sg_bsm_wait_uba:SS7 event id not expected:event id follows:2

Using block and unblock with individual circuits works:

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

This problem will be fixed in next major revision of ss7boost because the entire circuit maintenance method has been redesigned as mentioned in the previous post on this website.

No fix will be made in the following revisions and below:

Xyganda Technology, Inc. ss7boost Revision 1.0.1-25 (and any 25 branch revs like 25.2+)
Xygnada Technology, Inc. ss7boost Command Line Interface, Version: 1.0.1-01

Circuit Maintenance Manager and Bug Fixes

2008-01-21T16:48:00.000-05:00

The maintenance of voice circuits in ISUP in ss7boost is being overhauled. Currently, call processing and circuit maintenance initiate circuit resets and blocks directly without any coordination. As hardware blocking design evolved it became apparent that circuit maintenance needed centralized management. The central maintenance manager (CMM) controls the resetting and blocking of all ISUP voice circuits - 496 maximum presently - per node. Each circuit has a maintenance action request queue. The CMM is dormant until queues are loaded and a trigger is pulled. The CMM checks all queues processing N circuits every M seconds until all queues are empty. Then the CMM returns to its dormant state.

The CMM code is written to a point that initial unit testing has begun. The number of test cases needed to verify operation looks to be high so unit testing with the ss7boost unit tester is a huge time saver.

There are a number of upgrades and configuration changes on-going so support work is spiking this week, which slows down CMM testing. This is exactly what makes predicting when large features will be ready very difficult. It's the nature of the business.

Speaking of unit testers, sangoma_mgd now has its own unit tester apparatus. A number of bugs got stomped this past December as a result of using it.

We caught and killed bugs in sangoma_mgd and ss7boost last week. In sangoma_mgd there was a case where a call ended and was not propogated to ISUP. In ss7boost we found that some sigboost messages from sangoma_mgd to ss7boost were not being properly entered in to the ISUP CDR log. Also in ss7boost we found that the "SMGRev-" prefix was not attached to inbound RDNIS strings in Asterisk/Callweaver. A new SMG release is out today that delivers the fixes - ftp://ftp.sangoma.com/linux/smg/smginstall-2008-01-21.tgz

New Look for ss7box.com

2008-01-20T14:31:00.000-05:00

ss7box.com has a slightly new look. It is designed for rapid maintenance and moving as a defense against web hosts that suddenly and unexpectedly terminate service. It is also designed for optimal use as a technical user manual since that is its primary purpose. The design is embedded in a cascading style sheet.

We are back on blogspot

2008-01-02T12:03:00.000-05:00

The wiki experience was OK until the web host went out of business. All the material is written in tikiwiki format and stored in an SQL database. I know next to nothing about tikiwiki administration and SQL databases. I also found that not all web hosts provide tikiwiki.

So, I revert to web 1.0. I will use HTML and docbook. The nice thing about docbook is that the same source will produce HTML or PDF. Since many ss7box users are charged per minute for Internet access, the wiki has not been the best documentation option for them. They are better served by downloading a PDF document that they can refer to repeatedly at no extra charge. Docbook is also a good system for porting content from one web host to another as they seem to be a transient.

New ss7box blog location

2006-10-08T14:52:00.000-04:00

The ss7box blog has moved to the wiki because some people cannot reach the blogger.com website.

SMG High Capacity Testing

2006-07-13T22:01:00.000-04:00

The Sangoma Signal Media Gateway continues to take a beating in the lab with five E1 continuously running at full capacity with short duration phone calls. Quite a few problems have been shaken out and the limits of the particular machines being used are showing. System engineering rules have also been developed as a result of this testing program. The test grow to support eight E1 and a third SMG in the near future.

The ss7box wiki is newly revamped with improved product plan sections. Have a look to see what's in store for SMG.

ss7mon will be called upon to examine working SS7 links as part of recent changes to our method of operation for replacing existing systems. Experience teaches that reported configuration information and actual configuration can differ. By using ss7mon we will be able to verify configuration parameters before swinging service to a new system. ss7mon will also let us measure the health of the existing system before putting a new system into service. ss7mon uses the same hardware as ss7box and uses a simple passive tap cable and couplers to access the working SS7 circuit. A brief service interruption is required to install the circuit tap.

ss7box Wiki Finds New Home

2006-06-04T00:00:00.000-04:00

The ss7box wiki has a new home at none other than the ss7box website. Things are still being reassembled from various repositories. We are looking forward to using the new wiki. It's time to refresh the product plan.

SMG New Release

2006-05-26T16:20:00.000-04:00

A new revision of Sangoma SMG is being released. This new revision is the result of extensive testing in the SMG bulk call generation lab in Toronto. This lab has proven itself capable of creating a punishing load similar to a unrelentless regional crisis. The systems under test were also misconfigured intentionally to increase the chance of circuit dual seizure occuring. In order to survive in the test, some parts of the SMG had to be redesigned and optimized. This was not surprising after it was done, but figuring out where the redesigns were needed was a difficult process. The latest release of SMG is solid foundation on which to continue building this product.

New installations are keeping us busy. The installation process in much closer to being fully automated now with the release of the smginstall tool in the latest SMG release. Some of our regional representatives are using the tool to successfully install and run SMG at customer sites.

Sadly we must report a HDD failure on the host of the ss7box Wiki. Alternatives are being considered and this tool should return to service before long. Backups were made. We are just not sure how fresh they are.

Currently we are working on expanding ISUP support to the lesser used messages. We are starting to see regional differences and operator differences. We are working with multiple linkset and multiple trunk group configurations now. We have a distributed SS7 presence experiment on-going and we are working on media gateway clustering capabilities. There's a lot to do but we are making forward progress daily and the results are tangible.

Bulk Call Testing Underway in Lab

2006-04-20T13:56:00.000-04:00

The Sangoma SMG is undergoing bulk call generation testing in the lab. This battery of tests allows measurement of capacity, system load, endurance, accuracy, and reliability. In the past week since starting to use this test system, the problem find/fix rate has increased significantly. Also noticable is the elevated confidence felt by system designers and testers.

The bulk call tester was conceived and built in-house. It already has the ability to test Release 2 SMG systems having multiple networked call processing nodes. The system is easy to use and can be controlled remotely so that a geographically diverse development team can all control the test system as though they were in the same room with it.

Nanad Corbic, Chief Software Manager of Sangoma Technologies, Inc. says, "With the bulk call tester we expect to test SMG configurations handling 3000 or more circuits at very high levels of utilization. Already we see demand for SMG systems of this size."

SMP-Safe Queues Rule

2006-03-16T08:20:00.000-05:00

Spinlocks are out, SMP-safe queues are in. All sites have been upgraded and have been running for several days without interruption.

Spinlocks, like any semaphore, should be avoided if possible - or so the conventional wisdom goes. And we understand a bit more about why it is considered conventional wisdom now.

SMP-safe queues have mutually exclusive read and write methods so that both operations can occur simultaneously. In our MTP2 implementation there is a single reader and writer for each of four queues. Three of the four queues are exposed to the potential for simultaneous reading and writing.

Announcing the Sangoma Signal Media Gateway

2006-03-08T17:07:00.000-05:00

The SS7 ISUP attachment to Linux based softswitches finally has a name: Sangoma Signal Media Gateway. We call it SMG for short. Having a product name makes conversations and documenting so much easier. Here's a link to a product description: http://sangoma.editme.com/wanpipe-linux-asterisk-ss7

Installations in Pakistan, Paraguay, Manilla, Rome, and Michigan are helping us hone the installation process and are getting efficient at finding quality issues (bugs). They are pushing us further and faster along than we would have on our own. Thanks and keep up the good work.

The kernel module MTP2 had a set of nasty bugs that were cured with restructuring the buffer management scheme and surrounding a few critical section in the code with spinlocks.

We have introduced a trouble ticket system to track bugs. We give users access to the system so they can check up on our progress and make sure we are staying focused.

We found that we'll need to support overlap signalling in the early release of the SMG. Several locations cannot mandate en bloc signalling. The specs are a little weak in specifying how overlap signalling should work. Thanks to some attentive and knowledgeable users we captured the information we needed to complete the requirements we need to implement overlap signalling.

We've been told repeatedly that serving multiple E1 installations is required immediately. We identified the key item preventing us from delivering this capability is automated testing. We didn't want to deliver a multiple E1 support until we tested hundreds of simultaneous calls on a lab system. So, we designed and, are currently building, a bulk calling lab. We are going to replicate smaller versions of this lab in several places. The main lab will be able to generate thousands of simultaneous calls, verify connections, and vary hold times.

MTP2 Performance Improved

2006-02-12T11:18:00.000-05:00

The Xyganda MTP2 has been under development (off and on for the past year) for migration from user space to kernel space to improve real-time performance. Sangoma engineering has been an intergral part of this effort by providing an efficient interface to DS0 bitstreams and incorporating MTP2 kernel module installation into the Sangoma driver installation toolset.

Recent tests in a major equipment vendor's lab revealed a kernel panic which was the result of the xmtp2km kernel module not supporting SMP environments. Redesign of local buffer allocation tools within xmtp2km eliminated some access contention situations, while other access contentions that could not easily be eliminated were streamlined and protected with spinlocks.

The improved xmtp2km has survived a 90 hour duration test under heavy and light traffic loads with 0% message loss or gain. The next step is to distribute the fix to the field and continue observation of the fix in those environments.

One benefit of fixing the xmtp2km problem is that we learned that the interface between the Sangoma driver and xmtp2km is very efficient. The Sangoma driver allocates a large pool of buffers for managing the bitstream flows between itself and xmtp2km. We have never seen more than one buffer in use at any time regardless of traffic loading on the link. We also we able to transmit and receive an +80% load on a link for over 12 hours at a time without a single occurence of link congestion onset/abatement. A relatively weak computer (a single 933 Mhz Intel CPU) was in use which adds weight to our findings. These observations indicate that the code is efficient and that real-time requirements are being met with a wide margin of safety.

ISUP and CNAM development came to a full stop while xmtp2km was being debugged. We apologize for the delays in the ISUP and CNAM projects and will resume development on these applications immediately.

Product Plan Updated

2006-01-13T22:11:00.000-05:00

The product plan for ss7box, ss7boost, and CNAM services has been updated on the wiki. Work on ss7boost/ISUP is centered on circuit maintenance (reseting, blocking, and unblocking). The circuit maintenance state machines take effort than those for basic call processing.

The Signal Media Gateway (SMG) product description is updated. A feature that allows multiple Asterisk platforms to be served by a simplex or duplex ss7box is described in more detail. Configurations needing more T1/E1 than can be hosting in a single Asterisk platform will be possible using this feature.

In CNAM development there has been a new configuration function developed to map global title translation types to a static function id. This involved creating a new configuration section in the ss7boost.conf file. This was necessary because there seems to be no consistent industry definition for GTT types. Testing with external databases will begin next week.

ITU Calls Working

2005-12-18T09:35:00.000-05:00

Inbound and outbound calls using ITU ISUP intermachine trunks (IMTs) are working in Pakistan and Paraguay. Efforts are now focused on completing circuit maintenance procedures and features needed for releasing version 0.0.1 of the Signal/Media Gateway (SMG) which is anticipated to be in January 2006.

SMG Version 0.0.1 supports a single E1/T1 IMT controlled with a single SS7 F-link in both ITU and ANSI environments. Future releases will increase interoperability, functions, features, capacity, performance, and reliability. The SMG product roadmap is being developed and will be announced here and on the ss7box wiki.

Inbound Calls on ITU SS7 IMT

2005-12-09T13:44:00.000-05:00

We are beginning to get some success with inbound calls on an ITU SS7 inter-machine trunk on a Siemens switch in Pakistan. An inbound call is one that originates from the PSTN and terminates on the signal/media gateway (SMG). In the output below we see that a message code of 0x05 came in which is ignored. This is the switch requesting a continuity test which is not supported yet.

Some inbound calls are released by the switch because of "unavailable resources". This is probably a transient condition resulting from circuit group unblocking messages from the switch being ignored by the SMG. A remedy for this problem will be available shortly.

S:mtp3_smh.c:print_msu:
SI 0x05 PRIO 0x0 NI 0x2
dpc 3000 opc 4424 sls 10
MARK < >
-------------------------------------------------------------------------
0000 e2 f1 3f 85 b8 0b 52 a4 - 1a 00 01 18 20 01 0a 00 ..?...R..... ...
0010 02 09 07 03 90 24 02 40 - 99 f9 0a 07 83 11 24 02 .....$.@......$.
0020 90 10 08 31 02 00 be 3d - 01 1e a4 0e 03 02 00 00 ...1...=........
0030 03 a4 20 00 05 38 38 85 - 10 74 1d 03 80 90 a3 39 .. ..88..t.....9
0040 06 a4 c0 31 c0 3d c0 00 - 5b a9 ...1.=..[.
-------------------------------------------------------------------------

--------> rmt addr: 127.0.0.43 rmt port: 50220
I:../common/udp_sockets.c:check_udp_socket:received a msg:length/function follow:88:1
I:sb_sg_sm.c:discrim_sgw_msg:MARK:0
I:sb_sg_sm.c:handle_m3ua_x4_msg:MARK:0
I:sb_sprc.c:sprc_inbound:MARK:0
I:msu_decode.c:msu_decode:MARK:0
I:msu_decode.c:handle_m3ua_isup_transfer_msg:MARK:0
CIC: 26
MSG TYPE: IAM
NATURE OF CONNECTION INDICATORS:
SATELLITE INDICATOR: 0x00
CONTINUITY CHECK INDICATOR: 0x02
ECHO CONTROL DEVICE INDICATOR: 0x01
FORWARD CALL INDICATORS:
INCOMING INTL CALL IND: 0x00
END TO END METHOD IND: 0x00
INTERWORKING IND: 0x00
END-TO-END INFORMATION IND: 0x00
ISDN USER_PART IND: 0x01
ISDN USER_PART PREFERENCE IND: 0x00
ISDN ACCESS IND: 0x01
SCCP METHOD IND: 0x00
SPARE: 0x00
RESERVED: 0x00
CALLING PARTY CATEGORY: 0x0a
TRANSMISSION MEDIUM REQUIREMENT: 0x00 (TMR interpretation not coded yet)
MANDATORY VLP:
NAME: CALLED PARTY NUMBER
LENGTH: 7
OCTET 0: 0x03
OCTET 1: 0x90
OCTET 2: 0x24
OCTET 3: 0x02
OCTET 4: 0x40
OCTET 5: 0x99
OCTET 6: 0xf9
---CdPA/CgPA DECODE---
NUMBER OF DIALED DIGITS: 10
NATURE OF ADDRESS INDICATOR: 0x03
SCREENING INDICATOR: 0x00
ADDRESS PRESENTATION INDICATOR: 0x00
NUMBERING PLAN: 0x01
DIALED DIGITS: 42200499915
OPTIONAL PARAMETERS - BEGIN
OPTIONAL VLP:
NAME VALUE: 0x0a - CALLING PARTY ADDRESS
LENGTH: 7
OCTET 0: 0x83
OCTET 1: 0x11
OCTET 2: 0x24
OCTET 3: 0x02
OCTET 4: 0x90
OCTET 5: 0x10
OCTET 6: 0x08
---CdPA/CgPA DECODE---
NUMBER OF DIALED DIGITS: 9
NATURE OF ADDRESS INDICATOR: 0x03
SCREENING INDICATOR: 0x01
ADDRESS PRESENTATION INDICATOR: 0x00
NUMBERING PLAN: 0x01
DIALED DIGITS: 422009018
OPTIONAL VLP:
NAME VALUE: 0x31 - PROPAGATION DELAY COUNTER
LENGTH: 2
OCTET 0: 0x00
OCTET 1: 0xbe
(No decode for this ISUP parameter)
OPTIONAL VLP:
NAME VALUE: 0x3d - HOP COUNTER
LENGTH: 1
OCTET 0: 0x1e
(No decode for this ISUP parameter)
OPTIONAL VLP:
NAME VALUE: 0xa4 - (parm name string not defined)
LENGTH: 14
OCTET 0: 0x03
OCTET 1: 0x02
OCTET 2: 0x00
OCTET 3: 0x00
OCTET 4: 0x03
OCTET 5: 0xa4
OCTET 6: 0x20
OCTET 7: 0x00
OCTET 8: 0x05
OCTET 9: 0x38
OCTET 10: 0x38
OCTET 11: 0x85
OCTET 12: 0x10
OCTET 13: 0x74
(No decode for this ISUP parameter)
OPTIONAL VLP:
NAME VALUE: 0x1d - (parm name string not defined)
LENGTH: 3
OCTET 0: 0x80
OCTET 1: 0x90
OCTET 2: 0xa3
(No decode for this ISUP parameter)
OPTIONAL VLP:
NAME VALUE: 0x39 - PARAMETER COMPATIBILITY INFORMATION
LENGTH: 6
OCTET 0: 0xa4
OCTET 1: 0xc0
OCTET 2: 0x31
OCTET 3: 0xc0
OCTET 4: 0x3d
OCTET 5: 0xc0
(No decode for this ISUP parameter)
OPTIONAL PARAMETERS - END
I:sb_toolbox.c:find_trunk_group:MARK:0
tg 0
I:sb_toolbox.c:convert_cic_to_span_chan:MARK:0
cic 26 cic_base 1 ncic 25 span 0 chan 26
I:sb_sg_cpc.c:sg_cpc:MARK:0
I:span 0 chan 26 tg 0 cic 26 sls 5 nd 10 cld 422004999? ng 9 clg 422009018 spc 3000 imt_pc 4424
I:sb_sg_cpc.c:sg_cpc_idle:MARK:0
I:sb_send_sigboost.c:send_call_start_to_mg:MARK:0
I:span 0 chan 26 tg 0 cic 26 sls 4 nd 10 cld 422004999? ng 9 clg 422009018 spc 3000 imt_pc 4424
I:sb_send_isup.c:send_acm_to_ss7box:MARK:0
I:span 0 chan 26 tg 0 cic 26 sls 4 nd 10 cld 422004999? ng 9 clg 422009018 spc 3000 imt_pc 4424
I:isup_event.c:send_canned_acm:MARK:0
Message from A/S, vlph_len 22 asmlen 6
0x1a 0x00 0x06 0x14 0x10 0x00
S:mtp3_smh.c:print_msu:
SI 0x05 PRIO 0x1 NI 0x2
dpc 4424 opc 3000 sls 4
MARK < >
-------------------------------------------------------------------------
0000 e2 f1 3f 95 48 11 ee 42 - 1a 00 06 14 10 00 0a 00 ..?.H..B........
-------------------------------------------------------------------------

I:../common/udp_sockets.c:check_udp_socket:received a msg:length/function follow:96:131
I:sb_mg_sm.c:discrim_mgw_msg:MARK:0
I:sb_mg_cpc.c:mg_cpc:MARK:0
I:span 0 chan 26 tg 0 cic 26 sls 4 nd 10 cld 422004999? ng 9 clg 422009018 spc 3000 imt_pc 4424
I:sb_mg_cpc.c:mg_cpc_inb_wait_ans:MARK:0
I:sb_send_isup.c:send_ans_to_ss7box:MARK:0
I:span 0 chan 26 tg 0 cic 26 sls 4 nd 10 cld 422004999? ng 9 clg 422009018 spc 3000 imt_pc 4424
I:isup_event.c:send_canned_ans:MARK:0
Message from A/S, vlph_len 20 asmlen 4
0x1a 0x00 0x09 0x00
S:mtp3_smh.c:print_msu:
SI 0x05 PRIO 0x1 NI 0x2
dpc 4424 opc 3000 sls 4
MARK < >
-------------------------------------------------------------------------
0000 e2 f1 3f 95 48 11 ee 42 - 1a 00 09 00 10 00 ..?.H..B......
-------------------------------------------------------------------------

S:mtp3_smh.c:print_msu:
SI 0x05 PRIO 0x0 NI 0x2
dpc 3000 opc 4424 sls 10
MARK < >
-------------------------------------------------------------------------
0000 e3 f2 09 85 b8 0b 52 a4 - 1a 00 05 01 9b 23 ......R......#
-------------------------------------------------------------------------

--------> rmt addr: 127.0.0.43 rmt port: 50220
I:../common/udp_sockets.c:check_udp_socket:received a msg:length/function follow:28:1
I:sb_sg_sm.c:discrim_sgw_msg:MARK:0
I:sb_sg_sm.c:handle_m3ua_x4_msg:MARK:0
I:sb_sprc.c:sprc_inbound:MARK:0
I:msu_decode.c:msu_decode:MARK:0
I:msu_decode.c:handle_m3ua_isup_transfer_msg:MARK:0
CIC: 26
MSG TYPE: 0x05 (print decode for this message type not developed yet)
W:msu_decode.c:handle_m3ua_isup_transfer_msg:ISUP message type not decodable yet:msg type follows:5
W:sb_sprc.c:sprc_inbound:msu_decode failed: ignore following value:0
I:../common/udp_sockets.c:check_udp_socket:received a msg:length/function follow:96:132
I:sb_mg_sm.c:discrim_mgw_msg:MARK:0
I:sb_mg_cpc.c:mg_cpc:MARK:0
I:span 0 chan 26 tg 0 cic 26 sls 4 nd 10 cld 422004999? ng 9 clg 422009018 spc 3000 imt_pc 4424
I:sb_mg_cpc.c:mg_cpc_inb_icc_answered:MARK:0
I:sb_send_isup.c:send_rel_to_ss7box:MARK:0
I:span 0 chan 26 tg 0 cic 26 sls 4 nd 10 cld 422004999? ng 9 clg 422009018 spc 3000 imt_pc 4424
I:isup_event.c:send_canned_rel:MARK:0
Message from A/S, vlph_len 21 asmlen 5
0x1a 0x00 0x0c 0x02 0x00
S:mtp3_smh.c:print_msu:
SI 0x05 PRIO 0x1 NI 0x2
dpc 4424 opc 3000 sls 4
MARK < >
-------------------------------------------------------------------------
0000 e3 f2 09 95 48 11 ee 42 - 1a 00 0c 02 00 23 0a ....H..B.....#.
-------------------------------------------------------------------------

S:mtp3_smh.c:print_msu:
SI 0x05 PRIO 0x0 NI 0x2
dpc 3000 opc 4424 sls 10
MARK < >
-------------------------------------------------------------------------
0000 e5 f3 09 85 b8 0b 52 a4 - 1a 00 10 00 67 8b ......R.....g.
-------------------------------------------------------------------------

--------> rmt addr: 127.0.0.43 rmt port: 50220
I:../common/udp_sockets.c:check_udp_socket:received a msg:length/function follow:28:1
I:sb_sg_sm.c:discrim_sgw_msg:MARK:0
I:sb_sg_sm.c:handle_m3ua_x4_msg:MARK:0
I:sb_sprc.c:sprc_inbound:MARK:0
I:msu_decode.c:msu_decode:MARK:0
I:msu_decode.c:handle_m3ua_isup_transfer_msg:MARK:0
CIC: 26
MSG TYPE: RLC
I:sb_toolbox.c:find_trunk_group:MARK:0
tg 0
I:sb_toolbox.c:convert_cic_to_span_chan:MARK:0
cic 26 cic_base 1 ncic 25 span 0 chan 26
I:sb_sg_cpc.c:sg_cpc:MARK:0
I:span 0 chan 26 tg 0 cic 26 sls 4 nd 10 cld 422004999? ng 9 clg 422009018 spc 3000 imt_pc 4424
I:sb_sg_cpc.c:sg_cpc_inb_wait_rlc:MARK:0

ss7boost's Role Expands

2005-11-28T15:38:00.000-05:00

ss7boost, the ISUP state machine that sits on top of ss7box, is responsible for translating trunk group indicator to span/chan on outbound calls, and translating CIC to span/chan on inbound calls. Design discussions today explored that value of adding support for phone number to span/chan translations as a way to supress most trunk-side PSTN detail into ss7boost instead of handling it in higher levels. The discussion was prompted by questions from a user on how certain per-number services and selections would be configured and handled. We realized that under the current design guidlelines, these functions could be handled in several places. It makes more sense to keep those functions inside of ss7boost and expand the definition of the purpose and function of ss7boost.

The product composed of Sangoma-Woomerang-ss7box-ss7boost may get a name soon. The Release 0.0.1 content and function is being defined. There should be a link to this description forthcoming.

ss7box.com has returned to service. The website and email are both working now. The content is returning steadily.

ss7box.com Out Of Order

2005-11-27T22:03:00.000-05:00

The ss7box.com web host provider's HDD failed completely. For some reason the backups of the account are completely lost as well. The site content can be reassembled from the pieces archived on the author's CVS and HDD but it will take some time. The author is still waiting for ssh/scp access as well.

Calls In/Out of PSTN Working

2005-11-26T14:55:00.000-05:00

Calls inbound from and outbound to the ANSI PSTN over an SS7 inter-machine trunk were made using the Sangoma-ss7box-Woomerang-Asterisk combination. This is a significant milestone in a project that has been discussed and planned since mid-year 2003.

What' s next? There is a big todo list on the ss7box wiki. In the comming week we will work on automating installation of the Sangoma-Woomerang-ss7box-ss7boost-Asterisk toolset. We will also begin ITU-izing the ss7boost ISUP state machine component in Pakistan and Paraguay. There will be a discussion about per number ISUP option configuration - where and how it should be done to minimize impact to current design, be maintainable, and not force the user into a confusing sequence of config file edits.

The ss7box website has been down since 2005-11-25 because of a massive failure of the shared host server. The web host support group advised today at 12PM to open a trouble ticket on web sites that were still missing. A trouble ticket is open on ss7box.com and hopefully it will be available again soon.

CNAM Query Demo

2005-11-17T17:01:00.000-05:00

The ss7box CNAM system was successfully demonstrated today. This system accepts 10 digit phone numbers as input from a TCP socket, forms a CNAM query that is launched into the North American SS7 network, analyzes the response, and forms a simple response on the same socket that delivered the query. A Python script was used to deliver the query and print the response to the ss7box system. An example of the output is shown below.

Phone number: 9054741990
---> D 710 UDT CNAM response:return result (Network Lookup) gn:SANGOMA TECHNLG

Outbound call testing

2005-11-17T16:49:00.000-05:00

Outbound call testing began today. This is where a call is originated on the Asterisk/media gateway side toward the PSTN side. The number we dialed was terminated on the adjacent switch which sent and ANS immediately. This is within spec but ss7boost was expecting an ACM to preceed the ANS. We also found a need to implement the Circuit Reset Sending state machine (CRS) sooner rather than later.

We found a need for a special case of aborting a call waiting for span/chan assignment in the Woomerang component which is a minor fix.

In the course of testing we elected to manually reset the circuits in the connected trunk group which exposed us to the Circuit Group Reset procedure. Theis procedure runs indefinitely until 1) the CGR Reception state machine satisfies it, or 2) it is manually stopped on the switch. We'll have to build the CGRR state machine sooner rather than later too.

Call Completes With Voice

2005-11-15T20:24:00.000-05:00

Here is the ss7boost output of a complete incoming call (PSTN to Asterisk). If you call the number 9897200000 and wait a few seconds you'll get a voice mail announcement (this will not always be in effect as this is a test system).

I:../common/udp_sockets.c:check_udp_socket:received a msg:length/function follow:64:1
I:sb_sgw_sm.c:discrim_sgw_msg:MARK:0
I:sb_sgw_sm.c:handle_m3ua_x4_msg:MARK:0
I:sb_sprc.c:isup_sprc_inbound:MARK:0
I:msu_decode.c:msu_decode:MARK:0
I:msu_decode.c:handle_m3ua_isup_transfer_msg:MARK:0
CIC: 8
MSG TYPE: IAM
NATURE OF CONNECTION INDICATORS:
SATELLITE INDICATOR: 0x00
CONTINUITY CHECK INDICATOR: 0x00
ECHO CONTROL DEVICE INDICATOR: 0x00
FORWARD CALL INDICATORS:
INCOMING INTL CALL IND: 0x00
END TO END METHOD IND: 0x00
INTERWORKING IND: 0x00
IAM SEGMENTATION IND: 0x00
ISDN USER_PART IND: 0x01
ISDN USER_PART PREFERENCE IND: 0x00
ISDN ACCESS IND: 0x00
SCCP METHOD IND: 0x00
SPARE: 0x00
RESERVED: 0x00
CALLING PARTY CATEGORY: 0x0a
MANDATORY VLP:
NAME: USER SERVICE INFORMATION
LENGTH: 3
OCTET 0: 0x80
OCTET 1: 0x90
OCTET 2: 0xa2
MANDATORY VLP:
NAME: CALLED PARTY NUMBER
LENGTH: 7
OCTET 0: 0x03
OCTET 1: 0x10
OCTET 2: 0x89
OCTET 3: 0x79
OCTET 4: 0x02
OCTET 5: 0x00
OCTET 6: 0x00
---CdPA/CgPA DECODE---
NUMBER OF DIALED DIGITS: 10
NATURE OF ADDRESS INDICATOR: 0x03
SCREENING INDICATOR: 0x00
ADDRESS PRESENTATION INDICATOR: 0x00
NUMBERING PLAN: 0x01
DIALED DIGITS: 9897200000
OPTIONAL PARAMETERS - BEGIN
OPTIONAL VLP:
NAME VALUE: 10 - CALLING PARTY ADDRESS
LENGTH: 7
OCTET 0: 0x03
OCTET 1: 0x13
OCTET 2: 0x19
OCTET 3: 0x89
OCTET 4: 0x43
OCTET 5: 0x77
OCTET 6: 0x06
---CdPA/CgPA DECODE---
NUMBER OF DIALED DIGITS: 10
NATURE OF ADDRESS INDICATOR: 0x03
SCREENING INDICATOR: 0x03
ADDRESS PRESENTATION INDICATOR: 0x00
NUMBERING PLAN: 0x01
DIALED DIGITS: 9198347760
OPTIONAL VLP:
NAME VALUE: 196 - (parm name string not defined)
LENGTH: 3
OCTET 0: 0x19
OCTET 1: 0x79
OCTET 2: 0x55
(No decode for this ISUP parameter)
OPTIONAL VLP:
NAME VALUE: 234 - (parm name string not defined)
LENGTH: 1
OCTET 0: 0x00
(No decode for this ISUP parameter)
OPTIONAL PARAMETERS - END
I:sb_toolbox.c:find_trunk_group:MARK:0
tg 0
I:sb_toolbox.c:convert_cic_to_span_chan:MARK:0
cic 8 cic_base 1 ncic 7 span 0 chan 8
I:sb_mgw_tx.c:send_call_start_to_mg:MARK:0
I:span 0 chan 8 tg 0 cic 8 sls 0 nd 10 cld 9897200000 ng 0 clg spc 5-39-221 imt_pc 5-39-220
I:sb_sgw_tx.c:send_acm_to_ss7box:MARK:0
I:span 0 chan 8 tg 0 cic 8 sls 0 nd 10 cld 9897200000 ng 0 clg spc 5-39-221 imt_pc 5-39-220
I:isup_event.c:send_canned_acm:MARK:0
I:../common/udp_sockets.c:check_udp_socket:received a msg:length/function follow:96:131
I:sb_mgw_sm.c:discrim_mgw_msg:MARK:0
I:sb_sgw_tx.c:send_ans_to_ss7box:MARK:0
I:span 0 chan 8 tg 0 cic 8 sls 0 nd 10 cld 9897200000 ng 0 clg spc 5-39-221 imt_pc 5-39-220
I:isup_event.c:send_canned_ans:MARK:0
I:../common/udp_sockets.c:check_udp_socket:received a msg:length/function follow:32:1
I:sb_sgw_sm.c:discrim_sgw_msg:MARK:0
I:sb_sgw_sm.c:handle_m3ua_x4_msg:MARK:0
I:sb_sprc.c:isup_sprc_inbound:MARK:0
I:msu_decode.c:msu_decode:MARK:0
I:msu_decode.c:handle_m3ua_isup_transfer_msg:MARK:0
CIC: 8
MSG TYPE: REL
MANDATORY VLP:
NAME: CAUSE INDICATOR
LENGTH: 2
OCTET 0: 0x80
OCTET 1: 0x90
---CAUSE INDICATOR DECODE---
LOCATION: 0
CAUSE VALUE CODING STANDARD: 0
CAUSE CLASS: 0x01 CAUSE VALUE : 0x00
---SUPPLEMENTAL INTERPRETATION---
CAUSE VALUE CODING STANDARD: CCITT/DEFAULT
CAUSE: NORMAL CLEARING
OPTIONAL PARAMETERS - BEGIN
OPTIONAL PARAMETERS - END
I:sb_toolbox.c:find_trunk_group:MARK:0
tg 0
I:sb_toolbox.c:convert_cic_to_span_chan:MARK:0
cic 8 cic_base 1 ncic 7 span 0 chan 8
I:sb_mgw_tx.c:send_call_stopped_to_mg:MARK:0
I:sb_toolbox.c:find_trunk_group:MARK:0
tg 0
I:sb_toolbox.c:convert_cic_to_span_chan:MARK:0
cic 8 cic_base 1 ncic 7 span 0 chan 8
I:span 0 chan 8 tg 0 cic 8 sls 0 nd 10 cld 9897200000 ng 0 clg spc 5-39-221 imt_pc 5-39-220
I:sb_sgw_tx.c:send_rlc_to_ss7box:MARK:0
I:span 0 chan 8 tg 0 cic 8 sls 0 nd 10 cld 9897200000 ng 0 clg spc 5-39-221 imt_pc 5-39-220
I:isup_event.c:send_canned_rlc:MARK:0

First Real Call

2005-11-15T10:31:00.000-05:00

The following output from ss7boost (ISUP state machine connected to ss7box) is from the first real phone call from a DTI DXC 4K (CLLI CRNNMIAS00W) in Corunna, Michigan, USA (thanks Collin).

The Asterisk component was not connected so the call did not complete. The call on the calling switch timed out and sent a REL and ss7boost responded with a RLC.

I:../common/udp_sockets.c:check_udp_socket:received a msg:length/function follow:64:1
I:sb_sgw_sm.c:discrim_sgw_msg:MARK:0
I:sb_sgw_sm.c:handle_m3ua_x4_msg:MARK:0
I:sb_sprc.c:isup_sprc_inbound:MARK:0
I:msu_decode.c:msu_decode:MARK:0
I:msu_decode.c:handle_m3ua_isup_transfer_msg:MARK:0
CIC: 8
MSG TYPE: IAM
NATURE OF CONNECTION INDICATORS:
SATELLITE INDICATOR: 0x00
CONTINUITY CHECK INDICATOR: 0x00
ECHO CONTROL DEVICE INDICATOR: 0x00
FORWARD CALL INDICATORS:
INCOMING INTL CALL IND: 0x00
END TO END METHOD IND: 0x01
INTERWORKING IND: 0x00
IAM SEGMENTATION IND: 0x00
ISDN USER_PART IND: 0x01
ISDN USER_PART PREFERENCE IND: 0x00
ISDN ACCESS IND: 0x00
SCCP METHOD IND: 0x00
SPARE: 0x00
RESERVED: 0x01
CALLING PARTY CATEGORY: 0x0a
MANDATORY VLP:
NAME: USER SERVICE INFORMATION
LENGTH: 3
OCTET 0: 0x80
OCTET 1: 0x90
OCTET 2: 0xa2
MANDATORY VLP:
NAME: CALLED PARTY NUMBER
LENGTH: 7
OCTET 0: 0x03
OCTET 1: 0x10
OCTET 2: 0x89
OCTET 3: 0x79
OCTET 4: 0x02
OCTET 5: 0x00
OCTET 6: 0x00
---CdPA/CgPA DECODE---
NUMBER OF DIALED DIGITS: 10
NATURE OF ADDRESS INDICATOR: 0x03
SCREENING INDICATOR: 0x00
ADDRESS PRESENTATION INDICATOR: 0x00
NUMBERING PLAN: 0x01
DIALED DIGITS: 9897200000
OPTIONAL PARAMETERS - BEGIN
OPTIONAL VLP:
NAME VALUE: 10 - CALLING PARTY ADDRESS
LENGTH: 7
OCTET 0: 0x03
OCTET 1: 0x13
OCTET 2: 0x89
OCTET 3: 0x79
OCTET 4: 0x34
OCTET 5: 0x04
OCTET 6: 0x99
---CdPA/CgPA DECODE---
NUMBER OF DIALED DIGITS: 10
NATURE OF ADDRESS INDICATOR: 0x03
SCREENING INDICATOR: 0x03
ADDRESS PRESENTATION INDICATOR: 0x00
NUMBERING PLAN: 0x01
DIALED DIGITS: 9897434099
OPTIONAL VLP:
NAME VALUE: 196 - (parm name string not defined)
LENGTH: 3
OCTET 0: 0x89
OCTET 1: 0x79
OCTET 2: 0x34
(No decode for this ISUP parameter)
OPTIONAL VLP:
NAME VALUE: 234 - (parm name string not defined)
LENGTH: 1
OCTET 0: 0x00
(No decode for this ISUP parameter)
OPTIONAL PARAMETERS - END
I:sb_toolbox.c:find_trunk_group:MARK:0
tg 0
I:sb_toolbox.c:convert_cic_to_span_chan:MARK:0
cic 8 cic_base 1 ncic 7 span 0 chan 8
I:sb_mgw_tx.c:send_call_start_to_mg:MARK:0
I:span 0 chan 8 tg 0 cic 8 sls 0 nd 10 cld 9897200000 ng 0 clg spc 5-39-221 imt_pc 5-39-220
I:sb_sgw_tx.c:send_acm_to_ss7box:MARK:0
I:span 0 chan 8 tg 0 cic 8 sls 0 nd 10 cld 9897200000 ng 0 clg spc 5-39-221 imt_pc 5-39-220
I:isup_event.c:send_canned_acm:MARK:0
I:../common/udp_sockets.c:check_udp_socket:received a msg:length/function follow:32:1
I:sb_sgw_sm.c:discrim_sgw_msg:MARK:0
I:sb_sgw_sm.c:handle_m3ua_x4_msg:MARK:0
I:sb_sprc.c:isup_sprc_inbound:MARK:0
I:msu_decode.c:msu_decode:MARK:0
I:msu_decode.c:handle_m3ua_isup_transfer_msg:MARK:0
CIC: 8
MSG TYPE: REL
MANDATORY VLP:
NAME: CAUSE INDICATOR
LENGTH: 2
OCTET 0: 0x80
OCTET 1: 0x90
---CAUSE INDICATOR DECODE---
LOCATION: 0
CAUSE VALUE CODING STANDARD: 0
CAUSE CLASS: 0x01 CAUSE VALUE : 0x00
---SUPPLEMENTAL INTERPRETATION---
CAUSE VALUE CODING STANDARD: CCITT/DEFAULT
CAUSE: NORMAL CLEARING
OPTIONAL PARAMETERS - BEGIN
OPTIONAL PARAMETERS - END
I:sb_toolbox.c:find_trunk_group:MARK:0
tg 0
I:sb_toolbox.c:convert_cic_to_span_chan:MARK:0
cic 8 cic_base 1 ncic 7 span 0 chan 8
I:sb_mgw_tx.c:send_call_stopped_to_mg:MARK:0
I:sb_toolbox.c:find_trunk_group:MARK:0
tg 0
I:sb_toolbox.c:convert_cic_to_span_chan:MARK:0
cic 8 cic_base 1 ncic 7 span 0 chan 8
W:sb_mgw_tx.c:send_call_stopped_to_mg:REL dropped:could not validate CIC
I:sb_sgw_tx.c:send_rlc_to_ss7box:MARK:0
I:span 0 chan 8 tg 0 cic 8 sls 0 nd 10 cld 9897200000 ng 0 clg spc 5-39-221 imt_pc 5-39-220
I:isup_event.c:send_canned_rlc:MARK:0

Responding to RSC

2005-11-15T02:33:00.000-05:00

Working on the ISUP state machine suite called ss7boost. Program a monolithic source code file (with exception of MSU decoders and encoders). Split source file apart along functional lines. Created the SPRC, CPC, and MPC functional entitities to follow the ISUP SDL specs because it's easier to develop with naming similarities.

Calls work in the lab but now were in the field in Michigan, Pakistan, Paraguay, and India. New installations coming soon in Bulgaria and Phillipines.

First thing we encountered in .mi was the RSC message. We didn't bother with the maintenance ISUP messages in the lab so we expected to be greeted with this type of message.

We also found out very quickly that the system for mapping trunk group and CIC to span and channel was too simple and inflexible. That is now changed but not thoroughly tested.

This is where the author leaves off tonight:

I:../common/udp_sockets.c:check_udp_socket:received a msg:length/function follow:27:1
I:sb_sgw_sm.c:discrim_sgw_msg:MARK:0
I:sb_sgw_sm.c:handle_m3ua_x4_msg:MARK:0
I:sb_sprc.c:isup_sprc_inbound:MARK:0
I:../libmsu/msu_decode.c:msu_decode:MARK:0
I:../libmsu/msu_decode.c:handle_m3ua_isup_transfer_msg:MARK:0
CIC: 8
MSG TYPE: RSC
I:../libmsu/msu_decode.c:rsc_decode:MARK:0
I:sb_toolbox.c:find_trunk_group:MARK:0
tg 0
I:sb_toolbox.c:convert_cic_to_span_chan:MARK:0
cic 8 cic_base 1 ncic 7 span 0 chan 8
I:sb_mpc.c:ckt_reset_reception:MARK:0
I:sb_sgw_tx.c:send_rlc_to_ss7box:MARK:0
I:span 0 chan 8 tg 0 cic 0 sls 0 nd 0 cld ng 0 clg spc 0-0-0 imt_pc 0-0-0
I:isup_event.c:send_canned_rlc:MARK:0

An RLC is being sent in response to an RSC but the RLC is improperly filled out because the CDR for span 0 chan 8 is empty. Will fix by loading CDR with info from RSC.