Posts

Coexistence & Migration

Clouducation Episode #2

Coexistence & Migration

Coexistence & Migration

I know most people don’t want to hear it, but is it time to start thinking about removing legacy infrastructure and beginning the journey to rolling out a new telephony solution?  The old adage of ‘if it isn’t broken, don’t fix it’ might no longer fit with the rapid pace of change.   Perhaps you have already started the process of modernizing the work place and the voice communication and collaboration aspects that tag along.  Either way change is inevitable and this is really where a decision should be made of “how” that modernization should occur – not if.

In the old days, when moving from one PBX to another, the theory was much more of a “rip and replace” mentality where the users would leave work on Friday, then come back Monday morning to a new phone on their desk with a little cheat sheet on any new buttons or features that the new PBX has to offer.  But is this really the best way to make this type of change?  Is it fair to the users to be “forced” to immediately adopt the new platform?  Well, in many opinions, it is no longer the right way to go about this process and options now existing to smooth out this process.

Instead, companies are starting the concept of “migrating” to the new platform with some level of “coexistence” with the old and the new.  Let’s dive into a couple of things to keep in mind during this process as when done right, it is great but when done wrong…ouch…

A great example is in a larger organization, where many offices may exist in different geographical locations, and doing a complete cutover in a couple of days is usually impossible.  The IT teams do not have the manpower to make all the changes without a negative impact on the users – especially while focusing efforts to ensure successful deployment and functionality along the way.  This is where coexistence is key!

Coexistence allows IT managers to have both telephony platforms up and running, while meticulously identifying users and groups to migrate at a much more reasonable pace.  Users in one office can start the migration to the new platform, adopt the new technology, and continue working without interference.  At the same time, users in other offices will see no change in their daily activities, as they will continue to use the existing telephony infrastructure until they are selected and ready to migrate.

Now that is all well and good, but what about the IT department?  Having to manage two telephony environments, especially in cases where administrators may only have knowledge of one or the other but not both, can become very challenging.  This also could pose issues with the ability to manage and enforce dial plans to provide a similar experience across both platforms.  Many things to think about while beginning the journey but things that industry experts are able to assist with and reduce the pains that could come up along the way…

No need to despair and fret over the choices – there are solutions that can help in both scenarios.

We plan to cover all of the above (and much more) on our upcoming “Cloud”ucation Episode #2 – Coexistence & Migration, so please do join us to hear it from the experts.  If you have not already signed up, please do so at the following link: http://online.audiocodes.com/clouducation

CloudUcation

Microsoft WPC Toronto

Done with WPC and Getting Ready for Ignite 2016

Getting ready for Ignite at Atlanta soon, and I can tell you, we have some more innovation up our sleeve.  Stay tuned, we will be announcing some cool stuff before Ignite.

Once again, this year I had the privilege of attending Microsoft’s World Partner Conference in Toronto, Canada. Microsoft’s premier partner event generates much anticipation among its channel and technology partners who come in their droves to learn about the latest developments in Microsoft’s technology and products, as well as to network with existing and potential business partners.

Microsoft WPC Toronto

So it came as no surprise that this year was no exception.  Boy, oh boy, it was a busy event!
I had back-to-back meetings with lots of system integrators and service providers who are actively promoting on-premises implementations of Microsoft Skype for Business.  All of them are also starting to align with Microsoft on Cloud PBX as part of Office 365.

… everyone seems convinced about the technological and financial benefits of cloud communications, but there is reluctance to adopt all at once

One recurring theme that came up in conversations with the partners was that pretty much everyone seems convinced about the technological and financial benefits of cloud communications, in general, and Microsoft’s cloud offering including Office 365 and Cloud PBX. At the same time, there is an apparent reluctance by some customers to fully adopt cloud-based communications solution at once. And while many, if not most, customers are planning to take their communications infrastructure completely off premises at some point in the future, relatively few have actually made the move so far with most opting for a hybrid implementation.

