SIP Load Balancer Using Hash-Based Server Affinity
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional load-balancing approaches are inadequate for Session Initiation Protocol (SIP) networks due to the unbounded nature of SIP calls, leading to potential overload and performance limitations, as they require storing context information for extended periods, which can overwhelm the load-balancer, especially with a large number of simultaneous calls and backend servers.
Innovation Solution
A load-balancing system that uses point-to-point TCP connections and a database mapping resolved IP addresses to connections, allowing for efficient routing of SIP messages by selecting the appropriate connection based on the resolved address, reducing the need for extensive context information storage and maintaining only context for newly established calls.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional load-balancing approaches store context information for all active SIP calls, then server affinity is maintained, but the load-balancer becomes overwhelmed and performance deteriorates
Solution Approach 1:
The patent segments the load-balancing functionality into two parts: (1) a load-balancer that maintains minimal context information and uses hashing to determine server selection, and (2) backend servers that maintain the actual call context information. This segmentation allows the load-balancer to maintain server affinity through consistent hashing without storing extensive context data, thereby resolving the contradiction between maintaining reliability and preserving productivity.
Solution Approach 2:
The patent introduces a hashing mechanism as an intermediary between the load-balancer and backend servers. The load-balancer uses the hashing function on message parameters (such as Call-ID, From, To) to determine which backend server should handle the message, without needing to store context information about active calls. This intermediary mechanism enables server affinity while keeping the load-balancer lightweight and high-performance.
2Stability of the object's composition
If the load-balancer stores context information for extended periods to handle unbounded SIP calls, then call continuity is maintained, but resource requirements increase and the system becomes overwhelmed
Solution Approach 1:
The patent extracts the context information storage function from the load-balancer and places it on the backend servers. The load-balancer only maintains minimal state information necessary for hashing (such as the mapping of hashed values to server identifiers), while the actual call context (call parameters, state, duration) is stored and managed by the backend servers that process the calls. This extraction resolves the contradiction by maintaining call continuity through proper routing while dramatically reducing the memory resources required at the load-balancer.
Solution Approach 2:
The patent applies preliminary hashing action on message parameters before routing decisions are made. By computing the hash value of call parameters (Call-ID, From, To) in advance, the load-balancer can determine the destination server without needing to store or search through context information about active calls. This preliminary action enables continuous call handling while minimizing resource requirements at the load-balancer.
3Reliability
If a database mapping call IDs to backend servers is maintained, then server affinity is achieved, but the complexity of the load-balancer increases
Solution Approach 1:
The patent uses a hashing function to create a compact representation (copy) of the call context that can be used for routing decisions. Instead of maintaining a full database mapping each call ID to a backend server, the load-balancer computes a hash value from the call parameters and uses this compact representation to determine the destination server. This copying approach maintains server affinity while significantly reducing the structural complexity of the load-balancer.
4Productivity
If the load-balancer processes and routes each message independently without context knowledge, then processing speed is high, but server affinity cannot be maintained
Solution Approach 1:
The patent replaces the mechanical system of context-based routing (where the load-balancer would need to store, search, and manage context information about active calls) with a mathematical hashing mechanism. The hashing function takes call parameters as input and deterministically produces a server identifier, enabling the load-balancer to route messages with server affinity while maintaining high processing speed. This substitution resolves the contradiction by achieving both fast independent processing and reliable server affinity through mathematical rather than mechanical means.
Data Source
AI summary
According to one aspect of the present invention, there is provided a method of sending, from a processing system, a message to a destination identified in the message, the destination being one of a plurality of destinations, the message being sent via an intermediate module, each of the processing system and the destinations being connected to the intermediate module by individual point-to-point connections, comprising: resolving the address of the destination identified in the message; sending the message and the resolved address across the connection to the intermediate module; and at the intermediate module, receiving the message and resolved address, selecting, based on the resolved address, through which of the point-to-point connections the message should be sent; and sending the message through the selected connection.