Watch over everything from a single pane of glass

A Network Management Idea Whose Time Has Come

Watch over everything from a single pane of glass

A few weeks ago, when my wife and I celebrated our 30th wedding anniversary, she bought me one of those (very) expensive, high-end watches. But even though my wife has excellent taste, and did indeed choose a beautiful timepiece, I’ve got to admit that I’m very far from being a watch fanatic. To be honest, I haven’t worn a watch on my wrist for over 10 years. Why would I need to? If I want to know the time, all I need to do is have a quick peek at my mobile phone. Even better, I can also see the date, my emails and my WhatsApp messages — and I can even get an up-to-date weather forecast for anywhere in the world. It’s all there. So much information available at a single glance.

What if there was something similar in the telecommunications industry that could make managing networks almost as simple as having a quick look at a single pane of glass? After all, VoIP management landscapes generally comprise three main layers of management tools that you need to learn and keep up with.

Let’s have a look at each of these layers.

In the top layer, sitting above everything, are the service providers’ network management systems (NMS). Typically vendor-agnostic, these applications provide a picture of the aggregated status of the entire service provider network. The service provider NMS aggregates the multi-vendor EMS indications into a central view and gives general network level insight.

The second layer consists of multi-vendor VoIP management solutions. These applications monitor the voice quality of all the elements in the network and provide a root cause analysis based on the voice and data layers combined.

The third layer is made up of vendor-specific management tools and expert systems that cover device and element management, service monitoring, analytics, security and advanced centralized VoIP routing.

For monitoring the devices’ status, an element management system (EMS) is going to be your application of choice. When you need to perform a root cause analysis on a VoIP issue, another application will be required. The same goes for analytics — you’ll need a third application for that. It’s a bit like having to walk around all day with three different watches on your wrist — one to tell you the time, one to tell you the date and one to tell you what day it is.

And talking of time, it’s clear that the time has come for a network management solution that gathers all these disparate parts together under one roof. A full lifecycle management suite for VoIP deployments that provides monitoring, management and operation of all the products in the network — all in a single pane of glass.

AudioCodes’ One Voice Operations Center (OVOC) is that solution. OVOC shows all the devices associated with a specific user and the user service experience in a single window, without having to jump from application to application. From this one solution, you can do everything that previously demanded several different applications, including:

  • New device detection and configuration
  • Accurate inventory population
  • Automation and mass operation support
  • A central, correlated alarm dashboard
  • Group-based configuration and update management
  • Change documentation and device configuration backup and restore.

A Network Management Idea Whose Time Has Come

And if all that wasn’t enough, you also get service alarms, trends and statistical analysis, reporting, user experience monitoring, root cause analysis and issue correction. OVOC brings it all together in a single pane of glass, exactly the way a smartphone does.

Although I don’t really like the watch my wife bought me, I feel compelled to wear it. I genuinely want to remain alive to be able to celebrate my 31st wedding anniversary. However, now and again something strange happens. Sometimes, when my wife and I are winding down with a glass of wine and a movie in the evening, my watch will suddenly pick up a reflection from the television screen. Instinctively, I tap on it as I would my phone to see if I’ve got any messages. Old habits always die hard, don’t they? With a quizzical look on her face, my wife asks me if all is OK with the watch and reminds me that it has a lifetime warranty.

Our application note, The OVOC Journey from Detection to Correction, explains in detail how OVOC seamlessly fuses VoIP network device management and quality of experience monitoring into a single, intuitive web-based application.

To learn more, click this button.

Get It Now

Unified Communications: Technologies that Paved the Way for Cloud Communications Dominance

A Brief History of UCaaS

Guest post by Mark Dacanay of RingCentral

It was just a decade ago when only small and medium scale businesses saw cloud communications as a viable option for a business communications solution. Enterprises mostly ignored the emerging technology because they already had on-premises PBX phone systems and traditional telecoms that they had already been using for too long to take notice of a new alternative.

Technologies that Paved the Way for Cloud Communications Dominance

Technologies that Paved the Way for Cloud Communications Dominance

