[asterisk-ss7] Libss7 Status Update

Sun Jun 1 15:21:35 CDT 2008

Hi,

just updated my system to the latest version via svn checkout, also  
updated firmware and wanpipe drivers for my A104d Sangoma Card (i've  
been having a lot of issues with libss7 and a lot of unknown hangup  
causes, so i was very excited about this update)
After reloading the zaptel configuration and making my first test call  
i noticed that asterisk was behaving strangely; it would not respond  
to most commands, such as "core stop now" ( had to kill asterisk).  
After doing some tests I realized that this problem happens when the  
call comes in via an iax channel. I then tested with a sip trunk from  
another asterisk box, which until now seems to be working fine. I also  
haven't had any unknown hung-up causes as I had with earlier versions,  
but it is too early to get excited because the call volume at the  
moment is very low. I'll know more after a day or two when I can  
compare hang-up cause statistics.

--
Markus

On May 30, 2008, at 10:01 PM, Matthew Fredrickson wrote:

> 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.
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-ss7