Yaniv and his rump steak

How Can Your IP Phone Choice Reduce Infrastructure & Bandwidth Cost

Last month we had a roadshow in South Africa. My vegetarian friends will have to forgive me… but what a wonderful place! Over dinner while enjoying a really good rump steak and a glass of Pinotage, we met with an IT manager from a large enterprise that was interested in our IP Phone solution.

Yaniv and his rump steak

During the meeting, the IT manager explained his challenges and concerns.

His company recently selected an IP phone vendor for Skype for Business. Unfortunately, it didn’t provide the solution they were expecting and now they need to find a proper solution to their issues. Their call quality was poor, the phones weren’t user-friendly and the architecture design didn’t allow them to use media bypass.

But his first and major concern was cost savings:

Today, they spend hundreds of thousands of dollars annually on their infrastructure and bandwidth for communication between and in branches.

In between bites I introduced the AudioCodes solution and vision which is to not only to provide IP Phones but to offer a full solution. I explained how he can take advantage of our solution to solve his concerns.

Firstly, we are the only vendor in the market today that supports SILK and OPUS in our IP Phones.

SILK, the Skype for business native codec, is a dynamic breathing codec that adjusts to the bandwidth dynamically during the call according to the network capabilities and restrictions. If there is a good network, SILK will use wide band crystal clear high definition quality (even better than G.722). But if someone downloads a large file or a home user’s infrastructure is poor, SILK dynamically will decrease the required bandwidth, to even lower than what G.729 uses, allowing users to have a conversation without any chopped voice or interruptions. (SILK can overcome Packet loss, jitter and delay).

But SILK doesn’t only solve the bandwidth and quality issue; it also saves a lot of expenses on infrastructure as it consumes only 30% to 50% of the required bandwidth.

I mentioned to him that the improved voice quality and savings in bandwidth and infrastructure costs apply even to a greater extent in cases where communications is provided from the cloud by a hosted UC provider.

I noticed the gentleman’s eyes getting wider and a big smile emerging on his face.  I heard him saying that if he could save 40% of the required bandwidth, he could save hundreds of thousands of dollars on the first year and additional 10% on the call traffic every year! And all this, simply due to using AudioCodes phones with SILK!

But that’s not all.  Just imagine, I told him, that call quality complaints will decrease dramatically as well and user satisfaction and productivity will rise. And this is only the tip of the iceberg. We still haven’t discussed the savings that can be had by using AudioCodes IP Phone manager.

The IT manager paused for a second and asked what he should do with the phones that are currently using G.729 and G.711 and the PSTN calls? I need to divert all these calls to the core and transcode them in the mediation server, he continued, since our current SBC doesn’t support SILK. (He meant that all these calls must now go through the HQ Datacenter core, overloading the core network and introducing VoIP challenges such as long delays, packet loss and jitter).

I was happy to respond that since AudioCodes not only offers SILK IP phones but SBCs that support SILK as well, they can be used in the core while the calls will use media bypass. This will save a lot of money, and prevent having frustrated users and a complex and clumsy design.

At AudioCodes, I summed up, our products provide a full solution, using our entire ecosystem encompassing our IP Phones and SBCs, to provide end-to-end SILK capabilities including resiliency, should for whatever reason, Skype for Business become unavailable. But most importantly, these solutions can save your organization a lot of money on the infrastructure.


Satisfied, we both turned to enjoy our steaks…..


To learn more about AudioCodes IP Phone family, click here:


Management System

Amazing Savings with a Managed IP Phone System

Management System

In a recent No Jitter blog entitled Managing IP Phones Goes Way Beyond Provisioning, I pointed out how much more powerful a managed IP Phone system is than simple provisioning and that this power and flexibility can bring considerable cost savings to an IT department. This wasn’t just marketing talk. In this blog, I want to tangibly demonstrate how this savings is achieved and what kind of numbers we are talking about.

To do this, I want to take a real-world example of a large enterprise that has deployed 20,000 IP phones amongst its employees. There are several levels to the cost savings, but it starts with the basic element of a managed IP phone solution saving countless help desk hours by providing IT the ability to remotely detect, correct and configure IP phones rather than the need to speak with the user and figure out the problem. If the average time per help desk call to figure out the problem without the managed system is conservatively 15 minutes, with the managed system, that time is cut down to just several minutes – we’ll go with 3. If the cost of a help desk worker is $50 an hour, then the savings would be reflected in the amount of help desk calls multiplied by the savings in time between 3 and 15 minutes.

