Federal Court Throws Out Minnesota VoIP Regulation
An anonymous reader submits: "Voxilla reports that the FCC will announce Friday that 'a federal court has issued a permanent injunction against a recent ruling by the Minnesota Public Utilities Commission to regulate Voice over IP provider Vonage as a telephone company.'
This is a significant move towards stopping recent movement by states to regulate VoIP -- most notably, California vs. VoicePulse and Wisconsin vs. Packet8."
What is the fundamental difference between a traditional telephone company and purely VoIP-based companies? VoIP is slowly making it's way into traditional phone companies, does this make them less of a phone company?
I'd say the difference is quite minimal for the end user.
I'm just rambling, but I'd sure like to hear my fellow Slashdotters' thoughts.
.: Max Romantschuk
Why should there be any more regulation when the very data can be captured easily?
and, on a related note, will Microsoft be compelled to register as a bank? People use their technology to do online banking you see...
-
If you keep throwing chairs, one day you'll break windows....
My 73 yo father switched to broadband (10 Mbit/sec), voip, etc some two years ago. He surfs, reads the news, etc. He also pays all his bills via the net and is fighting hard to get me do it too - "Come on, it's really easy", he says. Not only that, know he wants me to install Linux on his machine so "he can see what all the fuzz is about". No, he never had a technical diploma of any sort.
Now, he bugs me with his fancy new voip connection. But, I am sure he never lobbied in Minnesota for their decision.
As someone who works in this industry, I thought I'd share some of the future of telecomm for those who aren't 'in the know'. All communication lines going to any endpoint (home, business, sensors, etc) are quickly moving to an IP based data network. Unfortunately, there are two problems that governments and current telephone companies face:
:-)
1) Roughly 50% of their voice revenue stream comes from per minute connection charges, other carrier access charges, & regulation charges (govn't). These will evaporate when subscribers move to data driven VoIP (ie: you pay a flat fee for DSL or cable modem bandwidth now, and it can run all your voice calls to anywhere in the world). Eventually the PSTN connection part will no longer be necessary, so Vonage will disappear as we know it today, but it has finally woken up the telcos to what the future will bring.
2) Pretty much the other half of their revenue stream comes from the 'premium' voice feature services (call waiting, text messaging, etc), all of which are quickly moving from the class 5 switch into the phones themselves (aka: free).
What do you do when your primary revenue stream evaporates? Fight it in the courts or with govn't officials. Remember, govn'ts have been taking a nice chunk of that revenue for themselves as well.
We will have to move to a bandwidth & quality of service (QoS) based payment style. A minimum bandwidth is given for a flat rate (which will include -all- voice), and extra bandwidth will be provided on demand at an agreed QoS. The higher the bandwidth & QoS, the higher the fee.
Things to watch out for: VoIP everywhere, SIP phones/services, VoWLAN, current voice carriers moving their infrastructure to their IP networks, and govn't regulations dictating that comm lines (called data services & unregulated) become regulated for QoS.
The companies that move to this model last will not survive. They aren't going to like this.
Mod parent up, excellent point.
The problem is that VoIP companies don't meet a lot of the service criteria that a POTS company does. Consider the example of making a VoIP call via your cable modem over your local provider's fiber backbone, over a microwave link, connecting to a satellite, to two tin cans tied together with a string somewhere in central Angola. Nowhere in there have you used anything that could be traditionally construed to be a "phone call". Welcome to the information age.
While you're absolutely corect, some regulation is good (especially when guaranteeing the service that you agreed to pay for, etc.) the problem with most regulation attempts of VoIP is that it's approached by PUCs or their equivalents around the world as an "all-or-nothing" issue.
There are loads of taxes and bills and whatnot, most only vaguely related to actual 'phone service', which many politicians would love to attach to your telco bill every month. Agreed, there's a more fundamental issue at stake here (i.e. why should you finance something completely unrelated through an everyday activity such as communication), but on the whole, I would rather not see any form of tax creep hit new technology development. I've had enough bad experiences with traditional telcos in Europe to be very wary of anything which might even vaguely artificially even the playing field for established service providers, even as a side effect of something like making the state's tax bottom line look better.
What I would really like to see is a middle ground, where communications companies can help fund something (a) vitally important, and (b) extremely relevant, such as 911 services. However, I guess I suppose it's naive to believe that this is possible without all kinds of rider charges being levied by your local PUC or board or council or whatever. It's well worth the effort, though, if it helps maintain the services that we all want and need, without weighing on the introduction of new technology.
Cole's Law: Thinly sliced cabbage
Has anyone else noticed that the latest MCI commercials on TV have a closed caption script that's completely different than the voice & video portions of the commercial?
The cc portion is pushing a VOIP company (can't recall the name) which is probably owned by MCI, while the voice & video portions are pushing MCI's latest calling plan. I find it interesting that one commercial appears to be pushing two completely different services.
I've seen two different versions of it too, so it appears not to be an error.
Help find a cure for Gidget.