Group Reset Reception Processing

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

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

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

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

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

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

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

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

SMG High Capacity Testing

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

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

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

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

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

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

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

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

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

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

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

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.