WebRTC Softphone Codec Negotiation Fails with G.729 on BYOC Trunks

Is it possible to force the Genesys Cloud WebRTC softphone to prefer G.729 during codec negotiation when routing through specific BYOC trunks? We are managing 15 BYOC trunks across APAC and EMEA regions, and while our carrier infrastructure supports G.729 for bandwidth optimization, the softphone client appears to default to Opus or PCMU exclusively during the SIP INVITE handshake.

The issue manifests as a SIP 488 Not Acceptable Here response from the carrier gateway when the softphone initiates outbound calls via Architect flows configured for these specific trunk groups. The carrier logs indicate that the SDP offer contains only wideband codecs, which the legacy PSTN gateway rejects, causing immediate call failure. This behavior is inconsistent with our SIP trunks using standard TCP transport, which correctly negotiate G.729 when configured in the trunk settings.

We have verified that the trunk configuration in Genesys Cloud explicitly enables G.729 and sets it as the preferred codec. The SIP registration state remains stable, and inbound calls to the same trunks work correctly, suggesting the issue is isolated to the outbound media path from the WebRTC client. The environment is running the latest Genesys Cloud release in the Asia/Singapore edge, and we are testing with Chrome 120+ on Windows 11 endpoints.

Has anyone encountered similar codec negotiation mismatches between the WebRTC softphone and BYOC trunks? We are considering implementing a workaround using Architect flow transformations to inject custom SDP attributes, but this seems overly complex for a standard codec preference issue. Any insights into how the WebRTC client handles codec priorities relative to trunk configurations would be appreciated.