Keywords: SIP protocol | 487 response code | VoIP communication
Abstract: This paper explores the meaning, triggering mechanisms, and practical applications of the SIP 487 response code "Request Terminated". Based on RFC 3261 standards, it analyzes the role of 487 responses in key processes such as CANCEL request handling and BYE message interactions, with code examples illustrating its implementation in VoIP systems. The discussion also covers the relationship between 487 responses and user/application behaviors, providing theoretical guidance for SIP development and troubleshooting.
Introduction
The SIP protocol, as a core standard for VoIP communication, defines a rich set of response codes to handle various session control scenarios. Among them, the 487 response code "Request Terminated" plays a crucial role in session management. This paper systematically examines the technical aspects of 487 responses from multiple dimensions, including protocol specifications, triggering mechanisms, and implementation examples.
Protocol Definition of 487 Response Code
According to RFC 3261, the 487 response code indicates "Request Terminated", with its core meaning being that a previous request was terminated due to user or application action. This response is not limited to specific request types but applies to various session control scenarios. In the protocol text, Section 15.1.2 on UAS behavior explicitly states that when handling BYE messages, the UAS must respond to all pending requests in the dialog and is recommended to generate a 487 response. For example, in code implementation, when a session termination event is detected, the response status can be set to 487: response.setStatusCode(487);.
Analysis of Main Triggering Scenarios
The most common triggering scenario for 487 responses is the handling of CANCEL requests. When a client sends a CANCEL for an INVITE request that has not yet received a final response, the server typically returns a 487 response to confirm that the original request has been terminated. This mechanism ensures clear synchronization of session states. The following pseudocode illustrates the core logic of this process: if (request.getMethod().equals("CANCEL")) { sendResponse(487, "Request Terminated"); }.
Additionally, 487 responses are applicable to other termination operations initiated by users or applications. For instance, in a multi-party conference, when the host actively ends the conference, the system may send 487 responses to all participants. This flexibility makes the 487 response an essential tool for handling abnormal or proactive termination scenarios.
Implementation Details and Best Practices
In practical development, proper handling of 487 responses requires consideration of dialog state management. After sending a 487 response, the UAS should ensure that related resources are released and the internal state machine is updated. The following example demonstrates a simple Java-based implementation: public void handleTermination() { terminatePendingRequests(); sendResponse(487); cleanupDialog(); }. Developers should also note the distinction between 487 responses and errors like 408 Request Timeout, with the former emphasizing active termination and the latter involving network timeouts.
Complementing with Answer 2, the 487 response in CANCEL flows ensures timely abortion of call establishment, avoiding resource wastage. In real-world networks, this mechanism is crucial for improving system efficiency and user experience.
Conclusion
The 487 response code, as a vital component of the SIP protocol, embodies the flexibility and reliability of session control. By deeply understanding its triggering mechanisms and implementation methods, developers can build more stable VoIP systems and quickly identify root causes during troubleshooting. Future evolution of the SIP protocol may further expand the application of 487 responses in new communication scenarios.