the whole is greater than the sum of its parts

WebRTC Connectivity Solution with Focus on Quality and Scale

The whole is greater than the sum of its parts

the whole is greater than the sum of its partsWe released a PR today about the AudioCodes WebRTC Connectivity Solution. In this post, I want to provide a technical insight into this solution, explaining why the whole is greater than the sum of its parts.

A typical approach to connecting WebRTC with an existing enterprise VoIP network would follow one of these two architectural concepts:

  • Browser using Opus with some kind of proprietary signaling-> WebRTC to SIP GW -> SBC -> Transcoding to G.7xx -> IP Phone on a SIP network
  • Browser using G.711 with some kind of proprietary signaling-> WebRTC to SIP GW -> SBC -> [Optional: Transcoding from G.711 to G.7xx]-> IP Phone on a SIP network

Both cases introduce some issues

The external WebRTC to SIP GW carries a price.

Transcoding from Opus to G.7xx is something you would want to avoid unless there is no other option. Opus requires hefty CPU resources (much more than most audio codecs) and introduces quality issues while increasing CAPEX.

The other alternative, using G.711 over the open internet, is not a good option as G.711 wasn’t built for sustaining quality over unmanaged networks.

Traffic traverses between networks and different network types (WiFi, Wireline Ethernet, public Internet and enterprise networks) while devices themselves can vary as well. Handling of network impairments should be done in the entity that connects between these networks as it is familiar with the requirements of each and has the per-session knowledge of source and destination of traffic. While the two links above use VoLTE as an example in the post, similar issues arise when traversing WebRTC to non-WebRTC networks and the algorithms described in these posts serve the need of this architecture as well.

Another missing piece in typical deployments is the ability to monitor the traffic, know what is happening on the network and impact SBC decisions for quality improvements.

Putting quality and scale at the front

The solution announced was designed with these two factors at the forefront and that is what makes it stick-out of the crowd.

Integrated solution

In our solution, WebRTC is supported in the SBC itself. This includes WebSockets, DTLS and other WebRTC “special” behavior. This architecture simplifies deployment and management as well as reduces delay, (or in other words, increases quality).

Minimal transcoding scenarios

By supporting Opus in the AudioCodes IP Phone, we hold the rope at both ends. On the one hand, voice over the open Internet is using the Opus codec which is purposely built for this task. On the other hand, transcoding is not required as the IP Phone also supports Opus. This significantly increases the number of calls supported while reducing CAPEX.

Signaling

For signaling we use SIP over WebSockets. We found this to be a good solution when the goal is to connect to existing networks.

Another advantage of the decision to use SIP for signaling is the connection to WebRTC API platforms. WebRTC API platforms typically use proprietary signaling. For connecting to existing networks they build an adaptor which is typically SIP. This basic SIP implementation can’t connect to any existing enterprise SIP network but going through the SBC allows it to do so. While this SIP adaptor varies and is not always pure WebRTC over WebSockets, eliminating the need for this adaptor to implement a full WebRTC to SIP GW, simplifies this interconnection making this task easier.

Voice quality enhancement

As mentioned, traffic traversing between networks typically suffer from call quality degradation. There are different implementations of media engines on the client side that are optimized for the network with which the client plans to work. When the client connects with another client on a network that it wasn’t built to connect with, voice call quality issues increase. Having the SBC as a demarcation point between the networks allows for the utilization of the AudioCodes voice enhancement algorithms for improving audio quality.

Detect & correct

The AudioCodes Session Experience Management (SEM) not only monitors and detects voice call quality issues, it also works in harmony with the SBC to allow for smart, quality based, routing and quality improvements.

Why is this important?

A WebRTC GW doesn’t stand by itself; it needs a multitude of capabilities and supporting elements to ensure effective and high quality service. This is why the whole is indeed greater than the sum of its parts when bringing all that is required for an end-to-end WebRTC Enterprise connectivity solution.

VocaNOM in Amazon AWS Cloud

How Amazon AWS Scaled Up Our Business

For several years we have been in the process of enhancing our products to allow them to live in the cloud, a good example of this is the virtual SBC. In this context we have taken VocaNOM one step further and changed it from being a product to a cloud service running on Amazon AWS.

The Amazon team was pretty excited about this and conducted an interview with our VocaNOM Product Manager Yacov Tzadikov. More about the magic of VocaNOM below the clip.

VocaNOM in a nutshell

We all know what personal assistants are, Siri being one good example. Less common are personal assistants at the enterprise level. As an employee in an enterprise, not all of the enterprise information is stored on your mobile device and synced.

