We are currently deploying a new AppFoundry integration that requires real-time call control signaling via a Bring Your Own Carrier (BYOC) trunk. While our OAuth and multi-tenant architecture are functioning correctly, we are encountering a persistent media negotiation failure during the initial SIP INVITE handshake. The Genesys Cloud environment returns a 488 Not Supported by Remote User response when attempting to establish the media path with our upstream carrier.
Our environment is configured as follows:
- Genesys Cloud Region: us-east-1
- BYOC Trunk Configuration: Standard SIP trunk with TLS 1.2
- Codec Preference: G.711u (PCMU) set as primary, G.729 as fallback
- SDK Version: Genesys Cloud Java SDK 10.2.4
We have verified that the carrier supports G.711u and that the SIP signaling path is intact. The 488 error suggests a codec mismatch, yet G.711 is the most basic standard and should be universally supported. We have checked the Architect flow for any conflicting media settings, but the issue appears to occur before any Architect logic is invoked, during the initial SIP session setup.
Has anyone encountered this specific 488 error in a BYOC context despite having standard codec configurations? We are considering enabling G.722 to see if the issue is isolated to G.711, but we want to understand if there is a known issue with how Genesys Cloud handles codec negotiation for new BYOC trunks in the us-east-1 region. Any insights into debugging the SIP offer/answer exchange would be greatly appreciated.
Since we are building this integration from the AppFoundry partner perspective, the issue likely stems from how the media negotiation is handled at the edge rather than within our OAuth or multi-tenant logic. The 488 Not Supported error during the INVITE handshake typically indicates a codec mismatch or an unsupported SDP attribute.
Given that your upstream carrier is using G.711, you must ensure that Genesys Cloud is explicitly configured to accept PCMU or PCMA in the SDP answer. However, the “Remote User” part of the error suggests the carrier is rejecting the offer.
First, verify that your BYOC trunk configuration in Genesys Cloud has “G.711” enabled and set as a preferred codec. Second, check if your carrier requires specific SIP headers or SDP attributes that Genesys might be stripping. We have seen issues where carriers reject INVITEs if the SDP lacks specific connection information or if the payload types do not align exactly with their expectations.
You can use the Genesys Cloud API to retrieve the detailed call logs for the failed session. Look for the SDP offer and response in the call-log endpoint. Specifically, inspect the m=audio line to confirm the payload type matches what the carrier expects.
If the codec list is correct, try disabling any optional codecs in the Genesys Cloud trunk settings to force a strict G.711 negotiation. This eliminates ambiguity in the SDP exchange. Additionally, ensure that your carrier allows the IP addresses of the Genesys Cloud SIP trunks in their firewall rules, as some providers interpret connection refusals as 488 errors.
From our experience with similar integrations, tightening the codec preferences and ensuring the SDP payload types are strictly aligned with the carrier’s documented requirements usually resolves this. If the issue persists, capturing a full SIP trace on both ends will help identify if the problem is in the offer or the answer phase.
Hey! I am not a SIP expert, but I have been running load tests on BYOC edges recently and noticed something similar when pushing high concurrent call volumes. The 488 error might not just be a codec mismatch.
In my JMeter scripts, when I simulate thousands of WebSocket connections or SIP invites rapidly, I sometimes see transient 488s if the edge is overwhelmed or if the SDP negotiation times out under load. I suspect your issue might be related to connection limits or rate limiting rather than just G.711 config.
Have you checked the WebSocket connection limits on your BYOC edge? Genesys Cloud has strict limits on concurrent signaling connections. If you are hammering the INVITE endpoint, you might be hitting a soft limit that drops the negotiation before the codec check even completes.
For my load tests, I use this JMeter configuration to keep connections alive and stagger requests:
<HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="SIP Invite Load" enabled="true">
<elementProp name="HTTPsampler.Arguments" elementType="Arguments" guiclass="HTTPArgumentsPanel" testclass="Arguments" enabled="true">
<collectionProp name="Arguments.arguments"/>
</elementProp>
<stringProp name="HTTPSampler.domain">your-byoc-edge.genesiscloud.com</stringProp>
<stringProp name="HTTPSampler.port">443</stringProp>
<stringProp name="HTTPSampler.protocol">https</stringProp>
<stringProp name="HTTPSampler.path">/api/v2/bulk/byoc/sessions</stringProp>
<stringProp name="HTTPSampler.method">POST</stringProp>
<boolProp name="HTTPSampler.follow_redirects">true</boolProp>
<boolProp name="HTTPSampler.use_keepalive">true</boolProp>
</HTTPSamplerProxy>
Try reducing your concurrent users in the test to see if the 488s disappear. If they do, you are likely hitting a capacity wall. Also, double-check that your SDP payload in the test includes a=rtpmap:0 PCMU/8000 explicitly. Sometimes the parser fails if the attributes are out of order during high load.
Hope this helps! I am still learning the SIP side, but this worked for my throughput tests.