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.

SBC is a Swiss Army Knife

Not a Toaster after All

I like reading the posts of Andrew Prokop, that’s why his blog SIP Adventures is featured on the sidebar of our blog as one of those we follow. Recently, Andrew posted an interesting and humorous post on Nojitter titled When the Session Border Controller Became a Toaster.

Comparing an SBC to a toaster, Andrew concludes that a commoditized SBC competes on capacity and price. Very much like a toaster that competes on the number of slots it has and the price, as after all, you just “put in a slice of bread and it pops out all nice and brown”.

In his post, Andrew looks for more interesting capabilities (of the SBC, not the toaster) and calls the companies to the challenge.

So Andrew, Challenge Accepted! J, hence this blog post.

A Swiss Army Knife

I view the SBC more as the Swiss Army Knife of VoIP rather than a toaster. Similar to the Swiss Army Knife, the SBC needs to handle many tasks and be flexible enough to live up to those challenges. It need to work in various environments, connect to different network devices and normalize SIP traffic to support this.

SBC is a Swiss Army Knife
This post relates to the challenge presented by Andrew and to his question how it is handled by different SBC vendors, Therefore, I will review how the AudioCodes SBCs not only tackles it but go beyond Andrew’s expectations. Hence, this post is AudioCodes product specific.

Dismantling the Challenge

Licensing – buy a bunch of SBCs and license them as needed from a pool of licenses.

To serve this customer need, AudioCodes provides its EMS (Element Management System) SW that handles among other things SW upgrade and license distribution. This allows service provides and enterprises to buy a pool of license and distribute them as needed between those SBCs from one central management system.

Virtualization – get rid of boxes.

There are a few modes in which an SBC can come. It can be a proprietary HW device, an appliance that comes bundled with the SBC SW of the vendor, SW on a CD that is installed on a server provided by the customer or a virtual SBC running on a virtual machine.

All 4 modes are supported by the AudioCodes SBC. Moreover, it supports Hyper-V, VMware and KVM hypervisors. We are working with NFV orchestrator vendors on integration with their platforms so customers will have a pre-integrated solution for NFV.

Support for WebRTC & Opus in the SBC

There are different ways to support WebRTC. Many implementations have taken the approach of supporting WebRTC in a box external to the SBC. This imposes quality issues as well as architecture complexities. The AudioCodes approach was to provide native support for WebRTC as an integral part of the SBC. This simplifies the architecture and gives the flexibility to bridge WebRTC to any network, including TDM, all with a one box solution.

The other side of WebRTC support is the media itself. Here also, the approach of the AudioCodes SBC is native support for Opus transcoding in the SBC.

The SBC, of course, comes in any of the 4 modes described above so it can be a virtualized SW SBC as well.

The support for WebRTC doesn’t stop at the SBC level but extends to the client. Some implementations have defaulted to G.711 in order to avoid the need for the transcoding of Opus to G.7xx. This is a bad choice as G.711 is not the best option for VoIP over the open Internet.

To solve this issue, AudioCodes has added Opus to the IP Phone. Through this we give our customers the option to hold the rope at both ends. On one hand the enterprise or service provider can use the best codec for VoIP over the Internet – Opus – and on the other hand there is no need for transcoding if the AudioCodes IP Phone is at the client side. Transcoding is, of course, supported for cases that require it.

Webification of Communications

Continuing from WebRTC to the general trend of Webification of communications, more and more non-VoIP developers need to integrate WebRTC into their applications. We have come across cases of services that are pure Web-based that wanted to add voice and video communications with external call control requirements. These developers know how to implement great Web services but they are not experts in VoIP call control. For them we have added REST APIs into the SBC that allow for configuration and 3rd party call control through an interface known and common among Web developers.

Web services and HTTP

