Confbridge timing issue

Dear Forum Users,

I posted an information request in JIRA, which was automtically closed by the system, and thoroughly looked in the forum and in the KB as well. I still can’t find an answer or a path to address my issue.

Most of the information is here

Briefly the effect is that I have audio “holes” in Confbridge while network connectivity is OK and not losing packets anywhere, but SIP clients show up audio loss and the local recording of the Conference reports around 2% of samples less than expected. But you can read on more on previous link.

I add that the timing module that is being used is and that the system is virtualized.

Thank you in advance for your help.

Best Regards,

Check is all legs are using the same codec. If transcoding is enabled maybe you have a problem there.
During the conference use the following command to see the used codec for each channel

sip show channels

I have G711 uLaw everywhere.

Check that the VM has dedicated use of sufficient CPU cores. This sounds like trying to run in a virtual environment which has not been specifically configured for real time applications with 20ms scheduling latency requirements.

Thanks @david551.
Is it worth to install asterisk on a linux real time kernel?

I’ve been reading this

Doing the steps there stated, it turns out that the production system has some high-latency spikes that must be addressed.
Rt.tests show up just slight changes even when using latency-performance tuned profile.

Best Regards,


Some investigations show that if asterisk is perturbed by multiple call attempts even on different extensions, confbridge recording will suffer from packet loss.
When the system is quiet (no calls made from clients/phones) there is no recording loss.

Anyway even under stress conditions (multiple call attempts) the overall system performance is good.


the problem seems to be related to dialplan execution while interacting with PostgreSQL 8.4 via res_pgsql native module, I still didn’t test the same dialplan execution with res_odbc. In parallel I will test the same scenarios with asterisk 13.8-certified.

Will let you know.

The issue was related to the use of external AGI scripts to interact with DB in order to set some channel variables for call setup.
Since I didn’t have res_odbc module because of unmet dependencies, I was forced to use realtime asterisk with res_pgsql and AGI scripts to fulfill call setup requirements.
I then recompiled Asterisk against unixODBC and ltdl and moved from res_pgsql to res_odbc for realtime asterisk, dialplan-started scripts have been replaced by func_odbc functions.
The problem was solved in this manner, anyway I will file this behavior as a bug.

Thank you @astbox and @david551 for your attention and hints.