[asterisk-dev] Packet Loss Concealment in confbridge

Pascal Cadotte pcm at wazo.io
Wed Oct 20 13:26:28 CDT 2021

Thank you for taking the time to look into this and reply. It is very

I've done some more testing to get as few variables as possible from the
tests I'm doing. This time around I've disable genericplc in codecs.conf to
check the results from the opus fec option. With two users using the opus
codec. When using the Dial application a 10% packet loss yields a decent
audio quality. When using the Confbridge application the audio is VERY

I've added JITTERBUFFER to all channels and added the option to the
confbridge bridge.
I've configured opus with fec=yes and have tried packet_loss=0 and
packet_loss=50 with no difference in sound quality.
I've used the following command on the laptop running one of the softphone
to simulate packet loss
sudo tc qdisc add dev enp0s31f6 root netem delay 2000ms 100ms 10%
distribution normal

Would I be able to dig deeper into this problem with the Asterisk sources
only or does it sound like a problem in the codec implementation?

Thanks again for your time.

- Pascal Cadotte Michaud

Le mer. 20 oct. 2021 à 01:43, Olle E. Johansson <oej at edvina.net> a écrit :

> > On 19 Oct 2021, at 21:56, Matt Fredrickson <mfredrickson at sangoma.com>
> wrote:
> >
> > On Thu, Oct 14, 2021 at 2:37 PM Pascal Cadotte <pcm at wazo.io> wrote:
> >>
> >> Hello everyone,
> >>
> >> We've been trying to improve the quality of our video conferences using
> confbridge. We've been able to figure out how to get the video usable for
> all participants even for users using bad internet connections using the
> REMB configuration options.
> >>
> >> However, we are still having problems getting decent audio when there's
> packet loss. We think this is because PLC is not used for channels in
> confbridge. We found that information in this page
> https://wiki.asterisk.org/wiki/display/AST/PLC+Restrictions+and+Caveats
> "In addition, MeetMe and ConfBridge calls will not use PLC."
> >>
> >> We are looking into ways to improve this situation and would like to
> gather some information about this restriction before working on it.
> >>
> >> 1. Does anyone know why PLC has not been implemented for meetme and
> confbridge?
> >> 2. Is there a known workaround to allow a channel to have PLC enabled
> while being in confbridge?
> >> 3. Is it a problem many people have? I've only seen this question that
> seems to be related
> https://community.asterisk.org/t/jitterbuffer-plc-fec-etc-how-do-i-know-they-are-working/85146
> >> 4. Is there something in progress that we could contribute to?
> >>
> >> The tests have been made using the opus codec, PJSIP on a WSS transport
> on Asterisk 18.6.0.
> >>
> >> Given two users Alice and Bob
> >> Given a 10% paquet loss on Alice
> >> When Alice and Bob are talking through confbridge Bob hears a lot of
> cracking
> >> When Alice and Bob are talking to each other using the Dial application
> to call Bob's phone, the call quality is almost flawless
> >
> > I'll take a quick stab at an answer here.  I went looking at
> > translate.c, plc.c, and channel.c, and here are some notes that I
> > wrote as I was trying to remember how this works:
> >
> > The generic plc code in Asterisk was written a long time ago and can
> > be only used for 8 KHz SLINEAR, not for other sample rates.  I'd
> > presume that this means a codec such as OPUS needs to output to 8KHz
> > SLINEAR somehow to even start using the generic PLC code.
> >
> > It appears that generic plc is actually calling the concealment
> > functions when making a write to an ast_channel (so after a frame is
> > produced from a mixing bridge presumably and goes out to a channel
> > driver) - not on the reception side, reading a frame from a channel.
> > (channel.c)  Unless someone else wants to go look at and correct me, I
> > would assume that that means concealment comes after a bridge mixes
> > frames together and presumably all input information about packet loss
> > is wiped clean (meaning no generic PLC is happening with a mixing
> > bridge).
> >
> > Looking at the codecs that support native PLC (such iLBC, speex, etc)
> > it looks like they implement this on the conversion to SLINEAR (and
> > correspondingly on an ast_read on the channel in quesiton), which
> > should work for a case where you have a confbridge or meetme involved.
> >
> > For Sangoma's codec_opus, we have support for its native PLC and FEC
> > functionality also, so I'd make sure that you have fec=yes enabled for
> > its entry in codecs.conf.
> >
> > I'd also make sure you have jitterbuffer enabled on any
> > channels/conferences in question for good measure.
> >
> > So, to sum it up:
> > If you're using OPUS, use the opus native fec option (I think PLC
> > should be happening also automatically as well) and make sure that the
> > jitterbuffer is enabled on the channels/conferences in question.
> >
> > If you'd like to use a codec with non-native PLC, you're going to need
> > to figure out how to get the generic PLC code working on the
> > ast_read() instead of the ast_write() to the channel in question.
> > (hoping my assumptions about some of this is correct too :-) )
> >
> > Hope that helps,
> > Matthew Fredrickson
> I had this problem with pure RTP channels using ALAW. To fix it, since
> G.711 is a simple codec, I wrote “Poor mans PLC” where the RTP channel just
> copied the previoius packet up to a maximum number of packets. This fixed
> our problem, but it was very specific and very crude.
> There was settings in rtp.conf and possibly sip.conf to enable this.
> The code was published in one of my branches but never integrated into
> asterisk as far as I remember.
> /O
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20211020/d8d26a57/attachment.html>

More information about the asterisk-dev mailing list