I use Opus as the primary codec for all devices. While trying to resolve an issue with Bria, Counterpath discovered through packet captures that FreeSwitch is sending "out of sequence RTPs". Please read their assessment below. I use default settings for the opus config (except for DTX testing see below). Opus is the first codec in vars.xml.
This was tested on 1.10.5 and 1.10.6 Nov 20 with same results. Tested on a test machine with Core i7 with nothing else running, only one extension.
The audio severity was not consistent so I lived with it. In early August we lost critical medical calls and voicemails that prompted me to work on the problem, so I can't say how long this has been around. Searching for FreeSwitch issues keywords RTP, OPUS, etc. it looks like others have had similar audio issues for some time, some still open, but I don't if they are related.
I have an AIFF voicemail file made by Freeswitch that plays fine as an audio file but is bad when played back listening to it as a Freeswitch VM message. I sent the file to Counterpath that consistently demonstrates the problem (75% unintelligible if Bria video on). I did a packet trace during playback from Freeswitch to Bria. That's where they see the gaps during playback. Keep in mind this also occurs on calls not just voicemail.
This information from Counterpath describes what they see playing back the voicemail:
We explored multiple theories and the packet captures you provided were invaluable. According to our development team, the primary issue appears to gaps in RTP timestamps as created by Freeswitch. One of our dev team tested playing back your DTX OFF capture.pcap to linphone and groundwire and heard audio artifacts in similar spots. Another used opussrtp and all pcap files sounded identical, however that utility does not take RTP timestamps or packet delays into account.
Analyzing your packet captures and quoting the dev team:
in DTX ON capture.pcap there are 53 audio packets from FS where the timestamp jumps, also with marker bit set
in DTX OFF capture.pcap there are 43 audio packets from FS where the timestamp jumps, also with marker bit set
in DTX ON Video Off capture.pcap there are 13 audio packets from FS where the timestamp jumps, also with marker bit set
The timestamp jumps seem to line up with when audio artifacting is heard; looks like webrtc thinks there are missing samples around this time. also it seems like the opus TOC byte (RFC 6716) indicates a consistent number of frames per packet.
it sounds like the audio sent is continuous if we ignore RTP timestamps (per opusrtp test), but gaps in RTP timestamp (but no gap in sequence number) indicates pause in audio.
He can't find anything in opus RFC or otherwise that indicates gap in timestamp + no gap in seq num is anything but DTX
We also found an older reference on the freeswitch forums suggesting this has likely been around for years (but only manifests itself in some cases now, worst when video is included?):
https://lists.freeswitch.org/pipermail/freeswitch-users/2012-May/083665.html ?
I'm seeing a audio problem when listening to the operator when
calling into voicemail to listen to messages and a wideband codec is used.
Looking at a wireshark trace, I see gaps between transmitted RTP
packets that exceed the jitter buffer depth in the endpoint
softphone, causing underflow. This causes clipping of the front-end
of words such as "Pressed" sounds like 'ess' and "Last name" sounds
like 'ast name'. While this is generally not noticeable with the
G.711 codec, it causes these clipped audio phrases with wideband
codecs, such as BV32. It might be due to the processing delay in mod_voicemail between phrases?
I hope this helps - at this time, we don't believe it to be an issue with Bria although Bria seems to reproduce it well in your environment, particularly when video is included. We tested on one of our Freeswitch setups including video and were not able to reproduce anything to the same degree. We'll continue to review whether we may be able to adjust the jitter buffer in Bria to compensate, but that is just trying to mask the issue which we think originates with Freeswitch.
I use Opus as the primary codec for all devices. While trying to resolve an issue with Bria, Counterpath discovered through packet captures that FreeSwitch is sending "out of sequence RTPs". Please read their assessment below. I use default settings for the opus config (except for DTX testing see below). Opus is the first codec in vars.xml.
This was tested on 1.10.5 and 1.10.6 Nov 20 with same results. Tested on a test machine with Core i7 with nothing else running, only one extension.
The audio severity was not consistent so I lived with it. In early August we lost critical medical calls and voicemails that prompted me to work on the problem, so I can't say how long this has been around. Searching for FreeSwitch issues keywords RTP, OPUS, etc. it looks like others have had similar audio issues for some time, some still open, but I don't if they are related.
I have an AIFF voicemail file made by Freeswitch that plays fine as an audio file but is bad when played back listening to it as a Freeswitch VM message. I sent the file to Counterpath that consistently demonstrates the problem (75% unintelligible if Bria video on). I did a packet trace during playback from Freeswitch to Bria. That's where they see the gaps during playback. Keep in mind this also occurs on calls not just voicemail.
This information from Counterpath describes what they see playing back the voicemail:
We explored multiple theories and the packet captures you provided were invaluable. According to our development team, the primary issue appears to gaps in RTP timestamps as created by Freeswitch. One of our dev team tested playing back your DTX OFF capture.pcap to linphone and groundwire and heard audio artifacts in similar spots. Another used opussrtp and all pcap files sounded identical, however that utility does not take RTP timestamps or packet delays into account.
Analyzing your packet captures and quoting the dev team:
in DTX ON capture.pcap there are 53 audio packets from FS where the timestamp jumps, also with marker bit set
in DTX OFF capture.pcap there are 43 audio packets from FS where the timestamp jumps, also with marker bit set
in DTX ON Video Off capture.pcap there are 13 audio packets from FS where the timestamp jumps, also with marker bit set
The timestamp jumps seem to line up with when audio artifacting is heard; looks like webrtc thinks there are missing samples around this time. also it seems like the opus TOC byte (RFC 6716) indicates a consistent number of frames per packet.
it sounds like the audio sent is continuous if we ignore RTP timestamps (per opusrtp test), but gaps in RTP timestamp (but no gap in sequence number) indicates pause in audio.
He can't find anything in opus RFC or otherwise that indicates gap in timestamp + no gap in seq num is anything but DTX
We also found an older reference on the freeswitch forums suggesting this has likely been around for years (but only manifests itself in some cases now, worst when video is included?):
https://lists.freeswitch.org/pipermail/freeswitch-users/2012-May/083665.html ?
I hope this helps - at this time, we don't believe it to be an issue with Bria although Bria seems to reproduce it well in your environment, particularly when video is included. We tested on one of our Freeswitch setups including video and were not able to reproduce anything to the same degree. We'll continue to review whether we may be able to adjust the jitter buffer in Bria to compensate, but that is just trying to mask the issue which we think originates with Freeswitch.