Posts

I don't gamble

I Don’t Gamble

The AudioCodes-Microsoft Lync angle

[Post is better viewed on the blog Website]

I don’t gamble.  Not that I hate gambling, or that I don’t understand the “thrill” that comes with it.  I just don’t gamble.

When I was in my early 20’s I went on a family vacation in Puerto Rico, and our hotel had a casino.  I had 5 quarters in my pocket when I sat next to a slot machine.

4 quarters went away in a blink of an eye.  The fifth gave me back 6 quarters, and as I was about to kiss the last one goodbye and move on, I won $86.

I took the money and ran off to rent a jet ski. That was it. I never put a single coin in a slot machine since.

I recalled this since 2014 starts off for me with an unusual sequence of travel destinations:  I just got back from Macau China two weeks ago from our APAC sales kickoff event, and I’m heading next to Las Vegas for the Microsoft annual Lync Conference.  The two biggest gambling destinations in the world, 1 month apart, for someone who doesn’t gamble. Go figure.

I don't gamble

2014 is starting off on a very positive note for our Lync program.  We have introduced a new high capacity session border controller (SBC) which has sufficient capacity to cover the data centers and headquarters of 99.9% of the world’s enterprises.  We focused significant development efforts on functionality, security and interoperability in the last 3 years, and in 2013 we were able to quickly scale up the capacity of our SBC.  I think that the timing is pretty good because we are seeing enterprises scaling up their Lync deployments, and as they start retiring legacy PBX and ISDN/T1 trunks, they are moving to SIP Trunking.  This is exactly where we fit in with our SBC, as part of our very successful One Voice for Lync offering which includes gateways, SBC, SBA, IP Phones and applications for Lync.

Our release got a lot of positive industry reviews such as the article Thinking Big with AudioCodes by Blear Pleasant on UC Strategies.

“That’s why AudioCodes is “thinking big” and introduced the Mediant 9000 Session Border Controller, which supports up to 16,000 concurrent sessions and extends the capacity of AudioCodes Mediant SBC family.  As part of AudioCodes’ One Voice for Lync product portfolio, the larger capacity SBCs enable enterprise customers to consolidate the network infrastructure for Microsoft Lync, simplifying training, deployment and support. AudioCodes and Microsoft have been working together for years, and AudioCodes realized that it was important to expand its SBC capacity in order to better support large Lync deployments. This is especially important as the momentum for Microsoft Lync continues to grow, with nearly 60% of enterprises with over 500 seats surveyed by Infotrack deploying or planning to deploy Lync.”

It was very clear to us that once we complete the networking products portfolio, the next step would be to offer a uniform management suite for it, and that we did!  We just announced our One Voice Operations Center which is a holistic suite of life-cycle management applications for large scale cloud or premise-based unified communications deployments.  With that, we are very well positioned to serve the largest of the Fortune 500 enterprises as they roll out Lync globally.

Just before the Lync conference starts, we will be hosting a closed user group event of top notch Fortune enterprise customers, for a round-table discussion about Lync global roll out best practices. Later in the week we are holding a “Vegas Style” party for our partners and customers. If you are coming to the event please make sure to stop by the Audiocodes booth #625.

All in all I expect we will have a great week in Vegas.

It makes me feel that if you plan properly, you don’t have to gamble…

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

Source: xiph.org

 

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.

Conclusion

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.

Secured Approach to Cloud Telephony Services

A Secured Approach to Cloud Telephony Services

Secured Approach to Cloud Telephony Services

Image credit: Flickr user opensourceway

One of the common dilemmas to most “mission critical” cloud service providers is whether an on-premise border gateway or tool should be part of their architecture for connecting on-premise software and HW appliances to their cloud services.

The purposes of such a border gateway or tool are various and depend on the cloud services provided. For example, a familiar tool is the AWS Storage Gateway. This gateway connects on-premise appliances to the Amazon Cloud storage services. Other cloud services such as big data analytics and network performance monitoring architecture may include on-premise tools for remote sniffing, data gathering, filtering, transforming, preliminary analysis and mass data transport.

When thinking of using a cloud service for enterprise telephony, a common decision point is whether to connect the enterprise IP Phones directly to the telephony service provider or to deploy an on-premise cloud appliance.

Actually, an enterprise cloud-based VoIP services architecture, dictates the need for an on-premise Session Border Controller for basic operation solving connectivity, (i.e. NAT traversal), security, resilience and quality issues.

Connecting the enterprise to the service provider cloud through VPN

Trying to reduce costs, VoIP service providers often bypass connectivity and security issues by connecting the Enterprise to the cloud using VPN over IPsec or MPLS-VPN service with or without standard End-to-End Service Level Agreements and performance reporting.

Both VPN-IPsec and VPN-MLPS connections simulate a L2/L3 LAN with the service provider. This architecture obviates the need for NAT traversal and on-premise VoIP security, as VoIP clients and IP phones share the same IP subnet with the service provider SBC.

Enterprise-Cloud-Over-VPN

VPN connection between the enterprise and the service provider

Adding Multitenancy

This approach may be satisfying for private or dedicated cloud architectures, although it doesn’t provide a solution for resiliency and voice quality monitoring. However, for cloud-based VoIP service providers who provide service to multiple enterprises, this approach is problematic.

Multi-tenant-SBC

