There is a number of precompiled packages, try different types On Thursday 07 August 2008 16:37, olivier taylor wrote: > hello, > > I have tried many of them. > My architecture is I686 and all the binaries I've tried > gave me a core dump... > > br, > > Olivier > > > Rony Ron a ?crit?: > Hi, > you can check here: http://asterisk.hosting.lv/ > BR, > > --> Your next partner ! > > Look for an IPP version than. > > On Thursday 07 August 2008 11:21, olivier taylor wrote: > > > Hello all, > > I have two servers installed with the latest SS7 > rellease (asterisk 1.6.0 and chan_dahdi). > > It works perfectly, thanks to the list. > But now, I need to install G729 on these servers but > digium claim that they does not provide binaries nor > support G729 on asterisk 1.6 > > Any idea is welcome, > > Regards, > Olivier > > > Patrick a ?crit : > Kristian Nielsen wrote: > > Low Yu Siang <yusiang at yahoo.com> writes: > > > After running for days(~300 incoming calls), the link > became unstable. Whenever a call is coming in, it throws > the following error messages. This call is accepted > properly but all other calls cant be accepted during this > moment(since the signalling link is already down), until > the link automatically comes up again. > > [Aug 6 11:07:43] NOTICE[25980]: mtp.c:1800 > mtp_thread_main: Empty Zaptel output buffer detected, > outgoing packets may have been lost on link 'l1'. [Aug 6 > 11:07:43] NOTICE[25980]: mtp.c:1748 mtp_thread_main: Full > Zaptel input buffer detected, incoming packets may have > been lost on link 'l1' (count=64. [Aug 6 11:07:43] > NOTICE[25980]: mtp.c:1015 mtp2_process_lssu: Got status > indication 'OS' while INSERVICE on link 'l1'. [Aug 6 > 11:07:43] WARNING[25980]: chan_ss7.c:622 process_event: > MTP is now DOWN on link 'l1'. > > This could be caused by a delay in the OS scheduling of > Asterisk, ie. that for too long time, the chan_ss7 code > did not get a chance to run due to other activity on the > box. MTP has realtime constraints, so this can cause the > link to drop. > > Are you running Asterisk on real-time priority (I think > this happens automatically if you start Asterisk as > root)? > > > Afaik you need to start asterisk with -p to run it as a > pseudo realtime thread. See asterisk -h > > You might also want to check if processes like anacron > and crond don't eat too much power/io. Updatedb causes > disk io which could interfere with Asterisk. And perhaps > others started by crond like makewhatis as well. > > Might also be worth investigating if updating to CentOS > 5.2 gives you a kernel that has more granular timing > compared to the one you are running right now. > > Maybe this one is totally not related to your problem but > it is also recommended to run a (caching) nameserver in > your Asterisk box. There was something with Asterisk > blocking if it could not resolve a name. > > Hope this helps. > > Regards, > Patrick > > _______________________________________________ > --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 > > > _______________________________________________ > --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 > > > > _______________________________________________ > --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
|