Many IP Phones on the market have an integrated browser that fetches screens and information from the server. This works well when working on the same LAN but in cases of remote workers that don’t have a VPN connection to the enterprise things can get tricky. HTTP can go out of the organization to the Internet but the firewall will not allow HTTP traffic to come in to the servers of the enterprise. To solve this, the AudioCodes SBC also functions as an HTTP/HTTPS proxy keeping the PBX secured while supporting remote workers.

Hybrid cloud and on premise

A hybrid cloud and on premise mode means I can separate SBC functionalities and decide which to run in the cloud and which to run on premise. Since enterprise communication requirements and architectures vary, it is important to allow for this flexibility.

The AudioCodes SBC handles this by offering both cloud access SBCs (at the service provider core edge) and on premise SBCs. The enterprise has the flexibility to choose to run functions that are more fit for on premise locally while keeping other functionalities in the cloud. Examples of such functionalities are:

  • Survivability – PSTN backup and alternate WAN connection
  • Quality monitoring – putting this in the enterprise on premise demarcation point allows to know if the problem is between the enterprise and the service provider or perhaps in the enterprise LAN.
  • 911 – In many cases it is better to run 911 services on premise for emergency services
  • Remote worker support – Simplifies the architecture on the SP server side as remote workers access the service provider cloud from the on premise SBC and not directly. By this, they look as if they are an on premise workers.
  • Bandwidth optimization and quality enhancement
  • Normalize the uniqueness of each enterprise simplifying the complexity of service provider access

 

The service provider and enterprise can decide which of these functions are deployed locally and which in the cloud.

Why this is important

While in a commoditized toaster you simply put in a slice of bread and it pops out all nice and brown, SBCs are far more complex than just port count and price.

The technology advancements of WebRTC, cloud and NFV impose new requirements for media quality and support for heterogeneous environments. This makes the selection process of the SBC that best fits your need far more complex than selecting a new toaster.

VoLTE Deployments

LTE Voice Summit Not Only About Voice

My takeaways from the LTE Voice Summit

Earlier this month I spoke at the LTE Voice Summit. As promised, slides are now available on SlideShare.

A few important notes from the event.

VoLTE – 11 service providers and counting

LTE was launched by 331 service providers worldwide. Once LTE has been launched, adding VoLTE to the mix makes sense to the service provider as it reduces their OPEX, saves spectrum and improves user experience by allowing for better voice quality, longer battery life and other benefits.

To date, VoLTE has been launched by 11 service providers.

60 others are in trials and planning.

VoLTE Deployments

 

Voice quality

Speaking with service providers that already launched VoLTE and have field experience and feedback, I heard there are issues when connecting calls between VoLTE and non-VoLTE networks.

Doing a one-size-fits-all transcoding to G.711 when exiting the VoLTE network is not a good solution.

There was a great presentation by Michael Thelander from Signals Research Group that compared quality over VoLTE vs. Skype. No surprise here, quality over VoLTE was better; they could have saved the dollars spent on the research. As VoLTE was built for real-time communication while Skype and other OTTs run over the data network, it is only expected that these would be the results.

The same applies to battery life. Since VoLTE is pre-integrated with the phone, things are better optimized. This includes video codecs that can be HW accelerated in native clients and other algorithms such as acoustic echo cancellation (AEC) that can run on the chip level. These yield better quality and lower battery consumption.

The more interesting question would be to test VoLTE to a VoIP client over a WiFi network and compare that to an OTT like Viber. In such a case, VoLTE has problems such as those I presented in my earlier post and in my presentation at the conference.

For these problems , AudioCodes presents a pretty compelling solution that comprises a smart entity (SBC) that resides in the core of the network and makes decisions with regards to transcoding, transrating, call routing and call properties negotiation (bit rate, codec, resiliency…). It uses network monitoring information and communicates with other network elements to apply its policy. Feel free to contact me for detailed information.

Services are based on RCS

Even though this was a conference about voice, services were mainly related to RCS. Service providers are continuing the RCS path and believe that once RCS will be fully integrated with the phone as default, users will use it.

