Outbound calls fail with SIP 486 Busy on 1st attempt, but immediate 2nd attempt works perfectly (TelTel Trunk)

WAFI

Customer
Joined
Oct 22, 2026
Messages
1
Reaction score
0
Hello community,
I am facing a very specific and frustrating issue with outbound calls on our 3CX PBX system (Hosted Instance, Version 20). Hopefully, some experts here can shed some light on this behavior.
The Issue:
Every single time a user makes the first outbound call to an international number, the call fails instantly on the 3CX Web Client or mobile app and displays a SIP 486 Busy Here error. If the user hangs up and immediately redials the exact same number, the second attempt works flawlessly.
The Environment Details:
  • 3CX Deployment: Hosted in Cloud (Instance IP: 104.***.***.237)
  • SIP Trunk Provider: TelTel (7******6.sip.teltel.io)
  • End-points: Occurs on both 3CX Web Client (Google Chrome via WebRTC) and 3CX iOS App.
  • Trunk Registration Status: The trunk shows a stable, active Registered (Green Status) immediately before the call, and does NOT drop or go red after the failure.
Here is the excerpt from our 3CX Activity Log on the first failed attempt:
"Call or Registration to 0097150****960 has failed. sip:104.***.1**.248:5060;lr replied: Busy Here (486)"
Troubleshooting already performed on our end:
  1. Verified the issue happens on multiple distinct extensions.
  2. Switched between "Register/Account based" and "IP based" authentication to rule out registration lag.
  3. Toggled "Support Re-Invite" and "Support Replaces" under the trunk options.
  4. Reduced the Re-Register Timeout to 60 seconds.
  5. Enabled "PBX Delivers Audio" in the SIP Trunk properties.
  6. Disabled "Video Calls" on the extensions to prevent any video codec payload negotiation on the initial INVITE.
It looks like either 3CX is sending a faulty initial INVITE packet header that triggers the provider’s firewall (1**.***.***.248) to immediately reply with a 486, or the provider's SBC is rejecting rapid consecutive packet generation.
Has anyone faced this behavior with TelTel or a generic provider before? Are there specific Outbound Parameter Mappings or custom headers I should tweak in 3CX to fix this initial handshake?
Thank you in advance for your expert support!


 
Hello,

Have you reached out to your Trunk provider (TelTel) to see what they advise? Providing them with a packet capture and the results of our Trunk testing function should help.
 

Forum statistics

Threads
112,314
Messages
591,847
Members
165,458
Latest member
Kayla Norris