Hey everyone, I’ve run into a really strange issue with our WebRTC softphone audio quality when routing outbound calls through specific BYOC trunks in the ap-southeast-1 region. The issue manifests as intermittent 200ms+ latency spikes and packet loss, but only when the call is bridged to a PSTN destination via the carrier failover logic. We are using the latest Genesys Cloud WebRTC SDK (v2.4.1) and have verified that the SIP registration state remains stable throughout the call lifecycle. The problem does not occur when using the desktop softphone or when routing through the Genesys Cloud native carrier. We have checked the network conditions and confirmed that the Jitter Buffer settings are at default values. The SIP trace shows no explicit error codes, but the RTCP reports indicate significant packet reordering. We have tried adjusting the codec preferences to prioritize Opus over G.711, but the issue persists. Is there a known issue with how the WebRTC client handles RTP packet sequencing when interacting with certain carrier SIP proxies in this region? We are seeing this behavior across multiple agent workstations, which suggests it is not a local network issue. Any insights into the underlying SIP negotiation or media path configuration would be appreciated. Thank you for your help.
The docs actually state that latency spikes on WebRTC softphones routed through BYOC trunks are rarely a pure network issue when SIP registration is stable. In my experience with bulk recording exports for legal discovery, I have seen similar timing discrepancies where the audio stream desynchronizes from the metadata timestamp during carrier failover events. The ap-southeast-1 region has specific routing tables that can introduce jitter if the jitter buffer is not explicitly configured in the WebRTC SDK initialization. You need to adjust the jitterBuffer settings in your SDK config to account for the additional hop to the PSTN carrier. Specifically, set maxDelay to 200 and enableAdaptiveJitterBuffer to true. This forces the softphone to buffer incoming packets more aggressively, smoothing out the 200ms+ spikes you are seeing. Additionally, check the BYOC trunk configuration in the Genesys Cloud admin portal. Ensure that the “Force Audio Codec” setting is set to G.711 ulaw, as codec negotiation failures during failover can cause packet retransmissions that manifest as latency. If you are using Opus, switch to G.711 temporarily to isolate the issue. For legal hold purposes, it is critical to capture the exact timestamp of the failover event in the call recording metadata. Use the /v2/recordings/{recordingId} endpoint to verify that the startTime and endTime fields align with the SIP dialog timestamps. If the metadata shows a gap, the chain of custody validation will fail. I recommend enabling detailed SIP tracing on the BYOC trunk for 24 hours to capture the exact moment the latency spike occurs. This data will be essential for proving that the issue is network-related and not a platform defect. Also, ensure your WebRTC SDK is configured to send regular RTCP reports, as these help the carrier adjust packet pacing.