Firefox + Realtime API (WebRTC): voice sessions drop deterministically on the user's second speech turn

Hi Prashant,

I re-ran the same repro page in Firefox 150 with the model swapped to gpt-realtime-2. The ICE disconnect still reproduces, same failure shape.

• Failing model ID: gpt-realtime-2

• Failure timestamp: 2026-05-11T12:56:38.554+02:00 (CEST, Warsaw)

• Pattern: Connection established at 12:55:57.665. Six user turns completed. ICE state went to disconnected at 12:56:38.554 — 13.2s after the final input_audio_buffer.speech_started (12:56:25.335), and 9.1s into the AI’s response (output_audio_buffer.started at 12:56:29.491). response.done never fired before the drop. conn-state went failed at 12:57:01.484.

• Same flow on Firefox 150, Win64. Note that the original “second user turn” framing in the Bugzilla report was the typical timing — here the connection survived several quick exchanges before dying on a substantive turn followed by a longer AI reply.

So the bug is consistent across both gpt-realtime-1.5 and gpt-realtime-2. We’re steering users to Chrome/Edge for now.

A few highlights from the dump:

• Selected nominated pair was peer-reflexive over CGNAT: 10.130.119.97:38696/UDP → 74.248.148.7:3478/UDP. Local host IP is 192.168.1.67, so the path goes through an intermediate NAT (hotel WiFi).

• Connection survived 6 successful consent refreshes, then STUN-CLIENT(consent): Timed out fired 5 times in a row, ending with Consent refresh final time out — same mechanism as the original Bugzilla report.

• Side observations from the ICE log that may or may not be relevant: (ice/ERR) duplicate priority 1853817087 candidate prflx and candidate prflx fires multiple times during pairing; and the second BUNDLE’d stream (mid:1, datachannel) shows peer has no stream matching stream transport-id=transport_1 warnings, even though the same SDP works in Chrome.

Best, Omer