Standby Call Processor Failover Error Handling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In Next Generation Networks (NGNs), stable calls can be prematurely terminated during failover due to the lack of call state information in standby call processors, leading to processing overhead and potential data loss, especially across less reliable networks.
Innovation Solution
Implementing a non-call terminating error response message by standby call processors when call state information is not found, allowing the call to continue without terminating the dialog, thereby avoiding the need for real-time replication of call state information.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If call state information is replicated in real-time from primary to standby call processors, then the standby call processor can handle signaling requests after failover, but this introduces major processing overhead and is impractical on large NGNs
Solution Approach 1:
The patent extracts only the essential call state information needed for failover handling rather than replicating all call state information. The standby call processor is equipped with minimal necessary data to handle critical signaling requests, eliminating the major processing overhead associated with full real-time replication while maintaining sufficient reliability for call stability.
2Reliability
If all call state information is replicated across the network, then the standby call processor has complete information, but call state information can be lost during replication especially across less reliable communications networks
Solution Approach 1:
The patent extracts only the critical call state information necessary for failover operation rather than replicating complete call state data. This selective approach reduces the risk of information loss during network transmission, especially across less reliable communication networks, while still providing the standby call processor with sufficient information to maintain call stability.
3Measurement precision
If the standby call processor returns an error when call state information is not found, then the error response indicates the problem, but stable calls are mistakenly and prematurely torn down
Solution Approach 1:
The patent applies different response qualities based on the specific signaling request type. For in-dialog requests where call state information is not found, the standby call processor returns a non-call-terminating error response that preserves the call. For other request types, traditional error responses are used. This localized differentiation allows accurate error detection while preventing premature call termination.
Solution Approach 2:
The patent changes the error response parameter from a traditional call-terminating error code to a non-call-terminating error code when call state information is not found for in-dialog requests. This parameter change allows the error to be communicated accurately while the call stability is maintained, resolving the contradiction between error detection precision and call reliability.
Data Source
AI summary
According to one method for preserving stable calls during failover, during a dialog between two user endpoints, a determination is made whether a standby call processor has become operational, such as when a corresponding primary call processor is in fault. Responsive to determining that the standby call processor has become operational, a signaling protocol message is received from a requester. A determination is made whether the message includes an in-dialog signaling protocol request. Responsive to determining that the message includes the in-dialog request, a determination is made whether a call state associated with the dialog is found in memory. Responsive to determining that the call state associated with the dialog is not found in memory, a non-call terminating error response is made responding to the in-dialog request. The non-call terminating error response may cause the requester to terminate the in-dialog request but not terminate the dialog.