[asterisk-ss7] Stupid problem...

Anton anton.vazir at gmail.com
Thu Aug 7 01:50:10 CDT 2008

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

More information about the asterisk-ss7 mailing list