Posts

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.

OTT-Island

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.

OTT-Island

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

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

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.