Andreas Kaufmann wrote:
> 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?
I don't have any distribution or hardware environment recommendations.
> 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?
No, sorry. Since this is very much a new feature, and it came out after
the 1.4 branch was released, it is only in trunk and the 1.6 branch :-(
Matthew Fredrickson
>
> 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.
>>
>
>
> _______________________________________________
> --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
--
Matthew Fredrickson
Software/Firmware Engineer
Digium, Inc.
|