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
|