[asterisk-ss7] Libss7 Status Update

[Matthew Fredrickson]

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_CHARGE_NUMBER
SS7_GENERIC_ADDRESS
SS7_JIP
SS7_GENERIC_DIGITS
SS7_GENERIC_DIGTYPE  (type of generic digits)
SS7_GENERIC_DIGSCHEME
SS7_ORIG_CALLED_NUM

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

SS7_CALLING_PARTY_CATEGORY
SS7_REDIRECTING_NUMBER
SS7_GENERIC_NAME

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

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.