Stuck on a weird SIP 488 Incompatible Media error when scaling up our outbound dialer simulation.
Running JMeter 5.6.2 with the SIP JS plugin from our Singapore staging environment. The goal is to validate the media path capacity for a campaign expecting 1,000 concurrent outbound calls. We are using the Genesys Cloud WebRTC SDK v3.2.1 for the signaling, but forcing the media to go over standard SIP/RTP via our custom SIP UA implementation to test legacy trunk compatibility.
The setup works fine up to 50 concurrent threads. Once we push to 100 threads, about 60% of the calls fail immediately with SIP/2.0 488 Incompatible Media. The SDP offer from our JMeter client includes audio/PCMU and audio/PCMA, which should be standard. The Genesys edge seems to be rejecting the offer before it even reaches the Architect flow.
Here is the relevant snippet from the SIP trace:
INVITE sip:[email protected] SIP/2.0
Content-Type: application/sdp
v=0
o=jmeter 12345 1 IN IP4 10.0.0.5
s=-
c=IN IP4 10.0.0.5
m=audio 9000 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
The error returns within 200ms, suggesting it’s a negotiation issue at the edge level, not a timeout or queue delay. We checked the Genesys Media Settings Documentation and confirmed that both codecs are enabled in the instance settings.
Could this be related to how the JMeter SIP plugin handles the SDP payload formatting? Or is there a hidden rate limit on SDP parsing for non-WebRTC connections? We are using the us-east-1 region for the Genesys instance. Any insights on debugging SDP mismatches in high-concurrency scenarios would be appreciated. We are not seeing any 429s, just these hard 488s.
Have you tried aligning your SIP UA codec negotiation with the specific media region settings in Genesys Cloud? This often happens when the legacy trunk expects a different payload type than what the WebRTC SDK initiates. In Zendesk, the media handling was more opaque, but Genesys Cloud requires explicit codec matching in the SIP trunk configuration.
Check if your JMeter test is offering G.711 ulaw while the GC edge is prioritizing Opus. You might need to force the codec order in your SIP INVITE headers. A quick fix is to add a Supported: codec-negotiation header and ensure the SDP answer matches the trunk’s allowed codecs.
This mirrors the strictness we saw migrating from Zendesk Talk, where default codecs caused similar handshake failures. See KB-9921: “SIP Trunk Codec Mismatch Resolution” for the exact configuration steps. It usually resolves the 488 error immediately.
This looks like a codec negotiation mismatch between the JMeter SIP UA and the Genesys Cloud media region. The suggestion above regarding codec alignment is correct, but the implementation in JMeter often requires explicit SDP manipulation rather than just trunk configuration.
When using the SIP JS plugin with a custom UA, the default SDP offer often includes Opus or VP8, which legacy trunks or specific BYOC edges may reject if not explicitly allowed. Forcing G.711 ulaw in the SIP trunk config is step one, but step two is ensuring the JMeter client sends only that codec in the SDP payload.
In the JMeter test plan, modify the SIP Request sampler or use a BSF PreProcessor to strip unwanted codecs from the SDP body before sending the INVITE. Here is a minimal Java snippet for a BSF PreProcessor to enforce G.711 ulaw:
import org.apache.jmeter.protocol.sip.sampler.SIPRequest;
import org.apache.sdp.SdpMessage;
SIPRequest req = sampler.getRequest();
String sdp = req.getSdp();
// Replace any existing payload types with 0 (PCMU)
sdp = sdp.replaceAll("a=rtpmap:\\d+ \\w+/\\d+", "a=rtpmap:0 PCMU/8000");
req.setSdp(sdp);
Also verify the media region in the Genesys Cloud admin console. If the edge is in sydney or singapore, ensure the SIP trunk profile associated with the load test campaign has Allow Opus unchecked if testing legacy compatibility. The 488 error confirms the server received the offer but rejected the media format.
Check the raw SIP trace in JMeter. If the 183 Session Progress response contains an SDP with only Opus, your UA is not sending the correct offer. Fix the SDP generation in the test script.
Note: Ensure your JMeter thread group ramp-up time allows for proper SIP registration. Too many concurrent INVITEs without proper state management can cause the Genesys Cloud edge to drop media negotiation packets, resulting in 488 errors that look like codec issues but are actually timeout-related.