[libss7-commits] mattf: trunk r175 - /trunk/NEWS-05-30-2008

Fri May 30 14:01:35 CDT 2008

Author: mattf
Date: Fri May 30 14:01:34 2008
New Revision: 175

URL: http://svn.digium.com/view/libss7?view=rev&rev=175
Log:
Add latest news update for libss7

Added:
    trunk/NEWS-05-30-2008

Added: trunk/NEWS-05-30-2008
URL: http://svn.digium.com/view/libss7/trunk/NEWS-05-30-2008?view=auto&rev=175
==============================================================================

--- trunk/NEWS-05-30-2008 (added)
+++ trunk/NEWS-05-30-2008 Fri May 30 14:01:34 2008
@@ -1,0 +1,52 @@
+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.