VocaNOM comes to solve a few fundamental issues:

  • How do I find contact details of a colleague who is not in my contacts?
  • How do I call this contact easily without starting to search my contacts when not really free to do so? (e.g. while driving)
  • How do I make sure my enterprise contacts are always in sync?

The scenario using VocaNOM is as follows:

  • You press a quick dial on your mobile or desk phone
  • You state the name of the person you are looking for and on which device to call him/her
  • The call is connected

This is as close to hands free/hassle free as it can get (that is until we have brain-controlled systems where you only need to think about the person you want to call).

No long search in the corporate directory or phone contact list and no driving while typing the name of a person (which is dangerous and rightfully illegal in many countries).

The idea behind VocaNOM is simple but can be realized only when you have a technological and product heritage as available at AudioCodes. The ingredients required to achieve this included:

  • Great and accurate speech recognition technology fully controlled by the company so we can modify and adapt the technology to run in any environment
  • An SBC that connects to any existing PBX and UC environment

All this was combined into a product that was installed on premise at enterprises. But we wanted more… We wanted to make the on-boarding of new customers as simple as possible. We wanted to make their buying decision risk free. We wanted to let people try it out instantly. The answer to this was to move VocaNOM to the cloud and offer it as a service.

Moving to Amazon AWS

The new architecture of VocaNOM as a service in the cloud can be viewed in the diagram below.

VocaNOM in Amazon AWS Cloud

In the Amazon cloud we have all the components required to run the VocaNOM service. These include the IVR and the Automatic Speech Recognition (ASR) SW as well as the web management interface. The VocaNOM system synchronizes with the company directory and stores contact information on Amazon RDS (data base).

Additionally, the AudioCodes cloud SBC takes care of passing the speech from the user to the ASR system for recognition and later to send the SIP instruction for connecting the call between the two users.

Since enterprise PBX environments vary including VoIP and TDM systems and since there is a need for a secured communication between the enterprise and the cloud in order to avoid fraud, there is a small enterprise SBC that the enterprise’s IT installs within minutes in order to make this VocaNOM magic work securely and in any environment.

Since this service is sold today both directly to enterprises and through service providers to their business customers, VocaNOM comes with a 3 level multi-tenancy management system to allow service providers to easily manage their customers.

By making VocaNOM a service in the cloud, we managed to significantly shorten the on-boarding process, making it a simple, risk free IT decision to try out the product. Since VocaNOM is addictive, making this service easily accessible created great momentum in the growth of this business and the number of customers using the product.

Although VocaNOM is great to use as it is today, the development team has a few cool rabbits in their hat soon to be pulled out, which will add more fun features to the service.

All this probably sounds great but you don’t need to believe me, try VocaNOM for free today and experience it yourself.

SBC is a Swiss Army Knife

Not a Toaster after All

I like reading the posts of Andrew Prokop, that’s why his blog SIP Adventures is featured on the sidebar of our blog as one of those we follow. Recently, Andrew posted an interesting and humorous post on Nojitter titled When the Session Border Controller Became a Toaster.

Comparing an SBC to a toaster, Andrew concludes that a commoditized SBC competes on capacity and price. Very much like a toaster that competes on the number of slots it has and the price, as after all, you just “put in a slice of bread and it pops out all nice and brown”.

In his post, Andrew looks for more interesting capabilities (of the SBC, not the toaster) and calls the companies to the challenge.

So Andrew, Challenge Accepted! J, hence this blog post.

A Swiss Army Knife

I view the SBC more as the Swiss Army Knife of VoIP rather than a toaster. Similar to the Swiss Army Knife, the SBC needs to handle many tasks and be flexible enough to live up to those challenges. It need to work in various environments, connect to different network devices and normalize SIP traffic to support this.

SBC is a Swiss Army Knife
This post relates to the challenge presented by Andrew and to his question how it is handled by different SBC vendors, Therefore, I will review how the AudioCodes SBCs not only tackles it but go beyond Andrew’s expectations. Hence, this post is AudioCodes product specific.

Dismantling the Challenge

Licensing – buy a bunch of SBCs and license them as needed from a pool of licenses.

To serve this customer need, AudioCodes provides its EMS (Element Management System) SW that handles among other things SW upgrade and license distribution. This allows service provides and enterprises to buy a pool of license and distribute them as needed between those SBCs from one central management system.

Virtualization – get rid of boxes.

