My point is that delays can come from many different areas, some you might not be aware of because they are in the backend. To be clear, I'm not saying the problem is on your end.jhphone wrote:Good points. But Internet cannot be causing this amount of delay. Lets discuss your point "...one server hop of 1ms bufferi[s] 10KB before sending anything and that could account for 400ms…"
... (followed by discussion of buffering)
All that matters is you get the sum total of the delays to something reasonable.
Looking at it from a black box, you can determine the network delays you are directly exposed to, but cannot see into the back-end at Ooma.
I gave you fictional examples at the extreme end just to illustrate a point, not to suggest that is exactly what is happening. Don't assume the problem must be buffering, as in it was (poorly) designed to work this way. There are other possibilities, especially since it was working reasonably at some point in the past.
For example another fictional example could be their transcoding server was working fine, but switched some network pathway or equipment resulting in periodic packet loss (which you can't see because it isn't your stream losing packets). Yes the transcoding server is "buffering" to do the transcoding, but buffering wouldn't be the issue in this case, rather it would be the packet loss causing retransmissions, which could be detected at the transcoding server, but at your end would just result in delays in your stream. Maybe somewhere some stream got configured to use TCP instead of UDP and that is interacting with packet loss to delay packets. Perhaps it is something else entirely. On my DSL connection, if they use fastpath, the latency is 40ms less than if they choose interleave. There is no explicit buffering going on in the network equipment, but the TCP protocols handle the delays or UDP protocols have designs to deal with it.
My point again is to triangulate on the delays first, and don't assume the cause. My examples are not meant to be bulletproof explanations, just to illustrate points. Your voice call is not simply a stream of packets from your ooma to the ooma servers and back. There's a whole other set of network and servers happening behind the scenes on the back-end.