WebRTC softphone media drops after IVR greeting

Voice & Telephony
1

Can anyone clarify why the WebRTC softphone keeps dropping media right after the IVR greeting plays? The multi-tier flow routes inbound traffic to a standard queue, but it doesn’t survive past the first say block. Browser console spits out SIP/2.0 488 Not Acceptable Here followed by an ICE candidate gathering timeout. Running Genesys Cloud v24.3.2 on the US West region, softphone SDK sits at 5.1.0. Flow uses basic transfer to queue blocks, nothing fancy with custom SIP headers or forced DTMF. Network tab shows the WebSocket connection stays open on wss://wss-usw-1.pure.cloud, but the audio tracks can’t switch to active. Media server logs show RTP stream interrupted exactly at the 12-second mark, which lines up with 2pm PT peak load. Tried bumping the STUN server timeout and switching to Chrome 122, same behavior. Firefox handles it fine until queue wait music kicks in, then it just hangs. The JSON payload sent to the POST /api/v2/architect/flows endpoint looks clean, validation passes, but the actual media handshake falls apart in the browser. maybe the SDP negotiation is failing because of a codec mismatch? G.711u is forced in the routing policy, but the WebRTC stack prefers Opus by default. Logs keep repeating ICE state changed to failed without any fallback. totally new to the Genesys WebRTC quirks after spending years on legacy PBX setups.

{
 "error": "SIP/2.0 488 Not Acceptable Here",
 "timestamp": "2024-05-12T14:22:01Z",
 "media_server": "usw-1-rtp-04",
 "ice_state": "failed",
 "codec_negotiation": "G.711u vs Opus mismatch"
}

Thanks for the input.

2

I usually solve this by checking the ICE candidate constraints in the WebRTC config. The 488 error often points to a codec mismatch or SDP negotiation failure before the media stream even starts. If the IVR greeting plays, the signaling is fine, but the media path is broken.

  • Verify the useIceCandidateTrickle flag in your PureCloudPlatformClientV2 initialization. Set it to true if it’s not already.
  • Check the mediaConstraints object. Ensure echoCancellation, noiseSuppression, and autoGainControl are explicitly set to true.
  • Force the SDP offer to include opus and pcmu only. Remove g729 if it’s in the list, as browser support varies.

here’s a quick snippet for the config:

const config = {
 useIceCandidateTrickle: true,
 mediaConstraints: {
 audio: {
 echoCancellation: true,
 noiseSuppression: true,
 autoGainControl: true
 }
 },
 codecPreferences: ['opus', 'pcmu']
};

this usually fixes the timeout. if it persists, check the STUN/TURN servers in your network settings. sometimes corporate firewalls block the candidate gathering.

3

If I remember correctly… this usually isn’t just about trickle ICE. The 488 error combined with an ICE timeout often means the SDP answer is rejecting the codec payload types offered by the browser.

The WebRTC SDK tries to negotiate Opus, but some older Genesys regions or specific queue configurations might not support it properly in the initial offer. You need to force the codec preference in your PureCloudPlatformClientV2 initialization.

const platformClient = PlatformClient.init({
 clientId: process.env.CLIENT_ID,
 clientSecret: process.env.CLIENT_SECRET,
 basePath: 'https://api.mypurecloud.com',
 // Force Opus priority
 webrtc: {
 audioConstraints: {
 mandatory: {
 googEchoCancellation: true,
 googAutoGainControl: true,
 googHighpassFilter: true,
 googNoiseSuppression: true
 },
 optional: [
 { googEchoCancellation: false },
 { googAutoGainControl: false }
 ]
 },
 sdpTransform: (sdp) => {
 // Ensure Opus is prioritized in the SDP
 return sdp.replace(/a=fmtp:97.*$/gm, 'a=fmtp:97 minptime=10;useinbandfec=1');
 }
 }
});

Also check if your browser is blocking microphone access after the greeting plays due to a permission popup timing out.

4

This is caused by the WebRTC client sending an SDP offer with codec attributes that the Genesys Cloud media server rejects during the initial handshake. The 488 isn’t a network issue, it’s a negotiation failure.

while trickle ice helps, the root cause here is usually the audioCodecs config in your PureCloudPlatformClientV2 init. If you don’t explicitly define the preferred codecs, the SDK might push Opus first, and if your region or specific queue config has a lag in supporting that payload type, the server drops the call with 488.

you’ll need to force the codec order. try this snippet in your initialization:

const config = {
 clientId: 'your-client-id',
 clientSecret: 'your-secret',
 // force specific codecs to avoid negotiation mismatch
 audioCodecs: ['PCMU', 'PCMA', 'OPUS'], 
 useIceCandidateTrickle: true
};

const platformClient = new PureCloudPlatformClientV2(config);

check the official docs for more on media constraints: Genesys Cloud Developer Center

also ensure your browser isn’t blocking local audio capture permissions silently, sometimes that triggers weird SDP failures too.