SIP 487 Request Terminated means a CANCEL request reached the server before the original INVITE got a final response. Most of the time this is normal — the caller hung up before the called party answered. When it isn't, the cause is almost always a CANCEL race, a forking branch that lost, or a proxy timeout.
SIP 487 Request Terminated is defined in RFC 3261 as the response a server sends to an INVITE that was canceled before a final response was generated. It is a final response itself — an ACK is required to complete the transaction.
The most common cause is also the most innocuous: the caller hung up before the callee answered. The caller's user agent sends CANCEL, the server stops processing the INVITE, and 487 is returned to confirm the transaction was terminated.
487 only indicates a problem when:
SIP CANCEL is a request that cancels a pending INVITE transaction. The flow involves four messages:
The two 200 OK responses sometimes confuse engineers reading traces — one acknowledges the CANCEL request, the other (if it arrives) would acknowledge the INVITE. Only one of these can win. If 200 OK to the INVITE arrives before CANCEL is processed, the call connects and CANCEL is too late. If CANCEL is processed first, 487 is returned and the call never connects.
The ACK after 487 is mandatory under RFC 3261. Failing to ACK a 487 leaves the transaction in an indeterminate state and may cause the server to retransmit the 487 until its timer expires.
Forking is when a SIP proxy receives one INVITE and sends multiple copies to different destinations. The most common scenario is an extension configured to ring multiple devices simultaneously — desk phone, mobile softphone, and a backup extension all ring at once.
The flow generates multiple 487 responses by design:
Two 487 responses for one call is normal in this scenario. The pattern only suggests a problem when no winner emerges — if every branch is returning 487 without any 200 OK, something else is wrong (commonly a proxy timeout that fires before any endpoint answers).
The classic SIP race is when the callee's 200 OK and the caller's CANCEL are in flight at the same time. Both are valid messages from valid endpoints; the outcome depends on which the server processes first.
The callee's 200 OK reaches the server first. The call is considered answered. The CANCEL arrives but is too late — per RFC 3261, the proxy responds 481 Call/Transaction Does Not Exist to the CANCEL because there is no pending INVITE to cancel. The caller, having sent CANCEL, expects the call to be torn down. The caller's user agent then sends BYE to terminate the established dialog, which the callee sees as an immediate hangup after answering.
The CANCEL reaches the server first. The pending INVITE is terminated and 487 Request Terminated is returned. The 200 OK from the callee arrives next. The proxy may forward the 200 OK back to the caller anyway (since some endpoints generate it before they fully process incoming CANCEL), and the caller's user agent must respond ACK followed immediately by BYE to dismantle the dialog.
Both outcomes are correct per the protocol, but both produce a confusing user experience. Designing endpoints to handle CANCEL races gracefully is an under-tested edge case in many SIP stacks.
When investigating a 487 in a SIP trace, the answers are almost always in the timing and the message sequence. Look for:
Most 487 responses in a healthy production environment are user hangups. The signal you're looking for is a pattern — many 487s clustered around the same destination, the same proxy, or the same time window — not individual occurrences.
SIP 487 Request Terminated means a CANCEL request reached the server before the original INVITE got a final response. The server responds 487 to the original INVITE to confirm that the transaction was terminated. Most 487 responses are normal — they happen any time a caller hangs up before the called party answers.
No. SIP 487 is the expected response when a call is canceled before being answered, which is a normal user behavior. 487 only indicates a problem when it appears unexpectedly — for example, when neither party hung up, when 487 arrives without a preceding CANCEL, or when forking branches are getting CANCELed faster than expected.
SIP 486 Busy Here is sent by the called endpoint when it cannot accept the call because it is on another call or otherwise busy. SIP 487 Request Terminated is sent in response to the original INVITE after a CANCEL aborts the transaction. 486 means the callee rejected the call; 487 means the call was canceled (usually by the caller) before the callee responded.
Paste your SIP trace into SIPSymposium. The analyzer identifies CANCEL races, forking branch losses, and proxy timeouts that lead to 487 Request Terminated responses.