Below, we look at a three-year model in which the amount of help desk calls will no doubt decrease over time as the system is used. Again, with a conservative estimate, if in the first year we can expect at least 20% of the 20,000 IP Phone users to have a single help desk call, going down to 10% in year two and 5% in year three, the savings can reach $70,000 over the three-year period. In reality, the amount of help desk calls could be as much as double ($140,000), the savings increasing accordingly.

IP Phone TCO

But that’s only part of the savings story. The IP Phone Manager allows for zero-touch customized configuration for multisite deployments. Such customization without a central management tool would require a pre-staging service from an integrator, estimated to be around $5-$10 per phone. Thus in the case of a 20,000 phone rollout, that could mean an additional $100-200K in savings.

And finally, AudioCodes IP Phones support SILK, the native Skype for Business vocoder. This vocoder delivers the best end-to-end voice quality experience available, further reducing the load on the help desk by eliminating call quality complaints which are possible in VoIP networks. But beyond the user experience and business productivity enhancement, the SILK vocoder consumes as much as 50% less bandwidth as compared to other IP Phones vocoders. This directly translates into the ability to save on remote branch MPLS access capacity and costs. In some cases, where dedicated bandwidth is allocated for voice traffic, this can lead to 50% less bandwidth consumption and MPLS costs.

In sum, the ability to manage IP phones with a system such as the AudioCodes IP Phone Manager, can lead to significant savings for a company.

AudioCodes IP Phone Manager Express is a freely downloadable Windows application that enables you to manage up to 500 AudioCodes IP phones efficiently from a single location.

The AudioCodes One Voice Operation Center IP Phone Manager, can support higher capacities.


Media, Signalling and Breaking the OTT Islands

My post summarizing some of the Telco presentations at WebRTC 2014 received a comment from Josh, one of our blog’s loyal readers,who pointed out the market need for breaking the OTT islands.

On the topic of transcoding in your piece. Can you tell me how hard it is to transcode or not and can being a strong transcoder bring a high barrier to entry OTT VoIP network to market? I believe Audiocodes is one of the few players that can transcode brilliantly. For example: I believe you can allow for Whatsapp users to talk to Viber or Line to communicate with Skype. Now that is a service that would knock the socks off the market. Can you give me some color on this thought process?”

My reply to Josh was:

“Great comment that deserves a post as an answer rather than just a reply in the comments section”

So here it comes…

I would like to break down the comment into 3 topics:

  • OTT Islands
  • Media
  • Signaling

OTT Islands

This boils down to the following: do these service providers/OTTs want their services to interconnect?

Imagine you couldn’t call your friends’ home or mobile phones just because you are using service provider A and he is using service provider B. That’s not something we can accept.

In the Telco world, interoperability is king.

One of the reasons excuses Telcos use to justify their slow progress on RCS and VoLTE is the need for specifications to stop changing. They invest endless efforts and money to assure interoperability, that you can call anyone and that you can take your mobile to any country with a compatible network and just use it as a roaming user.

Using the same thinking process, some wait with WebRTC as even WebRTC1.0 is not really finalized and now we have ORTC and WebRTC 1.1 in the plans.

In the OTT world, interoperability contradicts the basic DNA of the company. They build islands and protect them. They typically don’t want you to be able to call someone who is not on their network unless you do it using some “out” service based on PSTN and are charged accordingly.


There are rare cases where OTT players open up for others to interconnect between them. I was fortunate enough to be involved in such an initiative in my previous life. We provided a server that connected between two very big OTT players. Initiative came from them as they were battling an even larger OTT service provider and concluded they would be better off teaming up on this.

This interconnect was requested by them, hosted by them and available only for them. To the best of my knowledge, this interconnect wasn’t that successful. The reason might be that the interconnect was only for a limited set of capabilities. Doing full interconnect – user management, presence, voice, video, chat and advanced communication features – is hard and not always desired by the OTT as it eliminates the reason for a user to join their network, as he can access it from his current one, so why bother installing another app.

WebRTC is an interesting beast in this context. On one hand it is being adopted by traditional telecom vendors and service providers but on the other hand it was built for the web and has some OTT symptoms.

WebRTC deployments have strong client server coupling and connectivity to other networks is done through a GW, similar to the way it will be done in the case of OTT.

Assuming an OTT does want to open his service for interconnection, there are two big items he will need to make sure are open. Signalling and media.


Signalling in this context includes all communication between the client and the server that is not media (media preferably goes directly between the clients).

Finding users, adding them as contacts, publishing presence information and receiving such information, initiating sessions (chat, voice, video) and activating advanced features. All of these functions require signalling.

