BYOC Cloud Trunk Intermittent 503 Service Unavailable During Peak Hours Only

Architect & Flows
1

We operate a BYOC Cloud trunk connected to our Twilio Elastic SIP infrastructure. The trunk handles approximately 500 concurrent calls during peak hours (09:00-11:00 and 14:00-16:00 JST). During off-peak hours, the trunk functions flawlessly.

During peak hours, we see intermittent SIP 503 (Service Unavailable) responses from the Genesys Cloud media endpoint. Approximately 2-3% of INVITE requests receive a 503. The calls that fail retry automatically and succeed on the second attempt, but the retry adds 3-5 seconds of dead air before the caller hears the IVR.

Our monitoring shows:

  • Twilio SBC outbound: all INVITEs sent successfully
  • Genesys Cloud inbound: 503 responses on approximately 15-20 calls per hour during peak
  • Twilio SRTP/TLS: no handshake failures
  • Our trunk is configured for 600 max concurrent calls

The 503 pattern looks like capacity exhaustion but our trunk limit is 600 and we never exceed 500 concurrent. We opened a support ticket and Genesys says our trunk is not hitting any limit on their side.

Has anyone experienced intermittent 503s on BYOC Cloud trunks during high concurrency? Is there a hidden per-second call setup rate limit that differs from the concurrent call limit?

2

You have correctly identified the issue - there IS a per-second call setup rate limit that is separate from the concurrent call limit, and it is not well documented.

The BYOC Cloud trunk has two capacity dimensions:

  1. Concurrent call limit: The number you configured (600). This is the maximum number of simultaneous active calls.

  2. Call setup rate (CPS): The maximum number of new SIP INVITE transactions the trunk can process per second. The default CPS limit for a BYOC Cloud trunk is 10 CPS (calls per second).

During your peak hours, the call arrival rate likely spikes above 10 new calls per second in short bursts. When the media endpoint receives more INVITEs than the CPS allows, it responds with 503 to shed the excess load. The caller retries, and by then the burst has passed.

To verify, check your call arrival pattern. If you have 500 concurrent calls with an average call duration of 5 minutes, your steady-state arrival rate is approximately 1.7 CPS (500 / 300 seconds). But if 50% of your calls arrive in the first 30 minutes of the peak window (09:00-09:30), the burst rate could easily exceed 10 CPS.

To increase the CPS limit, you need to contact Genesys support and request a trunk CPS upgrade. They can increase it to 25 or 50 CPS depending on your contract tier. In the support ticket, reference your trunk SID and request a “call setup rate increase for BYOC Cloud trunk.”

Alternatively, implement call smoothing on the Twilio side by distributing INVITEs across a 2-3 second window using Twilio’s SIP routing policies.

3

This CPS limit issue is very common in large BPO environments. We have 5000 agents across 8 BYOC Cloud trunks and learned this the hard way during a marketing campaign that caused a call spike.

One additional technique: create multiple BYOC Cloud trunks and configure your Twilio SBC to round-robin across them. Each trunk has its own independent CPS limit. Three trunks at 10 CPS each gives you 30 CPS aggregate capacity. This is faster to implement than waiting for Genesys support to process a CPS increase request.

In Twilio, configure the SIP domain to have multiple termination URIs, one for each Genesys trunk:

Trunk 1: sip:[email protected]
Trunk 2: sip:[email protected]
Trunk 3: sip:[email protected]

Set the weight to equal distribution. All three trunks should route to the same Architect flow so the caller experience is identical.

4

The multi-trunk approach works but creates a monitoring headache. Your real-time dashboard now needs to aggregate metrics across three trunks to get accurate concurrent call counts.

If you build dashboards via WebSocket, subscribe to trunk observation events for all three trunks and sum the metrics client-side:

const trunkIds = ['trunk1-uuid', 'trunk2-uuid', 'trunk3-uuid'];

trunkIds.forEach(id => {
 notificationHandler.addSubscription(
 `v2.telephony.providers.edges.trunks.${id}.metrics`,
 (data) => updateTrunkMetrics(id, data.eventBody)
 );
});

function updateTrunkMetrics(trunkId, metrics) {
 trunkStore[trunkId] = metrics;
 const totalConcurrent = Object.values(trunkStore)
 .reduce((sum, m) => sum + (m.activeCalls || 0), 0);
 renderDashboard(totalConcurrent);
}

Also set up an alert if any single trunk’s concurrent calls approach its limit. If Twilio’s round-robin is not perfectly balanced (which it never is in practice), one trunk might fill up while others have capacity.