ED Magedson – Founder
MegaPath, Inc.2220 O'Toole Avenue San Jose, California United States of America
In January 2010 our company solicited bids from several T1 providers in the St. Louis area. The initial list included providers we already knew and some from a general internet search for alternative providers: AT&T, Sprint, XO Communications, MegaPath, and Covad. After our preliminary bids from the companies we narrowed the choice to XO Communications and MegaPath.
XO Communications was known to us from other companies who used their service in our area. They were very professional but their price was higher than MegaPath's and they were unable (or unwilling) to guarantee our 3rd party hosted VoIP telephony traffic which was paramount to our decision.
MegaPath on the other hand was less expensive, claimed to have the same level of local support staff as XO Communications and guaranteed they could handle our 3rd party hosted VoIP telephony traffic by implementing QoS/CoS. After many conference calls with both providers and weeks of due diligence we finally selected MegaPath.
The install of the bonded T1 (3M up/down) went smoothly and was completed in March 2010. Unfortunately several issues surfaced immediately.
1. The first hop ping time was 70ms+ and average ping times to major sites (e.g., google.com) were over 120ms+ even despite less than 2% utilization on our line. This made general web surfing noticeably slow and prevented our VoIP service from working at all.
2. Our geocoded location was now showing Washington D.C.
Considering we're in St. Louis and use geocoding to route shipments this was problematic.
3. There was no QoS/CoS for our VoIP traffic on the line as promised.
Problem 1 was actually due to the fact the salesperson lied about having "local" service. In reality they contract for a local loop to their "long haul" connection somewhere in St. Louis. Ironically the local loop provider is XO Communications. The long haul then provided a frame relay style service to their actual network in Washington D.C.
This was why our first hop had so much latency, it was actually a VPN-like hop over a very long distance through who knows how many actual routers. It also explained Problem 2 - our public IPs were assigned to their Washington, D.C. network. We ultimately fixed Problem 2 by hard coding the geolocation in our database. This has worked short term but the minute we open a second distribution center things will break again.
As for Problem 1, we opened trouble tickets with MegaPath. They claimed our first hop was within their SLA of <100ms... in other words, not their problem.
Problem 3 turned out to be another lie from the salesperson. They offer their own VoIP service (which they guarantee), but they don't guarantee VoIP traffic to/from outside their network. Mind you we were incredibly clear this is exactly what we wanted up front and the primary reason we selected them. I had insisted the salesperson include VoIP traffic in our quote so we had at least something to fall back on and they grudgingly made attempts to accomplish it.
After several months and many different MegaPath technicians tried and failed to set it up correctly (some even claiming the previous technician did nothing) we still could not get reliable VoIP connections for our phones.
MegaPath, to their credit, did take the step of changing their long haul connection from St. Louis to their Chicago network (apparently the long haul connection was out of contract so my guess is the new connection would actually cost them less). This change, which happened in August 2010 - yes that's 5 months later - did help with general internet surfing. Our average latency during non-peak times was down to around 70-90ms total, though still far higher than any dedicated connection to a "real" local provider would have been. Unfortunately it did not resolve our VoIP issues. Our phones continued to experience random disconnects to the hosted VoIP PBX, something that had never happened with our previous providers.
At this point we ended up getting a low end, non-SLA connection from a true local provider. This connection is similar to DSL in that it's asymetrical with 3MB in and 1MB out. Average total latency on this connection is around 30ms. We put our VoIP phones on this connection and they worked flawlessly without any QoS/CoS, leading us to believe the random disconnects on MegaPath were specific to their network.
We went back to MegaPath requesting they honor their original promises in one of three ways: 1) lower their price to offset the cost of our second internet connection; 2) install a different circuit (MegaPath can offer Covad lines for instance); 3) cancel our service and we will go with a different provider.
They refused 1 & 2, and while they can't stop us on 3 they are trying to enforce their early termination fees of 50% of the remaining payments. Despite the fact they lied. Despite the fact they can't provide us the service we require and asked for.
Be very careful doing business with this company. They obviously have no qualms about misleading customers to get the sale and then refusing to take responsibility on the back end.
This report was posted on Ripoff Report on 01/30/2011 10:40 AM and is a permanent record located here: http://www.ripoffreport.com/reports/megapath-inc/san-jose-california-95131/internet-service-providersmegapath-incmegapath-inc-covad-speakeas-775b9htm-688662. The posting time indicated is Arizona local time. Arizona does not observe daylight savings so the post time may be Mountain or Pacific depending on the time of year.
Ripoff Report has an exclusive license to this report. It may not be copied without the written permission of Ripoff Report. READ: Foreign websites steal our content
If you would like to see more Rip-off Reports on this company/individual, search here:Search Tips
In order to assure the best results in your search:
Advertisers above have met our
strict standards for business conduct.