Freeswitch vs Opensips or where to use them

 Why is hard to find any comparisons infact?

You find no comparison because it's like comparing a bus to a car they both have wheels they both can provide transportation but they serve different purposes. Freeswitch is media server, Opensips is signalling proxy.
Ok but let's go deeper and see where we can use Freeswitch and where Opensips and where we could combine them and how, so we can get the best of them.

For what Opensips is good for?

It is designed to handle large volumes of calls, load balance SIP, solve advanced NAT scenarios, and to deal with SIP signalling and registrations as no other. OpenSIPS is typically used when you are managing large volumes such as more than a thousand registered users. Opensips can handle all the requests and responses. This makes it possible to translate between two incompatible versions of SIP, handling directly the SIP headers, requests, and responses. This is an important feature when you have SIP implementations from different manufacturers, which can be incompatible between each other. Above is especially important if your future system should handle with different voip vendors.

Tough it is not designed to handle natively audio, with the help of RTP proxy this can be easy overcome. It does really good job with NAT traversal (better than FS) especially the module responsible for that which is highly tweakable, allowing optimization of the media call flow between the endpoints.

OpenSIPS is not a platform that you would use to create systems such as IVR, VoiceMail, TTS, and Voice Recognition, etc. This is by design.

For what Freeswitch is good for?

As media server by design, for services as Voicemail,Conferencing, Text to speech, speech recognition FS is very valuable. Ability for easy configuration of complex call scenarios trough XML and navigating trough IVR menus as Auto Attendance or Voucher recharge is unique. But along with all that you can register users and proxy media.

In one sentence it can be used as a "black box does it all".

Then why to use Opensips when Freeswitch can do the same and more?

Some people think that just because Freeswitch has a lot of features and they completely overlap with opensips except Freeswitch have more, they decide to count entirely on Freeswitch and eventually use Opensips only for load balancer. But this is not really true, Freeswitch has a lot of features, but do you really need them in each call? No. That is why you should involve Freeswitch only when is necessary.

How best to combine them? What principles to follow?

Just because FS has really a lot of features while Opensips architecture is simpler you might guess that Opensips have better performance and stability.
Opensips has processing a light-weight instruction script and singe thread can process hundreds of calls per min. On the other side FS runs thread for each call, hooking up to the call and watch it closely all the time.

If you want performance and consistency you should build your system of components, which have good integration between them, and do the best for what are designed for.
With the swiss knife approach of FS you would end up with system which does its job but with more overhead than needed, less scalable, flexible with performance tradeoff.

Good theory but any real world examples?

In VVS design, Opensips is responsible for registration, authorizing the call, preforming dial plan translation rules, communicating with Billing engine to see if caller can actually call the destination and if it has enough money to make the call, check the type of dialed destination (onnet or offnet). If offnet will prepare list of appropriate GW's based on price and priority. If onnet will evaluate if the user is registered or not, if call should do Follow me policy or should be send to Freeswitch in order to trigger VM logic, Auto Attendance or play error message.  At the end, trough the help of Billing engine CDR is written, along with adjustments to the balance of vendor, reseller and customer.
This ofcourse is very basic flow.
All needed additional custom modules are written in C, natively plugged into the Opensips core.

All the logic can be deployed on one single instance so when you need more capacity you just deploy another one on the cloud, in matter of minutes with the help of automated script. On the front of these units there is another Opensips which acts as Load balancer, SBC and allows adding and removing of VVS units to become not noticed from end users.

In conclusion

 - for systems which will be used mostly as PBX you better deploy cluster of Freeswitch, load balanced by Opensips
 - for large scale deployments you should count on Opensips to do most of the tasks (along with its "helper" modules) and involve Freeswitch only if necessary. We should mention here Couchbase and MongoDB native support in next version 1.9 of Opensips. This will make clustering easy job with possibility to share DIALOG and USRLOC among all units and should help you to design piece of SIP architectural system of the future with unmatched scalability. Dreamy ah!?

How many concurrent calls my system can handle?

One of my favorite questions in my practice. Note that the “real” measure of performance is the number of call attempts per second (since each request has to be processed by the system), while the number of concurrent calls is derived from it, based on your traffic patterns (average length of call, call success rate, etc.). A system which processes traffic with a lower ASR (average success rate) will handle fewer concurrent calls than an identical system which handles traffic with a better ASR.

Let's put some numbers

Assuming an aggregated call processing speed of 50 call attempts per second, an average call duration of 5 minutes, and a call success rate of 50% (the industry norms), it means that 50% of the 50 call attempts per second will succeed. So 25 calls will be connected, while the same amount of previously connected calls will be disconnected. Since the average call duration is 300 seconds, this means that at all times approximately 25 *300 = 7,500 calls will be in a “connected” state. If your ASR changes, it will have an immediate impact on the number of concurrent calls, e.g.:

 ASR 25%: (50 * 25%) * 300 = 12.5 * 300 = 3,750 concurrent calls
 ASR 60%: (50 * 60%) * 300 = 30 * 300 = 9,000 concurrent calls

Thus the value of 7,500 is an estimate based on industry norms (5 minutes ALOC, 50% ASR). The actual number in your system will ultimately be determined by your traffic patterns and other factors, such as the hardware used, network connection quality, and whether or not you proxy the voice stream for a large portion of calls.

To simulate how the expected maximum number of concurrent calls changes based on your traffic patterns, use this VoIP capacity calculator.

How many minutes of monthly traffic that means?

Again, this depends mainly on your traffic patterns (the ratio between the duration of your peak and off-peak hours and the differing amount of calls in peak and off-peak hours) and your call success rate. We can estimate this based on typical traffic patterns (as indicated below) with daily peak hours, medium load hours and off-peak hours. We should also bear in mind that your network must be able to handle all kinds of traffic – off-peak hours, peak hours, and extraordinary traffic splashes (e.g. New Year’s Eve).

Thus the total performance capacity must be greater than the maximum anticipated BHCA (busy hours call attempts). On average, extreme traffic peaks (such as Christmas, New Year’s, etc.) will have 2 to 3 times more call attempts than your normal peak hours, so approximately 50 / 2.5 = 20 call attempts per second can be expected during your peak hours. Using the same “industry norm” figures as above (50% ASR, 5mins ALOC), your switch could process (20 * 50%) * 5 * 3600 = 180,000 minutes during your peak hours. We can estimate that your total amount of daily traffic will be about 6 times the amount of traffic during one peak hour, i.e. 180,000 * 6 = 1,080,000 minutes per day. Then, multiplying the daily amount by the number of “business” days in a month, we get
1,080,000 * 20 = 21,600,000 minutes.