There are a few modes in which an SBC can come. It can be a proprietary HW device, an appliance that comes bundled with the SBC SW of the vendor, SW on a CD that is installed on a server provided by the customer or a virtual SBC running on a virtual machine.

All 4 modes are supported by the AudioCodes SBC. Moreover, it supports Hyper-V, VMware and KVM hypervisors. We are working with NFV orchestrator vendors on integration with their platforms so customers will have a pre-integrated solution for NFV.

Support for WebRTC & Opus in the SBC

There are different ways to support WebRTC. Many implementations have taken the approach of supporting WebRTC in a box external to the SBC. This imposes quality issues as well as architecture complexities. The AudioCodes approach was to provide native support for WebRTC as an integral part of the SBC. This simplifies the architecture and gives the flexibility to bridge WebRTC to any network, including TDM, all with a one box solution.

The other side of WebRTC support is the media itself. Here also, the approach of the AudioCodes SBC is native support for Opus transcoding in the SBC.

The SBC, of course, comes in any of the 4 modes described above so it can be a virtualized SW SBC as well.

The support for WebRTC doesn’t stop at the SBC level but extends to the client. Some implementations have defaulted to G.711 in order to avoid the need for the transcoding of Opus to G.7xx. This is a bad choice as G.711 is not the best option for VoIP over the open Internet.

To solve this issue, AudioCodes has added Opus to the IP Phone. Through this we give our customers the option to hold the rope at both ends. On one hand the enterprise or service provider can use the best codec for VoIP over the Internet – Opus – and on the other hand there is no need for transcoding if the AudioCodes IP Phone is at the client side. Transcoding is, of course, supported for cases that require it.

Webification of Communications

Continuing from WebRTC to the general trend of Webification of communications, more and more non-VoIP developers need to integrate WebRTC into their applications. We have come across cases of services that are pure Web-based that wanted to add voice and video communications with external call control requirements. These developers know how to implement great Web services but they are not experts in VoIP call control. For them we have added REST APIs into the SBC that allow for configuration and 3rd party call control through an interface known and common among Web developers.

Web services and HTTP

Many IP Phones on the market have an integrated browser that fetches screens and information from the server. This works well when working on the same LAN but in cases of remote workers that don’t have a VPN connection to the enterprise things can get tricky. HTTP can go out of the organization to the Internet but the firewall will not allow HTTP traffic to come in to the servers of the enterprise. To solve this, the AudioCodes SBC also functions as an HTTP/HTTPS proxy keeping the PBX secured while supporting remote workers.

Hybrid cloud and on premise

A hybrid cloud and on premise mode means I can separate SBC functionalities and decide which to run in the cloud and which to run on premise. Since enterprise communication requirements and architectures vary, it is important to allow for this flexibility.

The AudioCodes SBC handles this by offering both cloud access SBCs (at the service provider core edge) and on premise SBCs. The enterprise has the flexibility to choose to run functions that are more fit for on premise locally while keeping other functionalities in the cloud. Examples of such functionalities are:

  • Survivability – PSTN backup and alternate WAN connection
  • Quality monitoring – putting this in the enterprise on premise demarcation point allows to know if the problem is between the enterprise and the service provider or perhaps in the enterprise LAN.
  • 911 – In many cases it is better to run 911 services on premise for emergency services
  • Remote worker support – Simplifies the architecture on the SP server side as remote workers access the service provider cloud from the on premise SBC and not directly. By this, they look as if they are an on premise workers.
  • Bandwidth optimization and quality enhancement
  • Normalize the uniqueness of each enterprise simplifying the complexity of service provider access

 

The service provider and enterprise can decide which of these functions are deployed locally and which in the cloud.

Why this is important

While in a commoditized toaster you simply put in a slice of bread and it pops out all nice and brown, SBCs are far more complex than just port count and price.

The technology advancements of WebRTC, cloud and NFV impose new requirements for media quality and support for heterogeneous environments. This makes the selection process of the SBC that best fits your need far more complex than selecting a new toaster.

One Box for Lync Innovative Solution

Making The Most of Your Office 365 E4 Plan

Lync voice and Unified Communications are becoming increasingly popular. In this environment, it is natural that innovative solutions for specific requirements within the ever expanding Lync ecosystem are being introduced to the marketplace all the time.

