Session-Aware Load Balancing for SIP Telephony Servers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current load balancing techniques are inadequate for large-scale telephony applications, particularly for SIP protocols, as they fail to efficiently distribute requests across servers, leading to inefficiencies in response time and throughput due to the session-oriented nature of SIP and varying transaction overheads.
Innovation Solution
The implementation of Session-Aware Request Assignment (SARA) combined with dynamic estimates of server load and knowledge of the SIP protocol, using algorithms such as Call-Join-Shortest-Queue (CJSQ), Transaction-Join-Shortest-Queue (TJSQ), and Transaction-Least-Work-Left (TLWL), to route requests to servers based on load and response times, ensuring that transactions corresponding to the same session are directed to the same server.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If traditional load balancing techniques are used for SIP protocols, then server requests can be distributed, but response time and throughput are inefficient due to session-oriented nature and varying transaction overheads
Solution Approach 1:
The patent changes the load balancing parameters from simple request counting to weighted parameters that account for transaction overheads, response times, and session affinity. Different SIP transactions are assigned different weights based on their complexity and resource consumption, enabling more intelligent load distribution that optimizes both throughput and response time.
Solution Approach 2:
The system dynamically adjusts load balancing decisions based on real-time server state, transaction characteristics, and session information. The load balancer continuously monitors server response times and transaction outcomes, adapting its routing decisions to optimize performance under varying conditions rather than using static rules.
2Quantity of substance
If servers are scaled to support more users, then service capacity increases, but load distribution efficiency decreases without session-aware routing
Solution Approach 1:
The patent segments the load balancing process into multiple dimensions: session-based routing, transaction-type weighting, and server-state monitoring. This segmentation allows independent optimization of each aspect - maintaining session affinity for ongoing calls while distributing new transactions based on weighted criteria, thereby scaling efficiently.
Solution Approach 2:
The load balancer acts as an intelligent intermediary between clients and servers, making informed routing decisions that consider session affinity, transaction overheads, and server capabilities. This intermediary function enables efficient scaling by mediating the complexity of load distribution across the entire server pool.
3Device complexity
If all transactions are treated equally in load balancing, then implementation is simple, but performance is suboptimal due to varying transaction overheads
Solution Approach 1:
The patent applies different quality attributes to different transactions based on their type and overhead characteristics. INVITE transactions, which establish sessions and have higher overhead, are weighted differently compared to simpler UPDATE or DELETE transactions. This local differentiation optimizes processing efficiency while remaining implementable through standardized weighting rules.
Data Source
AI summary
Techniques are disclosed for load balancing in networks such as those networks handling telephony applications. By way of example, such techniques direct requests associated with calls to servers in a system comprised of a network routing calls between a plurality of callers and at least one receiver wherein a load balancer sends requests associated with calls to a plurality of servers as follows. A request associated with a call, a caller, or a receiver is received, depending on the particular load balancing technique. A server is selected to receive the request. A subsequent request is received. A determination is made whether or not the subsequent request is associated with the call, the caller, or the receiver, depending on the particular load balancing technique. The subsequent request is sent to the server based on determining that the subsequent request is associated with the call, the caller, or the receiver, again depending on the particular load balancing technique.