Fast forward to 2018 and cloud communications is poised to dominate the market through cloud-hosted unified communications solutions. On-premises PBX systems are on their way to being obsolete, while traditional telecoms are struggling to keep up with an always connected generation. In fact, the global unified communications and collaboration market is predicted to top $35 billion by 2019.

It seems like cloud-hosted unified communications is here to stay and is set to dominate the business communications industry in the near future.

But before we look more into the future, it is important to look back to the past. How did we end up here? How did cloud communications, specifically unified communications as a service (UCaaS), come to dominate?

To give you an insight, here are the technologies that paved the way for cloud communications dominance:

Development of VoIP

It was around 2000 to 2005 when companies started using IP networks to transmit voice data. The technology was called Voice over Internet Protocol or VoIP. Adoption was not that fast. In the early 2000s, very few calls were transmitted through IP based lines and companies still preferred the traditional PSTN. However, as internet connections became more stable, more and more companies saw the benefits of using VoIP. By 2008, 80 percent of all new corporate lines being installed were VoIP lines. Now, VoIP is used by most unified communications providers as its primary method of transmitting calls or voice data.

Virtualization of infrastructure

The 90s were all about hosting software on your own PCs, so it is not surprising that most businesses at the time also hosted their business apps on their own servers, within their own infrastructure. Intranet services or local web connections that could only be accessed within the premises of the company was a big thing back then. Aside from the familiarity with on-premises systems and infrastructure, cloud technology was still in its infancy and there were still various security concerns that needed addressing. After all, data is stored by a third-party provider and it is transmitted over the public internet.

It was not until Salesforce launched in 1999 that businesses were able to use an actual enterprise app delivered over the ‘net. Salesforce, like today’s cloud services, hosted their suite in a virtual server and delivered the service via the internet, which was accessed via their website. Since then, various cloud services have popped up including Amazon Web Services in 2002. Thus, the virtualization trend has begun. Organizations started delivering services (SaaS, PaaS, IaaS) via the cloud through different deployment models, namely private cloud (solely for one organization), public cloud (open for public use), and hybrid cloud (a combination of public and private). Security has also been addressed with most providers employing security measures like heavy encryption on all facets of data transmission.

Circumstances also aligned for the emergence of the virtualization of infrastructure. This includes the improvement of high-speed internet and the support of leading tech giants like Google and Microsoft. When these giants embraced virtualization technology, it also caused a domino effect within the industry as a whole.

Moving PBX from on-premises to the cloud

Private Branch Exchange or PBX has been around since the 40s. In the beginning, PBXs were simple systems managed by the local phone company itself. Calls were routed from the Central Office (CO) to a business customer. It was very simplistic back then but it paved the way for on-premises systems where companies invest in their own PBX infrastructure to route incoming calls within the company. As mentioned above, the virtualization of infrastructures presented an opportunity for PBX to be deployed through the cloud. Through the Software as a Service model (SaaS), cloud PBX started making noise around 2005 to 2010 as an alternative to on-premises PBX for small and medium companies who could not afford to invest in their own PBX infrastructure. But what started as an alternative to on-premises PBX soon became a viable business phone system for companies of all sizes because of its mobility, flexibility, and scalability, not to mention the numerous advanced features like auto-attendant, answering rules, caller ID, call screening, and call forwarding. As an actual business phone system, the cloud PBX has become the backbone of what we would call unified communications solutions nowadays.

Evolution of team messaging to team collaboration apps

Instant messaging has been around for a while with personal messengers like Yahoo Messenger but the technology did not take off with businesses right away. It was around 2010 when team messaging tools really became popular with companies with tools like Microsoft Lync and later apps like Jabber. Now, team messaging apps are more than just for chats. Apps like Slack, Glip, and HipChat are now full-on team collaboration apps with video chat capabilities as well.

Feasibility of stable audio and video conference

In the past, audio conference calls were a premium service only offered by traditional telecom companies. But with the rise of VoIP, the application of transmitting voice data over IP networks has also made audio conferencing more cost-friendly. In 2005, Lifesize Communication displayed the first video conferencing system at the Interop tradeshow with video showing 30 frames per second, with a 1280 by 720 resolution. By 2010, video conferencing has become a necessity for most enterprises and multiple video conference providers like GoToMeeting and Blue Jeans have popped up in the market.