Enterprise Voice for Lync can be accessed through Microsoft’s “Plus” Client Access License (CAL) offering, which in turn can be achieved by either deploying on-Premises Lync devices, or through the cloud-based Office 365 suite (Word, Excel, Outlook, Publisher, and OneNote, Exchange, SharePoint, Yammer and OneDrive). Microsoft’s Office 365 E3 plan, which costs $20 per user per month, provides UC functionality such as presence, IM, mobile clients, peer-to peer video and voice, voice and video conferencing, screen sharing and editing. The E3 plan, however, doesn’t include enterprise voice – the ability to place and receive calls on the PSTN/cellular network and the ability to use the features that allow organizations to essentially replace a PBX with Lync. To benefit from those features, the end-user would need to add an additional $2 a month to upgrade to Microsoft’s E4 plan and benefit from the “Plus” CAL (bringing the monthly cost to $22). However, the customer would need to install on-premises servers and gateways/SBCs to make it happen, requiring skills and resources many small to medium businesses (SMB) may not have.

An innovative solution to bridge the gap for Office 365 users who want to benefit from Enterprise telephony without the steep infrastructure costs is a lucrative opportunity for partners serving SMBs.

One Box for Lync Innovative Solution

A quick glance at recent research shows just how large the potential of such an opportunity might be. According to Gartner, for example, Microsoft Lync as a voice solution grew 106% in 2013. In research conducted by T3I, 80% of SMBs surveyed showed interest in deploying Microsoft Lync, and of those, 40% had interest in enterprise voice. And on the Office 365 side, one estimate had the service at 29.76 million paid subscribers, an increase of 1.32 million new subscribers per month.

Into this gap enters AudioCodes’ One Box 365. Recent conversations we have had with both industry analysts and many of our own customers have validated the strong interest we have seen in the solution since its introduction back in the summer.  A hybrid on-premises/cloud solution, One Box provides a one-stop shop for all the critical hardware, software and services required for a successful Lync voice implementation. Combining multiple Lync server roles, gateway and SBC functionality into a single appliance, it comes complete with Lync certified IP phones, an Active Directory Domain Controller, voice quality monitoring capabilities and a dedicated user interface for easy migration provisioning and configuring for Lync users. The end result is an offering which allows customers an intuitive, cost effective and quick way to bring Lync enterprise voice alongside their Office 365 deployments.

Further Information

Several articles have been published in the past few weeks about the solution.

  • An in-depth analysis by Marty Parker of UniComm Consulting and Brent Kelly of KelCor, Inc. using essentially the same methodology they used for theirLync Conference 2014 TCO analysis, determined that the five-year total cost of ownership for One Box 365 would be approximately 60% lower for an organization with 50 to 200 users than a comparable on-premises implementation of Microsoft Lync. To watch a recorded webinar with Marty Parker and Brent Kelly click here:
  • Brent Kelly expands on the above TCO analysis using One Box in several different types of Lync deployments in his article in No Jitter.
  • Articles by Kevin Keiller and Marty Parker in UC Strategies show how the Lync ecosystem allows for the introduction of innovative solutions answering needs rising from the field.
  • John Weber, a Lync Server MVP (2010-2014), takes an in-depth look at One Box in his blog, TsooRad.
VoLTE Deployments

LTE Voice Summit Not Only About Voice

My takeaways from the LTE Voice Summit

Earlier this month I spoke at the LTE Voice Summit. As promised, slides are now available on SlideShare.

A few important notes from the event.

VoLTE – 11 service providers and counting

LTE was launched by 331 service providers worldwide. Once LTE has been launched, adding VoLTE to the mix makes sense to the service provider as it reduces their OPEX, saves spectrum and improves user experience by allowing for better voice quality, longer battery life and other benefits.

To date, VoLTE has been launched by 11 service providers.

60 others are in trials and planning.

VoLTE Deployments

 

Voice quality

Speaking with service providers that already launched VoLTE and have field experience and feedback, I heard there are issues when connecting calls between VoLTE and non-VoLTE networks.

Doing a one-size-fits-all transcoding to G.711 when exiting the VoLTE network is not a good solution.

There was a great presentation by Michael Thelander from Signals Research Group that compared quality over VoLTE vs. Skype. No surprise here, quality over VoLTE was better; they could have saved the dollars spent on the research. As VoLTE was built for real-time communication while Skype and other OTTs run over the data network, it is only expected that these would be the results.

The same applies to battery life. Since VoLTE is pre-integrated with the phone, things are better optimized. This includes video codecs that can be HW accelerated in native clients and other algorithms such as acoustic echo cancellation (AEC) that can run on the chip level. These yield better quality and lower battery consumption.

The more interesting question would be to test VoLTE to a VoIP client over a WiFi network and compare that to an OTT like Viber. In such a case, VoLTE has problems such as those I presented in my earlier post and in my presentation at the conference.

