[Freeswitch-users] OPUS: Jitter Buffer for bridged calls to use FEC?

Wed May 13 15:00:09 UTC 2020

Hi Dragos,

that helps.
Thanks a lot!

Alex

Von: FreeSWITCH-users <freeswitch-users-bounces at lists.freeswitch.org> Im Auftrag von Dragos Oancea
Gesendet: Mittwoch, 13. Mai 2020 15:24
An: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
Betreff: Re: [Freeswitch-users] OPUS: Jitter Buffer for bridged calls to use FEC?

You can either:

1. proxy media
<action application = "set" data = "proxy_media=true" />
This is something I would not recommend as proxy-media is not the standard way FS works. But it will preserve the seq gaps client B-> Freeswitch and it's lightweight.

2.  use JB + FEC and also have FS enable FEC on encoding so client A has FEC info as well. This makes more sense because client A <- FS can be subject of packet loss too  (new gaps).  It is heavy (transcoding twice) but in a network environment subject to a lot of packet loss improves quality.

So in your case  OPUS->FS(bridge)->OPUS with JB might be right.

But there may be other solutions apart from these.

Cheers,
Dragos

On Wed, May 13, 2020 at 10:16 AM Alexander Haugg <Alexander.Haugg at c4b.de<mailto:Alexander.Haugg at c4b.de>> wrote:
Hi,

thanks for the fast answer.

How is it possible to transport the package lost information from the “leg Client B” to the “leg Client A”?
If I understand You correct, for the bridged scenario OPUS to OPUS I don’t start a JB on Freeswitch side?
Without the JB the OPUS FEC feature cannot used on the Freeswitch.
For this case, the Client A need the package lost information from the “leg Client B” to repair the stream via FEC info.
The sequence numbers for the “leg Client A” will set new, completely independent from the sequence numbers of the “leg Client B”, for which reason the Client A have no PL (package lost) information.

                                OPUS                                                                   OPUS
Client A  (JB)      <---------------------             FreeSwitch         <-------------------                Client B
                No PL info                                           Package lost
                Because new
                Sequence Numbering

Is there a FreeSwitch pattern to solve this problem? Or is it not solvable without JB on FreeSwitch side?

Thanks a lot!

Von: FreeSWITCH-users <freeswitch-users-bounces at lists.freeswitch.org<mailto:freeswitch-users-bounces at lists.freeswitch.org>> Im Auftrag von Dragos Oancea
Gesendet: Dienstag, 12. Mai 2020 14:49
An: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org<mailto:freeswitch-users at lists.freeswitch.org>>
Betreff: Re: [Freeswitch-users] OPUS: Jitter Buffer for bridged calls to use FEC?

That snip of documentation for JB is pretty old and obsolete I'd say, it does not mention transcoding + FEC .
But where transcoding is used/needed is like a "point of termination".

Relevant docs (and best practices) about OPUS + JB + FEC here:
https://freeswitch.org/confluence/display/FREESWITCH/FreeSWITCH+And+The+Opus+Audio+Codec
If there's no JB then it can't be any FEC decoding.

If you just do OPUS->FS(bridge)->OPUS then no point of enabling the JB, it only adds delay.

Cheers,
Dragos

On Tue, May 12, 2020 at 10:23 AM Alexander Haugg <Alexander.Haugg at c4b.de<mailto:Alexander.Haugg at c4b.de>> wrote:
Hi,

I try to find out the best practice to use the OPUS features.
The scenario is:

Client A -------> (JitterBuffer) FreeSwitch -----------------------> Client B
               <---------------------- FreeSwitch (JitterBuffer) <--------

Is this the correct way?

In the documentation for OPUS the message is, JitterBuffer is needed to use FEC.
But in the documentation for the JitterBuffer is written:
              If both sides of a bridge are RTP and both sides have a jb, its fairly
              useless.  In fact if anything, it can worsen call quality.

              You should only run jitterbuffers at points of termination change of
              protocol.  Examples, if FS was hosting a conference or IVR, if you are
              bridging the call to a phone for instance, you want to not use a
              jitterbuffer because you want to preserve the original timestamps so
              your phone can use its own jitterbuffer.

I think, package lost is the start indicator for FEC and normally the RTP sequence number is the indicator for package lost, but the sequence number is valid for the own SSRC space only.
That means, if I have lost packages from Client A to Freeswitch is this information on the other side to client B missing, correct?

Now the question, what is the best practice handle this scenario?

Thanks a lot!
Alex
_________________________________________________________________________

The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.
Build your next product on our scalable cloud platform.

Join our online community to chat in real time https://signalwire.community

Professional FreeSWITCH Services
sales at freeswitch.com<mailto:sales at freeswitch.com>
https://freeswitch.com

Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users at lists.freeswitch.org<mailto:FreeSWITCH-users at lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com
_________________________________________________________________________

The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.
Build your next product on our scalable cloud platform.

Join our online community to chat in real time https://signalwire.community

Professional FreeSWITCH Services
sales at freeswitch.com<mailto:sales at freeswitch.com>
https://freeswitch.com

Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users at lists.freeswitch.org<mailto:FreeSWITCH-users at lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20200513/e42eadca/attachment-0001.html>