[asterisk-ss7] libss7 stability issues

[Andreas Kaufmann]

Hi Matthew,

thanks for your fast answering - I will try this.

Anyway, can you recommend a linux distribution and maybe even a hardware 
environment where libss7 is known to run stable?

Also using always the latest versions of the asterisk/zaptel branch 
seems to be a little unpredictable to me. Is it possible to run libss7 
with one of the stable non-beta asterisk releases, lets say with the 
current 1.4.20 release?

Thanks for your help,
Andreas


Matthew Fredrickson schrieb:
> Matthew Fredrickson wrote:
>> Andreas Kaufmann wrote:
>>> Hi,
>>>
>>> I have encountered stability problems when using libss7. I am using 
>>> "sipp" to generate multiple calls over the link. After a few hundred 
>>> test calls asterisk randomly stops working and the asterisk process does 
>>> not exist any more in the unix process list.
>>>
>>> A second problem I have encountered is that after generating a lot of 
>>> concurrent calls,  some of the ss7 channels on the linkset are reported 
>>> to be busy ("app_dial.c: Unable to create channel of type 'zap' (cause 
>>> 34 - Circuit/channel congestion"), although this channels were not in 
>>> use any more. I have to restart asterisk to get this channels free again.
>>>
>>> I have tried the following configuration:
>>>
>>> OS: OpenSuse 10.3
>>> Zaptel: SVN-branch-1.4-r4315
>>> libss7: SVN-trunk-r171
>>> Asterisk: SVN-trunk-r118178M
>>> DIGIUM TE220P 2xE1 Card
>>>
>>> According to Matthews latest NEWS file (NEWS-05-30-2008) if have also tried:
>>>
>>> libss7: SVN-trunk-r176
>>> Zaptel: 1.4.11
>>> Asterisk: 1.6.0
>>>
>>> Can anyone recommend a stable version for libss7/zaptel/asterisk? Would 
>>> it be better to use another distribution, e.g. Fedora?
>> You might check to see if it is dumping core somewhere so we can get a 
>> backtrace of why it failed.  If you start asterisk with the -g flag, it 
>> will cause Asterisk to core dump when it crashes.  Then you can get a 
>> backtrace of it's failure point with gdb.
> 
> One other thing I forgot to mention would be a debug trace up to the 
> moment where it dies.  If you enable debugging (ss7 debug linkset x) and 
> make sure your verbose output goes to some log file in logger.conf, that 
> should leave a debug record I can use.
>