So what is deterring these companies from adopting a full cloud solution? Some make the “if it ain’t broke don’t fix it” argument while others are worried about disrupting users’ working habits. Others simply don’t feel comfortable with handing over control of their communications systems to a third party.

I believe in taking the plunge when it comes to disruptive, innovative technologies that will bring business benefits in the longer term. Of course, these changes can’t be taken lightly, which is why companies need a robust migration strategy and the technological tools to make the migration a success.

…for standalone, on-prem solution or in hybrid (on-prem/cloud) mode we offer the CloudBond 365 all-in-one UC appliance.

…for customers who do not require some users to be kept on premises, our Cloud Connector Edition Appliance delivers voice connectivity

Here at AudioCodes, we have been putting our minds to solving these issues of migration to cloud services for quite some time now, especially when it comes to Microsoft UC environments. For companies wanting a simple and rapid deployment of Skype for Business as a standalone, on-prem solution or in hybrid (on-prem/cloud) mode we offer the CloudBond 365 all-in-one UC appliance. In addition, for customers who do not require some users to be kept on premises, our Cloud Connector Edition Appliance delivers flexible on-prem voice connectivity for the Microsoft Cloud PBX users.

What makes these solutions particularly interesting is that both CloudBond 365 and the CCE appliance run on the same hardware platform so that when a company has completed its migration to Cloud PBX, the CloudBond 365 appliance can be converted to a CCE Appliance via a simple software update. We believe that the simplicity of these solutions, along with the fact that they are based on our Microsoft-certified SBC and gateway platforms, should help putting concerned IT managers’ minds at rest. They allow companies to control the pace of their cloud migration without compromising on functionality or efficiency.

CloudBond 365 appliance can be converted to a CCE Appliance via a simple software update.

Some of the partners asked me which path I recommend:  Go with CloudBond 365 for hybrid deployment, or go with CCE along with Cloud PBX?  My answer always is that we enable our partners and customers to choose the path that’s right for them.

When a customer doesn’t feel comfortable going all-in with the Cloud PBX proposition, I think that rolling with CloudBond 365 makes a lot of sense. In certain cases, the feature set that the customer wants is still not available on Cloud PBX.  Stalling the decision gives Cisco the opportunity to revisit the customers as part of a data network refresh, and offer a bundled offering to get them to stay with CUCM.  Getting the train out of the station and starting the Microsoft UC experience rolling quickly is the right choice and is implemented with our CloudBond 365.

Getting ready for Ignite at Atlanta soon, and I can tell you, we have some more innovation up our sleeve.  Stay tuned, we will be announcing some cool stuff before Ignite. Make sure you don’t miss any of our latest news and announcements by following us on Twitter, LinkedIn and Facebook.

Come visit us at Microsoft Ignite 2016, September 26-30 in Atlanta, Georgia, at Booth #409.

Want to learn more about our Skype for Business solutions? Click here to request a meeting with our experts at the show.

Unable to attend Ignite but interested in speaking with us? Click here or visit our website or contact your local AudioCodes representative.

UC Innovation Unleashed

Telephone-Exchange

Simplified Call Routing for Complex Networks

What makes VoIP level routing hard to manage?

Telephone-Exchange

One of the main achievements in the world of data routing over the last two decades is the emergence of the distributed routing architecture.

Using various routing protocols (RIP, OSPF, EGRP, BGP, etc.), networks are created and modified dynamically and automatically. VoIP routing is much more complicated than data routing, but with no routing protocols.

Traditionally, enterprise VoIP networks are controlled by the IP-PBX and call routing is typically based on static routing tables. The situation becomes complicated for off-net calls. The IP-PBX deals with such calls by directing them to the nearest media gateway or session border controller (SBC).

In the case of multi-branch organizations, a single VoIP network may have several IP-PBXs from different vendors, as well as media gateways and SBCs. Each IP-PBX, SBC and gateway in the network has its own static routing table resulting in a distributed system in which the included elements do not communicate with each other.

