Locate the response family
- 1xx ProvisionalRequest is progressing
- 2xx SuccessRequest succeeded
- 3xx RedirectionAnother destination
- 4xx Request failureInterpret this request487 belongs here
- 5xx Server failureServer could not fulfil
- 6xx Global failureFailure across destinations
Read the status with its request method and call leg. For example, 200 after REGISTER confirms a binding; it does not prove an INVITE succeeded.
Bind 487 to the original transaction
RFC 3261 defines 487 as the termination of the request identified by the response. For an INVITE, preserve the Request-URI, Call-ID, CSeq number, Via branch, tags, response source and exact leg. The 487 is a final response to the INVITE and is acknowledged with ACK; it is never the response code for the CANCEL transaction itself.
Keep the separate 200 OK to CANCEL beside the 487 to INVITE. A dashboard that displays only one status can hide that two transactions completed. If a PBX or B2BUA created another leg, correlate its channels without assuming that the same Call-ID, branch or cancellation owner crosses the boundary.
Find the matching CANCEL or termination event
A user abandoning a ringing call, a proxy cancelling losing fork branches, a PBX dial timeout and an INVITE Expires interval can all precede 487. RFC 3261 also recommends 487 for pending requests when a dialog participant has sent BYE. Record the first event that caused cancellation rather than treating the later final response as the initiating fault.
A matching CANCEL carries the same Request-URI, Call-ID, From, To, numeric CSeq and top Via value as the request it cancels, while its CSeq method is CANCEL. Use those fields to prove the pairing. A CANCEL cannot reverse a final response that was already generated, so preserve timing when answer and cancellation race.
Separate ordinary abandonment from an unexpected policy
A 487 after the caller hangs up before answer is normally protocol cleanup, not evidence of a trunk outage. In a forked call, one accepted branch can cause a proxy or application to cancel the still-pending branches. Count the user-visible attempt once, then retain branch-level outcomes for troubleshooting.
Investigate further when the call is cancelled earlier than the documented ring window, by the wrong application, or without the expected user action. Compare the application timeout, queue or hunt policy, INVITE Expires, intermediary timer and PBX dial timeout with the actual timestamp. Do not lengthen every timer until the cancellation owner is known.
Handle answer-and-CANCEL races correctly
If a 2xx response to INVITE crosses a CANCEL, the accepted dialog still requires ACK and then BYE if it is to be ended. A late successful answer is not converted into 487 merely because cancellation was in progress. Likewise, retransmitted requests or responses do not prove a new user action.
Test a deliberate caller abandonment, a normal answer, an unanswered timeout and any forked-answer workflow. Preserve the final response on every branch and confirm that no accepted dialog remains orphaned. For Asterisk, use the focused PJSIP 487 investigation to separate endpoint-facing and provider-facing cancellation evidence.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: CANCEL processing ↗
- IETF RFC 3261: 487 Request Terminated ↗
- IETF RFC 5407: SIP race-condition call flows ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.