Post
What SIP 481 really means—and why a BYE can receive it
SIP 481 does not mean a call mysteriously disappeared. It means the device receiving a request cannot find the dialog or transaction that request refers to. When a BYE receives 481, the usual question is: which side lost, changed or never created the call state?
The formal reason phrase is Call/Transaction Does Not Exist. In day-to-day troubleshooting, it is most useful to treat 481 as a correlation failure: the request’s identifying information does not match what the receiving system has stored.
First, identify the request that received 481
| Request | What 481 commonly points to |
|---|---|
| BYE | The far end no longer has that dialog, or the BYE was sent to the wrong leg, address or device. |
| ACK | The sender may be acknowledging a response from a dialog the recipient does not recognise. |
| REFER, re-INVITE or UPDATE | An in-dialog request arrived after state expired, changed during failover, or was altered in transit. |
| SUBSCRIBE or NOTIFY | The subscription dialog identifier does not match the receiving endpoint’s state. |
Do not assume a 481 is the original failure. A phone might send BYE only after RTP stops, a timer fires or a user hangs up. The response says that particular signalling request could not be matched; the earlier event may explain why.
The dialog values to compare
For an established SIP dialog, compare the Call-ID, the local tag in From and the remote tag in To. Together, those values identify the dialog. Also compare the request URI, route set and CSeq; they help establish whether the request reached the expected system and whether it is in sequence.
A practical investigation sequence
- Locate the 481 and read the request immediately above it. Record timestamps, source and destination addresses, transport, Call-ID, tags and CSeq.
- Follow that Call-ID back to the initial INVITE and confirm that a successful final response established the dialog you expect.
- Compare the request as it enters and leaves every intermediary. Look for rewritten Call-ID values, tags, Contact addresses, Record-Route headers or routing changes.
- Search the receiving device’s trace for the same dialog identifiers. If it has already sent or received a BYE, re-INVITE failure, restart or failover event, place that earlier event on the timeline.
- Check whether the destination address was learned from an old Contact header, stale registration or DNS result. A valid-looking BYE sent to the wrong node can correctly receive 481.
Common patterns behind a BYE/481 pair
One side already cleared the call. A PBX, carrier or phone may have ended the dialog after a timeout or media watchdog event. A delayed duplicate BYE then arrives and receives 481. In this pattern, the 481 is often harmless evidence of cleanup; investigate the first disconnect instead.
Failover did not preserve dialog state. If a proxy or SBC changes nodes mid-call, the new node must know how to handle in-progress dialogs. A return request routed to a node without that state can produce 481. Check load-balancer affinity, dialog replication and Record-Route behaviour.
A NAT or routing change directs the request incorrectly. A Contact address that was reachable when the call started can become unusable or point to a different endpoint after a network change. Compare the Contact and route headers with the actual packet destination.
An intermediary changes identifiers inconsistently. B2BUAs legitimately create separate dialogs on each call leg. Problems occur when translation between those legs is incomplete, a stale mapping is reused, or only one direction passes through the stateful device.
What not to do
Do not fix a 481 by blindly increasing SIP timers or disabling every timeout. That can hide a failed transaction while leaving calls stranded. And do not compare Call-ID alone: matching Call-IDs with different tags can refer to different dialogs.
The useful outcome is a timeline showing when each system believed the dialog began and ended. Once that timeline exists, the owner of the mismatch is usually clear: endpoint, PBX, SBC, carrier edge or routing layer.
Related: SIP response codes, SIP methods and call flow, SIP headers explained and packet captures for VoIP troubleshooting.
Source: IETF RFC 3261, section 21.4.19. Scheduled for 1 September 2026. Specific PBX and SBC logging terms vary by product and software version.