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
|