I brought a teleworker phone — er, excuse me, a Mitel 5220 VoIP set —
home from work a while ago to play with, and to use when I work from
home. Some networking issues here (mostly involving being too lazy to
set up a dhcp server behind the second router) prevented me from
getting it up and going until now, so tonight was my first chance
to try it. I can see now why our VARs are getting excited about this.
I have a extension from work sitting on my desk and all I had to do
to get it was plug in a ethernet cable and a power supply.
This is really one nifty setup. First of all, it’s a box that
everyone and their dog would identify as a phone. It doesn’t need
a computer to be around, it’s not a black box with a headset (although
it supports the same headsets our standard desk phones support). 
It’s just a desk phone that works like a desk phone.
It’s designed (only) for corporate use, so it’s not
“Internet calling” or anything like that. What it does do
is this: You plug it in somewhere that is Internet-connected and
provides DHCP — even behind a NAT gateway — and it works identically
to the way it would work on your desk at the office, with no interaction
at all to get it started. And the control and data connections between
the phone and the office are encrypted, so you don’t need to establish a
VPN from wherever you are to the office to keep things secure.
It sounds simple, but this thing sells itself. A salesman who’s
often on the road gets his usual extension, voicemail, and presets
at the hotel and at the trade show without having to co-ordinate
anything with the hotel or trade show staff beyond an ethernet jack;
support people can work from home without having to route calls over
PSTN; people can switch desks inside the company and out to non-VPN’d
branch offices without rewiring or repatching; and all of this without
having to train the users anything beyond “plug in the cable”.
(On the office side you’ve got one of our ICPs (IP PBXes, if you like),
with a 6010 Teleworker Gateway between the ICP and the Internet; the
phone is programmed to talk to the 6010, which performs the necessary
magic to get it up and running. The 6010 is based on the 6000 Managed
Application Server, which used to be the e-smith server and gateway,
so the teleworker project was the one that kept my group around and
me in work.)
One interesting part is that I don’t think this would sell as software
or as a software and peripheral bundle; people don’t trust soft
phones yet, because they think that hardware shaped like a phone is
reliable and hardware shaped like a computer is not. “You plug in
your phone and it just works” is a much more impressive pitch than
“This software works from anywhere!”, even though the software is
easier to carry around.
The secret to practical VoIP is to make it act like it’s not VoIP at all.
9 responses to “New toy!”
want
I second that.
wow.
Two things.
Sounds cool, but doesn’t all that extra IP traffic inside a corporate network require additional network hardware? Or do people actually *at* the office use a standard phone, and only teleworkers use this phone?
What’s the price range for this hardware?
Those are hard questions to answer succinctly. :-) And around here, VoIP sets are standard phones!
It requires additional network hardware like it requires additional phone hardware. Taking a step back away from the teleworker gear to the standard corporate VoIP offerings, there are essentially two markets: companies putting in a new phone system, and companies replacing their old phone system. (We’ll conveniently ignore the complicated ones, like brand-new branch offices of a company with an established phone system.)
In the former case, it’s not really a question of additional hardware. Yes, you’ll want switched ethernet to the desktop, but you probably want that anyhow; what you won’t need is to run two sets of cable to every desk, maintain two sets of patchbays, and so forth. So for new offices it’s really par for the course, except you get to run less cable, which saves quite a bit in the end. For established offices that don’t have switched ethernet to the desktop (even 10mb), then they’ll run into problems, but in that case the cost of replacing hubs with switches will just be added to the cost of moving from their current solution to VoIP. In both cases, the extra hardware required to turn a VoIP system into one that supports teleworker is a PC. We recommend server-class, of course, but it doesn’t need to be expensive — the recommendation is a 1.8GHz machine but I’m sure some customers are getting away with even less.
(I should mention that aside from the 3100 (small-business) and 3300 (enterprise) ICPs, we also have an IP card for our non-IP PBXes, so that you can transition to VoIP one area or one phone at a time. The intent is to eventually end up with nothing but VoIP though; there’s really no advantage to a mixed configuration outside of “we already own the old hardware”.)
Bandwidth usage isn’t very high; after all, this stuff has to work from home on a cable modem. The bandwidth usage of in-office sets will be accounted for in the design phase; the connection between the 6010 Teleworker Gateway and the 3100 or 3300 or SX IP card that it’s talking to will generally be switched (or direct) 100mbps anyhow. Besides, telephone audio is pretty low-bandwidth to begin with. I don’t have the audio numbers handy, but it’s not a great deal of data; think about the lowest possible settings you can record a mono WAV file and you have an acceptable telephone audio quality. On top of all that, for teleworker connections, all of the voice connections use G.729a compression; if the office happens to have a 3100 (which doesn’t do G.729a natively), the 6010 accepts G.729a data and transcodes it to G.711 for the ICP.
There are a lot of extra complications (two pages’ worth in the guidelines), but some rough figures for teleworker bandwidth requirements at the gateway end: 1 phone, 1 simultaneous call: 100kbps (50kbps G.729a); 5 phones, 5 simultaneous calls: 420kbps (150kbps with G.729a); 24 phones, 13 simultaneous calls: 1.1Mbps (375kbps with G.729a). On the set end, the rule of thumb is 100kbps, or 50kbps with G.729a.
On top of all of this, the phones all have a passthrough ethernet connector on the back, and do their own traffic-shaping; if a desk has a computer and a phone, and the computer is plugged into the back of the phone and the phone is plugged into the ethernet drop, then the phone will choke the computer’s connection during a call to ensure it has the bandwidth it requires. So bandwidth needs to be accounted for (by the VAR when making a proposal, preferably!) but it’s not hard to do. (Latency ends up hurting more than bandwidth does, too.)
As for price range, I can’t provide prices here — but the per-seat pricing for in-office VoIP is competitive with IP and non-IP offerings from, say, Nortel, Cisco and Avaya, and enabling teleworker costs about a business lunch per seat plus the price of a x86 server to run it on; it’s entirely software (and Linux-based!). When it comes down to it the budget for cabling will be bigger than the budget for teleworker licenses, and you have to buy your users IP sets anyhow.
Cons:
– They go off when the power goes out, unlike regular phones which are on a completely different power network. People have lots of cell phones these days, so it’s not that big an issue in an office setting.
– The easiest thing to do is to plug them into your existing data network. When the guy in the next cubicle starts sending massive disk images across the network, the quality may degrade.
Pro:
– On the ones we had (Cisco) the ring was an ordinary sound file that you could configure. That kills ring tones dead.
– Management of extensions was insanely easy, as you point out. I wonder if this contributed the monthly reshuffling of seating arrangements.
Questions I never got answered:
– Aren’t VOIP phones much easier to tap? You say it’s encrypted between home and office, but what about on the corporate LAN?
Most of the standard protocols have session-level encryption, not unlike “Secure HTTP” sessions. VoIP is actually a pretty complicated set of protocols and standards, so it depends on what they’re using…
Getting started playing with VoIP is fairly easy. Check out Free World Dialup at http://fwd.pulver.com for a free PC-to-PC (with limited support for access to the PSTN [primarily 800 numbers) VoIP system that has been gaining some popularity. They sell a under-US$100 VoIP phone that, while not as sophisticated as the Mitel, works very well.
For the record, I use an Asterisk phone system and a VoIP softphone to extend my office phone system everywhere I go. It even works at Starbucks/T-Mobile HotSpots!
Here, have my point by point comments! And I shall refrain from saying “Well, that’s what you get when you go with Cisco”. Woops, outside voice! :-)
The power problem is pretty easy to solve in the office. (At home is at home, teleworker or otherwise.) All of our IP sets get powered over the cat5 cable (802.3af); if your .3af source (switch or ICP) is on a UPS, your sets get power during a power outage. If it’s not on a UPS it doesn’t matter if your sets get power during an outage because they can’t talk to their ICP anymore. Wall warts are available but we discourage their use in the office.
The bandwidth problem isn’t that hard to deal with in a modern network; remember, the problem is one of latency before it’s one of bandwidth. Finding that 50kbps on a 100mbps switched link shouldn’t be that hard. In the office, the latency problem is one of management, and that can solve itself nicely too; in an office too small to have an administrator to configure traffic-shaping on the routers, the sets are usually plugged straight into the ICP, and the ICP does the traffic-shaping itself. In bigger offices you’ve got switching on your side plus traffic-shaping on internal routers (and deployment guidelines that say “type this recipe into IOS”); even then naive switching behavior tends to keep latency pretty good. That leaves you with managing latency on the link between the set and the switch, and the set traffic-shapes that for you.
Our ring tones on the basic sets are basic phone rings; it was important to avoid having the sets work much differently than the equivalent not-VoIP set. Some of the more advanced sets might have features like that; I don’t get to play with them though, so I don’t know.
Providing encrypted voice channels for VoIP is a SMOP. I think the standard implementation is cleartext G.711 or G.729 over encrypted RTP, but I should emphasize that I’m a data person, not a voice person. I just get to take neat phones home.