OTTs don’t wait for standards to be ratified. On the contrary, signalling is the area where they differentiate, where they add their unique competitive edge. While some base their signalling on standard protocols such as SIP, there are always layers on top that make it different from the standard.

Hacking OTT signalling is sometimes possible, the problem is that OTT service providers may change parts of their signalling or add capabilities as they add more features. Moreover, if they don’t want you to GW them to other networks, they can block you.


Media is a completely different animal. While some OTT service providers view voice quality as one of their strong points (Viber played on HD voice high quality in their early days), generally speaking, voice and video codecs used by these service providers are industry common codecs.  Skype, for example, developed the Silk codec for their internal use but later on opened it for everyone to use and today Silk is a popular codec. Opus, the mandatory codec for WebRTC, incorporates both Silk and CELT.

Viber does claim to use some internal codec but since most of these OTT players (Viber among them) provide PSTN connectivity, they have the capability to transcode the media used in their island to G.711, thus, to any codec.

Relating to the comment Josh made: While there are many transcoding solutions available, especially when voice traffic goes over the open internet, as in the OTT case, quality issues may arise. Given over 20 years of experience and technology developed at AudioCodes our products include quality enhancement capabilities that compensate impairments and network behaviour differences such as jitter and delay.

Why this is important?

While people see value in interconnection between OTT players or even having multi-OTT applications, OTT service providers typically view this in contradiction with their interest. They want users to use their service so they can monetize them.

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.


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.

Moving WebRTC Into Your Network Through the Front Door

Moving WebRTC Into Your Network Through the Front Door

As part of my work with WebRTC, I get a chance to speak to different types of companies about their WebRTC plans. When speaking with companies that have existing VoIP products and services, the conversation usually moves to how WebRTC should be added to their offering, what the additional service benefits are and how to architect the solution. The typical requirement is to leave the existing deployment untouched and bridge WebRTC into the existing network through some sort of a GW. Where should the logical function of the GW be located and what should the network architecture look like are usually the questions debated. To answer them, I decided to write this post.Moving WebRTC Into Your Network Through the Front Door

Image credit: Muhammad Mahdi Karim

To demonstrate the consideration points and options, I will use an example of a contact center. For the sake of this example, let’s take a contact center that has both PSTN lines as well as SIP Trunks from a service provider. All traffic inside the contact center is via SIP where some of the agents are working on premise and others are home agents who are “called in” for handling contact center peak traffic.


Architecture Options when Adding WebRTC

In my discussions with customers and partners who are looking to add WebRTC into their existing networks, the architecture alternatives considered were:

  • A dedicated GW
  • Adding a WebRTC interface to their current core server
  • Adding WebRTC through an SBC

Before and After WebRTC

BeforePre WebRTC Contact Center Connectivity

  • Traffic comes from a service provider over SIP trunks or PSTN
  • All traffic in the contact center is SIP
  • Home agents are connected over IP-SIP but this is done in a secured and controlled manner
  • The contact center core server is placed inside the contact center network. Security is handled by other elements so it is protected from denial of service attacks, call fraud and other security vulnerabilities
  • Calls are using G.729 or G.711. Transcoding, if required, is handled in the contact center network



Adding WebRTC into the game creates new requirements and a new type of traffic source. With WebRTC, users browsing the website of the company serviced by the contact center, can call in directly from the browser. Their traffic runs over the Internet directly to the contact center.

WebRTC includes 2 voice codecs: G.711 and Opus. These are the codecs that come within the browser. If the intention is to eliminate the need for download, calls must be initiated using one of these 2 codecs.

Since G.711 is not built for running over the open Internet as it doesn’t include resiliency, it is beneficial to initiate the calls with Opus. The optimal approach would be to run Opus end-to-end from the browser to the agent but in cases where this is not possible, it is best to keep Opus on the open Internet leg and transcode when getting into the contact center network.Alternatives for adding WebRTC to the Contact Center

  • The contact center is required to have a “leg” in the public Internet domain
  • Quality of service is not managed. Even though in many cases the quality is good, supporting SLA requires the capacity to manage and monitor quality of experience (QoE)
  • Supporting Opus requires either adding a new intensive computing transcoding function or adding Opus to the agent’s client


Alternatives Comparison for adding WebRTC to Contact CenterThe comparison above doesn’t relate to any vendor specific product but rather looks at common functionalities of such products. Given this, the following conclusion should be viewed in context of the actual functionality supported by the specific products considered.

