I am working on an asterisk application ( Asterisk 14.7.3 ) that uses ARI to create bridges type “simple_bridge”. This application creates several bridges and users enters and exits them all time. The problem is that at some time after entering a bridge the voices of all other people become unintelligible as if they were “scrambled”. Even when a sound is played it is unintelligible.
I was able to do a test ( at production environment ) at which there was a lot of users in bridges and I could isolate 2 users in one bridge. One of them could hear the other without problems, but the other just listened to unintelligible audio. They are using only g729.
Do someone had some issue like this and discovered the cause ?
Sure, we’ve all probably had similar issues and were able to identify the cause. There’s no magic configuration to solve call quality issues. You’ll need to check the following:
Trying to check a scenario like you sugested I did the last test I described. With several users in bridges at production environment I, with 2 cel phones side by side, using the same telephone company, isolated them at a specific “simple_bridge”. Just one could hear the other; one of them just heard “scrambled” voice. But this scenario I just reproduced one time.
I agree with you, there may be several causes. But the main question is how could I find some tip at asterisk log about this bad quality. I didn’t find anythink at asterisk-warning.log or asterisk-error.log. As this phenomenon just happens in production environment, logs are huge and difficult to watch. So I would have to filter by some kind of specific keyword about bad quality. Do you know if there is someway to identify this in astersk logs ?
Asterisk doesn’t do audio analysis like that, and in a simple_bridge actual audio processing can be non-existent or minimal. If the same codec then we essentially act as a packet forwarder back and forth. If different codec then there is a translation step but otherwise we just forward. You’d likely need to do a packet capture on each side and examine the actually audio leaving.
You’re in for what a co-worker once called, an adventure in packeteering. Hours and hours (and hours) of capturing packets, reconstructing audio legs, and analyzing every aspect of your network. All while trying to minimize the impact on the production environment and avoiding the observer effect.
If you are capturing RTCP statistics in your CDR, that would be a good place to start. You’re not going to find much in the asterisk logs. But you need to analyze everything, asterisk logs included. When you are able to reproduce the issue, note the time -or- get it from your packet captures. This can help you narrow down the asterisk logs you want to review to few minutes.
I captured packets from channels while the uninteligible audio was happening at Asterisk 14.7. There are a lot of channels ( at least 20 ) with Max Jitter from 1 to 8.4 ms and without packet loss. The channel with maximum jitter had 8.423 with mean jitter 0.196.
The detail I noticed is that ARI sends commands to build bridges of type simple_bridge. This is the one type I am using with ARI and having uninteligible audio problems.
I have another asterisk ( version 13.6 ) that is using only its LUA engine to execute the application LUA scripts instead of ARI. It uses channel CONFBRIDGE to build bridges and, instead of bridges type simple_brige, it always use native_rtp bridges. This way, using channel CONFBRIDGE with asterisk 13.6, asterisk does not have uninteligible audio for channels in the bridge.
No one of these asterisks use jitter configurations. Both asterisk are being used according round-robin choice. This way they use the same bandwith conditions to external internet. Both asterisk are running at machines with several cores and have no lack of CPU or memory.
Do you have some idea about the uninteligible audio problem ?