WebRTC softphone drops ICE candidates during Edge survivability failover

Running Edge version 2024.3.0 on bare metal Dell R750 nodes. Network config uses dual NICs for WAN and local LAN. We just pushed the WebRTC softphone client v2.8.1 to the agent floor. Handshake works fine under normal routing. Cut the WAN link to test survivability mode. Edge flips to local media handling within three seconds. Browser console immediately starts throwing RTCIceConnectionState failures. Softphone UI stays green for a second, then goes straight to disconnected.

Checked the Edge SIP stack logs on the primary node. Media server process is active. Local RTP ports are open on UDP 10000-20000. Firewall rules haven’t changed since the last patch. Packet capture shows the traffic just vanishes. Firewall is doing jack all to block it. The ICE gathering phase pulls the local IP correctly, but the trickle ICE messages never reach the WebRTC client after the failover switch. Seems like the signaling channel drops the candidate updates once the Edge routing table rewrites itself.

BIOS settings are locked to default. Virtualization is off. Network interface bonding mode 1 works perfectly for voice traffic normally. This only happens when the survivability trigger fires. We’ve tried clearing the browser cache and forcing a hard reload. Same result. The softphone logs show the SDP offer goes out, but the answer never comes back with the updated local IP. Looks like the Edge signaling daemon isn’t flushing the old candidate list before handing off to the local media server. Queue backup gets messy fast when agents drop during a drill. Edge pairing status remains solid throughout the test.

[2024-05-12T14:22:08Z] WARN EdgeSignaling - ICE candidate trickle dropped for session abc-123-def
[2024-05-12T14:22:09Z] ERROR WebRTCStack - Failed to negotiate DTLS. Remote candidate mismatch.
[2024-05-12T14:22:11Z] INFO Survivability - Local media bridge active. WAN interface DOWN.
[2024-05-12T14:22:12Z] WARN EdgeSignaling - PeerConnection state changed to: FAILED

You’re likely hitting the strict NAT type enforcement in the default Edge WebRTC config. When the WAN link drops, the Edge tries to keep using the public STUN servers for candidate gathering, but the local LAN interface doesn’t have a valid path to them. The browser sees the connection state change to failed because it can’t reach the remote candidate. You need to force the Edge to prefer local host candidates when in survivability mode. Add preferHostCandidates: true to your rtcConfig object in the softphone initialization. This tells the client to prioritize local IP addresses over reflexive ones. It’s a simple tweak but it saves you from the whole ICE restart dance.

const config = {
 orgId: "your-org-id",
 rtcConfig: {
 iceServers: [
 { urls: ["stun:stun.pure.cloud:3478"] }
 ],
 preferHostCandidates: true // Critical for local survivability
 }
};

Also check your firewall rules on the Dell R750. If you’re using dual NICs, ensure that the local LAN interface isn’t blocked from outbound UDP traffic on ports 50000-60000. The Edge needs to send media directly to the agent’s browser on the local network. If the firewall is dropping those packets, the ICE check will fail regardless of the config. You can verify this by checking the browser console for IceCandidate events. If you see local candidates being generated but no connectivity, it’s a network layer issue. If you see no local candidates, it’s the preferHostCandidates setting. Don’t forget to restart the softphone client after applying the config change. The settings don’t hot reload.