The arrival of true Unified Communications as a Service

In the last couple of years, the main focus of the industry leaders in cloud communications is to combine these different communication channels into one streamlined service.

With a system that meets most, if not all, the business communication needs of a company and removing the need to rely on separate providers for each application, it is no wonder why cloud communications, UCaaS in particular, is set for domination in the future.

About the Author

Mark Dacanay is a Digital Marketing Professional who has been working with a B2B company offering cloud-based services for more than 5 years. He is obsessed with anything about the cloud – the technology, not the fluffy stuff in the sky. You can reach him through Twitter and LinkedIn .

VoIP applications need dynamic routing decisions

If it’s Friday, I’ll Take the Scenic Route Home

VoIP applications need dynamic routing decisions

VoIP applications need dynamic routing decisions

In my opinion, Waze is the best navigation application in the market today. Actually, Waze is much more than just a navigation app: it’s a community of travelers and commuters who are constantly contributing to form one of the earliest and largest crowd-sourcing platforms. By using on-line navigation data and user notifications, Waze maps traffic jams and sends drivers a variety of notifications including hazardous situations on the road, police presence, and speed cameras.

When it comes to navigation setup, Waze is very much like other navigation applications; the navigation setup is static. The main setup decision related to routing that the user is required to do is choosing between the route with the shortest distance or the one with the fastest time.  In addition, the Waze user can decide to avoid toll roads, highways, ferries, complex turns and dirt roads.

The fact that the setup is static is a real shortcoming, since routing preferences may change during the course of a single day. For instance, in the morning when you’re in a hurry to get to work you might not mind using toll roads. But on your way back home, you might be quite happy to take it easy and go via the scenic route, enjoying the springtime aroma of orange blossom along the way. To achieve this with Waze or any other navigation application, you would need to modify your routing preferences twice a day.

VoIP routing applications suffer from the same issue: how to make decisions based on a variety of criteria. In an ideal scenario where the network is free of any impairments, the main VoIP routing criteria would simply be the cost to the desired destination (i.e. least cost routing). However, in real life, there are so many other competing criteria which need to be taken into consideration, e.g. VoIP delay, VoIP quality, bandwidth, connection health, the time of day, user policy, security, load balancing and call admission control.

Unlike a navigation application, in a VoIP routing application, most of these additional criteria can’t be configured with a simple binary yes or no. For instance, in the case of voice quality, the user would prefer the call to be transported via the route with the best quality while, at the same time, ensuring that the cost is as low as possible.  The same goes for voice delay, signalling impartments, etc. The network administrator would like his calls to take the optimal route, but how can he configure the priorities and weights for these competing criteria?  A tricky problem.

Currently, most VoIP routing applications handle this issue by associating weights to the main routing criteria. This means that the user associates a weight to each criteria giving each criteria a priority.  The routing algorithm takes into consideration the criteria based on their associated weights and calculates the routes accordingly.

An alternative scheme is basing the entire routing calculation on one criterion (usually cost). Any additional routing considerations are applied to the main rule as relevant on a call by call basis.

For instance, all routing rules can disregard VoIP quality in general, but a VoIP quality condition will be applied ONLY when it is relevant, e.g. any calls made specifically to New York must be routed via a high quality connection disregarding the cost.

With this per route association approach, routing rules can get quite complex but since the additional conditions are applied on a route by route basis they are still easy to configure and easy to maintain. Imagine how convenient it would be to be able to configure a routing rule which, for example, determines that calls from the CEO to the New York sales manager on Mondays between 8:00am and 10:00 am must be routed via best quality route. Now try to figure out how to configure the same routing rule using a Waze-like static routing configuration.

I wish that Waze had route options like playlists, aligned with users’ personal moods: happy routes, contemplative routes, romantic routes, routes for birthdays etc., maybe even combined with recommended music per route. In today’s dynamic lifestyle, we can’t rely on a static, generic setup.  We need tools that let us customise our needs as simply as possible, since routing is everything.


