As the telecom infrastructure world moves to software, there are still “anti-pundits” that question the ability of software to scale and be reliable. Call them hardware bigots.  But their position is totally understandable.  Hardware has scaled in telecom for decades, and hardware architectures have proven to deliver five 9’s reliability.  But the data and IT type architectures utilizing commercial off the shelf (COTS) equipment and “oversubscription” models have proven just as reliable. In these architectures, if a unit goes down there are others available to take up the slack.  And with the stacking of these units, they have proven to be just as scalable as well.

This has required software to manage and control the COTS and/or software based offerings.  And as NFV has moved telecom infrastructure inexorably more towards software, these load balancing and scalability architectures are becoming more and more important. Building large-scale and highly-reliable applications was a challenge that the web application world has solved with Application Deliver Controllers (ADCs), essentially an intelligent load balancer for web, database, and other network-based traffic.

This model can be applied to real-time telecom communications.  However, specialization will likely be required in the real-time SIP communication world because the requirements of voice and video calls are different than the requirements of accessing web pages or getting email.  “Real-time” is critical and cannot be treated as “other network-based traffic.”  We’ve already seen in management of software media servers  specs from the IETF (RFC 6917) and 3GPP (TS 23.218) that call for a Media Resource Broker (MRB) to direct traffic to/from Telecom Application Servers and media servers. 

For ADCs that are deployed in a real-time telecom software-based infrastructure environment, specialization is required because there are some shortcomings for web-focused ADCs. Namely, poor handling of RTC protocols, no support for WebRTC, and

SIP support issues including the ability to intelligently handle layer 5/6 traffic and SIP 3xx and 4xx messages.  These are critical for deploying an ADC throughout the IP infrastructure when real-time voice and video are deployed.

Which leaves two choices – deploy a new real-time ADC next to a web-focused ADC, (which is a great choice if you already have an ADC deployed), or deploy the real-time ADC in the telecom focused environment (which would also be able to handle the web based ADC requirements). 

In the future, I’ll cover some use cases for a real-time ADC. Stay tuned.