Issue with MixMonitor and ChanSpy when using codec_opus

#1

Hello -

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.

Thanks.

0 Likes

#2

I’m still slowly trying to chip away at this issue…

Perhaps this is an issue with the change in sampling rates between the opus codec ( 48000) and ulaw (8000). Is there a configuration setting that would allow the opus codec to use 8000 for the sampling rate? I can’t find much information on the web for that.

I did find documentation on opus on freeswitch which seems to support for different opus sampling rates as seen here:
https://freeswitch.org/confluence/display/FREESWITCH/FreeSWITCH+And+The+Opus+Audio+Codec

is there something similar for codec_opus in asterisk?

Thanks.

0 Likes

#3

You could try fiddling with some of the configuration options.

Besides upgrading Asterisk also make sure you are using the latest version of the codec. If you are downloading it via menuselect then you should be.

0 Likes

#4

Thanks @kharwell. Fiddling around with the configuration options did indeed help. We had the dtx option set to yes and it turns out this was what what causing the our call quality issues with one leg of the call in the chan_spy and MixMonitor audiohooks.

Prior to posting this question, I hadn’t put much thought into disabling that option, as I had just assumed since both ends of the bridged call could here each other fine that the audio hook would work to, but I guess they are different code paths or behave differently in relation to transcoding.

We don’t have an immediate need to enable DTX in our environment – I just thought it sounded like something reasonable to do. So at this point we are unblocked.

Thanks for the help.

1 Like