Tips and Tricks
gabriel_gr at February 17th, 2012 17:27 — #1
I've set up a remote callcenter routing calls through an IPSEC tunnel. Unfortunately I am having some issues with call quality (dropouts and gaps). I've investigated every option and I've finally realized that the internet connection in our remote site has unstable ping times (averages around 10-20ms but once every minute it can hit 100-150ms).
I am willing to trade some delay in voice in order to deal with this and I thought enabling jitter buffer would help.
I am using Freepbx 22.214.171.124 and asterisk 126.96.36.199
How can I enable Jitter Buffer?
niacs at February 17th, 2012 17:33 — #2
I'am not an expert in using a jitter buffer, but i think this kind of delays is even for a Jitter buffer to much. i think that looking for the reason of the RTT delay would help more.
Find out if the delay is on the uplink of the remote site or in between the sites using traceroute, if it's on the uplink then maybe the is a spike in bandwitdth usage by some device?
gabriel_gr at February 17th, 2012 17:36 — #3
I think I will try with a slight buffer of 40-50ms and see if it helps my case. It's not happening constantly and I was thinking it would get more acceptable.
Any idea on how to enable it?
skykingoh at February 17th, 2012 22:18 — #4
Gabriel - You did not tell us your version so how can we help you? Also suggest you read the Asterisk docs on jitter buffer so you understand what you are doing.
Variable latency like this is almost always caused by interface congestion.
cdsjerryw at February 29th, 2012 13:48 — #5
Don't know if you're still having problems or not. I see this is a couple of weeks old but jitter buffer has made a huge difference for me. We have remote phones and increasing the buffer has helped us. We seldom notice the delay and even when it's delayed, it's better than what happens without it.
I'm using Jitter buffer=enabled
Force Jitter Buffer=yes
Jitter Buffer logging=Disable
Jitter Buffer Size =300 jbresynchthreshold=500 (I've seen it suggested to use 1000 but mine is set to 500)
wizardofdos at March 28th, 2012 13:36 — #6
I have a similar issue at one site. Server is running asterisk 1.8 and FPBX 2.10
with a PRI. about 40 users working perfectly.
This is sitting behind a Sonicwall TZ-210 with a 50x5Mb business Cable connection from brighthouse as the primary wan and two bonded Cavalier T1's (carrying the dynamic PRI) as the failover.
Remote site has 5 phones behind a Sonicwall TZ-200 with another Brighthouse 50x5Mb business cable connection, and Cavalier T1.
Both data connections are one hop away on from each another on both carrier's respective network.
Sites are connected by IPSEC VPN via the sonicwalls. All endpoints are Polycom 550's with 4.x firmware
Average ping times are 18ms spiking to 100ms-225ms as often as 5 seconds as far apart and 15 seconds. I have made the vpn negotiate over both wan connections with no change.
I'm of course getting lots of Chop and Drops in the audio.
I'm wondering it Jitter Buffer can help me, but i don't want to introduce delay into 40 local phones to fix 5 remote phones...
Any input would be welcomed.
danerdavis at January 22nd, 2013 01:39 — #7
I am new to voip, but I would recommend you set up QoS at both routers (if sonicwall supports it) to give the SIP and RTP traffic priority. This made a major improvement for my remote users and site-to-site calls. I do not recommend you send the voice traffic over an ipsec vpn because of the extra overhead and delay.
cdsjerryw at January 22nd, 2013 15:03 — #8
I've played with a lot of QOS and in general, it will do nothing for you. QOS uses the last of your pipe, not the first. Unless your pipe is constant such as a T1 you never know how much you have. As a result, you never save what you need. The result is that you must assign a cap far below your bandwidth then reserve that space assuming your ISP respects your QOS. All you've really done is slow down your entire network and have gained nothing. QOS when you don't control the entire network is a waste of time.
reconwireless at January 22nd, 2013 16:44 — #9
Is MPLS an option between the two locations? Instead of using the Sonicwalls & VPN's to route your traffic, since you are using the same vendor at both locations does your vendor offer MPLS between the locations?
mustardman at February 7th, 2013 12:43 — #10
I will second that about the vpn. It's hard enough to get consistently good call quality over public internet connections. A VPN just makes it that much harder so is a very poor trade off for most scenarios imho.
wb3ffv at February 8th, 2013 16:41 — #11
Though your correct in that if you can't control QOS from end to end, you lose a lot, depending on where you congestion is QOS can still be a lifesaver.
For quite a few years, I had a T1 to a location, and we ran voice/data on the line. At times if a large file copy, or a backup was being done, it would easily max the T1 line, and needless to say VoIP call quality would get horrible. All upstream links were much faster, the bottleneck was at the one end, hands down.
We have Cisco grear, and I enabled QOS, setting up the appropriate queues, so that voice and voice control traffic had priority over normal data (priority queuing). At that point any SIP traffic always had priority over any other type of data, and from that point on I could bury the T1 with a backup, and still voice calls are perfect.
So to say setting up QOS/Priority Queues are useless, is quite wrong. Sure if something gets congested upstream on the internet, you could end up in the same boat, but if on your local end is your congestion, then it can go a long ways..
mazoola at April 28th, 2013 02:05 — #12
I know I'm late to the table, but I was struck by your comment, "Unless your pipe is constant such as a T1 you never know how much you have." Is that a reference to asymmetric vs symmetric data streams, or are you trying to run VOIP over something like cable? I've had excellent luck 'tuning' bandwidth utilization through traffic shaping, allowing me to set guaranteed minimum throughputs for various protocols (although, admittedly, I've always had to define queues based on address/port rather than protocol). This is true even for asymmetric links, as long as you remember to devote a high-priority queue to returning ACKs.
system at June 4th, 2014 15:28 — #13
This topic is now closed. New replies are no longer allowed.