[Home]

Summary:ASTERISK-26257: AGI scripts called from dialplan disturb confbrige audio quality
Reporter:Marco Nicoloso (mnicolos)Labels:
Date Opened:2016-08-02 05:34:22Date Closed:2016-08-03 15:05:24
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_confbridge Resources/res_agi
Versions:11.13.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:CentOS 6.5 x64 8 core RAM 16 GBAttachments:
Description:The issue has been reported in the Asterisk community and investigated.
Here the link to the forum.

The version we are using is quite old (11.13), but the problem can affect also other versione as, reading through the changelogs, I do not have any evidence that the problem is solved.

We have some clients that receive continuously audio from confbridge and try to setup once every 5 seconds new channels if the configured ones are  down. In parallel Asterisk records the audio of these conferences into some wav files.

The effect that wwe observed was that we were detecting some strange audio "holes" on client-side generated by asterisk  (20-40 ms) at least once every 2 seconds.

Looking at the recorded files, we noticed that there was about 2% of samples missing (during an hour of recording we had a loss of 1 minute and a half in record duration)

The dialplan was starting with an AGI script in order to retrieve from a PostgreSQL 8.4 DB some data and setup some channel variables.
After that step, dialplan was executing simple checks which wouold terminate eventually in confbridge or busy.

After switching from AGI script to func_odbc the loss is approximately 0,01 % of samples
Comments:By: Asterisk Team (asteriskteam) 2016-08-02 05:34:23.465-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Joshua C. Colp (jcolp) 2016-08-02 06:44:06.766-0500

I'm not really sure if there's anything that can be done for this. ConfBridge requires a constant timer in order to wake up, mix audio, and dispatch it. If this is not guaranteed by the system then you will see exactly the behavior you are seeing - gaps. If spawning a process for AGI causes the system to use resources such that the timer doesn't fire when it should there's nothing that Asterisk itself can do about that.
By: Freddi Hansen (freddi_fonet) 2016-08-02 09:53:18.859-0500

the workaround would be to dedicated one cpu core to the non timesensitive tasks and to exclude that from the Asterisk threads. You could modify the safe_asterisk script to use taskset when starting asterisk like change (sorry the long lines wrap in this setup):
{code}
nice -n $PRIORITY "${ASTSBINDIR}/asterisk" -f ${CLIARGS} ${ASTARGS} >/dev/${TTY} 2>&1 </dev/${TTY}
{code}
to
{code}
nice -n $PRIORITY /bin/taskset -c 0-6 ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} >/dev/${TTY} 2>&1 </dev/${TTY}
{code}
you have now excluded core 7 from your asterisk threads.
now in you extensions.conf change
{code}
_+X.,1,Agi(MyAgi.agi.)
{code}
to
{code}
_+X.,1,Agi(/bin/taskset,-c,7,/var/lib/asterisk/agi-bin/MyAgi.agi)
{code}
your are now only using core 7 when executing you agi script, it would make sense to also move your PostgreSQL to core 7.
If this isn't enough to give your asterisk the timing needed then use the isolcpu switch in the kernel boot line so you take e.g core 1-6 away from the OS scheduler and only use these cores in your safe_asterisk start.
 
By: Rusty Newton (rnewton) 2016-08-03 15:05:24.344-0500

Doesn't seem like there is anything we can do here and since there is no patch provided and a workaround is available, I'm going to close this out for now.

We can re-open this in the future if someone digs into it and finds an Asterisk source modification that would improve the behavior.
By: xrobau (xrobau) 2018-07-28 18:00:28.423-0500

As a late update to this ticket, we've spent some time diagnosing this in ASTERISK-27987 and it is an issue with the timerfd timing source freezing when asterisk uses the fork() system call to spawn an AGI.

The workaround is to use dahdi timing, or, switch to using FastAGI, which does not require a fork().