WebRTC Softphone Connection Drops at 300 Concurrent Threads in JMeter Load Test

Voice & Telephony
1

Could someone clarify why the WebRTC softphone connections are dropping unexpectedly during our load testing phase? We are trying to validate the concurrency limits for our BYOC environment using Genesys Cloud Web Components SDK version 1.45.0. The goal is to simulate 500 concurrent agent logins and softphone sessions to check for stability before the holiday season peak. However, the system starts rejecting connections once we pass 300 threads.

Here is the sequence of events observed during the test:

  1. JMeter script initializes 300 virtual users. Each user authenticates via the API using valid credentials and retrieves the required OAuth tokens.
  2. The users connect to the WebRTC signaling server. The connection state changes to “connected” successfully for all 300 users. No errors are logged in the browser console at this stage.
  3. The script triggers the “start media” action for all users simultaneously. This is meant to simulate agents ready to receive calls.
  4. At approximately thread count 301, the WebSocket connection drops for the new users. The console shows a generic “Connection closed” event with code 1006.
  5. The existing 300 connections remain stable, but no new connections can be established. The API response for the connection request returns a 503 Service Unavailable error after a timeout of 15 seconds.

We have checked the API rate limits and confirmed we are not hitting the standard 100 requests per second limit for the authentication endpoints. The WebSocket connections seem to be the bottleneck. Is there a hard limit on concurrent WebSocket connections per tenant for WebRTC signaling? Or is this related to the BYOC edge capacity? We are using the standard US East region. Any insights on how to troubleshoot this specific 1006 close code in this context would be helpful. We need to know if we should scale our BYOC resources or if this is a platform limitation we need to work around.

2

You might want to check at the performance dashboard to isolate whether the drops correlate with signaling latency spikes.

  • Check the Queue Activity view for 503 errors during the test window.
  • Verify that WebSocket handshake times are staying under the 3-second threshold.
3

you need to adjust the jmeter thread group settings to include a ramp-up period and connection pooling, as hitting 300 concurrent threads instantly triggers rate limiting on the websocket handshake endpoints. the default sdk behavior opens a new tcp connection for every single thread if not configured correctly, which exhausts the carrier gateway’s session table before the sip registration even completes.

when managing 15 byoc trunks across different regions, i’ve seen this exact spike in 488 not acceptable here errors when the signaling load exceeds the carrier’s defined session limits per second. it’s not a platform bug, it’s a carrier-specific quirk where the sip proxy drops registrations if the interval between invites is less than 200ms.

try adding a constant throughput timer to your jmeter script. set it to 1500 requests per minute per thread group to simulate a more realistic login pattern. also, ensure you are reusing the http sampler connection by enabling keep-alive in the http request defaults. here is a sample config for the timer:

all 1500

check the analytics dashboard for the specific carrier trunk associated with your test environment. if you see a drop in registered agents correlating with the jmeter start time, it confirms the carrier is throttling. you can also enable verbose logging on the sdk to capture the exact websocket close codes. usually, a 1008 policy violation indicates the platform is rejecting the burst. spreading the load over a 30-second ramp-up usually stabilizes the connection count and allows you to reach the 500 concurrent target without triggering the failover logic prematurely.

4 
const webrtcConfig = {
 maxConcurrentSessions: 300,
 retryStrategy: 'exponential',
 backoffBase: 1000,
 maxRetries: 3
};

It depends, but generally… the suggestion above regarding JMeter ramp-up is critical, but the root cause often lies in how the WebRTC signaling handles session limits during burst traffic. The platform enforces strict concurrency caps on WebSocket handshakes to protect the media resources. When JMeter fires 300 threads instantly, the signaling server queues requests that exceed the buffer, leading to dropped connections before the audio path is established.

Adjusting the test to include a gradual ramp-up allows the session table to populate correctly. Also, verify the maxConcurrentSessions parameter in the SDK configuration. If the BYOC trunk logs show 503 errors, it confirms the gateway is throttling the registration requests. Ensure the IAM policy for your bulk export jobs does not conflict with the signaling endpoints, as permissions can sometimes bleed over in shared environments. Focus on stabilizing the handshake first, then scale the media streams.