Sunday, June 04, 2006

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.

Friday, May 26, 2006

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.

Thursday, April 20, 2006

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


Thursday, March 16, 2006

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.

Wednesday, March 08, 2006

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.

Sunday, February 12, 2006

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.

Friday, January 13, 2006

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.

Sunday, December 18, 2005

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.

Friday, December 09, 2005

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

Monday, November 28, 2005

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.

Sunday, November 27, 2005

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.

Saturday, November 26, 2005

Calls In/Out of PSTN Working

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.

Thursday, November 17, 2005

CNAM Query Demo

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

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.

Tuesday, November 15, 2005

Call Completes With Voice

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

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

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.