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.
Monday, July 28, 2008
Thursday, April 10, 2008
New MTP and ISUP Features
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.
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.
Monday, March 17, 2008
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.
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.
Wednesday, March 05, 2008
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 <>
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 <>
Friday, February 01, 2008
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:
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.
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
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.
Thursday, January 31, 2008
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
./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
Monday, January 21, 2008
Sunday, January 20, 2008
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.
Wednesday, January 02, 2008
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.
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.
Sunday, October 08, 2006
New ss7box blog location
The ss7box blog has moved to the wiki because some people cannot reach the blogger.com website.
Thursday, July 13, 2006
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.
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.
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.
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."
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.
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.
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.
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.
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.
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
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
Subscribe to:
Posts (Atom)