dear friends
when i have some concurrent calls about 25 or more and all of them are listening ivr file, ivr file plays slowly and not ok, like you speed down the file,
for example in first seconds of file , sound is ok but suddenly it become very slow and again ok and after that so slow (that i cant even understand what it says)
it’s very bad,
Background and Playback and Read , all of them plays file with this problem.
do you think asterisk is craching ?!!
there is no exact log and no cpu or memory load. every things sounds good execpt playing ivr.
i use asterisk files like demo-congrats and files in en/ folder , but problem exist with these files too.
i thinks problem is not about file and its format or codec.
I can’t imagine how CDR processing would lock out audio playout for significant periods, other than CPU, memory, disk, or network resource contention. However, they way would go further woudl be to rebuild with no optimise, debug threads, and probably better back traces, then use core show locks to find out what the playout code was waiting for, and possibly also more invasive low level debugging techniques.
I would seriously want to consider whether this was a vitualisation problem was, unless you take steps to avoid it, system time doesn’t track real time, over shorter periods, in vrtual machines and you have to consider resource usage, in particular disk arm usage, across all hte guests.
acctually we have another problems,
CDR raised with delay about 20 minutes
i cant check status of a call because cdr table update after 20 minutes or more, for each call.
call at 1:30pm doesn’t have CDR till 1:59pm
i dont know why CDR proccessing is so slow,
-another problem is in setting channel variable:
i set a channel variable at 2:30pm in dialplan , but i take it from ami event (setvar ) at 2:38pm with delay of 8 minutes .
i think slowness in ivr sound, related to above problems too.
rebuilding with no optimise, debug threads, and back traces, can make any problem for my system ???
as it’s running and many important calls are on it.
Can you confirm that this is the figure from ps -l, as the way that Linux (and NT) works means that it is normal for the overall OS memory usage ot show a figure iike that, although, in the case of Linux, the standard tool also shows a figure without cache and buffer use.
If it really is showing in ps -l, you have a memory leak and you need to try and work out what causes it to grow, and, if possible, by how much it grows.
WIth virtualisation, it is possible you are getting page ins, even though you aren’t using an OS swap file.
Yes, channelstats is an Asterisk console command. It comes in two flavors: “sip show channelstats” and “pjsip show channelstats”.
The hardware should be more than enough, unless it is a running as a virtualization server and you’ve got a vm with1 GB of RAM, a misconfigured NIC, and a single processor.
You could increase the verbosity to 3 in the console, play a file and send us the output. Your problem should not occur on a correctly configured Asterisk server.
i just playback a simple file, but again slow voice of file :
Executing [49763430@check:1] Playback("OOH323/router-218", "demo-congrats") in new stack
> 0x7f8bc298cda0 -- Strict RTP learning after remote address set to: 10.1.10.11:19932
> 0x7f8bc298cda0 -- Strict RTP learning after remote address set to: 10.1.10.11:19932
> 0x7f8bc298cda0 -- Strict RTP switching to RTP target address 10.1.10.11:19932 as source
-- <OOH323/router-218> Playing 'demo-congrats.gsm' (language 'en')
i record my inbound calls from the first of ivr with mixmonitor()
but i dont use stopmixmonitor() at the end of call (in h exten)
is it make any problem?
for example some extra mixmonitor threads in asterisk stays and make bad performance for asterisk in some advanced senario(using agi -ami - complicated dialplan - many variable set in channel - some external api calling with curl in phpagi & …)
ivr plays slowly and cdr process with over 20min delay, file recording is not ok (bad recordind),