In theory, one could configure all the network elements once and leave everything unchanged. In reality, however, organizations’ VoIP networks are constantly evolving due to a variety of factors: mergers & acquisitions, new locations, integration of new & old IP-PBXs (or even legacy PBXs) and integration of SBCs and gateways. In addition, there is the organic growth of an organization and the accompanying technology evolution, such as introducing unified communications to the network and consolidating IP-PBXs. All of this makes managing the organization’s VoIP network a nightmare. A static approach is no longer fit for the job – there is a need for a centralized routing management system.

Centralized VoIP Routing System

System administrators should be able to design and modify their voice network topologies and call routing policies from a single location, resulting in significant time and cost savings. Time-consuming tasks such adding a new PSTN or SIP trunk interconnection, adding a new branch office or modifying individual users’ calling privileges should be carried out simply and rapidly.

The AudioCodes Advanced Routing Manager

AudioCodes-Routing-Manager-Dynamic-Creation-of-Logical-Network-Topology

AudioCodes Routing Manager (ARM) is a holistic, scalable, dynamic routing manager based on software-defined networking (SDN) principles. The AudioCodes Routing Manager decouples the device layer from the network routing and policy layer, automatically creates complex VoIP networks, and simplifies routing rules, monitoring and management configuration.

  • The ARM learns about the SBCs and gateways in the network automatically and dynamically. Every change in connectivity and configuration is reported to the ARM. Gradually, the ARM builds up a complete picture of the network topology, connectivity and health.
  • The ARM also assists with the design and creation of the VoIP network. With the ARM, a network can be created with one-click. The administrator can choose between mesh, star or dual star formations and all the connections are automatically configured in the SBCs and gateways. This can significantly reduce the time needed for professional services as there is no need to configure hundreds of classification rules, trunk groups, profiles and routing rules. And all of this is provided through an intuitive and simple graphical user interface.
  • The AudioCodes Routing Manager also looks at user attributes to optimize routing calculations. It imports and aggregates user information and huge dialing plans from different sources (e.g. LDAP server and CSV files) and groups users and dial-groups for routing calculation and implementation of number portability.

The AudioCodes Routing Manager is a critical 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.

Learn more about the ARM: http://www.audiocodes.com/audiocodes-routing-manager-arm

The ARM was recently featured in an article on No Jitter: http://www.nojitter.com/post/240171460/audiocodes-tackles-simpler-session-management

The road to NFV

Here’s Why Virtual Is Not Enough for NFV

The road from SW to NFV

The road to NFV

Image source: flickr user Cristian Bortes

Telecommunication products were traditionally based on dedicated HW. A collection of technology changes and market requirements have caused many of these products to move away from dedicated HW and to run on x86 platforms. These include:

  • Performance improvement of general purpose processors
  • Media processing acceleration integrated into Intel based processors
  • The move to the cloud
  • Market demand for service introduction agility mainly due to OTT threats

Many companies have made the effort to move their products to SW platforms.

Does SW mean virtual? Does virtual mean NFV?

NO

Moving from HW to SW

The move from a HW product to a SW one is probably perceived as the most complicated milestone to achieve on the road to NFV.

The effort involved in executing this shift depends a lot on the type of application. There are some things that HW just used to do better – things such as media processing and encryption. Acceleration features of CPU vendors like Intel have helped to significantly reduce this gap.

The move to SW means that your application can run on top of a specific OS installed on a dedicated x86 platform. If you have more than one application they compete for the same resources and you are at the mercy of the OS to give you the performance your application needs.

This is where virtualization comes in.

Going virtual

The next step in going virtual means that you are not going to run directly over an x86 platform with an OS that you install but rather you will have a layer in-between that will utilize the compute, storage and network resources of the system. This layer is a virtual machine.

Virtualization was first introduced by IBM for their Mainframes some 30 years ago. Given the price of those computers, there was great value in being able to utilize the same HW for several environments.

