>>>>>>
E:
I think the number one source of the problem is the VPN connection to the switch. The VoIP portion of the call proceeds from the laptop, through OpenVPN to an ASUS RT-N12/D1 router running Tomato Shibby, thenceforth to the Asterisk switch.
The ASUS router uses a MIPS/R2 300 MHz processor. Not the fastest kid on the block. In addition, since I'm paranoid, the block cypher is 256-bit AES. Also not the fastest kid on the block. Anyway, the upshot of all this is consistent round-trip ping times of 250ms. In other words, we have a 125ms penalty up front, before the jitter buffer ever comes into play.
I set the fixed jitter buffer to 60ms (about the smallest value that gave acceptable voice quality). I tried the adaptive jitter buffer with a high limit of 100ms but the adaptation algorithm fell on the floor, for whatever reasons. So, I went back to the fixed buffer. One would like to keep it as small as possible, since it also bones all of the analog calls that pass through the line card but 40ms, for example, didn't work.
There's probably another 20-30ms trip time through the switch and I'm sure the telco is inserting somewhere around half of their allotted delay (i.e. 70ms). By the time you add it all up, you're talking about 300ms one way.
Were it not for the VPN tunnel, the trip time to the switch would be more like 30-40ms. Not only that, but we could probably dispense with the jitter buffer because we'd be using UDP. That would make a huge difference in the 300ms one-way time.
Regarding your remark about Skype, there's a whole lot of stuff that Skype doesn't have to do. Basically, the call is just between two peers so the delay is only the packet transit time plus any processing time at either end. I could easily see this being less than 150ms, since I get consistent ping times over many hops to faraway places that are in the 80-100ms range.
As we said on the phone, its probably the best I could do, Jimmy, but it ain't going to cut it for anything other than the occasional call.
I:
I don't see the connection between UDP and the jitter buffer. The buffer is there to compensate for variations in transit delay. If there is no buffer, the codec starts decoding as soon as it gets its first frame of, say, 40ms and expects to find another frame of 40ms once its finished. No frame = problem for the codec. Let's say you have an average transit delay of 40ms, so the unwise would have a 40ms jitter buffer. This works great up to the point that the delay between any two packets doesn't exceed 40 ms, since you can work on saved data in the buffer. However, we all know what 'average' implies, so sooner or later, the delay between 2 packets will exceed 40ms, and the codec is boned. What you need is the standard deviation and use 2 SDs worth in the jitter buffer. Most codecs will tolerate 5% packet loss.
E:
I don't see the connection between UDP and the jitter buffer.
What I meant was, if you're using UDP, you can run without or much less jitter buffer and, when a packet is dropped, just take the hit.
Most codecs will tolerate 5% packet loss.
Even using UDP, any communications link that is dropping 5% of the packets on the floor is total s**t. So, one would expect something better than that. If the codec can hack 5% loss, using UDP and no jitter buffer might be a heck of a lot better than TCP with a 60ms buffer. You get way better RTT at the price of an occasional hiccup.
Thanks for your insights. It pays to know when its time to hang up
your butt-set and drink ginger beer.
<<<<<<