[asterisk-ss7] Libss7 Status Update

Matthew Fredrickson creslin at digium.com
Fri May 30 14:01:34 CDT 2008

Hey all,

It has been a while since I have made a status update with regards to 
libss7, so I think it is about time that I should do so.

Library Related Updates:

Many things have changed since the last status update.  Some of the 
highlights include are listed.

Lots of additional parameters and messages are supported and dumped....
Many new channel variables are now added in chan_zap to receive SS7 
specific information:

SS7_GENERIC_DIGTYPE  (type of generic digits)

SS7_LSPI_IDENT (these three are used for RLT support on DMS switches)


Most are fairly self explanatory as far as what they contain.  It is 
also possible to set many of these parameters on outbound calls as well 
by prefixing the variable with an '_' when you set it.

In addition, ANSI SS7 support has been improved extensively, thanks to 
Alan McMillan and Joseph (on this list).  RLT support has been added for 
DMS switch types.

*NOTE*: It is also recommended to all of you that are still using the 
trunk version of Asterisk for SS7 support to switch to the 1.6.0 branch 
(http://svn.digium.com/svn/asterisk/branches/1.6.0 to checkout via svn). 
  When it is released it will be the first release branch to contain SS7 
support.  I am continuing to maintain and bugfix both 1.6.0 and trunk 

Cool New Feature That You Should Use:

Also, as many of you may have noticed, there was a new Zaptel release 
(1.4.11).  So you maybe asking yourself, "Why should I care about a new 
Zaptel release, this is the asterisk-ss7 mailing list".  In case you 
were, this is why:

I recently added a new channel type to zaptel which performs most of the 
real time work required to keep an MTP2 link alive in the kernel instead 
of in Asterisk/libss7.  What does this mean for you?  It means your 
links are going to be much more stable under system load.

For most cases, the only thing now that will be able to knock your SS7 
link down is if you are trying to echo cancel more channels than your 
CPU can handle (as echo cancellation is done in the same place as the 
kernel level MTP2).  So if you have link stability problems still, it is 
likely your echo cancellation load is too high and you need to get a 
better CPU or a hardware echo canceller.

Now, in order to update to use it, you need to get the latest version of 
Zaptel (1.4.11), libss7, and asterisk-1.6.0 (or Asterisk-trunk if you 
really still want to use it).  Compile them in that order, and in 
zaptel.conf where you have the "dchan=" line for the signalling channel, 
change that to "mtp2=", run ztcfg, and, Voila!, it is done.  Your 
existing zapata.conf should require no changes.

This update is highly recommended, since the kernel is a much more 
appropriate place to do the work of a real time task like keeping FISUs 
and LSSUs constantly being sent on the line.

For those that want the technical details of the new channel type, here 
is an explanation.

Basically, it is similar to a dchan, so it does all you HDLC encoding 
and decoding, as well as CRC calculation and checking.  The difference 
is that when you write messages on that channel, it automatically 
repeats the last one written.  On the receive side, it compares the most 
recently received message with the last one received off the signalling 
link, and if it is different, it wakes up the Asterisk/libss7 process. 
If it is the same, it ignores it (so as not to have excessive and 
unnecessary user/kernel context switches).

As always, if you have any questions, I am available on this list to 
answer them.

Matthew Fredrickson
Software/Firmware Engineer
Digium, Inc.

More information about the asterisk-ss7 mailing list