{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibykxf7d2h3tij2em5joe2cdj3zmdjhjahmsvpki4jinxafuhjdmu",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mllei5y2ri32"
  },
  "path": "/t/firefox-realtime-api-webrtc-voice-sessions-drop-deterministically-on-the-users-second-speech-turn/1380257#post_7",
  "publishedAt": "2026-05-11T13:16:04.000Z",
  "site": "https://community.openai.com",
  "textContent": "Hi Prashant,\n\nI 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.\n\n  * **Failing model ID:** `gpt-realtime-2`\n\n  * **Failure timestamp:** `2026-05-11T12:56:38.554+02:00` (CEST, Warsaw)\n\n  * **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.\n\n  * **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.\n\n\n\n\nSo the bug is consistent across both gpt-realtime-1.5 and gpt-realtime-2. We’re steering users to Chrome/Edge for now.\n\nA few highlights from the dump:\n\n  * 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).\n\n  * 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.\n\n  * 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.\n\n\n\n\nBest,\nOmer",
  "title": "Firefox + Realtime API (WebRTC): voice sessions drop deterministically on the user's second speech turn"
}