[Freeswitch-users] OPUS: Jitter Buffer for bridged calls to use FEC?
Dragos Oancea
dragos at freeswitch.org
Wed May 13 13:23:45 UTC 2020
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>
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> *Im
> Auftrag von *Dragos Oancea
> *Gesendet:* Dienstag, 12. Mai 2020 14:49
> *An:* FreeSWITCH Users Help <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>
> 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
> 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
> 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
> 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
> 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/741c0e55/attachment.html>
More information about the FreeSWITCH-users
mailing list