I believe that service providers should manage a mix of “service provider OTT” with RCS in order to remain relevant. Offering only standard RCS capabilities will make differentiation hard as all service providers will offer the same thing with pretty much the same user interface as defined by the GSMA.

To that end, I presented this issue to David Hutton from the GSMA on a panel discussion. I believe that the decision of the GSMA to standardize everything in RCS right up to the user experience is a dreadful mistake, it is one of the reasons for the failure of RCS and imposes unnecessary limitations on the service providers. To my surprise, he agreed.

In conclusion:

  • VoLTE is happening.
  • Service providers that have already launched VoLTE services are starting to experience the complexity of connecting VoLTE to other networks.
  • Service providers understand that VoLTE by itself will not provide the required added value services and are looking for those services in RCS. They should combine these with their own OTT services in order to differentiate.
REST API for SBC Configuration

Why REST APIs are Not Yet Another SBC Configuration Interface

[Post is better viewed on the blog Website]

REST API for SBC ConfigurationFor most of us who grew up in the telecom industry, management protocols like SNMP, TR-69, and Command Line Interface (CLI) have been for many years the only management protocols we’ve known and used on telecom equipment.

Telecom’s bigger (but younger) brother, the Internet, has developed its own set of management interfaces (APIs), mainly SOAP and REST.

Well guess what? Similar to what happened to some telecom services that were replaced by Web apps (for example SMS replaced by WhatsApp), so are legacy telecom management protocols being replaced by Web management protocols, led by REST.

But REST is more than just another way to manage telecom devices. Being a dominant API in Web technology, REST serves, among other things, as a bridge between Web applications to telecom devices which were previously isolated in their own ‘telecom’ domain.

Linking these two worlds yields new services which were not previously possible.

For example, today an SBC can be connected to a CRM web application (i.e. Salesforce.com) and allow an employee to place a call to his customer by clicking the contact’s name on the CRM web GUI (this may also involve WebRTC).

Some words on how REST works. REST (or RESTfull API as it is sometimes called) is used to manage and read the status of a remote device.  It uses HTTP as its transport layer and in most cases the message payload uses ‘JSON’ structure.

JSON is a human-readable format, which makes it possible for anyone to inspect these messages.

Besides the great synergy that REST brings by linking the Web and Telecom worlds, REST in itself has important advantages over the legacy Telecom management protocols that make the development process easier for the 3rd parties integrating with the API. Unlike SNMP and TR-69, REST is, as said, human-readable. Thanks to HTTP, REST easily traverses firewalls – a problem which SNMP and CLI may face. REST also does not require identical schemas (data structures) to run on both managing and managed devices in order to talk to each other, which simplify its maintenance. REST is also secure as it can run over HTTPS while security on the legacy protocols is complex.

Lastly, REST is a stateless API unlike CLI (which is both statefull and unstructured). REST statelessness makes it easier to implement.

AudioCodes, which has always been a firm believer in open standards, is investing heavily in REST. Our soon to arrive next major SBC release, will have an impressive set of REST APIs with which our partners are already working to create innovative new applications. Stay tuned.

Redundancy & High Availability

High Availability Redundancy for All

[Post is better viewed on the blog Website]

The Need for High Availability

The need for businesses to remain on-line at all times, if the connection to the service provider or on premise equipment should go down, is a critical one. And it is critical for all businesses, large and small alike.

In VoIP networking, the ability to always keep the network up and running is called High Availability (HA) and it can mean several things. For one, it means survivability. If the WAN connection (SIP trunk) to the service provider goes down, the customer needs a “Plan B”.  This is typically accomplished with a Session Border Controller (SBC) deployed at the enterprise, playing an important role in continued phone connectivity and routing at the customer site. It also can mean resilience. Here, the calls at the customer will find their way out of the local site to their destinations via alternative channels. This can be via PSTN fall-back, via GSM connection or even via a connection to a back-up second SIP trunk.

