[Freeswitch-users] Freeswitch Transcoding, Bridging and PLC

[Russell Treleaven]

AMR might be appropriate. Sangoma hardware transcoders are AMR capable.


------------------------------
*From:* "Lawrence Conroy" <lconroy at insensate.co.uk>
*To:* "FreeSWITCH Users Help" <freeswitch-users at lists.freeswitch.org>
*Sent:* 28 January, 2014 8:06 PM
*Subject:* Re: [Freeswitch-users] Freeswitch Transcoding, Bridging and PLC

Hi there,

Multiple transcoding is not going to help your system overall audio
mean option score; converting from something basic like G.711 to a
compressed/"clever" codec and then back has been the bane of long
distance comms for years. [repeat for originator local telco, transit
telco, and terminating local telco for the definition of mud].

PLC is a feature in a number of codecs; basic idea is to drop the
output and repeat what you have in the face of errors or loss rather
than just blat the data out (or have sudden silences followed by the
next data value, whatever its amplitude). It can't perform miracles,
and if your packet loss gets above a percent or so, OR hits in longer
bursts, these are going to be noticeable almost whatever you do.
(remember, at about about 5% packet loss, TCP tends to die quite fast,
so it's not just VoIP that suffers).
Jitter resilience is very useful to avoid garbling, but again, it
requires at least a reasonable channel to give good results.

Skype's codec does have pretty good error concealment, pretty good
error limitation characteristics (low latency recovery), and they
spent a looooong time tuning it :). It's not just the codec, but the
whole path in the app that gives the result [so I'm told :].

If errors & loss are more than a few percent sustained, you have a
"challenge". At above 5% or so, you have "an opportunity to succeed".

SO .....
Q: what packet loss are you seeing over the "poor link", what is the
packet loss characteristic (bursty, random, or ...), and what is the
jitter?
Wireshark is your friend and is certainly my first stop, but to get a
feeling for random bit errors, you may need something a tad more
specialised.

all the best,
  Lawrence

BACKGROUND:
 Alan Duric, (who designed the ILBC codec at GIPS) told me that the
goal they had was to reduce the impact on sound output of losing a
packet. The problem with compressed codecs like G.729 (and G.723) is
that the output depends on more than one packet -- lose a packet and
the impairment lasts for a few packet times, which is long enough to
be noticeable. I know that GIPS also worked on advanced jitter buffers
with customers (a certain Finnish/Estonian VoIP company was,
allegedly, involved).
IIUC, the Skype codec is similar to ISAC and other "low impairment
latency" codecs; it's designed to "take the hit" when the packet loss
appears (and not to spread the impairment across a number of packet
times). Unsurprisingly, it takes the knowledge gained from the GIPS
codec work and applies that.

The issue with G.711, where output does not depend on previous packets
in the stream, is the bandwidth may be a tad high for marginal links.
Personally, I choose G.711 by default as it has a good enough MOS, and
is simple enough that pretty much every device supports it (and it's
really hard to get an implementation wrong when it's just a lookup
table :). I like G.722 as it has a good MOS, is (relatively) simple so
codec implementations tend not to be buggy any more, and is pretty
widely supported; however, you really DO need bandwidth for that and
it suffers with non-trivial packet loss => it won't be appropriate for
your problem.

SILK should be OK (albeit the bandwidth might be a tad high in normal
operation).
Hmm .... from what company did that come? It certainly has that low
latency recovery tradition, and was coupled with good buffer control
in Skype.
Can't say much about OPUS as it has way too many knobs to twiddle for
my liking so I've tended to shy away for production use. I kinda
wonder if by default it assumes typical Interwebs network quality
(which is pretty good), and goes for the high MOS "sweet spot".
:BACKGROUND


On 28 Jan 2014, at 23:00, jay binks wrote:
> So I have a freeswitch usecase that Im having trouble solving and would
> like the collective help of the community.
>
> I have a customer who has a commercial PBX on site ...  ( Supports SIP )
>
> However their network connectivity is quite bad at times, and there are no
> other options for connectivity.  ( lets say they are a mine site or
> something remote like that )
>
> SIP calls on this link sound pretty bad when they experience network issues
> ( mainly jitter & some loss ), BUT Skype calls sound pretty good.  ( not
> perfect, but a LOT better than say G711, G729 or any other open standard
> VOIP Call )
>
> What we considered doing is deploying a freeswitch box on their site, and
> one in a DC with reliable connectivity.   have their PBX send G711 calls to
> the onsite freeswitch, and have freeswitch transcode this call to OPUS /
> SILK.   send the OPUS / SILK over the bad network to the co-located
> freeswitch box, who will then trancode back to G711 and set the call to the
> PSTN network like normal.
>
> The intention here is to leverage the Packet Loss Concealment baked into
> OPUS / SILK
> as I imagine that is what gives skype its ability to hide the audible
> effects of loss.
>
> So far I have only set this up in a lab and used WANem to simulate loss,
> jitter, out of order packets.  but ive found OPUS / SILK to be no better
> than G711 at covering loss.
>
> I even tried with a 2 sec jitter buffer on both FS instances ( on each end
> ), which made no difference.
> I was expecting the jitter buffer to add more delay to the call, but it
> didnt even do this ... maybe I misconfigured something in the jitter
> buffers.
>
> anyways..   I would like some help with this,  has anyone tried doing
> anything similar to this and had success ?
>
> --
> Sincerely
>
> Jay Binks


_________________________________________________________________________
Professional FreeSWITCH Consulting
Services:consulting at freeswitch.orghttp://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication
Server

Official FreeSWITCH
Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com

FreeSWITCH-users mailing
listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140129/61f07752/attachment-0001.html