The comparison shows that in the case of the contact center example in this post, adding WebRTC to the existing internal contact center server will yield high risk and therefore, it is not a recommended alternative.

The selection between a pure GW and an SBC would depend on priority focus. If security and QoS are of high priority, the comparison leans towards the SBC alternative.

Going native with WebRTC

Going Native with WebRTC

Going native with WebRTCIf you are reading this blog there is a good chances you heard about WebRTC and are well aware of the various products and services around it. Centering on enterprise communication and how WebRTC is being realized in this segment, the market is pretty much focused on one solution – a GW.

Now don’t get me wrong, WebRTC GWs are very important, you can’t really do without them if you want to overcome the slow deployment cycles and stay current with technology advancements. The point is that a GW is not enough. Let’s delve more into that.

The Typically Proposed “WebRTC for Enterprise” Architecture

If you look at some of the architectures used today for bringing WebRTC into enterprise networks they typically comprise a WebRTC GW and a media server that transcodes Opus to some other common codec, say G.729. Some options will also include RESTful APIs for configuration and creation of services on top. On the Audio side, there are cases where G.711 is used end-to-end but this option is not a preferred one from quality perspective when going over the open internet even though there are ways to add resiliency and improve quality even if G.711 is used.

A typical architecture of WebRTC GW Deployment

A typical architecture of WebRTC GW Deployment


The architecture described above is great, it will do the job. Question is, at what price.

Basically this architecture is kind of an “easy” way to bridge WebRTC into an enterprise network. You put a big box that will brute-force everything to what you have running on your network today. If that big box doesn’t provide the required capacity, just add another one.

There is another option

The most “expensive” component in GWing WebRTC into an enterprise network is the transcoding part. The way to work around this is by adding native support for Opus to the end devices. Doing so will yield quality improvement, cost reduction and preserve privacy. You can find a detailed technical overview why going native with WebRTC media on the end devices is important in an earlier blog post I published.

Reality is that Opus transcoding is extremely computing intensive so architecting this task on the server side will take a significant capacity toll on your system.

The flip side of this is that putting Opus on the IP Phone is complex. Assuming you are going for a SW upgrade and not a HW change, it requires flexibility in the phone architecture and hard work to get Opus running on it.

The subject of why adding Opus to existing IP Phones is complex interested me for a long time so I had a chat with our experts. Eli Shoval who is running our DSP Group and Oren Klimker, a team leader in this group.

The challenges in running Opus on an IP Phone can be summarized to be:

  • Processing power – Since not all IP Phones were born equal there needs to be optimization work and actual rewriting of some codec parts to make it run best on the IP Phone processor
  • Memory – This includes both footprint and run-time memory requirements. Opus is a feature rich codes that serves a wide variety of implementation scenarios; additionally, since sampling rate of Opus is higher than traditional VoIP codes memory required for an audio channel is increased

This in turn yields 2 main tasks required to overcome the MIPS and memory challenges:

  • Optimization – This work includes optimized implementation of some components of the Opus codec for both performance on the specific phone’s SoC (System on Chip) and memory consumption
  • Selective implementation – Part of the rewrite work needs to include removal of certain functions not required on an IP Phone

But there is Opus 1.1, doesn’t that solve the issue?

The short answer to this is NO.

In details, there are 2 reasons why Opus 1.1 doesn’t remove the need for native support for Opus on the end devices but rather make it even more essential.

The first reason is simple. Since transcoding will always add delay, reduce quality and impose cost on the server implementation; whenever possible, better to avoid getting into transcoding.

The second reason lies in the details of Opus 1.1 improvements. There is a pretty long list of changes, some such as surround encoding improvements don’t really touch the IP Phone requirements that much. What I want to take a closer look at is the speed improvements. As it looks, the team that built Opus 1.1 focused on improving the codec speed when running on ARM processors with NEON (do I hear mobile?), they reached up to 40% improvement. On the other hand, for x86 architectures there is no real improvement and in some cases things even got a bit worse. This can be seen in the diagrams below.



Opus 1.1 performance on ARM Cortex-A9 and i7-3520M

Opus 1.1 performance on ARM Cortex-A9 and i7-3520M



This means that Opus 1.1 doesn’t bring good news to transcoding servers but it does improve the performance on some of the end devices.


As explained in this post and on earlier ones the preferred architecture for deploying WebRTC on any network and specifically on enterprise networks is one with end-to-end media without transcoding. The target should be to minimize the cases of transcoding to those where it is a must. Such cases as where traffic is going through a GW to PSTN or over SIP Trunks. In other cases, going native with WebRTC on the end devices is a preferred architecture.