Over the last couple of years, when I’ve wanted to take the temperature of the Vonage user community, I’ve often stopped at the Vonage Forum. This is a privately run enterprise, totally independent of Vonage. More than 23,000 people have joined the Forum since it was officially launched three years ago this month.

Anyhow, I have been noticing a growing number of posts in which many Vonage users and Vonage Forum Members have been complaining about the quality of Vonage calls over Comcast broadband connections.

It’s interesting that there are relatively few similar complaints about the quality of these Vonage calls over other broadband provider networks. Occasionally you’ll read about Verizon or AT&T complaints, but rarely.

But something has happened. Two weeks ago, a Vonage Forum Member named rdstoll began a Vonage Forum thread called Comcast vs. Vonage. The last time I checked, this thread had 116 posts and nearly 7,000 page views. That’s an exceptionally high number.

Although you will see all manner of opinions on this thread, there seems to be a sentiment that - politely put - Comcast could really be doing a better job of carrying Vonage bits.

There’s not much of a leap from that belief to one, expressed by some Vonage Forum Members, that the connection quality problems they are having over their Comcast lines just might not be coincidental. What’s also important to recognize is that many of these complaints are from Vonage users and Forum Members who have been around for awhile, and are more used to giving problem-solving advice in the Forum then venting about it.

“I am no believer in conspiracies, but having seen two episodes of Vonage issues tied directly to ‘work’ being done at Comcast, I cannot help but wonder what Comcast is up to,” rdstoll wrote in his thread-launching post. “Have absolutely no faith in baby bells or cable companies, and would not be surprised if they weren’t tinkering with some things to piss off Vonage users.”

“Well, Comcast is doing their own VoIP service in some areas now…. considering they have a competing product at a higher price…. well, you can be the judge on it,” a Forum Member named VonageTPA adds.

“I certainly hope that your conspiracy theory belongs on a bad episode of the ‘X-Files’, but sadly it’s not outside the realm of possibility,” writes NateHoy, who has been chosen “Vonage Forum Member of the Week at least twice by Forum founder and admin Dan Connor.

“VoIP from ‘independents’ like Vonage is a threat to the ISP industry because they are ‘yet another bandwidth hog’ making flat rate Internet access harder to provide due to increasing bandwidth demands,” NateHoy adds. “They are also a threat to the local telcos as they are direct competitors.

“Unfortunately, VoIP depends on ISP’s for bandwidth so our lines work, and on local telcos for access to their local bridges to hop onto the POTS network so we can talk to mere (mortals),” he writes.

It’s in the last graf of his post that NateHoy implies that all may not be on the up and up:

“And a little intentional ‘oopsie’ goes a long way toward discrediting VoIP…”

Are these complaints scapegoating by Vonage users, or is there something here? TalkBack and let us know!

Related Articles

In recent hours, Slashdot users have been commenting a lot on yesterday’s post in which is referred to an atmosphere of distrust some Vonage users have been directing toward Comcast. I first noticed this in a Vonage Forum thread I linked to. That thread, “Comcast vs. Vonage,” has just passed 10,000 page views.

Now, there’s a Slashdot thread linking to ours. The thread is called Comcast Accused of Blocking VoIP.

Posts run the gamut, but there’s one that really grabbed me. I was especially seized by it because the proportion of libertarian-minded thought on Slashdot is way out of proportion to the popularity of libertarian thinking in the general electorate.

The post I am referring to was composed by Slashdot reader bigpat.

He chooses to comment on an earlier post that said in part: “All these ideas are entirely possible but it could simply be that Comcast doesn’t provide the kind of broadband consistently necessary to use VoIP.”

Here’s what bigpat writes:

Well, there is an easy test. If their VOIP works fine and other people’s don’t then they are probably gumming up the lines with QoS. ISPs have been working on different levels of service for differently labeled packet s of data for a while now and I think it should be clear to everyone that QoS really stands for “pick your pocket”, not “quality of service”. Quality of Service is fine when companies like Comcast don’t have local monopolies or don’t collude with their only other competitor… potentially that would be Verizon in my area, in order to fix service offerings.

I am libertarian, but QoS (or whatever they want to relabel it as) is an area which needs regulation. Make them simple regulations, make them so that they promote competition. Unfortunately maybe the only way to do this is to prevent ISPs from offering any add on services at all, other than basic bandwidth, addressibility and letting them charge flat published and competitive rates for QoS which get charged directly to the customer and aren’t a part of secret deals. Otherwise it will be nearly impossible to prevent them from deciding which services succeed and which ones fail if they control the playing field, the referees and have their players in the game all at the same time. If gone unchecked, they could prevent other companies and other services from being provided to their customers, literally, at the flip of a switch.

Now for a typical Slashdot libertarian to call for QoS regulation- indeed any regulation - that’s like a religious conservative all of a sudden coming out as a Wiccan.

Related Articles

Note: This post contains code that the code-author re-posted as an update on Sunday, March 5.

You’re looking at a screen grab of a 10-participant Skype conference call- on an AMD X2-powered CPU.

“Now wait a minute,” you might be saying. “I thought Skype conference calls on non-Intel boxes had a five-participant limit.”

Well, yes, they do- and as I posted here the other day, AMD’s attorneys are not too pleased about this. They sense that this restriction might be deliberate - possibly a living artifact of a partner alliance between Skype and Intel that limits Skype 2.0’s conference call capacity on non-Intel boxes.

I suppose that is to be decided, but a blogger-hacker named Maxxuss has written code that he says will defeat this restriction.

Maxxuss has posted a hack for this five-participant ceiling. And he has made it publicly available, code and all.

I, of course, cannot personally vouch for the code, nor warn against it. But this is big news, and that’s a lot of why we are here. And you, too.

So let us see what Maxxuss has come up with.

“The patch is the result of two phases: code analysis and design of the patch. The code analysis, or reverse engineering, reveals the relevant code block, which overrides Skype’s limitation for Intel’s dual-core CPUs,” Maxxuss writes. “The patch design isolates the minimal set of instructions that need to be modified to cancel this limitation.”

As to the Code Analysis (i.e. Reverse Engineering) at work here, Maxxuss writes that an initial analysis of the executable revealed that the code references the string “You can now add up to 9 people to this call - learn more“”.

Maxxuss then provides the relevant call block code:

He then takes several more steps to explain how he gets to the core logic.

Next, he walks readers through some steps that lead to how to “suppress” the code that he believes limits Skype conference calls on AMD-powered PCs to a limit of five participants:

The routine with the patching code is located at 0×7251C0, which is unused otherwise. It is a bit more complex as expected, due to the fact that we cannot simply write into the code segment - this would result in a memory protection exception, since Windows and Skype itself sets the access rights to “executable and readable” (i.e. not writable). However, temporarily circumventing the memory protection is easy. We just use Windows’ VirtualProtect kernel function. So, in summary, the patch code does:

1. Make the code at 0×7FF7D0 - 0×7FF7E0 writeable and save original access rights,
2. Patch three bytes,
3. Restore original access rights,
4. Do what the original code at 0xB7CC40 did, which we have replaced.

For clarity, I will now post a rendering of Maxxuss’ assembler code in two screen grabs. Update: Maxxuss re-posted this code on Sunday, March 5:

And now the second part (which includes the last section of the updated first grab, for continuity purposes);

Has this code changed your mind or reaffirmed your suspicions about the Skype-Intel-AMD controversy?

Related Articles