[asterisk-ss7] Stupid problem...

[Rony Ron]

Hi,
you can check here: http://asterisk.hosting.lv/
BR,

--> Your next partner !
> 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
>>     
>
> _______________________________________________
> --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