SIP Trunking

What is a SIP server? Roles, software, and carrier reach

This guide explains what a SIP server actually does, breaks down the four logical server roles defined in the SIP standard, surveys the open-source options, and shows where the upstream carrier fits into the stack you are building.

By Eli Mogul

A SIP server is the software that routes, authenticates, and connects calls in a Voice over IP network. If you are building voice infrastructure with Asterisk, Kamailio, FreeSWITCH, or OpenSIPS, the SIP server is the control plane of your deployment, but that's only half the picture. The other half is the carrier network your SIP server connects to for reach into the public phone system.

What a SIP server does

The Session Initiation Protocol (SIP) is the signaling protocol that sets up, manages, and tears down real-time sessions: voice calls, video, and messaging. SIP itself does not carry the audio. It handles the negotiation, while the media flows over a separate protocol like RTP.

A SIP server is any network element that listens for and processes SIP requests. It decides where a call should go, whether the caller is allowed to make it, and how to reach the destination. SIP became the dominant choice for IP telephony largely because of its lighter footprint. Early IP telephony built on the older H.323 protocol could take up to 8 seconds for a call to be answered, a delay that component optimization eventually brought down to 100 to 200 milliseconds. SIP, by negotiating call features within a single transaction, set up calls in roughly 100 milliseconds and scaled better, which is why it won.

One of SIP's design tradeoffs is standards sprawl. An IETF informational memo, RFC 5638, noted that an Internet-centric SIP deployment could cut the number of SIP-related standards it needs to consider from roughly 100, and still growing, to about 11. For anyone implementing or operating a SIP server, that complexity is the reason architectural clarity matters so much.

The four SIP server roles

SIP server roles

The core SIP specification, RFC 3261, defines four logical server roles. The word "logical" is important: these are functions, not boxes. A single piece of software can play all four roles, and most production SIP servers do.

Role	What it does	Key behavior
Proxy server	Routes requests toward the destination and enforces policy	Forwards and may rewrite parts of a request on the caller's behalf
Registrar	Accepts REGISTER requests and records where users can be reached	Writes user location bindings into the location service
Redirect server	Tells the caller to contact an alternate address itself	Returns 3xx responses pointing to other URIs
Location server	Stores the mapping of users to their current network addresses	Supplies bindings that the proxy queries to route calls

The proxy is the workhorse. It receives a request, figures out the entity closest to the targeted user, and forwards it, handling authorization and network policy along the way. The registrar is how a SIP server knows where you are: when your phone or softphone comes online, it sends a REGISTER request, and the registrar stores that binding. The redirect server takes a different approach, responding to a request by handing the caller an alternate set of addresses to try directly rather than forwarding on its behalf. The location server is the database behind all of this, holding the bindings that the proxy consults to make routing decisions.

Because these roles are logical, real software combines them freely. That flexibility is what makes the open-source SIP server field so varied.

Open-source SIP servers compared

Four projects are especially common in open-source SIP deployments, and they split cleanly into two architectural camps: proxies that touch only signaling, and back-to-back user agents (B2BUAs) that touch both signaling and media.

Kamailio is a high-performance SIP proxy, the successor to the former OpenSER and SER projects, and it is widely deployed by carriers and providers. It excels at routing SIP traffic at scale: modifying headers, enforcing policy, terminating TLS, and load balancing. What it does not do is touch the audio stream. If you need to record a call, play audio, or bridge a conference, Kamailio hands that off to a media-capable component.

OpenSIPS shares Kamailio's roots and its proxy-first design, but folds more functionality into a single process. It ships native B2BUA logic, a dialplan module, and load balancing, which means it can consolidate several separate boxes into one tier. The practical distinction is subtle: OpenSIPS is often attractive when signaling, routing, and application logic benefit from tighter integration, while Kamailio is often chosen for high-throughput SIP edge routing.

Asterisk is one of the most widely deployed open-source telephony platforms. It functions as a B2BUA and handles both signaling and media, which is what lets it offer voicemail, conferencing, call recording, and audio playback out of the box. It is fast to learn and quick to prototype with, though at carrier scale it generally sits behind a proxy like Kamailio rather than facing the public internet alone.

FreeSWITCH is a media-first telephony platform that also operates as a B2BUA. It handles SIP, RTP, SRTP, WebRTC, and codec transcoding natively, making it a strong single-project choice when media processing is central to your application.

A common production pattern pairs them: Kamailio or OpenSIPS at the edge for routing and security, with Asterisk or FreeSWITCH behind it for anything that touches the audio. For media handling alongside a proxy, RTPengine is the most common companion daemon.

One more point worth making, because it is easy to assume otherwise: you do not always need dedicated SIP hardware. A 2024 peer-reviewed study in PLoS ONE on multi-threaded and multi-core SIP proxy servers found that adding AES encryption and secure media to a software SIP server introduced only about an 8-millisecond latency tradeoff, supporting the case that commodity multi-core systems can stand in for purpose-built SIP appliances in many deployments.

What your SIP server connects to

Here is the part that most explainers leave out. Your SIP server routes calls beautifully inside your own network, but the moment a call needs to reach a regular phone number, on a mobile or a landline, it has to cross from your IP network onto the public switched telephone network (PSTN). Your SIP server cannot provide PSTN reach by itself. It needs a carrier interconnection or gateway path into the public phone network.

This is the boundary where a lot of voice projects get complicated. The interconnection between an enterprise SIP network and a service provider is governed by a dense set of standards, and as the IETF's active working draft on automatic peering for SIP trunks puts it, given the sheer number of these standards it is often unclear which behavioral subsets a network ought to implement to peer successfully. The draft proposes a standardized capability document that a provider can publish and an enterprise edge device can poll to configure peering details automatically. It encodes transport, supported SIP methods, codecs, and security baselines like STIR and DTLS-SRTP.

The takeaway for builders is that the carrier relationship is not a detail to bolt on at the end. It shapes your security posture, your call quality, and your compliance footprint. Caller ID authentication is a good example: the FCC requires STIR/SHAKEN in the IP portions of voice networks, and in practice, signing is usually handled by the originating voice provider or carrier infrastructure, not by a standalone enterprise SIP server. The quality of your upstream carrier determines whether your calls are signed, trusted, and delivered.

Where Telnyx fits

Most carriers sit on top of someone else's network. Telnyx does not. As Ian Reither, COO at Telnyx, frames it:

"Telnyx runs SIP at the carrier level, with carrier licenses and a private backbone that is programmable end to end. Your SIP server connects directly to that network instead of hopping across someone else's stack."

That ownership is the difference. When you point your Asterisk, Kamailio, FreeSWITCH, or OpenSIPS deployment at Telnyx SIP trunks, your signaling and media ride a network Telnyx operates rather than leases. There are fewer intermediary hops, which means lower latency, structurally lower cost (SIP trunking runs roughly 2x cheaper than a reseller like Twilio over the same wholesale floor), and tighter control over quality and security. Because Telnyx originates calls on its own network, it issues A-level STIR/SHAKEN attestation directly, the highest level the framework allows, rather than inheriting partial attestation from an upstream carrier. Telnyx is a licensed telecom provider in 40+ countries and maintains support documentation for the SIP servers and PBX platforms developers actually run, including FreeSWITCH, FreePBX, Cisco, and Grandstream equipment.

For developers who want to move beyond signaling and routing into programmable call control, the Telnyx Voice API and WebRTC sit on the same owned infrastructure, so you can provision numbers, build call flows, and add real-time browser calling without stitching together a second provider. If you are evaluating the architecture from the ground up, the SIP trunking architecture breakdown is a useful next read, and teams running their own SIP servers can follow the Kamailio SIP trunk registration guide to connect directly.

Build voice on infrastructure you can control

Your SIP server is only as good as the carrier behind it. Telnyx unifies carrier-grade communications infrastructure with the programmable control developers need, all on a private global network Telnyx owns and operates. Connect your open-source SIP server to a carrier that runs the whole stack.

That owned network is also where Telnyx runs co-located GPU inference and voice AI, so the same carrier serving your SIP server today is the one you build AI voice agents on tomorrow. Voice is the wedge, not the ceiling.

Share on Social