“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.
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.
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:
“Shoot for the moon. Even if you miss, you'll land among the stars” - Norman Vincent Peale.
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..
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.