MGCP Keep-Alive Fallback via Virtual Endpoint
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing MGCP fallback mechanism in VoIP networks violates standard protocol requirements, leading to potential endpoint disablement and unintended consequences due to non-standard use of NTFY commands and incorrect handling of 'disconnected' states, which can result in service failures.
Innovation Solution
A compliant messaging mechanism using a virtual endpoint and MESG command format is introduced to send keep-alive messages, allowing for a fallback to a secondary call control protocol like H.323 or SIP when the primary call agent is unresponsive, ensuring interoperability and adherence to RFC 3435 standards.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the existing MGCP fallback mechanism uses non-standard NTFY commands without associated RQNT commands, then the gateway can detect call agent unavailability and switch to fallback state, but the call agent may disable endpoints or fail normal processing due to protocol violations
Solution Approach 1:
Instead of using the standard RQNT-NTFY request-response pattern, the patent inverts the approach by using periodic NTFY commands as keep-alive messages without requiring prior RQNT commands. This non-standard usage allows the gateway to proactively monitor call agent availability while avoiding the disconnect state that would result from standard protocol expectations.
Solution Approach 2:
The patent changes the operational parameters of the NTFY command by removing the requirement for an associated RQNT command and using it purely as a periodic keep-alive message. This parameter change enables the gateway to detect call agent unavailability through lack of responses while preventing the protocol from interpreting these as disconnect requests.
2Reliability
If periodic NTFY commands are sent to detect call agent availability, then the gateway can maintain awareness of call agent status, but the gateway may enter the 'disconnected' recovery state which requires special non-standard processing to avoid
Solution Approach 1:
The patent introduces a virtual endpoint as an intermediary that receives the periodic NTFY keep-alive commands. This virtual endpoint acts as a buffer that prevents the real endpoints from entering the disconnected state, allowing the gateway to monitor call agent availability without triggering protocol-defined disconnect recovery procedures.
3Adaptability or versatility
If the gateway uses the 'all-of' wildcard (*) when sending NTFY commands, then the gateway can send notifications to all endpoints, but this is explicitly forbidden in MGCP and may cause further unintended consequences
Solution Approach 1:
The patent creates a universal virtual endpoint that serves multiple functions: it receives periodic NTFY keep-alive commands, prevents disconnect states for all real endpoints, and enables call agent availability detection. This single virtual endpoint replaces the need for wildcard broadcasting to multiple endpoints, achieving the same monitoring goal while adhering to MGCP protocol requirements.
Data Source
AI summary
A mechanism provides for communication of “keep-alive” messages from clients to servers in a packet telephony network environment. The servers may be call agents and the clients may be gateways or MGCP-controlled IP phones. A client (e.g., gateway) registers a virtual endpoint. Upon a period of inactivity in which the client does not receive any commands or acknowledgments from an assigned server (e.g., call agent), the client starts to send keep-alive messages periodically to the server. The keep-alive message may include an endpoint identifier that identifies the registered virtual endpoint. If the server fails to respond to the keep-alive messages after a period of time, the client initiates a fallback mechanism from a first call control protocol (e.g., MGCP) to a second call control protocol (e.g., H.323 or SIP), to provide call control handling using a default application. The keep-alive messages may be sent to other servers among the plural servers that are configured to operate with the client before determining whether to initiate the fallback mechanism. During the fallback state, the keep-alive message may be sent periodically until a response is received from the server. Communications with the assigned server may be reestablished thereupon based on the first call control protocol.