For these problems , AudioCodes presents a pretty compelling solution that comprises a smart entity (SBC) that resides in the core of the network and makes decisions with regards to transcoding, transrating, call routing and call properties negotiation (bit rate, codec, resiliency…). It uses network monitoring information and communicates with other network elements to apply its policy. Feel free to contact me for detailed information.

Services are based on RCS

Even though this was a conference about voice, services were mainly related to RCS. Service providers are continuing the RCS path and believe that once RCS will be fully integrated with the phone as default, users will use it.

I believe that service providers should manage a mix of “service provider OTT” with RCS in order to remain relevant. Offering only standard RCS capabilities will make differentiation hard as all service providers will offer the same thing with pretty much the same user interface as defined by the GSMA.

To that end, I presented this issue to David Hutton from the GSMA on a panel discussion. I believe that the decision of the GSMA to standardize everything in RCS right up to the user experience is a dreadful mistake, it is one of the reasons for the failure of RCS and imposes unnecessary limitations on the service providers. To my surprise, he agreed.

In conclusion:

  • VoLTE is happening.
  • Service providers that have already launched VoLTE services are starting to experience the complexity of connecting VoLTE to other networks.
  • Service providers understand that VoLTE by itself will not provide the required added value services and are looking for those services in RCS. They should combine these with their own OTT services in order to differentiate.
Managing Voice Quality

3 Things Required for Managing Cross Network Voice Quality

So you’ve built your VoLTE network for high quality. You are providing high bandwidth to your customers so browsing and watching video is great. You also managed to get delay, jitter and packet loss down so voice calls are using WB-AMR giving your customers top quality.

Managing Voice QualityBut even though VoLTE is set to succeed, it will not happen overnight and it can’t be an island, there are other networks it needs to connect with. You need to allow for calls to GSM, PSTN and wireline VoIP.

To allow for this, you engineered your network in a way that if a call needs to exit the VoLTE network to any of the other networks you simply transcoded it to G.711. With that, it connects “without any issue” to any network out there.

So you connected your VoLTE network to other networks but that’s exactly when problems started to come up. Users started calling your contact center complaining about voice quality issues, they felt as if a mouse has cut the wire. Analyzing the complaints showed that there are problems not only when calling between the different types of networks but even when calling between VoLTE networks of different service providers.

Different type of networks perform differently

VoLTE

Think of a VoLTE network. It prioritizes voice over other data types. It will not retransmit voice packets even if there is packet loss (different from its handling of data) and it dynamically tunes rate, stuffing multiple voice samples into a single packet and add redundancy when needed.

In a VoLTE to VoLTE case, this results in great quality but when the destination is on a different network, that network handles things differently, resulting in quality issues.

GSM

On the GSM network, data will be retransmitted in case of packet loss, VoIP traffic included. This results in increased delay. Moreover, the 3G network works in burst mode sending a large amount of data to the core of the network in bursts, resulting in delay and jitter.

In case of voice TDM calls, NB-AMR is used which is, of course, different from what is used on the other networks.

Wireline VoIP

In the enterprise and consumer environments, VoIP provided by service providers typically uses G.729. The network itself is typically designed for wireline access but in reality many access it over WiFi. Needless to say that network behaviour is different in each case.

PSTN

Well, I guess there is no need to say too much about this subject. It is robust and voice quality is constant but at PSTN quality.

The brain and the tools that solve the problem

We have seen that different networks have different characteristics. That’s no news I guess. The conclusion though, is. Because this simple fact means that it is not efficient to decide on call setup properties and mid-call changes without knowing exactly the characteristics of the caller and callee networks.

Solving the quality issues when calling between networks requires three things:

  • Knowledge of all networks’ characteristics
  • Real-time monitoring information
  • Voice enhancement tools that will be managed dynamically based on actual call and network information

The entity that answers these requirements would be an SBC or a transcoding GW that resides in the core of the network. It would manipulate voice using various voice enhancement tools, decide on the best codec and rate for a call between the networks and use monitoring information for its decisions

On October 8th, I’ll be speaking on this topic at the LTE Voice Summit in London. If you happen to be there, drop by and say hello.

I will also be posting more information about voice call quality enhancement tools as well as a link to my presentation on SlideShare so stay tuned and be sure to follow: @AudioCodes and @AmirZmora

Here is a sneak peek to one of my presentation slides.

Voice Quality in Wireless Networks

Multi-Tenant-SBC-Use-Cases

Angelina and The Multi-Tenants

When Angelina Jolie plays in a feature, it’s reasonable to assume that she would be playing a close role to the meaningful relationship in the movie. In “Gone in Sixty Seconds”, Sara (Angelina Jolie) is the main star’s (“Memphis” Raines played by Nicolas Cage) girlfriend, however, Memphis’ closest relationship and most meaningful dialogs are not with Sara, but rather with Eleanor,  a customized 1971 Ford Mustang Sportsroof. In the dramatic reunion between “Memphis” and “Eleanor”, he speaks to the car and touches it tenderly in the most romantic of moments.

Multi-tenancy is all about relationships, or more precisely, the lack of relationships between tenants. Multi-tenancy refers to an architecture where an application running on a server or designated hardware, serves multiple clients (tenants). Multi-tenant systems emerged hand-in-hand with the cloud rush. As more services move to the cloud and are offered as a hosted SaaS, multi-tenancy becomes more and more relevant.

Users are wary of a multi-tenant architecture due to one main reason – the fear that a single system serving a large number of organizations may present a viable security breach. That’s why multi-tenant applications are described by marketers with the following adverbs; separated, partitioned, segregated, non-bleeding, etc., implying that a user from one tenant can’t penetrate another tenant’s space served by the same application.

As the visualization trend grows, multi-instance architecture is being suggested as the ultimate remedy to the all multi-tenant architecture weaknesses. Multi-instance architecture is simple, adding a new instance of the application for each tenant/customer, eliminating the potential for any security breach. However, in life there are no free lunches and multi- instance modularity and elasticity come with a cost, some aspects of which can be listed here:

  • Waste of  Compute & Storage
  • Multiple applications to manage
  • High availability complexity
  • Upgrades “One by One” instead of “One and Done”
  • And more…

Tenant size in a multi-tenant architecture can vary and therefore the instance CPU, memory and interface allocations, should be optimized so as to not waste resources for small-sized tenants on the one hand and not to allocate too many instances for a single tenant/customer on the other. Multi-instance is like shopping in a mall with a bunch of $100 bills with no option to get back change. So when you buy a soda, you may lose $98. Similarly, it would be a great waste to allocate an instance with a capacity of 1,000 concurrent sessions to a small tenant for which 10 concurrent sessions are more than enough.

So how complicated is it to convert a single tenant system to a multi-tenant system? The “screwdriver fixer SW architect” intuitive reaction will be “piece of cake”. Let’s associate a “tenant ID” to all our internal and external tables and, hocus pocus, we have a multi-tenant system. This might work for some tenants who are not totally vertically separated. Tenants may have shared interfaces, for example, a multi-tenant SBC may have a number of tenants sharing a single interface or several interfaces of a SIP Trunk. The figure below shows a few of the possible use cases relevant for an SBC.

Multi-Tenant-SBC-Use-Cases

A multi-tenant system should be a fully scalable, “non-bleeding” partition per tenant running on a single shared physical entity. In should support per tenant configuration, monitoring, reporting, analytics, alarms and interfacing.

A real time system (e.g. SBC) should provide each tenant with optimal real time performance, as each session received by the system is classified and processed only through the tenant’s “orbit”.

Full flexibility should exist to move a tenant with its entire configuration between physical servers and physical locations, assuming extra server capacity is available on the site.

Summary

Multi-tenant options are many and should be chosen following a prudent analysis, otherwise, you may choose the most beautiful single instance and end up with bunch of tenants to foster.

Survey Results - Top VoIP Features

Survey Review: What VoIP Buyers are Looking For

Back in March, I wrote about enterprises moving their VoIP communication systems to the cloud and why it is more complex than simply putting a credit card number on a website. In that post, I referred to what Don Sadler from Software Advice wrote about 3 Ways to Keep Your VoIP Service From Going Down With the Internet.

The guys from Software Advice were kind enough to send me the results of their latest survey – Small Business Buyer View 2014 and I thought it would be worthwhile sharing the results with our readers.

Survey Key Takeaways

There are several findings in the survey I find interesting. Let’s go over them one by one.

More than half of prospective buyers were investing in business VoIP service for the first time.

Most of us, techy, VoIP savvy people, tend to believe VoIP is common in most businesses. I mean technology is around for over a decade now. How much time do those SMBs need to get going? For many of us, VoIP as we know it is old school; we are looking today at more advanced variations of VoIP like WebRTC that bring VoIP to the browser.

The reality is that most SMBs are not connected to VoIP services. Itzik Feiglevitch from AudioCodes presents more information about this in a diagram based on an analysis he has done.