Multiple tenants connected to the service provider through VPN

Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server or HW system, serving multiple client-organizations. Although multitenancy can be achieved by running multiple instances of the application, in most cases multi-tenancy is designed by virtually partitioning an SBC data and configuration. Each tenant works with a segregated non-bleeding virtual application instance.

Multi-tenant cloud-based VoIP services share a single application server instance (i.e. IP PBX, application servers) and network entities instance (i.e. access SBC, peering SBC) between several tenants.

Seemingly, multi-tenant shouldn’t present any security or other issue, but in reality, this tenant segregation is almost impossible since, after all, tenants may share network interfaces (same IP and port 5060), and a SIP trunk or MGW in the northbound, so the segregation is not complete. An attack on one of the tenants or a misconfiguration of one of the shared resources, compromises all of the tenants’ security. In such a case,  as the tenants are sharing the same L2/L3 with the service provider and relying on the service provider IDS (intrusion detection server) and IPS (intrusion prevention server), a simple intrusion can be destructive.

Cloud-Appliance

 An SBC as demarcation point between the enterprise and the service provider

Isolating the enterprise from other tenants’ security threats

Organizations that can’t afford compromising their security and can’t trust 3rd party security services, should deploy an enterprise SBC as a demarcation point.

An Enterprise SBC provides:

  • Support for back-to-back user agent (B2BUA) functionality
  • Security and privacy (personal information is not forwarded to the cloud)
  • Emergency calls and regulatory
  • Resiliency
  • Remote Agent termination
  • Registration throttling
  • Voice Quality Monitoring
  • Call Admission Control and Rate Limiting.
  • Registrations overload and avalanche protection
  • On-premise recording, the SBC forks the calls

Finally, cloud-based VoIP services can be connected to an Enterprise via VPN-IPsec or VPN-MLPS without the need for an Enterprise SBC. However in choosing this path, the enterprise loses much of the above mentioned functionality related to the SBC and puts the enterprise in a security risk as well.

Image: AudioCodes SBC Configuration Wizard

Making SBC Configuration Human

When I visited a 777 cockpit for the first time, what struck me most was all the buttons. I thought to myself, how on earth do the pilots know what to do with them all?

Looking at an SBC configuration reminds me of that same experience and over the years I played aroundwith quite a few SBCs of the SBCs out on the market.

Putting things into perspective, a typical SBC user manual is a few hundred pages long. A typical vendor’s beginner SBC course would run three days or more.

In light of this reality, one of the first questions an experienced customer would ask when considering an SBC would be, “just how complex is the SBC to configure?”

The perception of complexity is well rooted in reality and for good reason. It is not that SBC vendors lack UX (User Experience) knowledge or capabilities. The complexity is derived from the flexibility of the different VoIP standards, which means that every vendor can implement the standards in a different way. An advanced SBC is expected to deal with all of this complexity and interwork between different parts of the network on multiple layers, including SIP, media and IP. The SBC needs to be able to classify groups of users according to multiple attributes, to maintain access lists, manage security, routing and more.

Complexity has its price

The implications of SBC complexity are serious. For one, such complexity raises the cost of installation as technicians need to spend more time on site; it increases the chance of misconfiguration resulting in communication errors and increased support costs. Overall, the complexity of an SBC constitutes a hurdle in the transition to SIP trunking.

But does it have to be that complex?

Consider the following:

  • As it does elsewhere, the 80/20 rule holds true for SBCs as well. 80 percent of SBC customers only use 20 percent of the SBC’s configuration options.
  • The variance between similar deployments of different customers is relatively small. By ‘similar deployments’ I refer to a setup which involves certain kinds of PBX (and software releases), a SBC, and a service provider’s SIP trunk service.

The bottom line is that when looking at two different customers that have similar setups, each customer’s configuration will only differ marginally. The difference would usually include IP addresses and other layer 3 to 4 settings, number manipulation rules, authentication passwords and several additional parameters.

Taking the wizard route

A configuration wizard is a well-known user interface concept common in desktops and web applications. The wizard is used to get the user up and running quickly in just a few steps, leaving the advanced application configuration to a later stage using a parameter centric GUI.Image: AudioCodes SBC Configuration Wizard

The 80/20 rule and the typical similarity between deployments makes the wizard approach a perfect fit for an SBC configuration.

At AudioCodes, we adopted this approach and have developed an SBC configuration wizard application.

Starting with the deployment similarities, we defined “interoperability templates” which in practice is a configuration set which relates to a certain kind of PBX and a service provider’s SIP trunk service. (It can also relate to hosted services and PBX to PBX setups.)

The user configuring the SBC is asked to insert the PBX model, service provider and SBC types into the wizard. After that, all that’s left to do is to provision a few more parameters.

AudioCodes routinely updates its interoperability templates database, which currently comprises over 60 different templates! Every time the SBC wizard is used, it connects to the AudioCodes cloud database and downloads the latest interoperability templates.

After filling in the wizard screens, an SBC configuration file is created. The file can be sent directly to the SBC from the wizard.

In some cases, the configuration will now be complete, leaving the SBC in an operational mode. In other cases, the user would already be able to send calls through the SBC, but would still need to complete the installation by configuring a few additional parameters on the device web GUI.

The end result achieved through using the SBC configuration wizard is a substantial reduction in time and complexity in configuring an AudioCodes SBC. In most cases, it takes no more than five minutes to get initial calls going.

If you, too, have felt “lost in configuration”, where finding the right knob to turn is like finding a needle in a haystack, we would like to hear about your experience and how you navigated through.