Webex Go Goes

by Dave Michels

Based on the conversations and questions occurring, I feel a need to explain Webex Go. It’s actually a breakthrough product announcement, but it’s hard to appreciate what’s happening here because some of the benefits sound familiar.

From the Cisco blog postThis new service enables you to make and receive business calls using your mobile phone’s native dialer, without an app, the way your phone was intended to be used.

Many apps offer this.

Or, from the Cisco Webex Go press release: Users no longer need to manage a business phone and a separate personal device. 

At best, maybe, but mostly unrelated to Webex Go.

Many mobile calling apps have claimed these benefits before. Webex Go is new, but these benefits aren’t.

The native dialer is the dial pad that came with your smartphone. Several UCaaS providers, including Dialpad and Verizon One Talk, can modify the native dialer to also work with third party calling apps. Such modifications are limited to Android phones as Apple doesn’t allow changes to core iOS apps. It’s a nice trick that creates a single dialer for native and app-based calls. The trick has been around for a while.

Webex Go is similar in that it also uses the native dialer for native calls and Webex calls, but does so without modifying the dialer. It’s done in the network, and this also means that it works with the native iOS dialer.

Webex Go could eliminate the need to carry two phones, but probably won’t. The two phone issue is usually more about boundaries than caller-ID. Many employers install management software on phones used by employees for business.  These utilities are intended to protect employer data and often include the ability to remotely wipe the phone should it be lost or stolen. Employees concerned about employer monitoring software on their personal device often prefer to carry separate devices for personal and work. Webex Go doesn’t change this, but admin visibility is contained to Webex usage. 

The magic of Webex Go occurs in the network, not the app or device. Calling apps have existed on smartphones for well over a decade (I think Skype was the first one I installed). They allow business features such as hold, transfer, and also protect the privacy of the user’s personal number. Unfortunately, calling apps generally provide low quality experiences. It’s not something the UCaaS industry talks about, nor is it their fault. 

The issue is that wireless carriers prioritize native voice traffic. It’s a practice that goes back to 2G and 3G when voice and data were transmitted with different technologies. With 4G/LTE and 5G all wireless traffic uses the same packet network, but carriers still give native calls a better/higher class of service. That’s why many people favor making calls over the native calling service, and avoid making calls with third-party calling apps. 

Webex Go gives Webex calls the same network quality as native calls. This requires a cooperating wireless carrier (AT&T for now with more coming). I believe Cisco is the first UCaaS provider to pull this off. Now that the cat is out of the bag I expect others will follow. RingCentral has several wireless partnerships, and Dialpad and T-Mobile may not be far behind. 

Webex Go is accomplished with some Cisco Secret Sauce. With AT&T, it requires the mobile device to support eSIM technology. A phone that supports two eSIMs can have a personal and work number on the same phone. Because the carrier is provisioning Webex to the eSIM the native dialer works as it was intended. Cisco says future Webex Go partners may do it through a back-end integration, but the eSIM route should work more consistently when roaming.

Webex Go brings with it advanced, network-based business calling features such as hunt groups, call forwarding, extension dialing, etc. Accounts are managed through the Webex Control Hub. 

Webex Go is a clever solution, to a very dumb problem. It makes call quality the same for apps and the native dialer, but does so by making app calls native carrier calls. The better answer is to either prioritize all real-time data, or let customers control which, if any, packets get priority. But that will never happen.