Wanted to update everyone on this:
We’ve seen some major improvements, and here’s what’s been done:
-We setup G.729 to certain endpoints. We definitely saw immediate improvements, but shortly after started getting complaints about some calls being very quiet. This was probably due to poor transcoding happening somewhere along the route.
-I started reading about mtr, and how to run reliable tests, and ended up running the VoIP test from this website: http://myspeed.visualware.com/indexvoip.php Right away, we were seeing high packet loss and high jitter from our main problem site. Other “semi-problem” sites showed similar, but not as poor, results. So I still haven’t played with mtr, but I’ve definitely seen a clear correlation between our poor audio quality sites and those that seem to have no problems by the results from the VoIP test URL above.
-I then dug deeper, with a fresh mind, and came across “jitter buffers”. Due to RTP packets arriving out of order, or severely delayed, they can be dropped and thus you hear breaking, weird sounds, poor quality, etc. Well, I read Jerry Warner’s reply on this post Enable Jitter Buffer and it changed my life.
On our FreePBX server, under Settings->Asterisk SIP Settings->Chan Sip, I enabled Jitter Buffer, and then set Force: Yes, Implementation: Adaptive, and Jitter Buffer Size: 300/500.
Our main problem site, as well as our semi-problem sites have great audio now! And we are using G.711, not G.729 per the quietness I explained above. Admittedly, I’ve heard a crackle here or there, but never any actual loss of a whole word or two like we were getting before. From what I understand, SIP devices have built in Jitter Buffer’s, hence FreePBX’s is disabled by default. Well, for really bad connections, the standard Jitter Buffer built into SIP devices doesn’t provide enough time for the delayed RTP packets to arrive and placed back in order before playing the audio through your receiver. By forcing the Buffer, you force the longer-than-default buffer size, and thus give more time for those laggy packets to be received and placed in order.
This does of course cause a delay in the audio, but it is not noticeable (I would say it seems less delayed than most cell phone conversations).
Anyway, a very non-technical and possibly somewhat erroneous analysis, but my hope is this will give some hope to those who are struggling with audio quality issues.