{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreieakmpfwhfb4bmxxyck37z33iyslr2ocjl5iwbpu3qdwarcmfy5tm",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mmwufd3o5z42"
  },
  "path": "/t/realtime-voice-behaviour-not-working-properly-on-mozilla-firefox/1381403#post_4",
  "publishedAt": "2026-05-28T19:55:06.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "@ingsplazas",
    "@Vultieris."
  ],
  "textContent": "Thanks for posting this @ingsplazas, and appreciate the reference thread too. A few people seem to be hitting the same Firefox-specific behavior after the first voice turn.\n\nAlso good catch from @Vultieris. Firefox tends to be stricter around ICE/WebRTC handling than Chrome, so adding explicit ICE servers is worth trying:\n\n\n    const pc = new RTCPeerConnection({\n      iceServers: [\n        { urls: \"stun:stun.l.google.com:19302\" }\n      ]\n    });\n\n\nFor production, a TURN server is probably the safer move since some Firefox/network combinations won’t maintain the media path reliably with STUN alone.\n\nThe fact that:\n\n  * session initializes correctly\n  * first response works\n  * then audio dies\n  * followed by `ICE failed`\n\n\n\n…really points to the WebRTC connection collapsing rather than an issue with ephemeral tokens or the Realtime session itself.\n\nAlso curious which Firefox version you’re on, because this seems to be fixed in Firefox 151.0 from what a few folks are reporting.\n\nChecking `about:webrtc` in Firefox can also help confirm whether candidates are failing or relay fallback never happens.\n\n-Mark G.",
  "title": "Realtime voice behaviour not working properly on Mozilla firefox"
}