Redundancy & High AvailabilityAnd then there is redundancy where fully redundant networking infrastructure is used, eliminating single point of failure risks. With VoIP networking this would mean there are two SBCs deployed in an active/standby configuration. In normal operations, the first SBC does everything while the standby SBC is only synched with the first one. However, if for whatever reason the first SBC goes down, the second one takes over and all the active calls now go through it, ensuring that no active calls are dropped. User registration is synched between the two devices and a transfer to the standby SBC, seamless to both the network and to the users, occurs.

Increase in HA Demand for Medium to Small Businesses

Survivability and resiliency tend to be features provided in networks of all sizes. However, redundancy, for many vendors, seems to be reserved for only the larger carrier and enterprise networks, those with over 600 sessions. To handle requirements for High Availability redundancy for small to medium businesses some SBC vendors offer their customers over-sized carrier-class SBCs. This mismatch forces customers to deploy SBCs which don’t fit neatly into the enterprise environment, as they are more expensive, have unnecessary features on the one hand and may be missing other features necessary for this environment on the other.  (We call this “Going duck hunting with a Howitzer” – overly complex and in the end, not very effective).

At AudioCodes, we have witnessed a sharp increase in demand for High Availability Redundancy in small to medium businesses.  Perhaps these businesses have reached the conclusion that even in these smaller business environments they simply can’t take the risk that something will take down their network. AudioCodes has moved to satisfy this demand from the smaller businesses by installing High Availability redundancy in the Company’s Mediant 500 and 800 SBCs in addition to the higher-session SBCs.

(BTW: no ducks were harmed in the writing of this article)

Let’s Hear IT from the Middleman

Let’s Hear IT for the Middleman

 [Post is better viewed on the blog Website]

The rapid rise of e-commerce internet sites in recent years has brought about significant changes in the way we go about purchasing goods and services. In particular, items that previously we would only have considered acquiring through an agent are now freely available for us to buy directly via the web. Despite all that, there are still some areas where we are more reluctant to cut out the middleman, like buying a house or car. The added complexity of this kind of purchase (e.g. legal issues, payment plans and just the amounts of money involved) means that we feel more comfortable in the knowledge that someone else is acting on our behalf.

Technological Middlemen and the SBC

Let’s Hear IT from the MiddlemanThe same can be said for the world of technology and telecommunications. Many middleware systems and mediation devices are available today to simplify and control interconnectivity between all sorts of platforms. In the world of IP communications, the predominant mediation device is the Session Border Controller or SBC, which sits at the border between two VoIP networks and provides security, quality, and access control between the two domains.

Connecting Microsoft Lync to SIP Trunking Services

Several recent posts on the AudioCodes blog have discussed the importance of deploying SBCs in a variety of different scenarios. One scenario where there seems to be grounds for leaving out an SBC is when connecting enterprise Microsoft Lync deployments to SIP trunks. According to Microsoft’s own recommendations, the Lync Mediation Server acts as the mediation device between the enterprise Lync Server pool and the outside world. Using this architecture, companies are able to connect to Microsoft-certified SIP trunking services and start to reap the technological and commercial benefits that they offer. With tight IT budgets always competing with the draw of technological innovation, the addition of an SBC into such a scenario would, on the face of it, seem to be something of an unnecessary extravagance. A closer look, though, reveals a number of important considerations that, when weighed up against the alternative, support a strong case for deploying an SBC to connect Lync to SIP trunking services.

Mediation Server or SBC?

Recently, we published a technical guide document entitled “SIP Trunking in Lync Networks – The Easy Way Out” (download it for free here). The aim of this document is to highlight some of the considerations when connecting Lync to SIP trunks which may not be obvious to many IT managers. The document explains how the complexity of SIP trunking connectivity cannot always be handled adequately by a direct connection from Lync’s Mediation Server. SBCs, on the other hand, deliver critical technological and cost-savings value to SIP trunking connectivity in areas such as:

  • Flexibility
  • Interoperability
  • Security
  • Voice quality