The virtual machine shares these resources with other virtual machines running on the same platform. This will allow you to have different OS/environments on the same physical HW. Some applications use modified OS versions with application specific modifications for improved performance or security. With virtualization, each application can use its own dedicated OS version sharing the same physical HW.

With the commoditization of computers, the motivation for virtualization stems from efficiency and agility requirements. To achieve these goals it is not enough to have a virtual machine on each computer. There is a need to automate the management of these resources.

Clouds already exist for several years and what they bring on top of the virtual machine is this automation. It provides the ability to bring up machines and applications, move an instance from one place to the other and make sure service availability is maintained.

Solutions for such high level management of clouds is offered by virtual machine vendors such as vCloud of VMware as well as Open Source initiatives such as OpenStack that support all major VM vendors but mainly shine in KVM setups.

There is a lot of complexity involved in managing networks (the main driver for SDN) and compute and storage resources within the data center. But even when all of this is available, it is still at the resources level and doesn’t include the application and service logic nor integration with the systems used by service providers to start/modify a service for a specific user.

That is exactly where NFV kicks-in.

NFV brings the required application and service awareness

The motivation for NFV came mainly from service providers. With their struggle to compete with the agility of OTTs, they strived to find ways to reduce the cost and time of launching new services and supporting peek service load demand efficiently.

Defined by ETSI’s Industry Specification Group for Network Function Virtualization, NFV is based on the basic virtualization elements mentioned above that virtualize the compute, storage and network resources through the NFVI. On top of these elements run multiple VNFs which are actually the applications. Each VNF has also a monitoring and alarms element (EMS).

NFV-ETSI-Architecture

One key part of the ETSI specification is management and orchestration (MANO) which comprise of 3 components:

  • Virtualized Infrastructure Manager (VIM) – Manages the virtual resources – compute, storage and network – which is basically the virtual machine or NFVI
  • VNF Manager (VNFM) – Manages and orchestrates the VNFs’ lifecycle, configuration and event reporting between the VNF and the EMS
  • NFV Orchestrator (NFVO) – Manages and orchestrates lifecycle of all elements in the NFV architecture and interacts with OSS/BSS systems. It orchestrates and chains the VNFs through their VNFIs, scales services up and down and has an overall global resource and policy management role

 

NFV use case examples

Two common use cases for NFV are service provider cloud services and vCPE.

In the service provider cloud, new services can be quickly launched and scaled up as usage increases or is terminated if not successful.

In the vCPE case, deployment can happen in several architectures where typically the first phase is of an on-premise CPE device that runs multiple services such as FW, NAT, Security and VoIP communications.

Later in the vCPE deployment cycle, some of these functions are moved to the service provider cloud. Moving some of the network functions to the central service provider cloud allows the service provider to have better control over the system and by that, improves the support offered to the end customer while reducing cost.

In both of these cases, the orchestration capabilities of NFV and its close integration with OSS/BSS systems are imperative as new customers can be quickly added to the service through the service provider systems and service packages can be changed and implemented instantly (e.g. adding features or capacity to a customer’s service package).

Why this is important

Running an application in a virtual environment is still far from being fully integrated and compliant with NFV. The benefits of NFV go beyond the automation of a single application. It integrates with OSS/BSS systems and brings an end-user service view to the system, something that is not possible in virtual environments.

AudioCodes recently announced the launch of its SBC VNF for vE-CPE and high capacity cloud deployments. This is in context of the adoption of NFV and vE-CPE that we see today in the market and our work with NFV orchestration and vCPE vendors.

Cards

We Lay Our Cards On The Table

Cards

AudioCodes SBC under the Miercom microscope

Quite often companies prefer to keep their cards close to their chest, no need to open up the product for others to find its soft points. We decided to take a different approach and let an independent 3rd party company put our products under attack, pushing their performance, resiliency and security to their boundaries. We are now putting our cards on the table giving everyone access to the results of these tests. The full Miercom report can be found here.

