<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div class="gmail_attr">I can't speak much directly about the confbridge packet loss scenario, but can talk a bit about OPUS. No guarantees it'll be helpful to this situation, or not information you don't already know :-)</div><div class="gmail_attr"><br></div><div class="gmail_attr">Most folks will want to leave codec OPUS alone, and let it do its thing. Meaning, OPUS is pretty good at automatically adjusting itself to a given situation. However, it does have some options, mostly encoder side, that one can configure if needed, or desired. Note though, the setting of some these options is more along the lines of making a recommendation to the encoder/decoder vs telling it exactly what to do. Also, it can be a balancing act when doing so. A gain in one direction may be a loss in another. For example, setting a higher 'complexity' value will probably result in more CPU utilization.</div><div class="gmail_attr"><br></div><div class="gmail_attr">Now on to OPUS and packet loss. With nothing configured OPUS _should_ default to doing native PLC when packet loss is detected. FEC can also help in a packet loss situation, but it's a little more complicated when, and how that occurs. Enabling FEC does not necessarily mean it's being utilized. For instance, in order for FEC data to be decoded by Sangoma's codec_opus module for Asterisk several things must occur:</div><div class="gmail_attr"><br></div><div class="gmail_attr">1) it must be enabled through configuration</div><div class="gmail_attr">2) both sides of a call must negotiate for it (via SDP)</div><div class="gmail_attr">3) packet loss must be perceived by the codec_opus module</div><div class="gmail_attr">4) a frame containing FEC data is received</div><div class="gmail_attr"><br></div><div class="gmail_attr">Similarly, several conditions apply as to whether or not FEC data is encoded:</div><div class="gmail_attr"><br></div><div class="gmail_attr">1) it must be enabled through configuration<br></div><div class="gmail_attr">2) both sides of a call must negotiate for it (via SDP)<br></div><div class="gmail_attr">3) the encoder must be told to expect packet loss</div><div class="gmail_attr">4) the codec must be operating in a mode conducive to lower bandwidths.</div><div class="gmail_attr"><br></div><div class="gmail_attr">More details below ...</div><div class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Wed, Oct 20, 2021 at 1:27 PM Pascal Cadotte <<a href="mailto:pcm@wazo.io" target="_blank">pcm@wazo.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thank you for taking the time to look into this and reply. It is very appreciated.<div><br></div><div>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 degraded.</div></div></blockquote><div><br></div><div>In the non Confbridge scenario is transcoding occuring? If not then Asterisk is simply passing through the audio frames, which may account for some of the improved audio quality. Try forcing a transcode scenario between two legs of a call and see if the audio sounds better or worse. Any options set for codec_opus are only utilized while encoding or decoding.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I've added JITTERBUFFER to all channels and added the option to the confbridge bridge.</div><div>I've configured opus with fec=yes and have tried packet_loss=0 and packet_loss=50 with no difference in sound quality.</div></div></blockquote><div><br></div><div>The 'packet_loss' option is an encoder side only option used in conjunction with the 'fec' option. Setting the 'packet_loss' option adjusts an internal threshold as to when the OPUS encoder should include FEC data in an encoded frame. The higher the expected 'packet_loss' value the lower the threshold.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I've used the following command on the laptop running one of the softphone to simulate packet loss</div><div>sudo tc qdisc add dev enp0s31f6 root netem delay 2000ms 100ms 10% distribution normal</div><div><br></div><div>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?</div></div></blockquote><div><br></div><div> It's hard to tell at this point. If you haven't already done so I'd try the following:</div><div><br></div><div>* Use a different codec in the Confbridge scenario, and see how it compares. For instance, if you swap opus for ulaw does it sound worse, better, about the same?</div><div>* Next using only the default configuration forcodec_opus. Does it sound better than the ulaw scenario?</div><div>* Enable FEC for codec_opus. Does it sound better, worse, the same?</div><div>* If worse or the same, then ensure both sides negotiated for it. Ensure/force the encoder into a lower bandwidth mode by setting the 'max_bandwidth' option to narrow or medium, or set the 'max_playback_rate' option to 16khz or less. Ensure the 'packet_loss' option is also appropriately set (might just try 100, and if things improve then work down).</div><div>* Enable the jitter buffer (Can try this option before enabling FEC as well if you want)</div><div><br></div><div>If after all of that you're still having issues then try to find out if the problem is occuring on the encoding or decoding side of things. Not sure if this would work, but to check this you could try recording the Confbridge, or perhaps "spy" on the incoming (decoding) side. I believe in the recording scenario the Confbridge should write to the file after decoding, but before encoding. So you should be able to listen to the recording to see how the decoded audio sounds.</div><div><br></div><div>As far as looking at Asterisk sources, and if you're interested in how it might all work, or not work then I'd start in main/translate.c (Note, not the easiest code to understand!). Specifically, the ast_translate, and framein functions. In the framein function for example you can see if a codec implementation has the 'native_plc' flag set it will pass things on to the codec implementation to be handled there. But this only happens if a given frame's datalen is 0. So might want to check, and look for the situations where Asterisk sets the length to 0. Generic PLC appears to only be available for 8khz slin (see generate_interpolated_slin in main/translate.c). A comment there says the interpolated frame may be handled later by other resources. You'd have to track down what those are if any are still around.<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Thanks again for your time.</div><div><br></div><div>- Pascal Cadotte Michaud</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 20 oct. 2021 à 01:43, Olle E. Johansson <<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 19 Oct 2021, at 21:56, Matt Fredrickson <<a href="mailto:mfredrickson@sangoma.com" target="_blank">mfredrickson@sangoma.com</a>> wrote:<br>
> <br>
> On Thu, Oct 14, 2021 at 2:37 PM Pascal Cadotte <<a href="mailto:pcm@wazo.io" target="_blank">pcm@wazo.io</a>> wrote:<br>
>> <br>
>> Hello everyone,<br>
>> <br>
>> 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.<br>
>> <br>
>> 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 <a href="https://wiki.asterisk.org/wiki/display/AST/PLC+Restrictions+and+Caveats" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/PLC+Restrictions+and+Caveats</a> "In addition, MeetMe and ConfBridge calls will not use PLC."<br>
>> <br>
>> We are looking into ways to improve this situation and would like to gather some information about this restriction before working on it.<br>
>> <br>
>> 1. Does anyone know why PLC has not been implemented for meetme and confbridge?<br>
>> 2. Is there a known workaround to allow a channel to have PLC enabled while being in confbridge?<br>
>> 3. Is it a problem many people have? I've only seen this question that seems to be related <a href="https://community.asterisk.org/t/jitterbuffer-plc-fec-etc-how-do-i-know-they-are-working/85146" rel="noreferrer" target="_blank">https://community.asterisk.org/t/jitterbuffer-plc-fec-etc-how-do-i-know-they-are-working/85146</a><br>
>> 4. Is there something in progress that we could contribute to?<br>
>> <br>
>> The tests have been made using the opus codec, PJSIP on a WSS transport on Asterisk 18.6.0.<br>
>> <br>
>> Given two users Alice and Bob<br>
>> Given a 10% paquet loss on Alice<br>
>> When Alice and Bob are talking through confbridge Bob hears a lot of cracking<br>
>> When Alice and Bob are talking to each other using the Dial application to call Bob's phone, the call quality is almost flawless<br>
> <br>
> I'll take a quick stab at an answer here.  I went looking at<br>
> translate.c, plc.c, and channel.c, and here are some notes that I<br>
> wrote as I was trying to remember how this works:<br>
> <br>
> The generic plc code in Asterisk was written a long time ago and can<br>
> be only used for 8 KHz SLINEAR, not for other sample rates.  I'd<br>
> presume that this means a codec such as OPUS needs to output to 8KHz<br>
> SLINEAR somehow to even start using the generic PLC code.<br>
> <br>
> It appears that generic plc is actually calling the concealment<br>
> functions when making a write to an ast_channel (so after a frame is<br>
> produced from a mixing bridge presumably and goes out to a channel<br>
> driver) - not on the reception side, reading a frame from a channel.<br>
> (channel.c)  Unless someone else wants to go look at and correct me, I<br>
> would assume that that means concealment comes after a bridge mixes<br>
> frames together and presumably all input information about packet loss<br>
> is wiped clean (meaning no generic PLC is happening with a mixing<br>
> bridge).<br>
> <br>
> Looking at the codecs that support native PLC (such iLBC, speex, etc)<br>
> it looks like they implement this on the conversion to SLINEAR (and<br>
> correspondingly on an ast_read on the channel in quesiton), which<br>
> should work for a case where you have a confbridge or meetme involved.<br>
> <br>
> For Sangoma's codec_opus, we have support for its native PLC and FEC<br>
> functionality also, so I'd make sure that you have fec=yes enabled for<br>
> its entry in codecs.conf.<br>
> <br>
> I'd also make sure you have jitterbuffer enabled on any<br>
> channels/conferences in question for good measure.<br>
> <br>
> So, to sum it up:<br>
> If you're using OPUS, use the opus native fec option (I think PLC<br>
> should be happening also automatically as well) and make sure that the<br>
> jitterbuffer is enabled on the channels/conferences in question.<br>
> <br>
> If you'd like to use a codec with non-native PLC, you're going to need<br>
> to figure out how to get the generic PLC code working on the<br>
> ast_read() instead of the ast_write() to the channel in question.<br>
> (hoping my assumptions about some of this is correct too :-) )<br>
> <br>
> Hope that helps,<br>
> Matthew Fredrickson<br>
<br>
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.<br>
There was settings in rtp.conf and possibly sip.conf to enable this.<br>
<br>
The code was published in one of my branches but never integrated into asterisk as far as I remember.<br>
<br>
/O<br>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div></div>