What’s the correct approach for handling WebRTC media renegotiation when a BYOC trunk flips? Architect v2024.3.1 routes the inbound flow through a transfer node, and the Ohio failover path doesn’t play nice with the softphone stream. SIP registration stays green, but the moment the secondary carrier swaps in, the DTLS handshake tanks. Console logs dump a MEDIA_TRACK_REJECTED: 408 right after the proxy pushes the updated SDP. The WebRTC SDK v2.4.1 client sits there waiting, but the GET /api/v2/telephony/providers/edge/connections/{connectionId}/webrtc endpoint just returns stale ice settings. Peak Eastern hours hammer the proxy and latency spikes to 450ms. The candidate gathering phase just hangs. It’s doing jack all to recover the stream. Can’t really blame the browser when the ice settings go stale. You’d think tweaking the iceTransportPolicy to relay would fix it, but that just kills the outbound leg entirely. The carrier’s SIP proxy definitely sends a re-INVITE, yet the softphone UI never refreshes the active session state. Mic stays hot, audio drops hard. Logs show the media server rejecting the new fingerprint before the handshake completes.
The 408 isn’t a BYOC issue, it’s your client dropping the ICE candidates before the SDP answer arrives. Check the PureCloudPlatformClientV2 logs for ice-gathering-state changes and ensure you’re not disposing the MediaStream prematurely.