Choosing the Right Open-Source Stack for Enterprise VoIP Development

Teams involved in the development of a custom VoIP have to pick more than one piece of software. Although some platforms already cover several VoIP responsibilities, a common practice in enterprise deployments is to separate SIP routing, application logic, media processing, and WebRTC connectivity. This way, each layer can scale independently.

In the following sections, we’ll discover those open-source VoIP projects that show up again and again in enterprise VoIP software development:

• Asterisk
• FreeSWITCH
• Kamailio
• OpenSIPS
• Janus
• LiveKit
• RTPEngine

Our main intention is to look at what each one actually does and where it fits. We’ll look at where each one runs out of room, because that’s usually the part vendors leave out of the pitch

The Core Split: Signaling Versus Media

Before the comparison of tools starts, it’s a good idea to make a clear distinction between what gets mixed together in conversation: signaling and media.

Signaling happens when a phone or app says “I want to call this number.” This is a pure negotiation step, because something has to figure out where that call goes, who answers, and how the session gets set up. In traditional VoIP, this is handled by SIP (Session Initiation Protocol).

Once a call is set up, we enter the media phase. This is the actual voice or video stream, where audio packets travel between endpoints. Sometimes they pass through a relay. Sometimes transcoding is needed if the codecs don’t match.

Some tools do only one of these jobs; other platforms handle both signaling and media. The latter simplify smaller deployments but can couple their scaling and operational requirements.

Asterisk

Asterisk started as a Private Branch Exchange (PBX). It still behaves like one. What makes this software a good choice is that it covers a lot of ground without requiring much custom development. 

What can Asterisk do? It handles call routing, voicemail, IVR menus, and conferencing and can be a standalone SIP server. So it makes sense for a call center or a company replacing a legacy phone system.

Asterisk was built around the dialplan model. Because of this, it gets harder to manage once thousands of concurrent calls need complex routing logic. The tradeoff becomes more visible as routing logic, tenant isolation, and signaling volume grow. Teams dealing with Asterisk development usually mitigate this at large scales by placing multiple instances behind a SIP proxy. This way, they keep Asterisk focused on application services such as IVR, queues, conferencing, and voicemail.

Despite the above, the platform fits small to mid-size deployments, call centers, and systems that need built-in telephony features without extensive customization.

FreeSWITCH

This software was written partly by former Asterisk contributors who wanted a more modular core. It works as a soft switch and media server rather than a strict PBX. Its architecture separates the core from modules. 

FreeSWITCH’s modular architecture supports conferencing, codec negotiation, transcoding, and other media applications. While this solution is commonly selected for media-intensive workloads, its actual capacity still depends heavily on the codec mix and enabled media operations. 

Other things to take into account while using FreeSWITCH:

• It supports WebRTC natively for basic cases.
• Its configuration syntax uses XML-based dialplans, and that has a steeper learning curve than Asterisk’s. 
• Community documentation is thinner too, in places.

Depending on its configuration, FreeSWITCH can operate as a media server, conferencing server, or B2BUA and perform some SBC-like functions. It’s a common choice as a media server sitting behind a Kamailio signaling layer.

Kamailio

Kamailio is a SIP proxy, registrar, and router that was built for a single job: moving SIP messages fast. Since it never processes the RTP media stream itself, a single instance can handle tens of thousands of registrations and a large volume of signaling traffic. Kamailio sits at the edge of the network: it decides where calls go, load balances between backend media servers, and enforces routing policy. 

That narrow focus is the whole point of the design. Kamailio’s configuration language, kamailio.cfg, is powerful but unforgiving. Any small mistake you make in routing logic can lead to calls being dropped, or worse, open the door to toll fraud. This is why testing matters more here than in most VoIP components.

Kamailio best fits are high-volume SIP routing, load balancing across media servers, and carrier-grade signaling layers.

OpenSIPS

This one shares a common ancestor with Kamailio: the OpenSER project, which was split into separate projects years ago. Functionally, they overlap a lot: both are SIP proxies that skip media handling entirely, and both scale well when the workload is signaling only. They differ in tooling and philosophy.

OpenSIPS ships a management interface, the MI/JSON interface. Some teams find it easier to integrate with external systems. It also has built-in support for NoSQL backends for registration data, which can matter in large distributed deployments. Also, while Kamailio has a larger community and more third-party documentation floating around, OpenSIPS has a management interface some teams prefer working with directly.

Both OpenSIPS and Kamailio fit the same general use case. It’s worth evaluating both before committing, since migrating between them later is painful, and few teams do it twice.

Janus

Rather than being another SIP server, Janus serves a WebRTC gateway. Its main job is bridging browser-based real-time communication into other protocols and topologies. It runs as a set of plugins: 

• one handles video rooms
• one that does SIP gatewaying
• one that streams recorded content. 

Developers build on top of it rather than configure it like a PBX.

Janus provides building blocks such as SIP gatewaying, recording, streaming, and SFU-based video rooms. Compared with LiveKit, however, what teams generally do is build more of the surrounding application layer themselves. This includes room orchestration, user management, application APIs, and client-side product workflows.

Janus fits WebRTC gateways and custom video or audio applications. Where fine-grained plugin control matters more than a managed SDK experience, this software is a good match.

LiveKit

LiveKit takes a different approach. It’s a WebRTC Selective Forwarding Unit (SFU) written in Go. It has been built for scale and offers an open-source core and a hosted cloud option. Where Janus expects a team to write plugins, LiveKit ships client SDKs for web, mobile, and native platforms. It also adds server APIs for room management, recording, and egress to files or streams.

