SIP 481 Call/Transaction Does Not Exist is one of the most confusing SIP responses. The call appeared to connect, but then a BYE, re-INVITE, or INFO request comes back with 481. Here's why the dialog went missing and how to fix it.
SIP 481 Call/Transaction Does Not Exist is defined in RFC 3261 Section 21.4.18. It means a server received a request that references a dialog (via Call-ID, From tag, and To tag) that the server doesn't have in its dialog table. The dialog either never existed on that server, was already terminated, or the server restarted and lost its state.
481 is very common after blind and attended transfers. During a transfer, the original dialog is replaced by a new dialog (via REFER or re-INVITE). If the original dialog isn't properly terminated before the new one is established, or if the transferee sends a BYE to the original dialog after it's been replaced, 481 results.
In the trace, look for the REFER or re-INVITE that initiated the transfer, then check whether the original dialog's BYE was sent and acknowledged before the endpoint sent any messages on the transferred call.
Find the 481 in your trace. Note the Call-ID and tags in the request that received the 481. Search backwards in the trace for the original INVITE with the same Call-ID — did it ever complete? Was there a BYE before this request? Was there a server restart or failover between the INVITE and this request?
If the Call-ID in the 481 response matches an active call that you believe should still be up, the server has lost dialog state — check server logs for restarts, crashes, or memory pressure events.
Server restarts: Implement high-availability SIP deployments that persist dialog state across restarts. For Kamailio/OpenSIPS use shared memory or database-backed dialog modules. For Asterisk, use ASTDB or external state storage.
Route set issues: Ensure your UA stores the complete Record-Route header set from the initial dialog and includes it (reversed) as Route headers in all mid-dialog requests.
B2BUA state management: Configure your B2BUA to keep both legs alive until both sides have sent BYE. Don't terminate the server leg before the client leg has completed its BYE/200 exchange.
Dialog timeout: Increase dialog state timeout on proxies and SBCs to cover your longest expected calls plus a safety margin.
SIP 481 means the server received a mid-dialog request (BYE, re-INVITE, INFO) but has no matching dialog in its state table. The dialog either never existed on that server, was already terminated, or the server restarted and lost its in-memory dialog state.
SIP 481 after a transfer happens when the original dialog is not properly terminated before the new dialog is established. During REFER-based transfers, the original dialog must be cleanly ended with a BYE before the transferee sends any messages on the new dialog.
After a server restart, active calls lose their dialog state. The fix is to implement state persistence — for Kamailio use database-backed dialog modules, for Asterisk use ASTDB. Alternatively, implement a graceful restart procedure that allows active calls to complete before the server restarts.
Paste your SIP trace into SIPSymposium. The analyzer identifies dialog state issues, checks Route set integrity in mid-dialog requests, and detects B2BUA state mismatches.