We have been experiencing some call quality issues with some of our endpoints that are connecting to our asterisk system from a new site. The endpoints are connected via WebRTC. We speculated there was some kind of characteristic in this new network that was producting the issue – network congestion, package loss?
After doing some research, we experimented with switching to the opus codec from ulaw.
Our initial tests were immediately successful. Callers on both sides were able to hear and converse with eachother clearly.
However, the audio quality issues have now surfaced somewhere else – ChanSpy and MixMonitor are now impacted.
When another user connects via ChanSpy to listen in on one of these active channels, they can hear the callee fine ( the endpoint connected via webrtc using opus), but the audio for caller ( coming in through TLS/ SRTP-SDES and using ulaw codec) is poor. This appears to be the same thing with the MixMonitor recording.
I don’t know the word to describe the quality, but it seems like its almost being played back at doublespeed and there are regular periodic breaks as if every other syllable is being stripped out.
We are only just getting experience with Opus and tryed the following settings:
[opus] type=opus dtx=yes cbr=yes bitrate=8000
We also tried these:
[opus] type=opus dtx=yes fec=yes packet_loss=4 cbr=yes bitrate=16000
This only happens when one of the WebRTC endpoints is using the opus codec. From our main location where endpoints are connected with webrtc and using the ulaw codec, there are no quality issues on the call or with ChanSpy or MixMonitor.
We are currently running on a custom build of asterisk 13.22.0. Our next step is to upgrade to 13.24.1 and see if that helps things.
I would greatly appreciate any troubleshooting steps anyone had to offer.