For this purpose we asked Miercom to run our SBCs through their brutal tests and report their results.

Miercom is a US-based network consultancy company, specializing in networking and communications-related product testing and analysis.

The products to be tested were the Mediant 4000B, Mediant 9000 and Mediant VE (Virtual Edition) Session Border Controllers. End result is a certification we received from Miercom for our SBCs’ performance, scalability and resiliency while under attack and overload conditions. The tests also verified the SBCs’ WebRTC Gateway functionality and monitoring capabilities with AudioCodes Session Experience Manager (SEM).

The AudioCodes Mediant SBCs

AudioCodes’ Mediant family of Session Border Controllers (SBC) is a line of versatile IP communications platforms that connect VoIP and TDM networks. SBCs are deployed at the border between the enterprise and the service provider. In the enterprise environment, they form an effective demarcation point between the business’s VoIP network and the service provider’s SIP Trunk, performing SIP protocol mediation and media handling (interoperability) and securing the enterprise VoIP network. In the service provider core, SBCs provide security and protocol normalization. Given this role, the performance, reliability and security of the SBC is imperative for successful operation of enterprise and service provider voice networks.

Miercom findings

“AudioCodes’ SBCs exhibit rich interoperability along with impressive performance and resiliency.”

AudioCodes Mediant SBCs offer advanced security capabilities that enable security detection, protection and analysis. They have a built-in application level IDS (Intrusion Detection System) feature that detects and suppresses malicious attacks directed at the SBC. Reactions can include blacklisting the assaulting IP addresses for a user-defined period of time and/or sending alerts (SNMP traps) with full details of the suspected malicious activity.

“The Mediant SBCs have proved fully resilient against Distributed Denial of Service (DDoS) attacks on both signaling and RTP/media ports, maintaining excellent MOS ratings and with no dropped calls or system degradation.”

AudioCodes SBC VNF

Ideally, all of the functionalities that are available within an appliance-based SBC should also be available within an NFV (Network Function Virtualization) version. While this may seem straightforward, some vendors struggle to deliver due to legacy product architectures which rely on hardware-specific feature implementations. This leads to challenges in assuring adequate performance and quality of service without purpose-built hardware.

AudioCodes Mediant VE can run as a Virtualized Network Function (VNF) in an NFV environment. It is one of the first SBC VNFs proven by Miercom to deliver effective protection against DDoS attacks, sustaining high performance while under heavy attack without sacrificing call quality.

AudioCodes NFV-based SBC provides full parity with traditional appliance-based SBC products, in large part because it has been available on leading industry x86 platforms since 2012. The virtual SBC design and software implementation allow it to protect against attacks without the need for purpose-built hardware.

To read the entire report, or for more details on how the tests were carried out, please refer to the full Miercom reports available on our website.

SIP based Contact Center

Migrating to a SIP Contact Center

With every year, SIP is becoming more and more common in unified communication solutions in general, and contact center applications in particular, as companies increasingly recognize the benefits that an all-SIP environment can provide. Legacy contact centers have become expensive to maintain and upgrade and harder to integrate with new and high-value applications. Companies with limited in-house resources can especially benefit from SIP which can support a more dispersed work force including home agents or those working from remote locations.

The SIP based contact center allows companies to leverage new capabilities without pouring more resources into management or IT, infrastructure and applications. These capabilities can be deployed quickly, they are easy to deliver to remote agents and as the companies grow, the solutions can grow with them.

SIP based Contact Center

For many organizations, SIP is an integral part of an upgrade, while for others, SIP is part of a telecom cost reduction strategy.

Consider the following migration paths and best practices:

Step 1: Disconnect the PBX from Contact Center trunks

By disconnecting trunks from the PBX, calls can go directly into the contact center, enabling the introduction of new features not supported by the PBX. Data centers can be centralized, routing calls to dispersed contact centers and sending calls to agents that may be company-based, remotely-based or home-based.

