The SIP load balancer is provisioned with a set of rules to determine where to forward a new initiated SIP session. Once a destination is assigned, it will make sure that all the following SIP messages including the same Call-ID Header are forwarded to the same destination. This is ideal to have a single entry point for SIP traffic into a workload and distribute traffic across multiple SIP-based microservices.
Load balancers are most commonly coming as a part of the kubernetes cluster in a form of ingress controller or as part of the cloud infrastructure in various forms. While these perform perfectly for UDP/TCP/HTTP type of traffic, we sometimes need more telecom protocols aware load balancers to properly distribute the telecom control plane within a workload. Slicce load balancers come to fulfill this need when the generic load balancer of the infrastructure is not able to load balance a specific telecom protocol.
In particular and focus on calls over packet switched networks, the SIP Load balancer facilitate:
When using load balancing based on any of the initial INVITE SIP Header, the system intelligently distributes calls among a set of services based on the header of choice (most typically To header). This brings the ability to segragate the services in the workload to differente Stateful or Stateless sets depending on the application. Once a call has been picked up by one service, the load balancer will ensure that following messages related to a same call are directed to the appropriate service. Using round-robin, least connections, or other algorithms to balance load, it ensure that requests for a specific call are sent to the service or stateful set best suited to handle that call. This to empower the workload with efficient scaling.
Traffic Routing Based on SIP header
The SIP Load Balancer can distribute traffic towards a same SIP Header between multiple service instances of a same kind. In which case it can automatically detects a failing service and assure service continuity via remaining service instances. The service set can be elastic or auto-scaled since the load balancer will allow traffic distribution to new instances of the service immediately. It is also possible for an external orchstrator to orchestrate the load balancer via REST API in case the toplology of the workload is getting updated.
Automatic failover with API Orchestration
| Software packaging | Docker image, RPM or DEB package. |
| SIP | 3GPP TS.24.229 IMS SIP extensions TISPAN ES 283 003 IMS extensions IETF RFC 3266 support for IPv6 in SDP IETF RFC 3261 (Session Initiation Protocol – SIP) IETF RFC 3262 (Reliability of Provisional Responses in SIP) IETF RFC 3263 (Locating SIP Servers) IETF RFC 2327 (Session Description Protocol – SDP) IETF RFC 3264 (An Offer/Answer Model with SDP) IETF RFC 3265 (SIP Specific Event Notification) SIP security agreement IETF RFC 3455 Private headers |