To find out more about how AudioCodes helps simplify call routing in complex enterprise and service provider VoIP networks, download our white paper today.

The path to replacing MPLS with broadband

Sustaining High Voice Quality Over Broadband

The path to replacing MPLS with broadband


The path to replacing MPLS with broadband

Hosted enterprise communication offers a good solution for enterprises looking to move their communication to the cloud and by doing so, reduce their CAPEX investment as well as benefit from a cloud managed solution that is regularly updated for supporting new technologies and features.

These benefits typically come with a caveat, however, a requirement to connect through MPLS to the communications service provider in order to reduce network impairments issues that impact voice quality.

MPLS cost TeleGeography

Source: TeleGeography


MPLS comes with a high price tag. The chart above shows typical costs of MPLS in key countries in comparison to broadband. For example, in the US, monthly costs for 10 Mbps of MPLA would be approximately $1,250 while broadband would be slightly over $100.

This represents a significant difference that calls for realizing the cost reduction opportunity. However, the risk of not being able to ensure high voice quality keeps many communications service providers away from recommending this option to their enterprise customers.

Voice QoS is a combination of codecs and other algorithms

Voice quality is determined by network characteristics such as delay, packet loss and jitter combined with the tools used to mitigate network impairments once they happen.

Many of the communications services are using technologies (phones and network servers) that are built for LAN environments or dedicated networks, are not built for the open Internet.

IP-Phones and applications are using codecs such as G.711 or G.729. These codecs are not built for the open Internet both from the resilience and voice quality perspectives.

Voice algorithms such as Jitter buffer need to be tuned for the network and additional algorithms such as Forward Error Correction (FEQ) and packet loss concealment should be implemented.

The end result is that many deployments today are not built for working over broadband and therefore the common practice is to default to MPLS, thus increasing OPEX and delaying customer acquisition (as setting up MPLS may take a few months).

Perfecting voice over unmanaged networks

Yet communications service providers can allow their enterprise customers to benefit from lower cost broadband without replacing their network elements or customer’s phones.

To realize this, however, a few things are required:

  • Real-time monitoring of the voice running over the network
  • Transcoding to codecs built for unmanaged networks such as OPUS. OPUS has resiliency built into it by design and supports a wide bitrate range going up to ultra-wideband.
  • Implementation and tuning of algorithms such as adaptive jitter buffer, FEC and packet loss concealment
  • Smart routing and balancing of traffic between several broadband links if more than one link is available

AudioCodes’ VoIPerfect offers all these capabilities and allows communications service providers a route for easy adoption of this technology by deploying SW or HW elements at their access and customer premises while not replacing the existing deployed elements.

