chan_ss7 - unstable link

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite Backpacking]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux