B2BUA vs SIP Proxy

1. Definitions

SIP proxy

A SIP intermediary that receives requests, makes routing decisions, and forwards them. RFC 3261 defines proxy behavior precisely — proxies can modify certain headers (Via, Record-Route, Route, Max-Forwards) but must not modify others (From, To, Call-ID, CSeq). A proxy stays in the signaling path but is transparent to dialog state.

B2BUA

A back-to-back user agent. Two complete UAs glued together. The first UA receives an INVITE as a UAS, terminates the dialog, and the second UA originates a new INVITE as a UAC to the next hop. Two separate dialogs exist, with the B2BUA in the middle of both.

The two dialogs share Call-ID-related state at the application level (the B2BUA knows they are the same logical call) but are independent at the SIP level. They can have different Call-IDs, different From/To tags, different SDP, different codecs.

2. How a SIP proxy works

When a proxy receives a request, it:

1. Validates the request and checks Max-Forwards
2. Decrements Max-Forwards
3. Adds itself to the Via header (so responses know how to come back)
4. Optionally adds a Record-Route header (to stay in the path for in-dialog requests)
5. Determines the next hop (registration lookup, routing table, ENUM, etc.)
6. Forwards the request to the next hop

For responses traveling back, the proxy:

1. Pops its own Via
2. Forwards to the address indicated by the next Via

The proxy never generates its own SIP messages (except for failure responses if no route exists). It does not change Call-ID, From, To, CSeq, or Contact in normal operation. Both endpoints see the actual identifiers from each other.

A stateful proxy (most common) keeps transaction state to handle retransmissions correctly. A stateless proxy (rare) just forwards messages without state, relying on UDP retransmission semantics.

3. How a B2BUA works

When a B2BUA receives an INVITE on one leg, it:

1. Acts as a UAS for the incoming dialog — sends 100 Trying, processes SDP, eventually sends 200 OK
2. Decides what to do with the call (route, transcode, anchor media, etc.)
3. Acts as a UAC and originates a new INVITE on the outgoing leg, with potentially different Call-ID, From, To, SDP, and codec
4. Bridges responses between the two legs — mapping a 200 OK on one leg to a 200 OK on the other
5. Maintains both dialogs independently, including all timers and refresh logic

For mid-dialog requests, the B2BUA can map them across legs (a re-INVITE on one leg may produce a re-INVITE on the other) or handle them locally on one leg without propagating.

The flexibility comes at a cost: the B2BUA is responsible for two complete SIP state machines. Bugs in either side affect the call. Many subtle interop issues come from B2BUAs that handle one direction correctly and the other slightly differently.

4. Side-by-side comparison

5. Real-world deployments

Kamailio and OpenSIPS as proxies

These platforms operate primarily as SIP proxies with optional B2BUA modules. Used for routing, load balancing, registration, and high-throughput message processing. The proxy-style operation scales to millions of registered subscribers and is the foundation of most carrier-grade SIP infrastructure.

Asterisk and FreeSWITCH as B2BUAs

These are application servers, not proxies. Every call traverses two complete SIP legs. Provides flexibility (transcoding, recording, IVR, mixing, conference bridging) at the cost of higher per-call resource use. Typical deployments handle hundreds to thousands of concurrent calls.

SBCs as B2BUAs

Almost every SBC is a B2BUA. AudioCodes, Ribbon, Oracle ACME, Sansay, Cisco CUBE — all terminate and re-originate dialogs. This is what enables topology hiding, header normalization, transcoding, fraud detection, and the SIP/RTP interop SBCs are bought for.

Hybrid platforms

Many platforms blur the line. A Kamailio-Asterisk pair often runs Kamailio as the front-end proxy for registration and routing, then forwards specific traffic to Asterisk as a B2BUA for application logic. From the endpoint's perspective, the path looks like: phone → Kamailio (proxy) → Asterisk (B2BUA) → carrier. The proxy sees the same dialog throughout; the B2BUA splits it.

6. Identifying each in a trace

The signal in a trace:

• Same Call-ID across the path: A proxy is in the path. The same dialog is being forwarded.
• Different Call-IDs on either side of an intermediary: A B2BUA. Two dialogs, one bridged to the other.
• From and To headers identical end-to-end: Proxy.
• From and To rewritten: B2BUA. The intermediary may rewrite display names, URIs, or even tags.
• Via header chain matches the path: Proxy. Each hop adds a Via.
• Via headers reset at the boundary: B2BUA. The new dialog starts fresh.
• Record-Route headers: Indicate proxies that want to stay in the dialog. Some B2BUAs add Record-Route on each leg, but they are different Record-Routes for different dialogs.
• SDP rewriting: A proxy never rewrites SDP. A B2BUA can change codecs, IPs, ports, and a=crypto lines.
• Mid-dialog request mapping: If a re-INVITE on one side does not produce a re-INVITE on the other, a B2BUA is handling it locally.

The most reliable indicator is Call-ID continuity across the intermediary. If the Call-ID changes at the box, it is a B2BUA. If it does not, it is a proxy.

Frequently asked questions

What is the difference between a SIP proxy and a B2BUA?

A SIP proxy forwards SIP messages between endpoints with minimal modification — it cannot change Call-ID, From, To, CSeq, or SDP. The same dialog passes through. A B2BUA (back-to-back user agent) terminates the incoming dialog and originates a separate outgoing dialog, with potentially different Call-ID, From/To tags, SDP, and codecs on each side. Two dialogs exist, bridged at the application layer.

Are SBCs proxies or B2BUAs?

Almost all SBCs are B2BUAs. Terminating and re-originating dialogs is what enables topology hiding, SIP header normalization, transcoding, media anchoring, and fraud detection. Examples: AudioCodes Mediant, Ribbon SBC Edge, Oracle ACME Packet, Cisco CUBE, Sansay VSXi. Some can operate in proxy mode for specific use cases but their primary role is as B2BUAs.

How do I tell from a SIP trace whether a proxy or B2BUA is in the path?

Look at Call-ID continuity across the intermediary. If Call-ID is identical end-to-end, a proxy is forwarding. If Call-ID changes at the intermediary, a B2BUA is in the path with two separate dialogs. Other clues: From/To rewriting, SDP modification, Via chain reset, and re-INVITE mapping behavior all indicate B2BUA presence. A proxy preserves all dialog identifiers; a B2BUA replaces them.