To learn more about the VoIPerfect and experience a real demo click here (

VoIP Quality Jitter Delay and Packet Loss

Is VoIP Jitter, Delay and Packet Loss the Best Measure of Voice Quality?

VoIP Quality Jitter Delay and Packet Loss

“One of the values that I think men in particular have to pass on is the value of empathy. Not sympathy, empathy. And what that means is standing in somebody else’s shoes, being able to look through their eyes.” Barack Obama

Empathy – being able to feel sorry for someone else’s troubles – is a basic ingredient for good mental health. However, sometimes, when irony is involved, empathy might turn to ambivalence. For example, you will naturally feel empathy when you see or hear about a building going up in flames, but you might even crack a smile if the building in question is the fire department. (Of course that would happen only if no one was injured, right?)

We recently had voice quality issues in our corporate telephony system. Now that might happen in any organization, but when it happens in AudioCodes, the company which has become the hallmark of HD VoIP, that’s ironic.

Our IT guys brought their usual armour to battle and started taking on the packet loss with Wireshark (network protocol analyser), upgrading this and downgrading that. Then they started looking at the AudioCodes products on the VoIP network; scrutinizing the latest IP phone firmware, restarting the SBCs, disconnecting the MGW.  And still, they couldn’t find anything to help pinpoint the problem.

After a week or so, one of my colleagues placed a call and couldn’t stand the noise on the line.  Naturally, he cut short the call as cellular SP has “trained” us to do over the past two decades. And since he is the Product Manager for AudioCodes Management Solutions, he decided to try troubleshooting the problem on his own (15 years in R&D can come handy sometimes), using the AudioCodes Session Experience Manager.

Now I have to apologize up front since at this stage the story gets a little corny.  He found that a substantial amount of the off-net calls originated by the UC system were faulty with a poor quality score.  After conducting a short analysis with our IT department, he found a misconfiguration of the VMware machine running one of the IPPBX servers.  He wondered why our own IT guys weren’t using the AudioCodes Session Experience Manager. Could it be as a famous man once said, “familiarity breeds contempt”?

I am not relating this story to point shortcomings on the part of our IT department (God forbid!) or alternatively to glorify an AudioCodes product.  A vendor who speaks about his own products is almost as bad as a mother who talks about her own children.  My point, rather, is to elaborate on the concept of VoIP quality monitoring.

It is human nature to reach a conclusion by reviewing the consequences of actions. The human brain is constantly on an endless quest to solve riddles and reach conclusions (Gestalt psychology or Gestaltism).  Therefore, it’s perfectly normal for an IT engineer to analyse the VoIP network, search for the causes of poor quality such as packet loss, jitter and delay and based on the analysis, evaluate the call quality.

From my perspective, this analysis method is problematic.  It’s like commenting on the taste of a casserole by evaluating its ingredients – before even cooking the dish. Voice quality can’t be accurately evaluated by reviewing only the relevant network impairments (jitter, delay and packet loss). An accurate measure of voice quality needs to be taken at the VoIP edges (MGWs, SBCs, IP phones, soft clients) while taking into account the vocoder, jitter buffer type and depth (static, adaptive), packet loss metric (Network Packet Loss Rate, Jitter Buffer Discard Rate) and more. This information can’t be obtained by only analysing the traffic.


There is a mistaken belief in the industry that VoIP Quality Monitoring applications are like insurance policies -you buy them hoping not to use them. This belief is due to decades of trusted legacy telephony and basic trust in the organizational network, devices and solutions. In Reality, VoIP Quality Monitoring should be considered for ongoing use for the following:

  • Day-to-day, end-to-end quality monitoring and assurance operations with the ability to perform proactive actions to prevent quality issues
  • Root cause analysis for diagnostics when VQ issues arise

So if you are having VoIP quality issues, I empathize, even though after reading this, you might smile at the irony.


Super Creativity in Routing Diversity


“Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after a while. That’s because they were able to connect experiences they’ve had and synthesize new things”- Steve Jobs.

Recent research shows that “super creativity” is the way the brain makes the connection between different segments of the brain. Furthermore, it’s all about amount and diversity of connectivity. What’s connectivity? Brain anatomy (circuitry) or routing?

Perhaps both?

Karl H. Pfenniger (origins of creativity; Oxford 2001) claims that creativity involves the association of diverse and apparently unrelated entities and that the brain’s plasticity allows for neurons to adapt their connectivity to function. In other words, new semantic connections will not only be associated or correlated but over time will become hard-wired in the network of associations. So creativity is related to routing diversity.

Routing in the network layer

Data routing’s main pride over the last two decades is the distributed routing architecture. Using various routing protocols (RIP, OSPF, EGRP, BGP, etc.), networks are created and shattered dynamically and automatically. Routers are totally independent and are allegedly the ultimate “plug and play” products. Hmmm…. that’s almost true. For every product there are usually two parties – the vendor and the user. Routers are the first products which users can’t use without the assistance of a mediator – “network engineers”. That’s because while a single router configuration may be simple, designing an architecture of a complete network of distributed routers is very complex.  Over the years there have been several failed initiatives (e.g. FORCES RFC, AT&T RCP) to standardize centralized routing architectures. The emergence of Software-Defined Networking (SDN) reshuffles the cards. SDN architecture is dynamic, manageable and mainly cost-effective. SDN decouples the network control and forwarding functions, enabling the network control to be centralized.  The underlying infrastructure is abstracted and used by applications and network services.

VoIP level routing

Routing in VoIP architecture lags considerably behind data routing. VoIP routing is much more complicated than data routing. Data routing is based on layers 2-4, while VoIP routing rules includes parameters from layers 2-7.  Since the initial design of the enterprise VoIP network gave control to the Soft-Switch or IP PBX, routing was typically based on static routing tables. The situation becomes complicated for off-net calls. IP-PBX/Soft Switches “get rid” of such calls by directing them to the nearest GW or SBC.

In the case of multi-branch organizations, a single VoIP network may have several IP PBXs from different vendors, as well as MGWs and SBCs. The complexity of such heterogeneous VoIP networks is rising all the time. Each IP-PBX, SBC and MGW in the network has its own static routing table; a distributed system in which the included elements don’t communicate with each other.

SBC vendors have tried to solve this complicated situation in two ways:

  • Routing Manager – a static application which helps to construct huge dialing plans and routing tables and then download them to the SBCs in the network as static tables. These files are large and complicated, allowing vendors to charge a high price for the professional services that build them.
  • Session Router -a “primitive” SIP proxy located in the center of a star formation network that performs hop-to-hop routing of the call signaling. The Session Router doesn’t solve the problem as it dictates that all the VoIP signaling will be directed via one route and leaves the routing to the VoIP peers to the SBCs and MGWs.

“Shoot for the moon. Even if you miss, you’ll land among the stars” – Norman Vincent Peale.

The scalable & manageable VoIP routing solution

VoIP Routing Controller (VRC) is a holistic, dynamic routing manager based on Software-defined Networking principles. The VoIP routing controller decuples the device layer from the network routing and policy layer, automatically creates complex VoIP networks, and simplifies routing rules, monitoring and management configuration.

Organizations’ VoIP networks are constantly evolving due to a variety of factors; mergers & acquisitions, new locations, integration of new & old IP-PBX (or even PBX) and integration of SBCs and GWs. In addition, there is organic growth of an organization and accompanying technology evolution such as introducing UC to the network and consolidating IP-PBX. All of this makes managing the organization’s VoIP network a nightmare.

Unlike the routing manager and the session router mentioned above, the VoIP routing controller is neither a configuration element nor a SIP proxy (or any other SIP element for that matter). The VRC is a dynamic routing controller which calculates end-to-end routes.

All SIP network elements (i.e. SBCs, GWS) register to the VoIP Routing Controller automatically as they boot-up. The SBC and MGWs update the VRC with all the peer connections, (the SBC / MGW connections to IP-PBX, PSTN, SIP trunk, user interfaces, etc.) The VRC learns about the SBC and MGW automatically, and it’s done dynamically. Every change in connectivity and configuration is reported to the VRC.  Eventually, the VRC has the complete network topology connectivity and health picture.

The VRC also assists with the VoIP network design and creation. With the VRC, a network can be formed in one-click. The administrator can choose between mesh, star or dual star formations and all the connections are automatically configured in the SBCs and MGWs.. This literally saves days of professional services as there is no need to configure hundreds of classification rules, trunk groups, profiles and routing rules. Everything is done automatically by VRC. For customized network connections, the administrator just draws a line and the connection is configured automatically in the SBC or MGW. The same is true regarding erasing and modifying connections. Configuring connections between SIP elements is as simple as drawing a line. And all of this is provided through an intuitive graphical and simple user interface.

The VoIP Routing Controller deals with users’ attributes to optimize routing calculations. It imports and aggregates users’ information and huge dialing plans from different sources (i.e. LDAP server and csv files) and groups user and dial-groups for routing calculation and implementation of number portability.

How does this work? When an SBC or MGW receives a call, it sends a query to the VoIP Routing Controller by REST API. The query includes the entire set of call information (i.e. sip:invite) The VRC calculates the entire route end-to-end and sends the entire route back by REST API. From there, SBCs and MGWs perform the call and when the call terminates, the last node in the route sends a notification to the VRC. The routing calculation may be done using a variety of decision criteria, including: priority, time based, least cost, quality, connectivity, user and dial group..

Testing Creativity

Close your eyes and imagine ten or more different animals. OK, now open your eyes and write down the imaginary list.. This simple test can differentiate between Walt Disney and Steve Jobs and the rest of us mere mortals. Where most of us will imagine cows, donkeys, sheep and maybe a lion, in the “Super Creative” list you will find anything but “regular” animals, instead you will find the likes of Capybaras, Fennec Foxes, Kinkajous, and Servals.

Routing rules and manipulations are complex and can’t be implemented on-line. Therefore, one of the VRC’s important features is the “test route” and “test manipulation” which allows for testing any rule and policy that was created in the VRC and immediately seeing the impact on the routing and policy.


The VoIP Routing Controller is a very much needed solution.  It reduces the operational time spent on designing and provisioning the network topology; it dramatically reduces OPEX by avoiding routing configurations of many VoIP network elements; it lowers the need to rely on telephony experts; and it reduces the time spent on adopting evolutions in the network.

Privacy Security

What Do You Know about OTT Voice Usage in Your Enterprise?

Encryption doesn’t always equal privacy

IT departments have all the means necessary to manage voice communication over the enterprise network and know the ins and outs of those communications. Some enterprises have compliance requirements to which they must adhere, some have security considerations and others have reasons to “know what’s happening in their network”.

With traditional VoIP systems, achieving the above is relatively a simple task.

However, OTT VoIP traffic is a different story. And in the case of OTT, most enterprises settle with one of the following options:

  • Block it
  • Live with the reality

The question is, are these the only two options available and what do enterprises really want to do about OTT VoIP?

Border TURN server

Some enterprises are adding a new entity to the border of their network, a border TURN server that forces all VoIP media traffic to go through it. This includes enterprise managed VoIP as well as OTT. VoIP media that doesn’t go through the border TURN server is blocked.

Adding this entity and blocking all VoIP media that doesn’t go through the border TURN server creates a problem for WebRTC communication because only one TURN server address can be provided for the peer connection establishment procedure. Since many services require media to go through an application TURN server, the border TURN server is left out of the flow and media that doesn’t go through, is blocked.

In a post I published last week together with Dan Burnett (co-editor of WebRTC standards) on (where we publish updates about what takes place at IETF and W3C with regards to WebRTC), we talked about RETURN. In a nutshell, RETURN encapsulates two TURN servers into one by adding the border TURN server as a configuration option to browsers. Details and illustrations can be found in the original post.

Since WebRTC media is always encrypted, what is the point in requiring it to pass through the border TURN server?

What can be extracted from encrypted communication?

Privacy SecuritySince all media flows through the border TURN server, there are some basic things it can “know” – such as the source, destination and length of a call.

With this knowledge, the server can block calls from black listed addresses, limit/monitor call duration and collect this information.

These capabilities are pretty basic and I wanted to know if there was more a border TURN server can detect in an encrypted media stream. To better understand, I turned to Yossi Zadah (who is already well known on this blog) and to Ilan Shallom. Ilan is a Professor at Ben-Gurion University and founder of a speech recognition company that today is part of AudioCodes. His technology is the brain behind our VocaNOM solution.

Some might be surprised to learn that there is a significant amount of information that can be extracted from an encrypted media stream. There are studies that show it is possible to identify the language of the conversation. Other studies show it is possible to unveil the identity of the speakers on such a call and even create approximate transcripts of encrypted VoIP calls by identifying words in the stream.

There is also a thesis specifically relating to Skype using Silk (from back in 2011) that details information that can be learned from such conversations.

Key Takeaways

  • Border TURN servers are being deployed at enterprises. Though they impose problems on WebRTC communication, RETURN is planned by the IETF as a solution.
  • Given the limitations border TURN servers impose on OTT traffic, my personal view is that they would be counterproductive in most cases as they limit Bring Your Own OTT (BYOO) in the enterprise
  • If you thought that your WebRTC call is private…think again.
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.


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.


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.


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.


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.