Single Number Concept: UC Clients Sport Two Problematic Features
If ever there was a standard needing attention, it's how to provide a true single number feature. Current implementations can be bandwidth killers or SIP trunk blockers.
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.






