|> Until recently I had 768k/128k. Eventually I was able to upgrade to a |> whopping 1M/384k but the service still does not seem suitable for |> VOIP. The funny thing is that the problem appears to be mainly in the |> downstream direction. The various web sites that offer tests for VOIP |> suitability seem to concentrate on the upstream path. I'd really like |> to understand better what is going on...
|Who is providing your DSL service?
Verizon MA
|I've often suspected the likes of |Verizon and other companies of deliberately blocking VoIP traffic if |it isn't destined for THEIR servers.
It's probably not that simple. I see similar problems regardless of whether I go directly or through an encrypted tunnel. The latter hides the details from the local ISP and it's a rather non-standard setup (IPSEC inside L2TP) so I doubt they are looking at, e.g., the packet sizes.
The problem is not total failure, and in fact sometimes it works acceptably. But a lot of the time I get long dropouts and the router providing the voice port shows lots of silence fill. I've gone so far as to write programs to simulate packet streams similar in size and timing to RTP streams, but at least when I run them I'm not seeing either drops or out-of-sequence packets. Of course, the end points are not the same as those of any of the VOIP services I've played with so I suppose the problem could be far-end rather than near.
The simplest explanation is that the DSL downstream is just way oversubscribed and happens to perform poorly often enough to make for a bad VOIP experience. If this is typical, though, I wonder how things like MagicJack work acceptably. Maybe I'm just too sensitive...
Dan Lanciani snipped-for-privacy@danlan.com