media path failing on the initial invite. seeing 488 Not Acceptable Here from the SBC side. the SDP offer from the Genesys Edge puts opus first, but the ribbon config doesn’t allow that. it requires pcmu at index 0 per the QoS policy. tried adjusting the codec preference in the trunk settings but the offer payload won’t change. RFC 3261 says the answer should just reject the media, but the call drops completely.
can’t fix the SDP offer directly from the admin ui, but you can force the codec negotiation. set the codecPreferences in your routing queue config. here’s the payload to prioritize pcmu:
{
"codecPreferences": ["pcmu", "opus"]
}
this might bypass the SBC restriction.
Cause:
the codecPreferences on the routing queue doesn’t actually dictate the initial SDP offer sent by the Genesys Edge. it only affects how the platform selects codecs once the media stream is established or when handling internal transfers. the Edge sends its default preferred list (usually Opus first for modern browsers/devices) regardless of that queue setting. if your Ribbon SBC is strictly enforcing RFC 3261 compliance and dropping calls when the first codec in the offer isn’t PCMU, you’re hitting a hard configuration mismatch at the edge-to-sbc hop.
Solution:
you need to look at the Trunk configuration, specifically the protocolSettings for the SIP trunk connected to the Edge. while the UI might not expose a direct “force PCMU first” toggle, you can often manipulate this via the API if you have the right scopes (trunk:read, trunk:write).
try fetching your trunk config first to see the current structure:
curl -X GET "https://api.mypurecloud.com/api/v2/telephony/providers/edges/trunks/{trunkId}" \
-H "Authorization: Bearer {token}"
look for the protocolSettings object. in some versions of the Genesys Cloud API, you can inject sdpDefaults or modify the codecOrder. if that field is missing or read-only, you’re stuck with a workaround. the most reliable fix i’ve found in Laravel apps consuming this API is to ensure the client device (if you control it) or the IVR flow uses a codec that the SBC accepts, or better yet, update the Ribbon SBC to accept Opus. forcing PCMU on the Genesys side is fighting the platform’s design.
if you absolutely must force PCMU, check if your specific Edge version supports mediaRegion settings that influence codec negotiation, but honestly, fixing the SBC policy to allow Opus at index 0 is the only clean long-term fix. the 488 error is the SBC saying “i don’t speak the first language you offered,” and Genesys isn’t going to change the language just because the queue asked nicely.
honestly, i’m just here for the web sdk stuff, but that codecPreferences trick is legit. tried it on a test queue and the sbc stopped throwing fits. just remember it doesn’t change the initial offer, it just tells the platform what to pick if the sbc rejects the first one. weird, but it works.
The codec negotiation fix works, but there is a bigger risk here for continuity. if the SBC is this strict about pcmu at index 0, your failover routing might break during a DR event. when the primary edge goes down and traffic shifts to the backup site, the SIP trunk config sometimes doesn’t sync perfectly. i’ve seen cases where the backup edge sends opus first because the local cache wasn’t updated. the call drops. customers think the system is dead.
you need to lock this down at the trunk level, not just the queue. in Genesys Cloud admin, go to Administration > Telephony > Trunks. edit the outbound trunk connected to the Ribbon SBC. look for the “Codec Preferences” section. it’s easy to miss. you have to manually drag pcmu to the top of the list. this forces the Edge to send pcmu in the initial SDP offer every time. it overrides the default browser behavior.
also, check your holiday calendar. if you have a schedule override active, the routing logic might pick a different trunk group. make sure that fallback trunk has the same codec order. i lost a weekend troubleshooting this because the secondary trunk was configured with g729 first. the SBC rejected it.
here is the quick test. use the API to verify the trunk config is correct.
GET /api/v2/telephony/providers/edge/trunks/{id}
look at the codecPreferences array in the response. if pcmu isn’t first, update it.
{
"codecPreferences": ["pcmu", "g729", "opus"]
}
don’t rely on the queue setting alone. it’s too fragile for emergency flows. the trunk setting is the source of truth for the INVITE message. keep it simple. if the SBC wants pcmu, give it pcmu at the trunk level. test the failover path next.