[humba3]

In the SPA400 sticky, I was asked about my experience with Linksys customer support vis a vis fixing problems.. having owned a full blown LVS since May, I've gone through considerable pains with Linksys support and finally decided to write it all down and ask Linksys to step up to the plate. Even though I was told

We apologize for the inconvenience our system has caused you. Linksys will use the information provided to make your next experience a better one.

on September 14th, I'm still very much in the same situation, and have more open issues than ever. So I'm posting my whole mail, plus addendums that outline what happened between September 14th and today.

[humba3]

..........

I'm writing in the hope that in the future, people won't have to go through the same ordeal as I have.

Back in May, I decided to replace a 10 year old ISDN PBX in my house with a VoIP solution. I settled on the LVS system. Long story short, I got the hardware and the problems started.

Number one was regional settings: All devices, even though bought here in Switzerland came with US settings. When I asked customer support for help in finding the proper settings. That was on May 25th, the case number is 060527-008693. After some forth and back I was told the issue had been sent to engineering.. and I never heard from that case since. I spent many hours reading through ETSI and Swisscom documentation to finally get a combination the behaves like any PBX with proper Swiss settings does. I don't think that when I buy a product in Switzerland, I should read ETSI specs.. it's your job to provide the proper regional configuration for a device that you're selling around here.
I also sent the request in German to the German support department (case id 060530-007650), and all they could come up with was "Contact Sipura support".. and then a link to a page that provides a configuration for Germany.. but not a Linksys / Sipura page, but a page set up by users who had to figure it all out on their own.

I happen to work in the voice support department of a system integrator, and if we'd set up a PBX for a customer with US defaults and then told them that they have to figure out the Swiss settings on their own.. we'd have gone out of business a long time ago. I can't understand how you can sell a product in countries without adapting that product for the country you're selling it in.

As part of my setup, I got two WIP300 phones. I opened a case (id 060610-004574) since the device wouldn't properly register with my SPA9000. The engineer quickly reproduced the problem, but then we descended into the usual "not meant to support this and that". If you follow the case history, you'll see that I actually traced the problem down to a protocol implementation failure in the WIP300 after the case had been open for almost a month, and I refiled with the Linksys support department. However, I don't think it's the job of the paying customer to read RFCs and to point out errors.. it would've been the engineer's job to look at why the problem ocurrs, then conclude that the SPA devices are working properly and that the error lies with the WIP300.

I then filed the same case with a more to the point description on July 9th (case id 060709-008082). Since July 10th, I have not heard a single word from you regarding this case. I brought the issue up when the firmware engineer finally called me for another case (see below), and indeed, this is a known issue as well. It would be nice if bugs were at least confirmed if I take the time to study RFCs.

On June 20th, I filed another case (id 060620-002765) on the interop between WIP300 and SPA9000. After some initial discussion, a long wait ensued, then on July 5th the dreaded "doesn't have this feature" (actually a reply to the wrong case). On July 14th I informed the engineer that by reading the RFC and making traces I had been able to trace the problem to an RFC implementation failure on the WIP300. Once again, RFCs and Tracing isn't the job of your average user..

I refiled the case with Linksys support (060710-000271) on July 10th. It took until September 6th until the case finally made it to engineering and last Monday (Sept 11th), an engineer finally called and confirmed that there's indeed and problem and that it would be fixed by the end of the year. Seeing as I initially filed a case on June 20th, this is way too long for a rather critical problem.

Back in June, I decided to upgrade my wireless network as the reception in certain areas in my house was rather bad with the WRT54G device I had before. So considering that 802.11n should reach further, I opted for the WRT300N V2. However, my joy about a better reception and range was shortlived when I had to find out that QoS was broken on the device. I filed a bug on this on June 28th (case id 060628-011199). On July 3rd, the case was forwarded to your second level support department, and I only heard back on July 29th, from a person who obviously confused my WRT300N V2 with the US model - the WRT300N V1. After I corrected the engineer, I got an apology for the confusion on July 30th and since then I have heard zip, despite asking back several times.

Losing patience, I filed the same case again, with a more precise description (the engineer owning the original case never bothered to reproduce the problem) as I had in the meantime found out more details about the problem. The case id is 060729-001076. After a full slap in the face (the engineer didn't appear to understand VoIP at all), I have yet to hear again on this case.. the first and last reply was on July 29th.

I also filed another case on the WRT300N on July 1st, case id 060701-002526. It took 12 days and some not so very helpful comments to finally get confirmation that there's indeed something broken on that device - imho waiting for 11 days to get confirmation of a problem is a bit long, especially if it's something that takes a minute to verify. Up to this day, no fix has been made available.

On July 1st, I filed another case on the WIP300 and SPA9000 (case id 060701-006840). It turns out, I was wrong opening that case.. in reading the RFCs I realized that the behavior I found is correct. The case timed out and was set to resolved. However, the reply I got from your engineer was once again "WIP300 not meant to be used on the SPA9000".. and that's a slap in my face when Linksys was handing out LVS brochures with a WIP300 on the front page and on the business solution image at VON 2006 in Stockholm. I'd have expected a technical response telling me that the shared line behavior on the LVS is an extension of the SIP standard that the WIP300 doesn't support, and not some marketing spech.

Another one of my favorites is case 060628-012053, first filed on June 28th. I still have a hard time believing I'm being told it's normal that I experience hiccups when I move around when talking on a wireless phone. Regular wireless phones, cellphones, even WLAN phones from other manufacturers don't have any of these problems so I'm puzzled why I should consider this normal and not insist on a fix.

Another lengthy case is 060701-012294. Filed on July 2nd, we're still at it. In the particular scenario, your support department was able to come up with exactly one provider (I have a handful where it doesn't work) where it works, after long waits on my part (I even provided my own SIP accounts for testing) that doesn't exhibit the problem and tried to make this the end of it.. but if you blame my IPTSPs, I expect to be told what they're doing wrong.. and we're still at it. I have a feeling once a I get a hub I'll be the one to figure out this problem as well, even though it's really not my job doing so (I already opened a bunch of accounts for testing and spent quite some time making experiments with various IPTSPs).

