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)? If not, you could try that, it might help. Generally I would consider running a realtime priority a requirement for getting a stable link, but YMMV, of course. - Kristian.
|