Super Creativity in Routing Diversity


“Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after a while. That’s because they were able to connect experiences they’ve had and synthesize new things”- Steve Jobs.

Recent research shows that “super creativity” is the way the brain makes the connection between different segments of the brain. Furthermore, it’s all about amount and diversity of connectivity. What’s connectivity? Brain anatomy (circuitry) or routing?

Perhaps both?

Karl H. Pfenniger (origins of creativity; Oxford 2001) claims that creativity involves the association of diverse and apparently unrelated entities and that the brain’s plasticity allows for neurons to adapt their connectivity to function. In other words, new semantic connections will not only be associated or correlated but over time will become hard-wired in the network of associations. So creativity is related to routing diversity.

Routing in the network layer

Data routing’s main pride over the last two decades is the distributed routing architecture. Using various routing protocols (RIP, OSPF, EGRP, BGP, etc.), networks are created and shattered dynamically and automatically. Routers are totally independent and are allegedly the ultimate “plug and play” products. Hmmm…. that’s almost true. For every product there are usually two parties – the vendor and the user. Routers are the first products which users can’t use without the assistance of a mediator – “network engineers”. That’s because while a single router configuration may be simple, designing an architecture of a complete network of distributed routers is very complex.  Over the years there have been several failed initiatives (e.g. FORCES RFC, AT&T RCP) to standardize centralized routing architectures. The emergence of Software-Defined Networking (SDN) reshuffles the cards. SDN architecture is dynamic, manageable and mainly cost-effective. SDN decouples the network control and forwarding functions, enabling the network control to be centralized.  The underlying infrastructure is abstracted and used by applications and network services.

VoIP level routing

Routing in VoIP architecture lags considerably behind data routing. VoIP routing is much more complicated than data routing. Data routing is based on layers 2-4, while VoIP routing rules includes parameters from layers 2-7.  Since the initial design of the enterprise VoIP network gave control to the Soft-Switch or IP PBX, routing was typically based on static routing tables. The situation becomes complicated for off-net calls. IP-PBX/Soft Switches “get rid” of such calls by directing them to the nearest GW or SBC.

In the case of multi-branch organizations, a single VoIP network may have several IP PBXs from different vendors, as well as MGWs and SBCs. The complexity of such heterogeneous VoIP networks is rising all the time. Each IP-PBX, SBC and MGW in the network has its own static routing table; a distributed system in which the included elements don’t communicate with each other.

SBC vendors have tried to solve this complicated situation in two ways:

  • Routing Manager – a static application which helps to construct huge dialing plans and routing tables and then download them to the SBCs in the network as static tables. These files are large and complicated, allowing vendors to charge a high price for the professional services that build them.
  • Session Router -a “primitive” SIP proxy located in the center of a star formation network that performs hop-to-hop routing of the call signaling. The Session Router doesn’t solve the problem as it dictates that all the VoIP signaling will be directed via one route and leaves the routing to the VoIP peers to the SBCs and MGWs.

“Shoot for the moon. Even if you miss, you’ll land among the stars” – Norman Vincent Peale.

The scalable & manageable VoIP routing solution

VoIP Routing Controller (VRC) is a holistic, dynamic routing manager based on Software-defined Networking principles. The VoIP routing controller decuples the device layer from the network routing and policy layer, automatically creates complex VoIP networks, and simplifies routing rules, monitoring and management configuration.

Organizations’ VoIP networks are constantly evolving due to a variety of factors; mergers & acquisitions, new locations, integration of new & old IP-PBX (or even PBX) and integration of SBCs and GWs. In addition, there is organic growth of an organization and accompanying technology evolution such as introducing UC to the network and consolidating IP-PBX. All of this makes managing the organization’s VoIP network a nightmare.

Unlike the routing manager and the session router mentioned above, the VoIP routing controller is neither a configuration element nor a SIP proxy (or any other SIP element for that matter). The VRC is a dynamic routing controller which calculates end-to-end routes.

All SIP network elements (i.e. SBCs, GWS) register to the VoIP Routing Controller automatically as they boot-up. The SBC and MGWs update the VRC with all the peer connections, (the SBC / MGW connections to IP-PBX, PSTN, SIP trunk, user interfaces, etc.) The VRC learns about the SBC and MGW automatically, and it’s done dynamically. Every change in connectivity and configuration is reported to the VRC.  Eventually, the VRC has the complete network topology connectivity and health picture.

The VRC also assists with the VoIP network design and creation. With the VRC, a network can be formed in one-click. The administrator can choose between mesh, star or dual star formations and all the connections are automatically configured in the SBCs and MGWs.. This literally saves days of professional services as there is no need to configure hundreds of classification rules, trunk groups, profiles and routing rules. Everything is done automatically by VRC. For customized network connections, the administrator just draws a line and the connection is configured automatically in the SBC or MGW. The same is true regarding erasing and modifying connections. Configuring connections between SIP elements is as simple as drawing a line. And all of this is provided through an intuitive graphical and simple user interface.

The VoIP Routing Controller deals with users’ attributes to optimize routing calculations. It imports and aggregates users’ information and huge dialing plans from different sources (i.e. LDAP server and csv files) and groups user and dial-groups for routing calculation and implementation of number portability.

How does this work? When an SBC or MGW receives a call, it sends a query to the VoIP Routing Controller by REST API. The query includes the entire set of call information (i.e. sip:invite) The VRC calculates the entire route end-to-end and sends the entire route back by REST API. From there, SBCs and MGWs perform the call and when the call terminates, the last node in the route sends a notification to the VRC. The routing calculation may be done using a variety of decision criteria, including: priority, time based, least cost, quality, connectivity, user and dial group..

Testing Creativity

Close your eyes and imagine ten or more different animals. OK, now open your eyes and write down the imaginary list.. This simple test can differentiate between Walt Disney and Steve Jobs and the rest of us mere mortals. Where most of us will imagine cows, donkeys, sheep and maybe a lion, in the “Super Creative” list you will find anything but “regular” animals, instead you will find the likes of Capybaras, Fennec Foxes, Kinkajous, and Servals.

Routing rules and manipulations are complex and can’t be implemented on-line. Therefore, one of the VRC’s important features is the “test route” and “test manipulation” which allows for testing any rule and policy that was created in the VRC and immediately seeing the impact on the routing and policy.


The VoIP Routing Controller is a very much needed 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.

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.