Low Yu Siang <[EMAIL PROTECTED]> 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. _______________________________________________ --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
