SIP Load Balancer
SIP-LB is the SIP-layer counterpart to Slicce's signalling load balancer family — SS7-LB for SIGTRAN/SCCP, DMT-LB for Diameter, GTP-LB for GTP-C. It sits between SIP originators and a pool of SIP destinations — softswitches, IMS core elements, or application servers — distributing and routing session signalling across them from a single multi-client/server node, administered over a REST API rather than through per-peer configuration on every downstream element.
Features & Benefits
Multi-client/server SIP routing from one node
Following the pattern set by SS7-LB and DMT-LB, SIP-LB terminates SIP signalling from multiple originators and routes each dialog to the right destination from a single instance, rather than requiring point-to-point trunking between every client and every server.
Routing by realm-equivalent identifiers
Where DMT-LB routes Diameter traffic by realm and GTP-LB by IMSI/APN, SIP-LB routes calls by Request-URI, domain, or a configurable dial-plan table — one routing layer instead of per-destination configuration on each originator.
REST administration,
not box-by-box configuration
Peers, routing rules and service state are managed through the same kind of REST admin API already exposed by SS7-LB and DMT-LB, so SIP routing changes are an API call rather than a maintenance window on a softswitch.
Consistent operability across the signalling estate
CDR, audit and alarm logging, and SNMP traps for link and peer state, follow the same format already used across the Slicce load balancer family, so SIP traffic is observable through the same tooling as SS7, Diameter and GTP.
Route SIP signalling across multiple destinations from one node
The SIP counterpart to SS7-LB, DMT-LB and GTP-LB, entirely inside the operator domain
Deployed between SIP originators (PBXs, application servers, other network elements) and a set of SIP destinations, SIP-LB terminates signalling from each originator and routes each dialog to the appropriate destination based on its routing table, administered over REST rather than through per-peer configuration.
SIP Processing Modes
SIP-LB's role would not be fixed to one behavior — the way SS7-LB can be configured as IPSP, ASP or SGW depending on the association, SIP-LB is intended to take on a different one of four RFC 3261 roles per route or per peer rather than committing to a single one for the whole deployment. Three of them route calls with progressively more state and control; the fourth, the registrar, underpins the other three by keeping track of where each subscriber currently is.
Stateless Proxy
No transaction table — each message routed independently, endpoints own retransmission and forking
Per RFC 3261 §16.11, a stateless proxy forwards each SIP request or response using only the information in that single message plus its routing rules — it retains no memory of the transaction once the message is forwarded, and reconstructs nothing from prior messages if a retransmission arrives. That absence of per-transaction state is what makes it cheap: no transaction table, no timers, no per-call resource ceiling — the closest SIP equivalent to how SS7-LB routes SCCP or DMT-LB routes Diameter by realm, without holding session state. The tradeoff is that a stateless proxy can't reliably retransmit on a client's behalf, can't fork a request to several destinations and reconcile the responses, and can't match a CANCEL to the INVITE it's meant to cancel — reliability and forking are pushed back onto the endpoints. This mode fits high-volume, pure routing traffic where the endpoints themselves already handle SIP timers correctly.
Stateful Proxy
Request forked to a pool of candidate peers — best response kept, other branches cancelled
A stateful proxy keeps RFC 3261 §17 transaction state for as long as a request is outstanding — one state machine per client transaction, one per server transaction it creates toward each candidate destination. That state is what lets it retransmit reliably over UDP, fork a request to multiple destinations in parallel or in sequence, pick the best response when several come back, and cancel the branches it didn't choose. For a product carrying "load balancer" in its name, this is the mode that does the actual balancing: a pool of destinations behind one route, with SIP-LB — not the originator — deciding which one gets each call and retrying another if the first doesn't answer. It costs more per call than a stateless proxy (a transaction table sized to concurrent call attempts, not concurrent calls), but it's what makes peer failover and distribution SIP-LB's responsibility rather than something every originator has to implement for itself.
Call-Stateful (B2BUA)
Call state correlated, dialogs independent
A back-to-back user agent, as characterized in RFC 7092, goes a step further than a stateful proxy: instead of relaying one dialog, it terminates the incoming leg as a UAS and originates an entirely independent outgoing dialog as a UAC, holding full call state — not just transaction state — on both sides for the life of the call. Nothing about the two legs has to match: SIP-LB could re-anchor headers, change identifiers, or keep a call up on one leg while the other renegotiates, in a way a proxy — which only relays what it's given — cannot. That control comes at the highest per-call cost of the four modes, and it puts SIP-LB explicitly in the signalling path of every call rather than as a pass-through router. This is the mode that matters when the operator's own topology needs to stay hidden from the far end, or when a call needs to survive a change a plain proxy couldn't paper over.
Registrar
Registration feeds the same binding table a proxy or B2BUA consults when routing
A registrar, per RFC 3261 §10, doesn't route calls at all — it accepts REGISTER requests and maintains the binding between a subscriber's address-of-record and the contact URI (or URIs) where they're currently reachable, typically authenticating each registration against the operator's own subscriber directory. That binding table is what the other three modes consult before they can do anything: a stateless or stateful proxy routing "to" a subscriber, or a B2BUA originating a leg "to" one, both need an answer to "where is this AOR right now" first. Run alongside a proxy mode rather than instead of it, a registrar is what turns SIP-LB's routing table from a static peer list into one that follows endpoints as they register, re-register and expire.
Technical specifications
REST Admin API
Slicce internal (pattern shared with SS7-LB / DMT-LB / GTP-LB)
SIP
Softswitch / IMS core / SIP application servers
IETF RFC 3261
SIP over TCP / TLS
IETF RFC 3261, RFC 8446
SIP over UDP
IETF RFC 3261
Architecture
Pattern inferred from the SS7-LB, DMT-LB and GTP-LB siblings — no dedicated SIP-LB architecture document
Ask us about our load balancers?
When and how to use a telecom protocol aware load balancer to optimize a workload.
Get in touch!