No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Single Number Concept: UC Clients Sport Two Problematic Features

Single number concept isn't new and I remember being around call centers dumping numerous 800 numbers to use just one number to take the place of the many. It also meant that callers could be routed based upon their area code to a specific call center, with time of day routing kicking in for some options that AT&T developed for eagerly awaiting enterprises. Today, for very small businesses and homeowners, the single number is an automated attendant that answers, then plays music or message on hold until the host system finds you to deliver the call by ringing your home, cell, office or girlfriends iPad; and if callers wait long enough they may get in touch with who they called. Google Voice is similar and I remain unimpressed.

For enterprise, read Avaya's view about single number service for phones here, Cisco's here, Ericsson's here, Mitel's here, and everyone else is pretty much the same. Most systems and solutions today employ two old features that can be problematic for customers and vendors, by using the old hunt and peck method or simultaneously ringing all your numbers at once. For network managers is this really a wise thing to do?

I've noted previously the eroding barriers between work and home. People are more connected than ever, and not getting connected today could mean the loss of an opportunity, job interview or an order. Too many repeated failed attempts to connect translates to lost customers and opportunities. I don't think the solution that we have today--simultaneously ringing all the assigned phone numbers for all available devices--is an ideal solution. Let me put this in perspective--if we deploy simultaneous ringing at my company using just two devices for every person, then we'd run out of Concurrent Call Sessions (CCS) on our SIP trunks. The inbound call counts as one call or 1 CCS then the IP-PBX dials out a second call to connect using a second connection. As I've stated numerous times this is inefficient--it works very well but still is not efficient.

Secondly, the mobility feature that everyone wants and thinks they are getting in UC is seemingly more of the same--of the old. Ringing multiple phones simultaneously or putting calls into a hold pattern while the system searches (hunt & peck) to find the person you called is old technology. Current UC solutions using either simultaneous ringing of multiple devices or the old hunt and peck method of trying to track down the person by ringing the right device doesn't ring true with today's customer tolerance level of letting a phone or any communications device ring more than 3 times (3 ring cycles) before the customers abandon their effort or go somewhere else for their need.

These two features can also be bandwidth killers or SIP trunk blockers. The saving grace of UC when it comes to cell phones is that when the SIP invite is sent to the mobile device it is via data connection, not voice. Even with only two devices ever listed in the UC client--desktop office phone and a mobile phone if your calls originate from an IP-PBX on your premises--then you are still using two CCS (2 SIP trunks) to make the connection, or at best you bond the inbound call to a WiFi for a connection. Calls that route trunk to trunk are specifically what eats up bandwidth and creates call blocking.

My server buddy thinks the Google Voice feature is hot but it too is inefficient because callers don't get his voice mail upfront. Instead, when he’s too busy to talk, calls are spun into queue (18 rings) and can only hope he or his voice mail greeting will answer. Of course I have customers that have Verizon’s service and they have in their heads that the recording "Please wait while I attempt to locate your party" is prestigious. Were I to place these kinds of novelties on our services, you can guess that we would have huge call abandonment rates and I know it would put some customers over the edge.

If ever there was a standard needing attention, it's how to provide a true single number feature. Now, re-read Sorell Slaymaker’s post: How Many Phones Do You Use? Then take note of a reader’s comment: "How many (phone) numbers do you have across all these devices?" Single number concept is a long way off from being ideal, efficient and better, faster, cheaper--easier to use. Too much stuff signifies what another reader stated as being "over-compensating" and what we’re really doing is using an elephant when we really need something much less that will bind our all devices effortlessly and seamlessly and not use up all available bandwidth or CCS. The UC clients have scores of options but these varied features and enhancements inevitably will get in the way of ease of use. Adopters of UC needn’t be tasked with constant or complex changes or modifications to update their presence.

The question I always get asked is, "What one thing would you do to improve this product or service?" UC clients must be made for any communications device that users find appealing to add to their collection of business tools. My friends at Zultys were wise to build their UC client on Windows, Apple and Linux. Assuming that your UC client will run any most communications devices then it would be safe to say that you will have a solution for the masses until you use simultaneous ringing or hunt and peck.

Find out specifically how the features work and interoperate with other features such as Find Me/Follow Me and then how do the calls get delivered to the right device the first time--every time without blasting calls to all devices owned by the users. Don't hold your breath or wait for someone to tell you unless you or your vendor engages in the specifics because you will need to address these two features and then determine whether or not you have ample bandwidth to support the call traffic. The generations coming up don't think like older generations but they will challenge your thinking and they are using many devices –especially ones without cords. I challenge you to find out before you may deplete your CCS or overburden your network resources; and I can only guess about the number of hours spent on running down these issues.

Sorry for being like a mosquito on crack and I know I'm repeating myself but just to be clear:

* Simultaneous Calling and Hunt & Peck calling eat up resources including CCS

* Phone numbers are losing their geographic exclusiveness

* Customers don't like to wait more than 3 rings unless you have FREE money or something they can't live without

* IP communications devices are in a growth stage

* CCS = Concurrent Call Sessions--how many simultaneous calls did you purchase/contract for, with your SIP trunks not the same as Hundred Call Seconds, but you can end up creating a blocking network if you're not careful.

* User simplification--less human interaction is better--make it natural like wearing shoes, sandals, flip flops or going barefoot.

For the factory guys & providers: a question. Will your UC clients support 10 Matt Brunk identities? The UC clients must support no less than 5 identities for Matt Brunk and one of them must be a 2500 set with POTS. Refer to Sorell Slaymaker’s post about the numbers and kinds of communications devices. Each of the 10 Matt Brunk UC client identities would be Matt Brunk (iPhone), Matt Brunk (iPad), Matt Brunk (2500 set using POTS) etc. You can't charge me for 10 licenses but an up-charge for the capability is okay. When I login on any of the 10 communications devices then the UC client must send my calls, messages and notifications to that device and not the 9 other devices.

Maybe you have something slicker (Hot Devicing) than simultaneous ringing and hunt and peck; please tell me what it is. For the IP-PBXs, bonding two SIP trunks together (the inbound caller to an outbound channel [SIP Trunk] instead of using a feature TBCT for PRIs that frees up the channels--means you must persuade the carriers to provide the similar feature for SIP trunks.