Worldwide-SMBs-connected-to-VoIP-Services

The answers received in the survey fall nicely within the general point of this diagram – there is still a large market of SMBs out there that haven’t yet made the shift to VoIP.

Buyers were primarily concerned with reliability and scalability when evaluating new phone systems

Scalability is one of the advantages of going cloud but moving VoIP communication to the cloud doesn’t really increase reliability. There is the reliability of the servers themselves that typically improves because a VoIP communications cloud provider would normally have a stronger team of IT expertise that make sure the service is always on. However, having all the traffic go up to the cloud and back and the dependency on the link to be always on remains a challenge.

As explained before in my post All You Need is Cloud, the on-premise SBC would help mitigating this challenge by providing resiliency, optimized call routing, call cost optimization and QoE.

No buyers were interested in an on-premise IP-PBX, while a vast majority wanted a hosted solution

This is a clear trend we see across all businesses of different sizes and for different services – shift to SW solutions and cloud services. Having said that, concerns raised in the previous point must be addressed.

77% of SMBs are looking for services in the browser

Another interesting point that was not part of the “key Findings” presented at the top of the survey but did draw my attention, is the requirement for Web based solutions.

Many SMBs are probably not even aware yet of WebRTC but they are experiencing more and more services that are provided in their browser. Seeing that 77% actually preferred VoIP in their browser is an interesting indication for the potential of WebRTC in the UC for SMB space.

Survey Results - VoIP Deployment Preferences

Auto Attendant Tops the List of Desired Applications

The survey was seeking to learn the most important features buyers have on their decision checklist. The diagram below shows that Auto Attendant is well positioned on this list.

Survey Results - Top VoIP Features

Auto attendant is the way to navigate through a company’s directory instead of speaking with a real person who would transfer the call.

What if you could just say the name of that person, or what if employees could dial to anyone on their contact list, company list of suppliers and customers by just saying their name?

Based on AudioCodes advanced voice recognition technology, we provide this service today in the cloud, connecting to any PBX or hosted VoIP system.

Why is this survey important?

Understanding the criteria based on which SMBs make their buying choices is important. It reassures us about the “move to the cloud” trend but also clarifies the need to continue and provide reliability in the process.

VocaNOM People

Mobilize Your Users or Stay Behind

[Post is better viewed on the blog Website]

With very few players providing mobile communication services before the smartphone era, it felt like heaven for some major mobile service providers. But then mobile OTT apps kicked in! And ruined the party.

Oh, the Good Old Days

What was it like to be the CEO of a mobile carrier back in the days? Having a huge user dependency on cellular infrastructure and running in a playground where the smartphone is yet to be on-shelf, data revenues were booming and profits seemed well assured.

But in today’s mobile reality, OTT mobile apps are posing a huge threat for all service providers and carriers alike. Data revenues are continuously dropping. Being a CEO of a mobile service provider today means you’re in a war that you’re probably not too familiar with; Not a war between giants, but between viral mobile startups who are able to take the market within a year, to slow-moving, monopoly-DNA’ed creatures who now realize the urgent need for a decent battle.

Alongside mobile carriers who are struggling to cope with the booming OTT mobile market, the enterprise sector stays stuck in the middle. IT departments have to be impossibly flexible when they need to provide an organizational infrastructure that’s as easy as WhatsApp but well secured and comprehensively managed like Microsoft Lync.

VocaNOM People

No sweat, No Sweets

Building a solid mobile application arsenal for the OTT battle is not only fruitful, but also crucial for a service provider to stay in the game. AudioCodes is constantly aiming to enable mobile carriers and enterprises to cope with the modern OTT challenge in telecom. MobilityPLUS, an OTT mobile application for service providers and carriers, makes a classic 1-stop solution with its all round voice, messaging, video and social features. For a mobile carrier, the ability to distribute HQ mobile VoIP user-clients to its subscribers, freely branded and thoroughly integrated makes it an ultimate weapon for its OTT war. Roaming, a well-known incentive for users to go OTT, can finally be untangled and brought back to the service provider playground not just for data but for native voice communication as well at competitive costs and top-tier service quality.

A Foot on the Gas for the Enterprise

VocaNOM, a cloud-driven voice communication app for businesses and organizations, is a good example of how the enterprise market can also start making its way forward in the mobile app plot. Organizational and business contacts are always a mess to handle when you have an organizational phone directory that has zero-connectivity with a user’s smartphone.  For an enterprise, being able to manage all organizational contacts on the cloud, providing easy access and dialling for its users using voice recognition, is simply great if it wishes to stay up-to-speed and serve its organizational users with top-notch communication tools.

