Ah, memories! How I've thrashed the same issue.... Have you considered using GSM, rather than the other codecs? Or G726/16? I've used both for shakey links and cell phone clients with good success. They're basic codecs, but low bandwith and quite stable- a big improvement over G711 in poor conditions. The jitter buffer works well in combination with these codecs, say up to 200ms is comfortable enough without too much latency. Another way to mask packet loss is to reduce Ptimes to 10ms. This adds a smallish overhead to traffic, but still well below G711 and much less noticeable than the stock 20ms. By doing this, at any % of packet loss, you effectively reduce equivalent audio loss by about 30 - 40%, and distortion itself is reduced because the gaps are half the size, masking the loss to some extent to the hearer. It's the difference between a call that occasionally sounds a bit fuzzy, as opposed to downright choppy. Francis On 29/01/2014 11:04 AM, Lawrence Conroy wrote:
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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org