The guide goes into some detail in each of these areas. There isn’t room in a single blog post to cover all of them but, for the moment, let’s just take a closer look at one aspect of the first item to illustrate the limitations of Mediation Server when compared with using an SBC. (In future blog posts we will look at some others.)

SBCs for Routing Flexibility

Least cost routing (LCR) is a common feature in any communications setup for controlling costs, giving administrators the ability to decide how to route outgoing calls in the most economical way. Mediation Server is only capable of connecting to one SIP trunking provider at a time, meaning that enterprise-controlled LCR for outbound calls is not possible. With an SBC in place, however, administrators are able to connect to multiple SIP trunks simultaneously and create extensive LCR schemas to ensure that calls are handled in the most efficient and cost-effective manner. And, if your SBC is a hybrid device supporting both SIP and TDM connections, you can perform LCR between multiple SIP trunks and PSTN connections.

SBC – The Middleman You Can’t Do Without

So maybe not all middlemen are unnecessary evils. Just as your real estate agent might have the market knowledge and experience to find you a better deal than you could have done yourself, so too deploying an SBC can help you control the costs, quality and security of your SIP trunking connections.

To quote from “SIP Trunking in Lync Networks – The Easy Way Out”:

An experienced IT manager knows that sometimes the potential downsides of taking shortcuts outweigh the cost of well-designed deployments. The expense of an SBC is relatively small compared to the overall cost of designing, implementing and operating a Lync deployment. The decision to include an SBC is, therefore, a simple one, given the value it offers in terms of security, interoperability and quality.

If you want to learn more, please download our guide. We’d love to hear to your thoughts in the comments section below.

Michael-Williams

Using the SBC Configuration Wizard: An Interview with Michael Williams

[Post is better viewed on the blog Website]

Speaking with customers is always a great way to get feedback. The PM team at AudioCodes does this regularly. Avi Grabinsky who is already well known on the AudioCodes blog was kind enough to invite me to join one such virtual meeting. The result of that meeting is this first customer interview on our blog. The interview is with Michael Williams who is a Technical Consultant for Nexus Open Systems. Nexus is an AudioCodes partner using our SBC Wizard as part of their installation and maintenance process for their customers. It was interesting to hear Michael’s view on this tool.Michael-Williams

Michael, for our readers who are not familiar with Nexus Open Systems, can you tell us what the company is all about?

Nexus Open Systems delivers IT solutions, software, websites and support services to companies and organisations of all sizes that require true technical expertise to meet their goals. Established in 1998, the company has two offices, incorporating a digital media studio and a hi-tech IT Training and Exam Centre, in Exeter the heart of South West England.

We are a networks and technology solutions company working throughout the UK and beyond. 15 years old, we have 75 staff encompassing a team of 40 engineers and developers.

Nexus has been involved with the Microsoft Lync product since its inception and amongst our 18 Microsoft competencies we hold the Gold Communications competency which relates to the Lync product set. This is testament to our ability to consult, install and support Lync solutions. For 2014 our goal is to become a Premier Lync Support Partner and our software development team are developing a Lync application which will go to market in 2015.

We have strategic relationships with key vendors within the Lync Ecosystem including: Microsoft, AudioCodes (Silver Partner), Mitel (Gold Partner), Dell (Premier Partner), VMware (Enterprise Solutions Partner) and Jabra (Gold Partner).

In the segment of Microsoft Lync who are your prime customers and what segments do you cater for?

Nexus works primarily with medium to large enterprise clients with regards to Lync, with on-premise deployments making up the majority of our current projects.

We are not confined to any organisation segments and work across all verticals, including professional services, public sector, education, non-profit and general industries.

Where do you see  AudioCodes products playing a role in Lync environments?

AudioCodes form a core part of our Lync environment offerings, both in terms of gateways and also handsets. We build our solutions primarily around the AudioCodes product set and then bring in other elements from the Lync ecosystem.

