SIP Proxy Queue Filtering for Provisional Response Bursts
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing SIP systems face challenges in handling bursts of provisional responses, leading to queue overflow and loss of important responses due to potential DDoS attacks, which disrupt communication and impact system performance.
Innovation Solution
Implement a proxy server with a message queue that uses response identifiers, such as SDP values, to filter out duplicative responses and manage bursts by starting a queue timer to drop incoming responses during trigger events.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Stability of the object's composition
If a message queue is used to store incoming SIP responses, then responses can be processed in order, but the queue may become full during bursts of responses causing important messages to be dropped
Solution Approach 1:
The patent changes the parameter of queue management by introducing response identifier comparison and selective dropping. Instead of simply adding all responses to the queue, the system compares response identifiers (such as CSeq numbers) to detect duplicates and selectively drops duplicative responses, thereby preventing queue overflow while maintaining reliability of important message delivery
Solution Approach 2:
The patent applies the principle of discarding unnecessary elements (duplicative responses) while recovering and keeping useful elements (unique responses). By identifying and discarding duplicate responses based on response identifiers, the system prevents queue overflow without losing important unique responses, thus resolving the contradiction between queue stability and response delivery reliability
2Reliability
If all incoming SIP responses are queued without checking for duplicates, then no responses are lost, but system performance degrades during DDoS attacks with bursts of duplicative responses
Solution Approach 1:
The patent changes the processing parameter by introducing response identifier comparison before queuing. Instead of uniformly processing all responses, the system evaluates each response's identifier against previously seen identifiers and selectively processes only unique responses, thereby maintaining reliability while improving performance during attack scenarios
Solution Approach 2:
The patent extracts and removes duplicative responses from the incoming stream before they can degrade system performance. By taking out only the necessary unique responses and filtering out duplicates, the system maintains reliable delivery of important messages while preventing performance degradation during bursts of duplicative responses
3Reliability
If response identifiers are compared for every incoming response, then duplicative responses are filtered, but processing time increases
Solution Approach 1:
The patent applies partial action by comparing response identifiers selectively rather than performing full response processing for every incoming message. The system performs a lightweight identifier comparison (partial action) to filter duplicates, avoiding the need to fully process every response, thus maintaining reliability while minimizing time loss
Solution Approach 2:
The patent performs preliminary action by comparing response identifiers before adding responses to the queue. This preliminary check filters out duplicates early in the processing pipeline, preventing unnecessary queue operations and reducing overall processing time while maintaining reliable duplicate filtering
Data Source
AI summary
Various embodiments of the present technology generally relate to systems and methods for provisional response handling in session initiation protocol (SIP) calls, to maintain performance during directed denial of service (DDoS) attacks or bursts of response messages. A proxy server for SIP calls may initiate processing of a first SIP response, receive a second SIP response, and add the second SIP response to a message queue. The proxy server may then receive a third SIP response having a response identifier, compare the response identifier to responses in the message queue, and drop the third SIP response based on the response identifier matching a response in the message queue.