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.
What's the price range for this hardware?
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.
some experience with VOIP phones
- 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?
Re: some experience with VOIP phones
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!
Re: some experience with VOIP phones
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.