SBC Routing Tables Made Easy

SBC Routing Tables Made Easy

Taking the pain out of configuring service provider SBC routing tables

Session Border Controllers (SBCs) are a vital part of any VoIP network. Deployed, as their name suggests, at the border between an enterprise and a service provider, SBCs provide connectivity, security, quality assurance, regulatory compliance and media services. Not only that, SBCs are also adopting more and more network roles with the rapid growth of unified communications.

So it’s clear that SBCs are here to stay. But if you’ve ever configured a service provider SBC, the chances are you know exactly how complex the routing tables can get when each service provider SBC is a key element of the link to literally thousands of customers.

In fact, it wouldn’t be a stretch to say that configuring the routing table is generally thought of as being the most complicated part of incorporating and using an SBC in a network.

Obstacles Ahead?

Let’s have a look at some of the challenges that present themselves.

Because of the sheer number of customers that service provider SBCs are responsible for, you should take several important points into consideration when you configure routing tables.

Firstly, a service provider SBC must be able to easily distinguish between different customers while routing INVITES from the service provider server. It must also pass details about the customer to the service provider server while sending an INVITE from the SBC to the server.

Secondly, you need to determine how to eliminate the need for per customer message manipulations, customer service records and routing rules.

Thirdly, you’ve got to be able to configure call admission control for each customer.

And lastly, you want the ability to add additional customers without touching the common configuration settings.

Finding the Right Way

We at AudioCodes make it our mission with everything we do to cut right through to the heart of the matter. Our aim is always to make complex technology as easy to understand and as simple to use as possible. So, in the case of our SBCs, one of the things we asked ourselves was how we could make routing table configuration as painless as possible.

Our answer was to take apart and completely rethink the traditional SBC routing configuration model. We developed the concept of routing tags to simplify and reduce the number of route rules that need to be defined.

In essence, this involves dividing the routing process itself into two separate actions by adding a new route tagging stage. This is preceded by the classification stage and followed by the routing table, as per the traditional model. This means that routing on AudioCodes SBCs is actually executed over three steps instead of two, as shown below.

SBC Call Routing Architecture

SBC Call Routing Architecture

This configuration procedure is GUI-based, with no scripts needed. As a result, the routing tables are compact and easy to read, delivering total routing flexibility.

We’ll Get You There

This approach ensures maximum flexibility and can easily be adjusted to new methods or different nuances, such as different flavors of TGRP. Also, different data exchange methods can be used at the same time on the same device, with the ability to translate between them. The required configuration for each customer is minimal, there is no configuration redundancy, and configuration is non-bleeding. Finally, our SBCs can use external databases for routing, and they also allow both routing and advanced message manipulations.

OK, we admit it. We can’t (at least, not yet) give you a magic map or a handy GPS unit to figure out your SBC routing tables for you. But we think we’ve put our SBCs together in such a way that you can avoid most of the routing headaches. Why don’t you join us for the journey?

To learn more about making SBC routing easy, click the button.

Talk to us

Cast a spell over your SBCs

We’re Off to See the (SBC) Wizard

Try the magic wand that makes SBC configuration easy

In the Wizard of Oz, Dorothy and her companions found themselves trapped in a strange and unfamiliar land where nothing was as it seemed and everything was vastly more complicated than it needed to be. They embarked on a long search for everyday things that most of us usually take for granted, before finding out at the end of the movie that they had them all along but just didn’t know it.

SBC configuration is complex and time-consuming

If you’ve ever had the pleasure of installing SBCs for your customers, you’ll know that each deployment is different and that each SBC has thousands of possible parameters that need to be configured. The complexity of configuring these SBCs not only takes up a huge chunk of time – you also need well-trained (and therefore highly paid) people to do it.

What if there was another way of configuring SBCs that could cut through all the complexity? A splash of color in the middle of the monochrome monotony of network configuration. Well, now there is.

A simple solution to end complex configuration processes

At AudioCodes, our “Oz moment” was realizing that 80% of all SBC installations only use about 20% of the possible configuration parameters. We also understood that any differences between two installations containing the same PBX and SIP trunk service types tended to be very minor indeed. These two factors showed us where to look for an effective solution.

The AudioCodes Mediant SBC Configuration Wizard was designed with one thing in mind – to make the whole SBC configuration process quick and easy.

Cast a spell over your SBCs

As you’d expect, using the SBC Configuration Wizard is simplicity itself. You start by selecting the required IP-PBX model and SIP trunk service. After that, the Wizard walks you through a handful of straightforward and intuitive configuration screens.

Our templates make everything easy

The SBC Configuration Wizard works with a set of interoperability templates for different IP-PBX models and SIP trunk services. The AudioCodes template database currently contains over 35 IP-PBX models and over 95 SIP trunk services. Brand new and updated templates are routinely created by us and are then stored in the AudioCodes cloud. Whenever you open the Wizard, these templates are automatically available for you to use right away.

Once you’ve finished filling in the Wizard screens, you’ll see a summary of all the configuration details. If you’re happy with everything you’ve done so far, you can go ahead and create a configuration file. You can then send this file directly to the SBC, or you can save it for later if you haven’t yet installed the SBC on site. And that’s it.

Ready to go in less than five minutes

In many cases, the SBC will be fully operational at this point. In other cases, although you will be able to route calls through the SBC, you might also need to configure a few additional parameters on the device’s web GUI.

The AudioCodes SBC Configuration Wizard is available on the SBC Web GUI and as a standalone Windows application. The SBC Web GUI is ideal for on-site configuration, whereas the Windows application can be used to configure an SBC ahead of time before its actual installation.

The SBC Configuration Wizard has been used by our customers on thousands of installations, and is a tried and tested way of significantly reducing the length of time it takes to configure AudioCodes Mediant Session Border Controllers (SBCs). You can usually expect to have the first calls going through the SBC in less than five minutes.

In addition, the SBC Configuration Wizard can be used to configure AudioCodes media gateways and Multi-Service Business Routers (MSBRs).

Cast a spell over your SBCs

If you’re deploying AudioCodes Mediant Session Border Controllers (SBCs) in a customer’s network, you owe it to yourself to make configuration simple. Try the AudioCodes SBC Configuration Wizard now and pull back the curtain of complexity. You’ll be glad you did.

Put the Wizard’s magic in your hands today

Get it Now

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?


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).


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.


We Lay Our Cards On The Table


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. 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.