The Consumer Electronics Market: Ensure A Robust User Experience, Or Order Yourself A Casket

The Consumer Electronics Market: Ensure A Robust User Experience, Or Order Yourself A Casket

BY BRIAN DIPERT

The consumer electronics business may be the most challenging market in all of technology, simply by virtue of its product diversity coupled with users' understandable desires for interoperability. Granted, this particular market segment offers the potential for high unit shipment volumes, but per-unit profit margin is scant. As such, the staffing expense of just one technical support phone call or email is often sufficient to turn that profit margin negative. So you'd be well advised to make sure that every feature your product touts is robustly implemented; similarly, don't roll out features that are only “half-baked.”

Some companies, such as Apple, intentionally constrain the ecosystem in which their products play in order to ensure the highest possible likelihood of a seamless usage experience, under the rationale that consumers would prefer a fully functional feature-constrained widget to a more “featured” one that causes nothing but headaches. A recent experience of mine exemplifies what happens when a company unfortunately goes down the latter rocky path.

A few months back, I added a 3G MicroCell (which is an AT&T-branded, Cisco-designed cellular femtocell) to my LAN, after unsuccessful attempts to get several manufacturers' cellular signal boosters to reliably work at my location. Unfortunately, I discovered that it was incompatible with the Linksys OGV200 Network Optimizer, a QoS management widget which I'd placed in-between my DSL modem (a Westell MSTATEA, in 'bridged' mode to avoid potential firewall issues, since by default the MSTATEA implements rudimentary router functionality) and router (an Apple Airport Extreme 'N', handling my AT&T DSL account PPPoE sign-on process). The OGV200 refused to honor the IPsec VPN tunnel that the 3G MicroCell attempted to set up on startup in order for it to register with AT&T's servers, so the 3G MicroCell refused to go online.

Westell MSTATEA DSL modem

The OGV200 Network Optimizer

The Apple Airport Extreme router

The 3G MicroCell

The Ooma Hub

The root cause, I suspect, is a MTU incompatibility between the OGV200 and 3G MicroCell, which I was unable to surmount because the OGV200 doesn't offer MTU size adjustment capabilities. So, in order to get the 3G MicroCell working, I ended up needing to remove the OGV200 from the network chain. This outcome is unfortunate, because since the router doesn't offer user-accessible QoS features, the OGV200 had been alternately doing an admirable job of prioritizing WAN-sourced and -destined traffic associated with my Ooma Hub VoIP device located “behind” the router (i.e. acting as a LAN client). Because of its location “in front” of the router, the OGV200 wasn't able to manage intra-LAN traffic. But all I needed it to do was to prioritize VoIP packets, so as to avoid Internet telephony drop-outs and other glitches, and the OGV200 had performed admirably in this role.

As soon as the OGV200 disappeared from the network, my Ooma service degraded to uselessness any time I was simultaneously using the WAN connection for some other bit-heavy task (such as doing a file upload or download, or streaming a movie). This was a problem, but I thought I had a solution. According to Ooma, in many cases the Hub can alternatively be placed in front of a standalone router, since the Hub also implements elementary router functionality, and regardless of which device (the Hub or the standalone router) ends up tackling the PPPoE sign-on task. In this configuration, the Ooma Hub's WAN port would connect to the DSL modem, and its LAN port would connect to the standalone router.

The resultant double-NAT configuration can sometimes be problematic, both with respect to LAN devices accessing the Internet and WAN-located devices accessing (via firewall “holes”) LAN devices. But, analogous to the DLS modem's bridged mode, the Ooma Hub claims to support a feature designed to alleviate these problems. A LAN client in the DMZ receives all traffic coming from the WAN port, regardless of port or protocol, with no explicit forwarding definition setup required. As such, after accessing the Ooma Hub's setup menus via the device's LAN port, I first configured the Hub as the PPPoE sign-on device, with the router configured with a static IP address and that same address entered into the Hub's DMZ definition box.

At first, all seemed well. The Hub got an AT&T DSL-sourced DHCP assignment and went online. So did the router and the LAN clients behind it, including the all-important 3G MicroCell that caused all this trouble in the first place. I was even able to execute some fairly exotic network tricks, such as instituting and maintaining a VPN tunnel between my MacBook Pro and the servers at my primary job's corporate office.

But then I went on a business trip, and the house of cards collapsed. I'd previously set up numerous firewall hole and port forwarding definitions in the router, enabling me to do such LAN things from a WAN connection as access my Windows Media Center server, control computers via Back to my Mac or VNC, sent jobs to a home-based printer, and peruse several webcams. All of this had been possible before, but none of it was possible now with the Ooma Hub in front of the router, even with the router in the Hub's DMZ. I couldn't even access the router itself.

What followed was an occasionally comical but predominantly frustrating series of telephone and email conversations with Ooma tech support, stretching over several weeks. I spoke with several support representatives, initially standalone (and involving, among other things, me explaining to them what a DMZ was) but later with them acting as intermediaries between Ooma's engineering team and me. I tried numerous suggestions they offered; alternately configuring either the Ooma Hub or the router as the PPPoE client, setting the router to a variety of different static IP addresses, etc. And I once again had to explain to them why some of their suggestions didn't make sense; my favorite was when they told me (several times) to both give the router a static IP address assignment and configure it as the PPPoE client. Or maybe it was they time they suggested I hook up the Ooma Hub and router in parallel to the DSL modem. Sorry, but my AT&T account doesn't support more than one simultaneous PPPoE connection.

In parallel, I did my own research; this guy got his setup to work, but unlike mine, his was a static IP address DSL account. Eventually, Ooma stopped responding to my emails; I presume they threw in the towel and gave up. . At that point, I seemingly had four options:

1. Give up on the idea of ever getting remote access to my LAN

2. Give up on the idea of ever having glitch-free VoIP again

3. Shell out the bucks for a different router that offers user-configurable QoS capabilities, or

4. Make the Ooma Hub the full-time router, and switch the Airport Express router into 'bridge' mode to transform it into an expensive wireless access point

For now, at least, I've come up with a clumsy but serviceable fifth-option workaround that blends options 1 and 2 above. Normally, the Ooma Hub is behind the router. When I need to make or take an important call, I temporarily switch the order.

I never got the sense that Ooma truly understood what my problem was; even if they ever did, I'm not sure how serious they were about solving it. Granted, remote access to network resources isn't yet a mainstream activity, but I'd wager that it'll be increasingly common over time. And Ooma's gear will remain unable to address the need, until the company figures out how to make the DMZ feature supposedly supported by that gear actually work as advertised. At minimum, Ooma, here's some free advice; don't disregard a customer who's dropped several hundred dollars on your hardware, which subsequently doesn't work as advertised. The customer's not the problem. You are.