Why Evariste’s customers choose CSRP to solve the SIP Class 4 carrier interface

At Evariste Systems, our vision for our Kamailio-based CSRP project germinated from a perceived gap in Class 4 switch platform solutions for the small to midsize ITSP market.

12074504_10104890114887410_1352926093300463537_n
Alex Balashov, founder of Evariste Systems and member-in-council of the Kamailio project management board.

We started out in the mid-2000s as a FOSS technology-focused consultancy into the VoIP service provider space, specialising in high-performance call routing, accounting and rating solutions built on top of the OpenSER/Kamailio technology stack.

Rather quickly, we realised that we were constantly being asked to build subsets of the same sort of thing: a Kamailio-based trunk routing platform for hosted PBX operators, wholesale SIP origination & termination providers, and VoIP application service providers. These implementations had a common denominator of requirements:

  • Least cost routing or other dynamic routing to and from PSTN connection providers;
  • Call detail record (CDR) accounting and/or mediation;
  • High-volume call processing engine.

We had to ask ourselves: why did so many ITSPs want to build a Kamailio-based Class 4 switch? After all, there were, by the time we entered this arena, plenty of canonical solutions to these problems in the enterprise segment, with well-established elements like Nextone (Genband) and Acme Packet (Oracle) for call processing and redirect-based LCR folk traditions, as for example from Global Converge.

The picture that emerged from our discovery:

  • Most obviously, small and midsize ITSPs were priced out of the enterprise Class 4 solution space.
  • Many small to medium ITSPs relied on the the trunking/Class 4 side of their Class 5 feature platforms, e.g. multitenant hosted PBX platforms, for the carrier interface. However, this component was distinctly lacking in technical and business-layer features. In those kinds of platforms, the carrier interface portion was a relatively colourless afterthought — just another check box in a very long feature matrix.
  • The carrier interface of Class 5 platforms was not built with high-volume, high-throughput applications in mind, as call processing in these systems has to be funneled through an application-heavy engine. This engine was good for applications and user experience, not for high-volume call processing.
  • The conventional combination of “dumb” network element (e.g. SBC) + “intelligent” outboard routing server + [often] mediation solution was too complex, too expensive, and demanded too many moving parts.By the time this zoo was built out, there were three vendors to pay and three infrastructure silos to operationalise and keep highly available. It was simply too burdensome.
  • The Tier 1 supply chain that feeds the VoIP DID & termination industry was getting better and better at delivering small transactions with shrinking ramps and commits, squeezing distributive resale and arbitrage plays out.
  • Accordingly, as small to medium ITSPs had to look elsewhere for differentiation strategies, there was a widespread ask for programmable solutions and universal integration paths, such as APIs and direct database access.
  • Enterprise equipment offered these, but usually through a highly bureaucratic interface such as SOAP, or a complex SDK. The more technically minded in the industry demanded a purer, simpler, and more flexible way to externally drive their platform from their in-house OSS/BSS elixirs, customer portals and so on.
  • The performance of enterprise equipment in high-volume wholesale scenarios was easily exaggerated and often did not meet expectations, especially relative to the licencing costs.

Open-source engines were just that — engines. They offered no silver bullet because, while they offered good core technology, they lacked any of the vertical-specific business features.

So you want to build a FreeSWITCH-based platform? Okay, you’ve installed FreeSWITCH. Now what? While it can be wrestled relatively easily into a PBX or static call routing role, a Class 4 switch it does not make. Kamailio/OpenSER does even less out of the box; with its domain-specific, low-level route script, it can almost be thought of a kind of SDK with SIP proxy core.  These technologies are toolboxes, not finished products. All of which is to say: you can’t just download an open-source trunking box real quick — at least, not if you want it to do the kinds of things listed in the CSRP features matrix.

And thus became it clear that there is a market opportunity to fill a gap — an inexpensive Class 4 interface which:

  • Runs on commodity hardware.
  • Provides straightforward and folkloric integration paths.
  • Performs well under high loads, in many cases better than big brand commercial equipment.
  • Provides an expansive business layer with wide applicability to the global VoIP ITSP, carrier, call centre and application farm workloads.
  • Combines call processing, accounting and mediation functions into one chassis.
  • Solves commonplace technical problems in the delivery of SIP trunking as well or better as big brand SBCs, e.g. far-end NAT traversal for off-net gateways.
Screenshot from 2014-12-13 15:41:00
Configuring a Customer Billing Group in the CSRP web management interface.

We broke ground on our reference implementation for CSRP in February of 2010, choosing to build the platform on top of Kamailio with a strong focus on performance.

Although Kamailio, as a SIP proxy, was a decidedly unconventional core call processing technology in an industry accustomed to opaque B2BUA (Back to Back User Agent) network elements, it has paid handsome dividends in performance and reliability. Despite technical trade-offs that come with foresaking the traditional B2BUA formula, we feel our decision is vindicated by the thousands of calls per second effortlessly set up by our highest-volume customers. At that level, it’s a challenge to find suppliers whose Sonuses and Acme Packets won’t fall over from the loads CSRP easily copes with!

In terms of trajectory, we took the slow, organic customer-driven development route, preferring high market validation to an explosive–if spectacular–front-loaded marketing blitzkrieg. This means that the feature set of CSRP today is closely coupled to concrete customer demand in this space because we have taken the time to truly understand our market, and it means that our technology has seen extensive field battle testing in the precise applications for which it was intended. We don’t have a lot of dark feature corners of bit rot for the sake of another coveted check box; if something is there, it’s there for a reason.

This conservative and involved business strategy puts us in a unique position of credibility from which to comment objectively and soberly on the suitability of CSRP to your application. We know what our customers want, and we provide a vendor service relationship commensurate with the insight we have painstakingly cultivated into the Class 4 arena.

CSRP is not a piece of a larger puzzle for us; it’s the endgame. We are passionate about the platform we have built, and dedicated to making it better every day.

If you would like to learn more about CSRP, please do not hesitate to reach out!