Step 2: Computer Telephony Integration (CTI) Migration

Moving to SIP removes some major pain points that have limited contact center efficiency improvements in the past. In particular, it removes the dependency on the PBX. With traditional PBXs, the link between the PBX and the contact center is via a proprietary CTI link. If the CTI link does not support a certain function or does not provide the data necessary for a specific operation, nothing can be done to overcome the limitation. However, in a SIP environment the flexibility is significantly increased because calls can be directed to the contact center application directly.

Step 3: SIP trunking

Consolidation of telephony trunks into SIP trunks saves a considerable amount of money and is far more flexible and scalable. In addition to the estimated cost savings that can be achieved by using VoIP calls, SIP offers the ability to introduce a whole range of additional services to make the customer service operation more effective, ranging from high definition voice to video and more. Contact centers can save considerable expenses by cutting back on toll-free numbers, as VoIP enables click-to-call, which customers can initiate from their PCs or smartphones. Also, with domestic calling being free, VoIP provides another option for agents to make outbound calls to customers, allowing them to be more responsive or even proactive. In terms of enhancing the customer experience, SIP trunking also enables HD audio, providing a high quality call which can be a real differentiator for many companies.

The Key: Seamless Migration

A seamless migration from legacy infrastructures to SIP is key for organizations making the move, many of which are deeply invested in their legacy equipment. In moving to a SIP-based contact center, there is no need for “rip-and-replace” or discarding earlier investments. Customers can choose to convert to this architecture at their own pace and the SIP solution can grow in line with business needs.

Of course, an open architecture like SIP does have some pitfalls: there is no guarantee that two SIP devices will seamlessly operate together out of the box. Basic functions will work but enhanced functions may need to be tested first. AudioCodes provides a complete end-to-end solution consisting of gateways, SBCs, IP phones and other devices that have already been extensively tested and documented in the contact center environment to ensure full functionality out of the box, considerably reducing risk and professional service requirements in a SIP installation.

TCO Reduction

Ultimately, the result of the move to SIP is a significant reduction of TCO.  This is reflected in the considerable savings generated by a reduction of infrastructure costs including the consolidation of telephony trunking and the elimination of separate infrastructure at each location. By virtualizing the resources through the provision of centralized administration, enterprise-wide resources are better put to use, and the company benefits from the flexibility to support multi-channel interactions with customers and a distributed contact center structure which can consist of multiple sites, home agents and hosted services. Additionally, SIP future proofs new media and applications. All this leads to increased agent satisfaction and a better customer experience which also saves costs.

See what AudioCodes has to offer for your Contact Center.

the whole is greater than the sum of its parts

WebRTC Connectivity Solution with Focus on Quality and Scale

The whole is greater than the sum of its parts

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

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

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

Both cases introduce some issues

The external WebRTC to SIP GW carries a price.

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

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

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

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

Putting quality and scale at the front

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

Integrated solution

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

Minimal transcoding scenarios

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

Signaling

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

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

Voice quality enhancement

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

Detect & correct

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

Why is this important?

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

VocaNOM in Amazon AWS Cloud

How Amazon AWS Scaled Up Our Business

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

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

VocaNOM in a nutshell

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

VocaNOM comes to solve a few fundamental issues:

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

The scenario using VocaNOM is as follows:

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

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

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

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

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

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

Moving to Amazon AWS

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

VocaNOM in Amazon AWS Cloud

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

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

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

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

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

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

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

Managing Voice Quality

3 Things Required for Managing Cross Network Voice Quality

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

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

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

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

Different type of networks perform differently

VoLTE

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

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

GSM

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

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

Wireline VoIP

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

PSTN

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

The brain and the tools that solve the problem

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

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

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

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

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

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

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

Voice Quality in Wireless Networks

Multi-Tenant-SBC-Use-Cases

Angelina and The Multi-Tenants

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

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

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

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

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

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

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

Multi-Tenant-SBC-Use-Cases

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

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

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

Summary

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