SIP 487 Request Terminated

The sequence that produces a 487

The canonical exchange looks like this, read from the caller's side:

INVITE   -->
         <--  100 Trying
         <--  180 Ringing
CANCEL   -->
         <--  200 OK                  (answers the CANCEL)
         <--  487 Request Terminated  (answers the INVITE)
ACK      -->

Two transactions are being closed at once, and that is the part that trips people up when they read a trace. The CANCEL is its own hop-by-hop transaction: every proxy in the path answers it with its own 200 OK and issues a fresh CANCEL downstream. That 200 OK says only "I heard you". The 487 is the final response to the original INVITE — that is the "I did it" — and because it is a non-2xx final response, the ACK it triggers is also generated hop by hop by the transaction layer, not end to end. Three messages come back for one hang-up, and none of them is bad news.

RFC 3261 section 9 sets the rules: a client must not send CANCEL until at least a provisional response has arrived (otherwise the CANCEL can race its own INVITE), and a UAS that receives a CANCEL for an INVITE it has not yet answered should answer that INVITE with 487. If the UAS had already sent its final response, the CANCEL changes nothing — a case that matters below.

Who cancelled, and why

A human gave up

The bulk of all 487s. The phone was ringing, nobody picked up, the caller stopped waiting — or realised they had dialled the wrong number. The tell is ragged timing: CANCELs at 8, 14, 23 seconds after the INVITE, with a 180 in between. Humans are irregular.

A timer fired

Dial(PJSIP/100,20) in Asterisk sends a CANCEL at exactly 20 seconds and moves on to voicemail; the phone that was ringing returns 487 and the CDR reads NO ANSWER. Every PBX, SBC and application server has an equivalent no-answer or ring-timeout timer. Machines are exact: 487s landing at precisely 20.0 or 30.0 seconds after the INVITE, call after call, are a configured timer, not a person.

A fork was tidied up

Simultaneous ring, shared-line appearances, desk-phone-plus-mobile-app twinning — all of it is parallel forking, and forking is a race with exactly one winner. The moment one branch answers with a 200 OK, the proxy cancels every other branch, and each of them dutifully returns 487. A polite implementation marks these CANCELs with Reason: SIP;cause=200;text="Call completed elsewhere" (RFC 3326), which many phones use to keep the abandoned branches out of the missed-calls list. A user with a desk phone, a softclient and a mobile app generates two 487s for every call they answer. Piles of these are health, not disease.

A transfer, pickup or dialer moved on

Directed call pickup grabs a ringing call and the original branch gets cancelled. A queue ringing several agents cancels the losers when one accepts. An attended transfer that completes cancels whatever was still ringing. Predictive dialers cancel calls when no agent frees up in time — and a flood of INVITE→CANCEL pairs with sub-10-second lifetimes is exactly the shape carriers' fraud and abuse systems watch for.

When a 487 is a symptom

Abandonment caused by post-dial delay. If the CANCELs come four to eight seconds after the INVITE and no 180 or 183 ever arrived in between, callers were listening to dead air and gave up. The 487s are innocent; the missing ringback is the finding. Measure INVITE-to-first-provisional per call across the trunk — a pile of 487s is often a PDD complaint wearing a polite status code.

The answer race. Sometimes the 200 OK and the CANCEL cross on the wire. Per RFC 3261, a CANCEL that arrives after the final response has no effect: the call is answered whether the caller still wants it or not, and the caller's UA must ACK the 200 and immediately send BYE. In the field this looks like zero-duration answered calls in the CDR — which get billed, and disputed — or a callee who picks up to dead air. Twinning to mobiles makes the race routine, because the mobile carrier's voicemail "answers" the forked branch at almost the same moment the caller or the proxy gives up on it.

Retransmitted 487s. The UAS retransmits its 487 until the hop-by-hop ACK arrives, and gives up when Timer H (64 × T1 = 32 seconds by default) expires. A trace with the same 487 repeated every few hundred milliseconds is not a cancellation problem at all — the ACK is being lost on the return path, which is a NAT or routing finding. See the retransmissions page for the ladder itself.

487 vs 486 vs 480 vs 408

The four codes people conflate under "the call didn't happen" differ in who made the decision:

• 486 Busy Here — the callee's device decided. The user was there and busy, or pressed decline.
• 480 Temporarily Unavailable — the far end or its proxy decided the user cannot be offered the call right now: unreachable, DND, no registered contacts.
• 408 Request Timeout — nobody decided anything; a local timer (usually Timer B at 32 seconds) filled the silence.
• 487 — the calling side decided. The callee merely filed the paperwork.

That direction matters when you are assigning blame from statistics. Most CDR tools bucket 487 under NO ANSWER, which is fair for a ring-timeout cancel and wrong for a fork tidy-up: count raw 487s as failures and your "failure rate" climbs with every simultaneous-ring user you add, while the users themselves are perfectly happy.

What to check in the trace

1. Pair the 487 with its CANCEL, and establish who minted the CANCEL. On a multi-vantage capture, the leg where it appears first is the author; a CANCEL on the egress leg with no matching CANCEL on the ingress leg was created by the box in the middle, and its timer is the story.
2. Measure INVITE-to-CANCEL, and note whether a 180/183 arrived in between. Ragged intervals after ringing are humans. Identical intervals to the decimal are timers. Short intervals with no provisional at all are post-dial delay.
3. Read the Reason header on the CANCEL. SIP;cause=200 with "Call completed elsewhere" is a healthy fork. A Q.850 cause means a gateway is relaying a PSTN-side release — the caller hung up on the other network.
4. Look for a 200 OK to the INVITE near the CANCEL. If the answer won the race, confirm the ACK and immediate BYE followed, and check whether a zero-duration answered call reached billing.
5. Check whether the 487 is retransmitted. If it repeats, the ACK is not getting back — chase the return path, not the cancellation.
6. In a forked call, count the branches. One 200 OK and N−1 487s is the healthy shape. N 487s and no 200 anywhere means nobody answered, and the interesting question becomes how long the caller was left ringing before something gave up.