SIP 481 Call/Transaction Does Not Exist: what it means and how to fix it

Short answer: SIP 481 Call/Transaction Does Not Exist means the server received a request that does not match any dialog or transaction it knows. The most common cause is one side having already ended the call while the other keeps sending messages. If calls always drop at the same minute, review the session timers and NAT.

How Monitor treats SIP 481

The reading depends on what should answer the number, which is the question 2N5 answers when it adds each circuit. These are the rules the product applies today, generated from the same function that judges every test call.

What should answer the number	Reading
A greeting or recorded message (the IVR)	Down
A test tone or echo service	Down
Other: it may ring or be answered	Down

What Monitor records for an IVR: The provider refused the call (SIP 481).

A call read as Down alerts nobody on its own: it is repeated 3 times, every 2 minutes, and only 4 failures in a row open an incident, with each call's SIP code and Q.850 cause as evidence for the carrier. At the default pace, every circuit is tested every 15 minutes.

If the carrier returns SIP 481 when 2N5's calling account registers, before any call, the test is monitoring blind: it is a problem on 2N5's side, it does not count against the circuit and it does not alert the customer.

What does SIP 481 mean in practice?

Under RFC 3261, SIP 481 Call/Transaction Does Not Exist indicates that the server received a request that does not match any existing dialog or transaction. The dialog is identified by the Call-ID and by the From and To tags. If any of these values changes along the path, or if one side has already forgotten the call, the next message gets a 481.

The RFC also says that when a request inside the dialog gets a 481, the client must end the dialog. That is why the SIP 481 error rarely keeps a call from starting. The typical effect is a call that connects, carries audio normally and drops on its own after a few minutes, or a CANCEL that arrives too late. A gateway that carries the 481 into the phone network translates it as Q.850 cause 41, temporary failure.

Common causes in Brazil

• A session timer refresh (re-INVITE or UPDATE) reaching an SBC or PBX that has already discarded the call, dropping it at the same minute every time.
• A NAT mapping on the router that expires during the call, so later messages arrive at a different destination.
• The router’s SIP ALG rewriting tags or the Call-ID.
• A restart or node switch on the carrier’s SBC or on the PBX (Asterisk, Issabel, FreePBX, 3CX) in the middle of active calls.
• A CANCEL sent after the call had already been answered or ended on the other side.
• A BYE sent by both sides at almost the same moment.

How to diagnose it

1. Capture with sngrep port 5060 and find the message that got the 481: BYE, CANCEL, re-INVITE, UPDATE or INFO.
2. Compare that message’s Call-ID and From and To tags with those of the original INVITE. If they changed, some device along the path is rewriting the SIP.
3. On Asterisk or FreePBX, turn on pjsip set logger on (or sip set debug on with chan_sip) and check the negotiated Session-Expires and Min-SE headers.
4. Measure how long the dropped calls last. If it is always close to half of Session-Expires, the problem lies in the session refresh.
5. Review the UDP timeout on the firewall and disable the router’s SIP ALG.
6. On 3CX, enable “Verbose logging” and check whether the trunk received the 481 from the carrier or whether 3CX sent it.

What to send the carrier

• Date and time, with the time zone, of when the calls started and when they dropped.
• Calling number (A) and called number (B).
• The Call-ID of the call and the message that got the 481.
• The full response line and the negotiated Session-Expires value.
• How many calls dropped and whether the duration repeats.
• The pcap of the whole call, from the INVITE to the drop.

Frequently asked questions

Why do my calls always drop after the same amount of time?

A common pattern is the session timer (RFC 4028). Each side refreshes the session with a re-INVITE or UPDATE at the agreed interval. If that refresh gets a 481 or no response, RFC 3261 says the dialog must be ended, and the call drops. When this always happens at the same minute, check the negotiated Session-Expires.

Is getting a 481 on a BYE serious?

Usually not. If the other side had already ended the call and your BYE arrives afterward, the 481 just confirms there is nothing left to end. The problem is a 481 on messages inside a call that should still be active, such as re-INVITE, UPDATE or INFO, because that drops the call midway.