2600Hz Blog

At 2600hz we like to say that we’ve “re-written the telephony stack.” Which either elicits looks of belief and wonder or hardcore skepticism. Which is fair. So we’re going to be temporarily replacing our usual Wednesday Bug series with a short series on the architecture stack we’ve designed to improve telecom like it’s never been done before. The seven components are: 

• Session Border Controllers (for SIP)
• Load Balancers (for SIP)
• Media Servers
• SMS / MMS / SMPP
• Dialplan /  Call Processing
• Messaging Buses
• Databases

Today, we’ll talk about two of those components and our experiences using them. These components are OpenSIPs–our load balancer, and FreeSWITCH–our media server. 

Why We Selected These Components
OpenSIPs has a long history of being an extremely stable, flexible SIP proxy, allowing you to set up a load-balanced, redundant setup for many millions of calls per day. One of its greatest strengths is its rock-solid reliable performance and its ability to do reasonably complex tasks in a short amount of code. But OpenSIPs can’t natively handle audio and frankly, wasn’t really designed to.

FreeSWITCH has a long history of being an extremely stable and flexible media switch,  allowing you to handle many thousands of simultaneous phone calls on a minimal amount of hardware without degrading call quality. In addition, FreeSWITCH has built-in functionality to support integration with OpenSIPs which is crucial as it would otherwise be hard to work with.

How OpenSIPs and FreeSWITCH Are Different
At the fundamental level, OpenSIPs and FreeSWITCH serve two different purposes. OpenSIPs was originally designed to be a scripting engine and a proxy for SIP packets. In English, think of it as the “traffic cop” with the neon vest that stands in a busy intersection. You can program it to tell it how to direct traffic in different ways, based on volume, quality or location or other factors.

So if we say OpenSIPs is the load balancer that directs traffic (call flow) along the road which is the Internet…where does all that traffic get directed towards? You guessed it. FreeSWITCH. 

FreeSWITCH is a media server. Think of a media server as being similar to a language translator between two people who speak two completely different languages. In its simplest form, a media server takes audio from one person, processes it, and passes it on to another person. It also provides translation services, meaning if one person “talks” another language it can convert that language on the fly to something the other party can understand.

Technically speaking, there are major differences in how you would architect a traffic cop versus a translator. The analogies to real life work well, so lets continue with those.

In the OpenSIPs as “traffic cop” analogy, think for a minute about the length of time a traffic cop is concerned about the traffic flowing around it. A traffic cop directs cars down a street, but once the cars pass by, the cop no longer cares who they were, where those cars go,  or what direction they continue to travel in. In this regard, a traffic cop may see millions of cars pass them per day but is only ever concerned with the few cars it is currently directing at any given time.

In the FreeSWITCH as “translator” analogy, lets contrast the length of time a translator must focus on a conversation between two people. (For the purposes of this analogy, we will represent a FreeSWITCH box as a building filled with thousands of translators.) A translator must focus on only one conversation at a time while being able to understand and speak the language of both sides. The translator can’t leave in the middle of a conversation easily to be replaced with another translator – they must stay for the duration of the entire conversation.

Comparing OpenSIPs and FreeSWITCH For Capacity (and why you shouldn’t)
I’ve seen lots of people try to compare the capacity of OpenSIPs to that of FreeSWITCH. This doesn’t make much sense. Looking back at the above analogies we can see the fundamental differences between OpenSIPs and FreeSWITCH.  In technical terms, this translates into different ways to analyze capacity based on work done by threads.

Both OpenSIPs and FreeSWITCH utilize threads in order to process calls. The difference lies in what the threads are doing.

For OpenSIPs you have a Linux thread running which is the equivalent to a traffic cop. A single thread might pass 10,000 calls per hour from point A to point B, processing a light-weight instruction script (“is this person authorized? OK, let them through!”) for each call. The real concern around capacity for OpenSIPs is how many simultaneous requests OpenSIPs will get at any one point in time. Think of this as the difference between a four-way intersection and an eight-way intersection. You might need only one traffic cop at a four-way intersection but need an extra cop at an eight-way intersection simply because of the extra load.

For FreeSWITCH you have a Linux thread running which is the equivalent of one translator. A single thread will only ever process one call, for the entire duration of that call.

So, when planning capacity, you need to ask yourself:
OpenSIPs – How many simultaneous people are going to register a phone, make a call or hangup on a call at the same exact time? Divide that number by how many calls each thread can process and you know how many threads you need.

FreeSWITCH – How many simultaneous people are going to be on the phone at any given time? That is how many threads you need.

Now that we understand the difference between OpenSIP and FreeSWITCH and their purposes and capacities, stay tuned for next Wednesday’s post on FreeSWITCH support for OpenSIPs (or any proxy.)