On July 19th, I opened yet another case on the LVS hardware (id 060719-010277). After first being told what I want to do isn't possible (even though your product page hints it is), your engineer provided a working configuration 6 days after I filed the case. I could've done with the initial "can't be done", but I guess a working solution in 6 days is something. But the issue wasn't fully off the table as my tests yielded two more problems in the scenario. On September 7th, an engineer finally came back with a workaround to solve the problem.. that did the trick but it was nontheless a workaround.. so he escalated the case. ON September 14th, I was provided a link to a new firmware, which I loaded and which did indeed resolve the issue. As luck would have it, I just found another issue..

Bottom line, I've filed a great many cases on my hardware, and the treatment of these cases ranged somewhere between "just taking way too long" to extremely poor. It can't be that a case is just not being handled at all for over 6 weeks, especially something as critical as the QoS problem, or the CANCEL issue on the WIP300. I also don't understand why when I provide traces and references to the SIP RFC, the support engineer doesn't escalate immediately to a party that fully understands the information I have provided. I'm a software engineer, and working in a support department, I'd kill to have bug reports like that.. I'm convinced that a majority of the cases you get are neither as concisely described, nor will be so much information given and you can count on getting traces from the problem, and even RFC references in some cases.

I have made a considerable financial investment (SPA9000 + 16 user license, 3 SPA942 phones, 1 SPA922 phone, 2 WIP300 phones and an SPA3000) and invested days into tracing down problems, yet I often felt as my efforts were more seen as a nuisance than doing the best I can to provide as much information as possible so that problems can be fixed quickly. I am very disappointed in what I have experienced in many of those cases. There is the occasional engineer that doesn't make me feel like I'm disturbing his coffee break, but I expect more than that. I'm not dumping some useless "it doesn't work" on you, I provide detailed accounts and more than enough information to make an issue reproducible, and I don't think it is too much to ask to expect a certain amount of effort on part of the engineer owning a case. I get to own cases at work, too, but if I treated them with the same level of "enthusiasm" as some of mine were treated, I'm not sure I'd still be working there.

[humba3]

On September 11th, my SPA9k/SPA3k interop case was transfered to an engineer that both cared and knew what he was talking about. So, the interop case is now closed and the engineer even went beyond his call of duty to check on another few cases and issues for me. And as part of this case, I got a new PBX firmware that solved the WIP300 cancel issue.. why that is nobody knows, I never heard from the person in charge of the case 060710-000271 even when I informed them of my findings. It still bothers me today that a change in the SIP message format took care of a WIP300 problem.. I suspect a change was made in how the SPA9000 handles requests from the WIP300 so that the WIP300 won't get confused anymore.

Since early October, the moh case (060701-012294) was finally transfered to another engineer who cares and after some creative encouragement sat down and tried to reproduce the issue. To this date, the issue remains unresolved though.

There has been no progress whatsoever on the QoS issue on the WRT300n (open since June 22nd), the WIP300 hiccups (open since June 28th), https on the WRT300N (open since July 1st) and the WIP300 shared line registration (open since June 10th). In fact, the solution sometimes appears to simply remove features... the inofficial 2.00.15 firmware I got to test for the QoS case removes https access completely (rather than to finally make it work), and when I asked about the missing configuration backup / restore functionality of the WIP300 (060924-001462), I was told that the datasheet was inaccurate. But, the phone has been available for a long while.. don't tell me nobody ever noticed.

And then there are the SPA400 missing features and bugs (specifically no mailbox ID in FXS calls, transfer instead of redirect for external calls that should go to voicemail, and the SPA9000 trying to run the extension vm and vmm through a numeric-only number verification when a non SPA9xx phone tries to access voicemail, and the ever resetting eventlog settings), all outlined in more detail in my custom review: Voxilla - Linksys SPA400 (4-port FXO gateway)

Last but not least, my reporting that the SPA phones block if you set them up with an incorrect proxy address (one that cannot be resolved via DNS), als didn't yield a response and has been dormant since October 8th.

[Kevin270]

I too have experienced problems with the Linksys support leading me down the garden path. In other words, they have not given me much help at all, and are quick to jump to the conclusion that their system is just not going to do what I need it to do without what seems to be any real investigation. I have been told "No" to the voicemail FXS problem. "No" to the SPA400 not allowing me to select a specific FXO line problem. There is no hope in any of the emails either. Nothing such as, "This is something we are working on, or will be working on." The things I have asked for have not been outrageous things. They are pretty much the same thing that you, humba3 and others have been asking Linksys to address.

I'm not sure why this company does not treat their customers more seriously.

Oh well - more lessons learned.