You have been an early adopter of the AudioCodes SBC Wizard. What did you find as the key benefits of this tool and how was life before it?

The SBC Wizard helps us reduce the amount of time needed to setup an SBC: as the wizard applies the most common settings, it saves around an hour and a half per SBC.

Before the SBC Wizard we would have to configure all the basic settings that are needed manually. This can be very tedious and time-consuming.  Moreover, previously when we did the configuration manually there were configuration errors. If we were lucky, those errors were discovered on the spot as part of the configuration process and then we had to spend some time figuring out the errors and fixing them. In the harder cases, errors were discovered after deployment when users were already using the network and some scenarios weren’t running well. Such cases are more of a problem because they involve bad customer experience. Therefore, using the wizard not only saves us time but helps us improve our customers’ experience.

You have several Unified Communications partners. How do you handle cases of multi-vendor sites and do you use AudioCodes products to support these environments?

Our engineers have the expertise to be able to integrate Lync together with AudioCodes devices within multi-vendor sites. Microsoft Lync and AudioCodes are our prime focus for Unified Communications; alternative solutions play a much smaller role in this part of our portfolio.

What do you see as the future direction and growth areas for Nexus?

Nexus is increasingly moving into the large business and enterprise sector. With regard to voice, we are currently developing this segment of the market and are driving it through a direct and reseller channel pre-sales and consultancy regarding Microsoft Lync and AudioCodes gateways.

I think the technology that will have the biggest impact in the communications market will be SIP trunks. They allow our customers to reduce costs and improve disaster recovery options.

If you are interested in sharing your experience with AudioCodes products in an interview on this blog please send me a note.

Seesaw

Why SBC Signaling and Media are no Longer Tightly Coupled

[Post is better viewed on the blog Website]

Most SBCs, whether enterprise SBCs or core SBCs, are measured and sized by one prime resource – an SBC session.

An SBC session represents a voice call flowing through the SBC and is comprised of a SIP signaling dialog (‘signaling session’) and a media stream.

One would expect that the number of signaling sessions would be equal to the number of media streams, however, the advent of hosted services and unified communications are changing this paradigm.

Imbalance between signaling and media sessions

On a typical SIP trunk service, each call consists of both signaling and media, nevertheless, on hosted PBX service, this is no longer the case.

Seesaw

Typically, two thirds of the calls that take place in a branch office are on-premise calls. In other words, calls that take place between two workers in the same office. The media streams of these calls, assuming the core SBC supports “local media”, remain internal to the branch. This way the bandwidth consumption and delays involved with sending the media streams to the core network are avoided. What this means is that for every three calls, only one media stream goes to the core vs. three signaling sessions.

Another source of SIP signaling to media imbalance, is non-voice traffic such as presence and instant messaging which are part of unified communications. These services generate substantial SIP signaling traffic but carry no media traffic (at least in the form of RTP streams). Presence and IM services are growing at a rapid pace, far outpacing the growth of voice services. Furthermore, a single change of user’s presence generates multiple signaling messages towards all the users who follow this user’s status.

Similar to the data vs. voice trend, where data traffic surpassed voice traffic in 2009 (according to an Ericsson report from 2009), we are experiencing growth of session signaling vs. media streams.

Why is it important for SBCs?

Being prime network entities that traverse and manipulate signaling sessions and media streams, SBCs must be built to handle this trend. More precisely, SBCs need to be architected in a flexible way to handle un-balanced SIP and media traffic. One way to do this is to separate SBCs that handle signaling from those that handle media. Another way is to dynamically allocate CPU and memory resources of a single server to optimally handle different traffic loads of signaling and media.

Lastly, vendors also need to start pricing their SBCs not just by the number of SBC sessions, but also by SBC resources, such as signaling sessions and media streams. This will provide the customer with a more flexible pricing model allowing him to fine-tune his costs based on his usage profile.