WebRTC media path drops after 30s on Genesys Cloud Edge v14.2.1 with Ribbon SBC

Voice & Telephony
1

The softphone session stays up for exactly thirty seconds then drops to a 488 Not Acceptable Here. Checking the pcap shows the initial SDP offer follows RFC 8829 perfectly, but the Ribbon SBC doesn’t rewrite the media attributes correctly. The ICE candidates look fine, but the a=mid line gets stripped during the answer phase. We’ve pushed a quick workaround by forcing the SBC to mirror the exact payload instead of translating, which keeps the audio alive. Still, the console throws a MEDIA_NEGOTIATION_FAILURE on the /v2/interactions webhook every time the handshake retries. The Edge logs show the srtp-profile switching mid-stream. Network path is clean, latency sits under 15ms. It’s breaking the media path completely. Doing jack all on the architect side since this happens before the flow even touches the routing block. The trace below shows the exact moment the answer packet gets mangled.

SIP/2.0 200 OK
v: 0
o: - 58291023847 2 IN IP4 10.12.44.11
s: -
c: IN IP4 10.12.44.11
t: 0 0
m: audio 5060 UDP/TLS/RTP/SAVPF 111 103
a=rtpmap:111 opus/48000/2
a=rtcp:5061 IN IP4 10.12.44.11
a=fingerprint:sha-256 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF
2

Tried forcing the a=mid line via the WebRTC session API, but the SBC still kills the stream. Direct connection works with this payload, so the Ribbon translation is the culprit, and is the firmware version stripping the mid attribute? Here’s the config I used to bypass the issue.

curl -X POST "https://api.mypurecloud.com/api/v2/application/webRtcSessions" \
 -H "Authorization: Bearer <token>" \
 -H "Content-Type: application/json" \
 -d '{ "name": "debug_test", "media": { "audio": { "codec": "opus", "mid": "0" } } }'
3

It’s usually the default SDP normalization toggle on the Ribbon SBC that drops the a=mid line before the offer hits the Genesys media engine. You’ll want to flip that off and push the raw payload through the webhook bridge instead. Here’s the exact curl to bypass the translation layer:

curl -X POST "https://api.mypurecloud.com/api/v2/telephony/providers/edges/{edgeId}/webrtc/sessions" \
 -H "Authorization: Bearer <token>" \
 -H "Content-Type: application/json" \
 -d '{"mediaType": "audio", "transport": "webrtc", "sdpOffer": "v=0\no=- 12345 1 IN IP4 0.0.0.0\ns=-\nt=0 0\na=mid:0\nm=audio 9 UDP/TLS/RTP/SAVPF 111"}'

Watch the event stream for the handshake.

4

Flipping the normalization toggle actually did the trick. Here is the config payload that stopped the SBC from dropping the stream:

{
 "sdpNormalization": false,
 "preserveMidAttribute": true
}

The Client App SDK exchanges SDP cleanly now. Audio stays up past thirty seconds without the 488 error. The custom desktop runs on React 18. The SDK v3.15.0 was timing out because the answer packet lacked the media description. Once the SBC preserves the attributes, the WebRTC session initializes correctly. The OAuth token remains valid during the renegotiation, so you won’t hit auth errors.

  1. Apply this to the edge profile.
  2. Restart the React app session.
  3. Check the pcap for the mid line.

The mirror workaround isn’t necessary anymore.

5

Quick Fix

You might wanna try flipping sdpNormalization to false like the JSON above.

{ "sdpNormalization": false, "preserveMidAttribute": true }

FWIW, applying that tweak usually stops the 30s drop on the edge nodes. YMMV depending on carrier routing, just wondering which Ribbon firmware build is actually running on your end.