Endpoints
Endpoints by Dave Michels
Remember when endpoints were called phones? There was no need to clarify hard or soft. Pretty much the only question was rotary or push-button. Now when we speak about phones we have to use the word “endpoint” as a catch-all for all the various types. Endpoints can be hard or soft; SIP, proprietary, or analog; video-enabled; HD-audio capable; wireless (DECT or Wi-Fi); or desktop or mobile (iOS, Android, BB, Win8, tablet, or smartphone).
We’ve come a long way from the infamous “you can have any color you want as long as it’s black” mentality. It’s nice to have so many options. Or is it?
Personally, I think it does make sense to have lots of options. Others disagree, uninterested in new hard phone announcements (SEN, Cisco). Believing only softphones make any sense moving forward. It’s a common misconception that continually gets disproven. Microsoft learned this back with OCS when it introduced only a few hard phones as evolutionary stumps. The following year Microsoft dramatically expanded its selection of hard phones.
It is ok to have a preference for what type of endpoint you want, but remember that multiple endpoint options do and should exist in an enterprise deployment. A comprehensive enterprise UC solution will utilize multiple types of endpoints; each with unique benefits.
Softphones: The biggest advantage is the full keyboard and mouse. The traditional telephone user interface is very limited and intimidating (asking a novice to transfer a call is a risky proposition). Another key benefit of softphones is they don’t take-up any more room in the computer bag for those that need a non-mobile phone when on the road. Two popular softphone misconceptions are they are less expensive and easier to integrate than hard phones. Technically, they are typically less expensive, but remember to factor-in headsets – cost and lifespan. As far as integration, an app can usually just as easily interface with a hard phone as a softphone. A big limitation with softphones is they typically require a login to access – thus not suitable for shared/public/emergency locations.
Hard phones: The biggest benefit is they are understood. Anyone can work a phone and place a basic call, especially if the dial plan involves a 9 for an outside line. Another key benefit is hard phones are always on – and even those that do require a login (hotdesking) still offer limited functionality (internal/emergency) without credentials. They also have the added satisfaction that comes with slamming down the handset in anger. Hard phones often make better speaker phones than (default) desktop/laptop computers. A desktop hard phone has a reasonable life expectancy of at least five years.
SIP vs. Proprietary: The promise of SIP endpoints (hard or soft) is a best-of-breed vendor independent freedom, but in reality customers of Avaya, Cisco, NEC, SEN, and Mitel tend to buy like branded endpoints. The downside of SIP endpoints is they are generally less capable than the proprietary endpoints. SIP is great at basic signalling, but how/what gets displayed is less mature. SIP interoperability is still a concern, but significantly improved. SIP endpoint provisioning and security tends to be more manual than proprietary endpoints.
Analog: Contrary to popular opinion, there is nothing wrong with analog endpoints. Admittedly they are not particularly sexy, nor feature rich – but they offer a reliable cost-effective alternative. They are particularly useful in situations where data-grade cabling is unavailable. Also, some UC dashboards provide rich point-and-click functionality that integrates with any endpoint – including analog devices. The sad part of analog is reduced voice quality, which used to be considered better than VoIP but has now been eclipsed by HD-Audio on IP endpoints. Analog endpoints are still commonly used in hospitality and healthcare, and special use devices like courtesy or dock phones.
Video Enabled: This is rapidly becoming standard issue on softphones, but still the exception on hard phones. That’s simple economics – the softphone cost doesn’t include the screen or the camera. However, the cost of video-enabled hard phones is dropping quickly, and some make the camera an add-on option. I’d like to see a video-enabled hard phone that can be used as a USB webcam on a computer – or a phone that can use/share a USB webcam. I like video, and I like hard phones, but the combined selection is sparse. This is an area that should grow as most UC solutions are now supporting SIP video.
Wireless (non cellular): Considering the general enterprise has excellent wireless coverage and considering the general employee is highly mobile, the wireless extension should make a lot of sense. The problem is there just isn’t that many to choose from. Most use Wi-Fi which isn’t great for voice as it tends to consume both the device’s battery and the AP’s capacity. DECT is far better, but that involves a separate wireless infrastructure. These phones can make a lot of sense in specific verticals like retail, warehouse, and healthcare. They tend to increasingly compete against smart mobile devices. They aren’t as versatile, but less likely to break (drop) or get stolen. Some have bar code scanners. They are far more popular in Europe than the U.S., possibly because most are designed by Europeans.
Smartphones: The current smartphone is a wondrous device capable of replacing many things: pagers, wallets, folded maps, diary/calendars, calculators, flashlights, cameras -- and yes, possibly desk phones. The biggest problem with mobile phones is battery life. They also get lost, stolen, misplaced, and dropped. Smartphones tend to be personal thus unsuitable as a shared device. To integrate smartphones into a UC solution typically requires an application to run on the smartphone. Smartphone applications vary in connectivity approach and may use wireless voice minutes, wireless data minutes, and/or Wi-Fi.
Tablets: See above, but with big pockets.
I get suspicious when I hear about softphone-only implementations. The fact is this wide-selection of endpoint types is there to strengthen and customize a UC implementation. There is no reason to fight this, and lots of reasons to leverage it.