[v20 Update 8 Build 1121] Intermittent inbound call drops before answer — duplicate INVITE/CANCEL internally — 481 Call/Transaction Does Not Exist

[AshishKushwaha]

Hi everyone,


We are experiencing an intermittent issue where inbound calls drop before the agent can answer. The agent is logged in, available, and answering other calls without any problem — but on some calls the phone rings and then drops by itself before the agent can pick up. Reports show "ended by caller" but our Wireshark capture proves otherwise.


System Info:

• 3CX Version: v20 Update 8 Build 1121
• Deployment: Self-hosted Linux
• Server: Meets 3CX specifications
• Firewall check: Passing

What we have already ruled out:

• Multiple device registrations — single active SIP session confirmed per agent
• Server hardware — migrated to larger server, issue persisted
• 3CX configuration — performed two full reinstalls, one with backup and one completely clean from scratch
• Queue wrap-up time — not enabled
• Accept multiple calls — unchecked on all extensions
• Call forwarding — no immediate forwarding rules configured

What Wireshark shows:

Provider → 3CX INVITE SDP (g711A g711U g729 iLBC g722 speex)
3CX → Provider 100 Trying
3CX → Provider 180 Ringing
3CX → Agent INVITE ← first INVITE sent to agent
Agent → 3CX 180 Ringing ← agent phone is ringing ✓
3CX → Agent CANCEL ← 3CX cancels its own INVITE after only 0.13 seconds
3CX → Agent INVITE SDP (g711U g711A g722 g729 opus) ← immediate re-INVITE with OPUS added
Agent → 3CX 200 OK
Agent → 3CX 487 Request Terminated
Agent → 3CX 180 Ringing ← still ringing on second INVITE
3CX → Agent CANCEL ← 3CX cancels second INVITE too
Provider → 3CX 200 OK
Agent → 3CX 481 Call/Transaction Does Not Exist ← transaction table broken
3CX → Agent BYE
3CX → Provider BYE ← call ends

Key observations:

1. The CANCEL fires only 0.13 seconds after receiving 180 Ringing — this is too fast for any timeout or queue rule. It is an internal 3CX processing event.
2. The second INVITE has a different codec order and adds OPUS which was not in the original provider INVITE — possible SDP renegotiation triggering the re-fork.
3. All of this is happening on loopback 127.0.0.1 — entirely inside 3CX, nothing from the provider or agent side is causing it.
4. The 481 confirms 3CX internal SIP transaction table is out of sync after the duplicate CANCEL and cannot recover.

Questions:

1. Has anyone seen 3CX internally cancelling its own INVITE within milliseconds of receiving 180 Ringing on the agent leg?
2. Could the codec renegotiation between the first and second INVITE be causing 3CX to cancel and re-fork the agent leg?
3. Is there a way to force a fixed codec list to prevent this SDP mismatch on the internal leg?
4. Any known workaround for Build 1121 while waiting for a stable fix?

 

[KyriacosS_3CX]

Hello,

OF course the community might recognise the pattern and be able to provide some insight, but this does look like an issue better addressed through a ticket by the support team.

Can you, on this thread, provide some info on the devices registered/used by the agent(s) in question?

 

[AshishKushwaha]

Hello @KyriacosS_3CX

Thank you for your response. Some users are using PWA, and some users using desktop application and mobile applications.