Could someone explain why our secondary BYOC trunks in the Singapore region are consistently returning a SIP 488 Answering Media Not Acceptable error during high-volume failover events? We manage 15 BYOC trunks across APAC, and while the primary carriers handle traffic without issue, the secondary carriers (configured for redundancy) reject the INVITEs immediately when the primary path is saturated.
The environment consists of Genesys Cloud Architect v2.1 flows routing outbound traffic via specific trunk groups. The SBCs are running firmware v4.2.1, and we recently updated the SIP codec preferences to prioritize Opus over G.711 to reduce bandwidth costs. The error occurs specifically when the failover logic triggers, suggesting a mismatch in media negotiation between the Genesys Cloud edge and the carrier SBCs.
Here is the relevant snippet from the SIP trace on the SBC side:
INVITE sip:+[email protected] SIP/2.0
Via: SIP/2.0/TLS 10.0.1.5:5060;branch=z9hG4bK-12345
Contact: sip:10.0.1.5:5060;transport=tls
Content-Type: application/sdp
…
m=audio 9 RTP/AVP 118 0 8
a=rtpmap:118 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
The carrier responds with:
SIP/2.0 488 Answering Media Not Acceptable
Content-Type: application/sdp
m=audio 9 RTP/AVP 0 8
It appears the carrier is stripping the Opus codec from the supported list during the response, but Genesys Cloud seems unable to fall back to G.711 dynamically in this specific failover scenario. We have verified that the trunk credentials and SIP registration status are healthy. The issue is isolated to the secondary trunks; primary trunks accept Opus without issue.
We are considering forcing G.711 for failover trunks, but this impacts call quality metrics significantly. Is there a specific setting in the BYOC trunk configuration or the Architect flow that controls codec negotiation fallback behavior during SIP 488 responses? Any insights into carrier-specific quirks regarding Opus support in the Singapore region would be appreciated.