I’m running a self hosted 3CX v20 instance with a Twilio SIP trunk for my HVAC business, and I’ve run into a behavior that I believe is a meaningful gap in 3CX’s call handling.
The issue
When the concurrent call license limit is reached, 3CX answers the incoming call and plays a recording stating that the license is full. From a customer experience perspective, this is unacceptable for a business grade phone system. A customer calling for service should never hear an internal licensing error. They should either be connected to a live person or routed to an overflow destination of our choosing, without ever knowing that anything went wrong on our end.
Why this matters
Most professional PBX platforms (Asterisk, FreeSWITCH, FreePBX, Cisco UCM, and others) handle capacity limits by returning a proper SIP failure response, typically 486 Busy Here or 503 Service Unavailable, to the upstream trunk provider. This is the industry standard behavior. It allows the SIP provider to apply standard overflow logic, such as Twilio’s Dial verb action attribute, to gracefully reroute calls to a backup destination (an answering service, a secondary trunk, a different DID) without the customer ever being exposed to the failure.
Because 3CX answers the call and plays audio instead of returning a SIP failure code, there is no clean signal for upstream providers to detect the overflow condition. This forces customers to build complicated proactive call counting solutions (querying active call counts via API before routing, maintaining external state, etc.) just to work around what should be a standard SIP behavior.
The ask
1. When the concurrent call license limit is reached, please have 3CX respond to incoming INVITEs with a SIP 486 Busy Here or 503 Service Unavailable, instead of answering the call.
2. If a full code change is not feasible in the short term, please provide a documented configuration option or supported workaround to enable this behavior.
3. In the meantime, any guidance on how existing customers should handle license overflow gracefully would be appreciated.
Reproduction
I have a working test setup (3CX v20 self hosted with a Twilio SIP trunk) and would be happy to provide reproduction details to the engineering team if helpful.
Thanks for considering this. I think it’s a small change on the 3CX side that would meaningfully improve the customer experience for everyone running production deployments.
The issue
When the concurrent call license limit is reached, 3CX answers the incoming call and plays a recording stating that the license is full. From a customer experience perspective, this is unacceptable for a business grade phone system. A customer calling for service should never hear an internal licensing error. They should either be connected to a live person or routed to an overflow destination of our choosing, without ever knowing that anything went wrong on our end.
Why this matters
Most professional PBX platforms (Asterisk, FreeSWITCH, FreePBX, Cisco UCM, and others) handle capacity limits by returning a proper SIP failure response, typically 486 Busy Here or 503 Service Unavailable, to the upstream trunk provider. This is the industry standard behavior. It allows the SIP provider to apply standard overflow logic, such as Twilio’s Dial verb action attribute, to gracefully reroute calls to a backup destination (an answering service, a secondary trunk, a different DID) without the customer ever being exposed to the failure.
Because 3CX answers the call and plays audio instead of returning a SIP failure code, there is no clean signal for upstream providers to detect the overflow condition. This forces customers to build complicated proactive call counting solutions (querying active call counts via API before routing, maintaining external state, etc.) just to work around what should be a standard SIP behavior.
The ask
1. When the concurrent call license limit is reached, please have 3CX respond to incoming INVITEs with a SIP 486 Busy Here or 503 Service Unavailable, instead of answering the call.
2. If a full code change is not feasible in the short term, please provide a documented configuration option or supported workaround to enable this behavior.
3. In the meantime, any guidance on how existing customers should handle license overflow gracefully would be appreciated.
Reproduction
I have a working test setup (3CX v20 self hosted with a Twilio SIP trunk) and would be happy to provide reproduction details to the engineering team if helpful.
Thanks for considering this. I think it’s a small change on the 3CX side that would meaningfully improve the customer experience for everyone running production deployments.