LiveKit supports distributed and multi-region deployments, but teams must configure and operate that infrastructure when self-hosting. You can distribute rooms across different nodes (in this case, each individual room is assigned to a single node, so large-room capacity still requires careful benchmarking). 

LiveKit fits browser and mobile video or audio apps. For teams that want an SDK-first developer experience instead of writing plugin logic from scratch, this tool is a strong pick.

RTPEngine

RTPEngine is a media relay. It was developed by Sipwise and sits alongside a SIP proxy like Kamailio or OpenSIPS. RTPEngine handles the actual RTP media stream, including NAT traversal, transcoding, recording, and encryption (SRTP/DTLS) for WebRTC-to-SIP bridging. 

As mentioned above, Kamailio and OpenSIPS don’t touch media. But something still has to relay it, and this is why RTPEngine matters in enterprise stacks. This is even more important when endpoints sit behind NAT, or when transcoding is needed between mismatched codecs. RTPEngine does this in kernel space when possible. That keeps latency low, even at high call volumes.

For any deployment using Kamailio or OpenSIPS that needs a dedicated, high-performance media relay instead of routing media through the media server itself, RTPEngine is always a good fit.

The following simplified Kamailio route shows how the SIP layer can instruct RTPEngine to rewrite SDP and anchor media without forwarding RTP itself: 

request_route {
    if (is_method("INVITE")) {
        if (has_body("application/sdp")) {
            if (!rtpengine_manage(
                "replace-origin replace-session-connection"
            )) {
                send_reply("500", "Media Relay Error");
                exit;
            }
        }

        t_on_reply("MEDIA_REPLY");
    }

    if (is_method("BYE")) {
        rtpengine_manage();
    }
}

onreply_route[MEDIA_REPLY] {
    if (has_body("application/sdp")) {
        rtpengine_manage(
            "replace-origin replace-session-connection"
        );
    }
}

This abbreviated example omits RTPEngine node selection, transaction failure handling, NAT policies, WebRTC-specific flags, and other production routing logic. The purpose here is to show that Kamailio modifies the session through RTPEngine’s control interface while the RTP packets follow a separate media path.

How These Pieces Fit Together

The table below summarizes each of the tools explained in the previous sections: 

However, a typical enterprise VoIP architecture layers these tools rather than picking just one.

Signaling stays at the edge, handled by Kamailio or OpenSIPS. Kamailio or OpenSIPS also controls RTPEngine during session setup but does not forward the RTP packets itself. Thanks to this, signaling and media capacity can be scaled separately. 

Behind that, we have FreeSWITCH or Asterisk, running the application logic: 

• IVR 
• voicemail
• conferencing

Janus or LiveKit stays at the WebRTC edge, translating between browser clients and the SIP core in case the product needs browser-based calling, 

Chudovo’s engineering team has used variations of this layered pattern on telecom projects, in cases where signaling volume and media processing needed to scale independently of each other. On one such project, moving the SIP registrar off the media server’s box cut failed-registration incidents during peak hours, since REGISTER traffic no longer competed with active calls for CPU time. 

Below is a simplified Kamailio snippet showing how a registrar can store endpoint contacts and route an INVITE to a registered user. This example does not pretend to be production-level code, because it intentionally omits authentication, authorization, and other things that a production-level code should also consider (such as transaction and dialog handling, Record-Route logic, NAT traversal, rate limiting, accounting, media-relay control, and correct processing of in-dialog requests, CANCEL, and ACK messages).

route {
    if (is_method("REGISTER")) {
        save("location");
        exit;
    }

    if (is_method("INVITE")) {
        if (!lookup("location")) {
            sl_send_reply("404", "Not Found");
            exit;
        }
        t_relay();
        exit;
    }

    sl_send_reply("405", "Method Not Allowed");
}

Tradeoffs and limitations

There are some limitations that don’t show up in most vendor comparisons, so it is worth stating them directly. 

1. Kamailio and OpenSIPS require someone on the team who understands SIP deeply. A common cause of production incidents is misconfigured routing. 
2. As routing complexity, tenant count, and integration requirements grow, Asterisk dialplans can become difficult to maintain. Because of this, it’s important to do a separate benchmark on call capacity to properly test the expected codecs, recording settings, and media operations.
3. Since FreeSWITCH has some documentation gaps, teams often rely on community forums or paid support contracts for edge cases.
4. Compared to Janus, LiveKit usually needs less custom development for room orchestration, user management, application APIs, and client-side workflows.
5. LiveKit is not a drop-in SIP replacement. Bridging into the PSTN still needs a SIP-aware component.
6. RTPEngine needs monitoring and capacity planning separate from the SIP layer, which adds an operational dependency. Teams sometimes forget that until an incident forces the issue.

Picking a starting point

The first step for teams building a custom VoIP platform is to select the telecom technology stack. A commonly used path is to start with Kamailio or OpenSIPS for signaling. For media relay, RTPEngine is what they pick. The choice between FreeSWITCH or Asterisk will depend on whether the priority is media flexibility or built-in telephony features. Finally, they add Janus or LiveKit if browser-based calling is a real requirement (not a hypothetical one someone raised in a planning meeting). 

In the end, there isn’t a stack that works for every one of those combinations at once. The final decision depends on several factors like call volume, whether media needs transcoding, and whether the product needs to reach browsers directly. 

What matters most is understanding which job each tool does, so the architecture doesn’t end up with three components fighting over the same responsibility.