But caching the ephermal key is risky. No? And if the code works fine on Safari without caching then it should work on Chrome too. It was actually working for last few months. It just started too have problem last week.
works for me.
It seems that Iâm using the old (currently wrong) way.
The Ephemeral token method is the OpenAI secure method so that is the fix that we can implement as customers - to move to the local server process that trades out the API key for a token etc⌠That is the best practice for security etc.
I know from using some âUndocumentedâ API end points related to costs that many of us used before the official end point was released that OpenAI has code that only will accept the ephemeral token for Auth to workâŚ
My thought is the realtime API endpoint has some nodes in the âRotationâ or load balancing that have that code on them or the staged changes to require tokens is getting released in error.
The point is â IMO it is not a websocket issue we control â it is Auth and it is code related within OpenAI and relates to how they are managing the security.
The Ephemeral tokens work 100% on 100% of browsers if I understand correctly â its the Client side API keys in the clear that get rejected in the headers â need to wait for them to run to run it down⌠or move to these ephemeral tokens.
I
.
1 Like
Thats the problem. Sometimes it works and sometime it does not.
I canât access the video anymore, but I understand now that you were trying to show me that in some browsers / client environments, the browser is not able to establish a socket connection with our servers at all, versus receiving an error upon connecting.
Given that there are no currently detectable backend problems with Realtime, and many people on our side (myself included) are not able to reproduce these connection problems (tried on multiple computers and my mobile hotspot), there is likely to be some kind of OS or network issue at play that is creating this behavior, or possibly some kind of infrastructure level filtering. Can you:
1.) validate the certificate chain - does:
openssl s_client -connect api.openai.com:443
give any errors, etc
2.) see if you can expose more details on the handshake - like what do you see with:
npm install -g wscat
wscat -c wss://api.openai.com/v1/realtime
I donât know if this is possible in BrowserStack, I will explore better debugging options there.
1 Like
Would you like to do a screen share session and I can show you this not working and share any log with you in realtime?
Here are answers (output) to your questions:
1. validate the certificate chain
CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R4
verify return:1
depth=1 C = US, O = Google Trust Services, CN = WE1
verify return:1
depth=0 CN = api.openai.com
verify return:1
Certificate chain
0 s:CN = api.openai.com
i:C = US, O = Google Trust Services, CN = WE1
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256
v:NotBefore: Nov 24 22:52:24 2024 GMT; NotAfter: Feb 22 23:52:20 2025 GMT
1 s:C = US, O = Google Trust Services, CN = WE1
i:C = US, O = Google Trust Services LLC, CN = GTS Root R4
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R4
i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256
v:NotBefore: Nov 15 03:43:21 2023 GMT; NotAfter: Jan 28 00:00:42 2028 GMT
subject=CN = api.openai.com
issuer=C = US, O = Google Trust Services, CN = WE1
Acceptable client certificate CA names
C = US, ST = California, L = San Francisco, O = âCloudflare, Inc.â, OU = www.cloudflare.com, CN = Managed CA 5574435b22d1ce4b99e50f19d77e1914
C = US, ST = California, L = San Francisco, O = âCloudflare, Inc.â, OU = www.cloudflare.com, CN = Anchor CA 5574435b22d1ce4b99e50f19d77e1914
Requested Signature Algorithms: ECDSA+SHA256:RSA-PSS+SHA256:RSA+SHA256:ECDSA+SHA384:RSA-PSS+SHA384:RSA+SHA384:RSA-PSS+SHA512:RSA+SHA512:RSA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA256:RSA-PSS+SHA256:RSA+SHA256:ECDSA+SHA384:RSA-PSS+SHA384:RSA+SHA384:RSA-PSS+SHA512:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
SSL handshake has read 3216 bytes and written 430 bytes
Verification: OK
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
Start Time: 1737348863
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 14336
Start Time: 1737348863
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 14336
2. With the wscat
Connected (press CTRL+C to quit)
< {âtypeâ:âerrorâ,âevent_idâ:âevent_AreDj2i7NBz5PWfqwewOGâ,âerrorâ:{âtypeâ:âinvalid_request_errorâ,âcodeâ:null,âmessageâ:âMissing bearer or basic authentication in headerâ,âparamâ:null,âevent_idâ:null}}
Disconnected (code: 3000, reason: âinvalid_request_errorâ)
Can you please check that your server (OpenAI or any proxy in between) accepts the same Sec-WebSocket-Protocol the client is requesting. Chrome will drop the connection if the protocol doesnât match. Safari can be more lenient in some cases.
1 Like
We tried this and it did not work
I tried Realtime api on both Websocket( using API Key) & WebRTC( with Ephemeral token), both are not working since 18th Jan. Till 17th Jan, it was working flawlessly. I tried on Chrome, Firefox, Safari. Still the issue exist. When using WebRTC, the first text response is coming but the audio is getting stopped abruptly after 1-2 sec. After that Realtime apis are not connecting at all.
1 Like
What about WebSocket? Did you try? Here is how Websocket behavior for us:
- Works fine on Safari on iPhone and MacBook
- Works fine on Chrome on iPhone
- Does NOT work on Chrome on MacBook/Windows Desktop.
It used to work fine till last week.
Yes, I have tried websocket on safari as well. Same issue. I have implemented functions with it and its still failing. As I mentioned, it was working until last week.
/node_modules/@openai/realtime-api-beta/lib/api.js:191
throw new Error(RealtimeAPI is not connected);
^
Error: RealtimeAPI is not connected
at RealtimeAPI.send (/node_modules/@openai/realtime-api-beta/lib/api.js:191:13)
at callTool (node_modules/@openai/realtime-api-beta/lib/client.js:307:23)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
Node.js v20.12.1
1 Like
I dont know if there is anyone designated at OpenAI to look into it. Every email that I get from Customer Support is from a new person and they ask the same question repeatedly. The WSCAT command is like Turn off your Router, wait 10 second, and restart. That has been done by me 100 times at least in the last 5 days. I have spent entire day today watching this thread with ZERO progress.
Since Realtime is still in beta, may be issue with it is not on OpenAI priority.
The problem is fragmented response from OpenAI. Nearly half a dozen employees with similar questions and no progress
1 Like
We are facing same issue, webRTC might work fine
The problem is when you try to connect to the sockets URL from the browser. wscat runs from node env and thus works without problems.
This is really a problem in Chrome/Firefox browsers. It works in Safari from the same device without any problem.
I am available for any kind of cooperation on this, screensharing, can give you access to our BrowserStack that has the problem as well.
As you can see, there are other people complaining about this, so there must be a new problem introduced on Thursday. Then it was somehow âfixedâ on Friday, but since the weekend, it doesnât work again.
1 Like
OK, because I am working on a prototype, I can use workarounds now. I found this ready made relay server by Cloudflare: GitHub - cloudflare/openai-workers-relay: A relay server for OpenAI's realtime API, for Cloudflare Workers
I deployed it to Cloudflare workers (free version works fine for me), implemented some simple auth so only I can connect and nobody else and it works for me this way now when I connect my client through this relay server.
But anyway the original issue is still there and it seems like a lot of people have problems with it, so OpenAI should really investigate this.
EDIT:
Also, please refer to this thread on Github: Websocket Connection Failing on Chrome with error (Error : Could not connect to "wss://api.openai.com/v1/realtime). ¡ Issue #513 ¡ openai/openai-realtime-console ¡ GitHub
A lot of people are struggling with this, so this is really not a network-related problem on our side.
1 Like
I am available for any kind of screenshare/access to app to debug too. I think by this time, the first step for OpenAI is to admit that there is a problem and users are not hallucinating.
2 Likes
If you have a few minutes â respectfully suggest pulling this code and experimenting with it so we have a baseline to understand a known good stack etc. Takes minimal time effort to load and test with it.
This runs 100% of the time for me â Does this code run for you? It uses the ephemeral tokens.
Several things did not work with this code earlier. For example disabling VAD for push to talk did not work. Also there were issues with Safari. The worst part is that WebRTC for OpenAI lacks support for capturing audio of what the user says and the response. Implementing such voice capture with workaround creates its own set of issues and totally unreliable.
In any case Websocket beaded realtime has a problem and it needs to be fixed.