AudioCodes at SMW C2014

Time to Take Mobile Communication Forward

These are only few examples of how holding off the OTT turbulence is more than possible for service providers and enterprise, given the right tools and applications. At CTIA 2014 Super Mobility Week, we will be meeting up with service providers and enterprises to talk about what AudioCodes can do for them to mobilize organizational and commercial users all at once. I feel like whether you’re a service provider or an enterprise IT manager, there’s a lot we can do for you to empower your user-base.

See you in Vegas!

To schedule a meeting with AudioCodes at CTIA 2014 Super Mobility Week, visit:

http://www.audiocodes.com/events/ctia-2014

Steve Austin

Why RCS Failed

[Post is better viewed on the blog Website]

How Standards Define Themselves to Death

Steve AustinSteve Austin, The Six Million Dollar Man, was – Better…Stronger…Faster… That was the hope of RCS (Rich Communication Services).

RCS started its journey at the GSMA in 2008 with the promise to allow service providers to deliver “OTT like” services with interoperability across service providers and managed quality of service as it is provided by those that own the network. By being better than what OTT can offer, users would vote for those services of the service provider.

Where was the market back then?

Looking at OTT on mobile at that time, things were still kind of preliminary.

Skype – Mainly used on desktops, Skype for mobile was in its infancy

WeChat – didn’t exist, launched in 2011

WhatsApp – Didn’t exist, launched in 2009

Facebook Messaging – Project Titan for user to user messaging was launch in 2010 and mobile messenger app was launched in 2011

Viber – Didn’t exist, launched in 2010

You get the point…

The important things to conclude from this data are:

  • Back then, when RCS started, there was still plenty of market share for it to capture
  • The OTTs listed above took the market by storm working vertically (a specific service) and not horizontally (many services for a specific segment/region)
  • They are all islands…didn’t wait for any standards
  • Oh…and they are all free

Why RCS lost to OTTs?

RCS has standardized itself to death in 2 ways.

It has insisted on trying to define and standardize everything possible rather than sticking to the bare minimum. Due to this, it lost a lot of time and left little room for flexibility to those who wanted to deploy it. RCS and the brand “joyn” defined everything all the way up to the user experience, what the address book should look like and what the user would see on each and every screen.

On top of that, RCS standardization tries to capture requirements from 2 camps, what was known previously as RCS and RCSe, later to be unified under the Blackbird standard version. This moves sounds great but Blackbird still includes different options for doing pretty much the same thing. When you define multiple ways to send a message and to implement presence based features, the life of the developer becomes more complex.

The promise of RCS was valid

The promise of RCS was, and even today still is a valid one. It has been proven to be valid through the success of OTT players such as WhatsApp that provide some of the RCS services but in a proprietary way.
Different from VoLTE, that has good technical and business reasons to replace Circuit Switched voice, RCS doesn’t enjoy the network ownership advantage, OPEX savings and enhanced user experience compared to using an OTT service for the same purpose.

The major benefit of RCS could have been cross service provider interoperability.

Other assumed benefits, such as a unified user experience, are not more than a pipe dream as not all device vendors will vote for what joyn has defined (i.e. Apple). Given that, we are left with an application, at least on some of the devices, and not a pre-integrated experience that comes pre-loaded on the device.

The enhanced address book and integration with the phone’s address book has come to the OTT applications user experience a long time ago. Given the ubiquitous nature of some of them (who of my friends doesn’t have WhatsApp? None!), the benefit of RCS interoperability is losing its advantage.

There was another option

The other option was to put time-to-service at a higher priority than top to bottom standardization work.

Time-to-service as priority #1 doesn’t translate to zero standards, it translates to standardizing only what really needs to be standardized as was done in WebRTC, while leaving the rest for the implementers.

In context of RCS that would mean APIs (e.g. send message, get contact…) for applications to use the RCS service for launching innovative services and things related to payload (e.g. how a file is transferred between clients).

Service providers and RCS server vendors would provide client SDKs based on which the service provider could launch its own services. Additionally, they would provide them to developers to build services with and integrate them into other applications.

Conclusion

Reality has proven that even in places where standards exist, once communication crosses between services and networks, it goes through mediation servers. We see more coupling between clients and servers today, something that contradicts the goal of standards, to enable zero vendor lock. This reality is apparent today in every type of real-time communication – UC, IP-PBX, VoLTE and WebRTC. There is no reason why it will be different in RCS and therefore waiting runs the risk of missing the opportunity.