SIP 481 Call/Transaction Does Not Exist
The request matches no existing dialog or transaction.
4xx Client failure · RFC 3261 · Answer to OPTIONS: Up. It rejected the request.
What SIP 481 means
A 481 means the server received a request that should belong to an existing dialog or transaction, and it has no record of one. Dialogs are matched on the Call-ID and the From and To tags, so any change to those, or any loss of state on the server, produces a 481.
You see 481 most on BYE, re-INVITE, UPDATE, INFO and CANCEL: requests that only make sense inside a call that is set up or being set up. A BYE answered with 481 usually means the call is already gone on the far side. That is harmless for that call, but a sign the two ends disagree about call state.
Example response
SIP/2.0 481 Call/Transaction Does Not Exist
Via: SIP/2.0/UDP 198.51.100.24:5060;branch=z9hG4bK-481-r6
From: <sip:+[email protected]>;tag=7a90
To: <sip:+[email protected]>;tag=dl-5c
Call-ID: [email protected]
CSeq: 104 BYE
Content-Length: 0Common causes of SIP 481
- The far end already ended the call, so a BYE from your side finds nothing to end.
- A server in a cluster failed over, and the node that took over has no copy of the dialog.
- An SBC or ALG changed the From tag, the To tag or the Call-ID, so in-dialog requests no longer match.
- A CANCEL arrived after the INVITE transaction had already completed.
- A session refresh or re-INVITE was sent after the other side had silently dropped the call.
How to fix SIP 481
- Compare the Call-ID and both tags in the failing request with the ones in the original INVITE and its 200.
- Check whether the call moved between cluster nodes, and whether those nodes share dialog state.
- Look for a missing BYE in the other direction; one side may have ended the call without telling the other.
- Use session timers so both ends notice a dead call within a known time.
SIP 481 as an answer to OPTIONS
A 481 to OPTIONS is unusual, because an OPTIONS sent outside a call has no dialog to match. It usually means the server treated the probe as part of a call, for example a request that carries a To tag. It still proves the server is up, and a PingVo Route counts it as reachable by default.
Questions about SIP 481
Is a 481 to BYE a problem?
Not for that call, which was already over on the far side. If it happens often, find out why the two ends disagree about when calls end.
Why do re-INVITEs get 481 after a failover?
The node now handling the call doesn't know the dialog. Unless the cluster replicates dialog state, calls in progress can't be changed after a failover.